@FreePietje @torproject I guess I didn't understand the consequences of v2 obsolescence. I thought the network and directory would break onion v2, so that a v2 supporting client couldn't talk to a v2 server. If the network will still allow v2, i'd say that's fair enough.

@resist1984 @torproject
It can be that I'm not fully understanding it (too), because I don't know/understand all the aspects of how the tor network works.

My initial/primary reaction was that *I* think your argument was unfair.
If you're running oldstable, which soon (tm) will be oldoldstable, that's your choice but you also have to accept the consequences. But solutions exist.

Also note that the link in OP points to a post from July 2nd, 2020, so OP is a reminder not an initial announcement.

@FreePietje @torproject i know it's not an initial announcement. When I 1st heard the announcement stretch was /stable/. I found it so proposterous at the time that I was certain they wouldn't get away with that nutty schedule. The schedule has already slipped & rightfully so. If they break the network this year, it would be reckless. If this move doesn't break the network, then it's not an issue.

@FreePietje

I just logged in to the GUI & noticed your avatar. Normally I just use a terminal. I appreciate the heads up on Debian getting a new release in the next week.

I only migrate from scratch anymore (no dist-upgrade), so perhaps I'll skip buster.

@resist1984
Friday (2021-03-12) will be the start of the Hard Freeze (https://release.debian.org/testing/freeze_policy.html). It may take weeks/months for the actual release of Bullseye.

There's nothing wrong with dist-upgrade afaic and it's (much) safer to first upgrade Stretch -> Buster and then Buster -> Bullseye. You could do them in close succession.
Upgrades to the next Stable release are tested; skipping one, not, and is much more likely to break things.
I personally prefer aptitude (better resolver) to apt/apt-get.

@torproject
Can you clarify this?
Recently I learned through an issue with v3 onions, that there was a central coordination part of the Tor network.
So the primary question is:
will onion v2 sites cease to function (at all) on October 15th, 2021 (onward)?

@resist1984

@FreePietje @torproject @resist1984 yup, v2 onion will be disabled from the Tor network on October 15th.

@ggus
Holy crap!
The impact of that is FAR bigger then I thought.

Deprecation in my understanding is a 'nudge' to use a better way.
Not "it ceases to work at all".

@resist1984 I still recommend to upgrade from oldstable, but other then that, it looks like you were (far) more correct then I was.

@torproject
Assuming gus is right, you really need to work on your messaging.
If you're intimately familiar with Tor internals, 'retiring' may have been clear enough.
For normal users, not so much.

@FreePietje @resist1984 a great and positive impact to the Tor network health. Please read why we’re removing v2 onions: https://lists.torproject.org/pipermail/tor-dev/2020-June/014365.html

@ggus @FreePietje I think everyone agrees that v3 is more secure. The problem is two-fold. It's a reckless schedule. Demanding everyone migrate in 15 months grossly miscalculates many different situations. Not everyone is a gamer who can simply hit an upgrade button without side-effects.. without important tools failing. 15 months would be reasonable *iff* the network were not impacted.

@FreePietje @ggus The 2nd problem is that people know their own threat models better than you do, and they know better than you if their adversary is going to have the capability of cracking RSA1024. Users should be in control of their own security, not have a vendor impose on them.

@resist1984 @FreePietje the problem is not only your threat model, but the whole Tor network.

@ggus @resist1984
It was likely through that ML post that I learned v2 uses RSA1024 and my reaction to that was "holy crap!" as well.

I'm thoroughly convinced of the superiority and need for v3 onions.
My complaint is about the non-clear messaging to normal users.
And also the lack of messaging. Possibly through my 'nagging' they tooted about it recently. The previous one was ~9 months ago.

@FreePietje @torproject @resist1984 @ggus as a #Bullseye user, it's clear that Bullseye was designed assuming people don't use Tor. https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1934040 https://bugs.launchpad.net/ubuntu/+source/curl/+bug/1934044 https://bugs.launchpad.net/ubuntu/+source/fetchmail/+bug/1934155

@ggus @resist1984 @torproject @FreePietje So @torproject is forcing people to upgrade their platforms, but then at the same time Debian has made moves to break more stuff under the bogus pretext of improved security, without understanding how onion routing works.

@bojkotiMalbona @resist1984 @ggus
If you want to get things fixed in #Debian (#Bullseye), launchpad is an irrelevant tool. Complaining here isn't going to fix your issue either.

> Bullseye was designed

Bullseye wasn't designed. There are/were release goals, but that's a different thing.

Assuming you reported those issues on LP, you should have no problem properly reporting it to Debian. The 'reportbug' tool works great ime.
https://www.debian.org/Bugs/

(tip: loose the attitude)

@FreePietje @ggus @resist1984 i use LP because of issues with the debian mail server. I've given up trying to report bugs in trackers that have accessbility issues. I just throw it out in the wild on the off chance that it gets seen. Sometimes I only report bugs in Mastodon. https://infosec.exchange/@bojkotiMalbona/104637098084869887

@bojkotiMalbona
Maybe the issue is on your side?
I've never heard of a problem with the mail server preventing people from sending bug reports.
You can literally (just) send an email to submit@bugs.debian.org.

Or you could mail the maintainer of the relevant package you're having a problem with directly.

But throwing it out there on a random place on the internet? Don't expect anything useful to come from that.