Completely drop support for Tor 0.2.2.x

changed milestone to %Tor: unspecified

added component::core tor/tor milestone::Tor: unspecified needs-analysis points::medium/large priority::medium severity::normal status::new tor-dirauth tor-relay type::task labels

Shall we reach out to relays with contact information to ask them to upgrade? I'd be willing to do this.

I'd suggest that once 0.2.4.x is stable, that's the time to ask them to try 0.2.3.x or 0.2.4.x. Alternatively, a good question to ask them would be whether anything is preventing them from upgrading: Maybe there's some showstopper for some relays moving to 0.2.3.x that nobody tols us about?

I would be truly surprised if it was due to any showstoppers, especially anything they didn't already file a ticket for. Ping me when you'd like me to contact folks.

Okay, I think it's a fine time to contact these folks and ask them to upgrade to 0.2.4.x.

Also, let's remove 0.2.2.x from the recommended-versions lists.

Hi Nick, relay operators notified...

685 relays are running the 0.2.2.x series
274 had contact information
215 people emailed, of the rest 34 had rubbish contact information and 25 immediately bounced

Here's the script I threw together to get the relays...

from stem.descriptor.remote import DescriptorDownloader
from stem.version import Version

downloader = DescriptorDownloader()
count, with_contact = 0, 0

print "Checking for outdated relays..."
print

for desc in downloader.get_server_descriptors():
  if desc.tor_version < Version('0.2.3.0'):
    count += 1

    if desc.contact:
      print '  %-15s %s' % (desc.tor_version, desc.contact.decode("utf-8", "replace"))
      with_contact += 1

print
print "%i outdated relays found, %i had contact information" % (count, with_contact)

Unfortunately more time went toward manually un-obfuscating addresses (~60-90 minutes).

Cheers! -Damian

One operator replied that Tor 0.2.2.x is part of the repositories for the latest Ubuntu LTS release (12.04). I'm not sure if 0.2.3.x is in the backports but, if not, it probably should be. Iirc ioerror offered to be our maintainer for Ubuntu.

I'm in the same Ubuntu LTS boat - I'll update to 0.2.3.x as soon as it's available through the Ubuntu 12.04 packages. I'd recommend not kicking 0.2.2.x nodes off the network until an update is available through Ubuntu, as I suspect there are a lot of people with the same situation.

Trac:
Username: ZorbaTHut

On Debian, I know there is a new release but this is still supported (I think?):

lsb_release -a

No LSB modules are available. Distributor ID: Debian Description: Debian GNU/Linux 6.0.7 (squeeze) Release: 6.0.7 Codename: squeeze

apt-cache show tor

Package: tor Priority: optional Section: net Installed-Size: 2272 Maintainer: Peter Palfrader weasel@debian.org Architecture: amd64 Version: 0.2.2.39-1

Trac:
Username: PimpMyRide

It's nice to see that there's a ticket on this.

I've slowly been sending out some emails to 0.2.2.x operators manually. From what I've seen so far, it looks like most users are running that version because that's what's in the Debian/Ubuntu LTS repositories. Once linked to the page that points out how to add Tor's repos to their sources, the ones that got back to me were happy to upgrade.

From my perspective, I'm more concerned about cryptographic and Tor-level attacks, rather than old code, but I can see that dropping support would certainly be helpful for you devs.

0.2.2.x nodes currently account for 2.7% of the nodes by bandwidth weight; and 5.8% by raw count.

We should at the very least remove it from the recommended list in the consensus.

We should also be trying to get people to move to 0.2.4 if possible.

I talked with weasel about this, and came up with this tentative plan:

Now -- remove 0.2.2 from recommended-versions
Some time over the next month -- stop accepting 0.2.2 servers in the consensus.
Around June, once debian squeeze hits EOL -- consider which features if any we no long need to support in Tor.

I think in 0.2.5, we can stop accepting 0.2.2 servers for the consensus this month.

For 0.2.5, we should also remove client support for talking to 0.2.2 servers: won't it be nice to finally get rid of the client-side renegotiation code?

Dumping server support for 0.2.2 clients can wait till squeeze EOL.

(Just added those three as child tickets.)

Trac:
Milestone: Tor: 0.2.5.x-final to Tor: 0.2.6.x-final

I've been watching Tor Metrics to see what impact the OpenSSL "Heartbleed" vulnerability was having on the Tor network as a whole, if any. Among other things, I've noticed that the number of 0.2.2 relays has almost dropped to zero. From the graph it looks like it's less than a dozen or so. I say that now is a great time to drop support if it's doable.

See https://metrics.torproject.org/network.html

Trac:
Keywords: tor-relay tor-auth deleted, tor-relay tor-auth 026-triaged-1 added

Trac:
Keywords: tor-relay tor-auth 026-triaged-1 deleted, tor-relay tor-auth 026-triaged-1 unfrozen added

Being a coward, pushing to 0.2.7. We need to figure out the issue with the handful of remaining zombie 0.2.2 clients turning from slow zombies into fast zombies when the network stops supporting them.

Trac:
Milestone: Tor: 0.2.6.x-final to Tor: 0.2.7.x-final

Trac:
Status: new to assigned

Marking triaged-out items from first round of 0.2.7 triage.

Trac:
Keywords: tor-relay tor-auth 026-triaged-1 unfrozen deleted, tor-relay, unfrozen, tor-auth, 026-triaged-1, 027-triaged-1-out added

Make all non-needs_review, non-needs_revision, 027-triaged-1-out items belong to 0.2.???

Trac:
Milestone: Tor: 0.2.7.x-final to Tor: 0.2.???

Trac:
Parent: N/A to #15940 (moved)

Trac:
Type: defect to task

Trac:
Cc: N/A to starlight.2015q2@binnacle.cx

Trac:
Milestone: Tor: 0.2.??? to Tor: 0.2.8.x-final

Trac:
Sponsor: N/A to N/A
Points: N/A to medium/large

Our current best guesses suggest that we can start doing this in 0.2.8, but we can't finish.

Trac:
Milestone: Tor: 0.2.8.x-final to Tor: 0.2.9.x-final
Severity: N/A to Normal

Trac:
Priority: High to Medium

tickets market to be removed from milestone 029

Trac:
Milestone: Tor: 0.2.9.x-final to Tor: 0.2.???

0.2.2.x clients apparently shit themselves on bootstrap (See: #19939 (moved)).

Trac:
Reviewer: N/A to N/A

Replying to yawning:

0.2.2.x clients apparently shit themselves on bootstrap (See: #19939 (moved)).

Agreed. But I think that's just because dizum is busted currently. Once it's back, I expect those clients to resume working (for whatever terrible definition of 'working' it will be).

Milestone renamed

Trac:
Milestone: Tor: 0.2.??? to Tor: 0.3.???

Finally admitting that 0.3.??? was a euphemism for Tor: unspecified all along.

Trac:
Milestone: Tor: 0.3.??? to Tor: unspecified
Keywords: N/A deleted, tor-03-unspecified-201612 added

Replying to nickm:

Dumping server support for 0.2.2 clients can wait till squeeze EOL.

I hear squeeze has reached (and exceeded) eol.

Right; the remaining problem here is the prospect of "fast zombies" per proposal 266. (I know you know; noting this here so others see it.)

Remove an old triaging keyword.

Trac:
Keywords: tor-03-unspecified-201612 deleted, N/A added

Trac:
Keywords: N/A deleted, 027-triaged-in added

Trac:
Keywords: 027-triaged-in deleted, N/A added

Trac:
Keywords: 027-triaged-1-out deleted, N/A added

Trac:
Keywords: 026-triaged-1 deleted, N/A added

Turns out that tor-auth is for directory authority so make it clearer with tor-dirauth

Trac:
Keywords: tor-auth deleted, tor-dirauth added

Change the status of all assigned/accepted Tor tickets with owner="" to "new".

Trac:
Status: assigned to new

Trac:
Keywords: unfrozen deleted, needs-analysis added

Tor versions older than 0.2.4.26 or 0.2.5.11 no longer believe enough current directory authorities to bootstrap: https://trac.torproject.org/projects/tor/ticket/22251#comment:5