Tor 0.1.2.x abandoned by upstream, update to 0.2.0.34

[Roger Dingledine]

Binary package hint: tor

I am the Tor project leader (aka the upstream).

In Sept-Oct 2007 there was a thread on ubuntu-devel and ubuntu-motu with
the subject "Tor Packages", wherein mako suggested that Ubuntu drop the
Tor package from gutsy and hardy, because Tor doesn't provide multiple years
of support. See e.g.
http://<email address hidden>/msg24404.html
The conclusion was that there should be an exception for Tor,
such that when we abandoned a major release, Ubuntu would switch up to
the next stable Tor release.

This time has come. Earlier this week we officially dropped support for
the Tor 0.1.2.x branch. Since there are many known security problems
(including some potential remote exploits that can turn into remote
roots in the right circumstances), we recommend that nobody use it.

In particular, gutsy is shipping 0.1.2.17: http://packages.ubuntu.com/gutsy/tor
and hardy is shipping 0.1.2.19: http://packages.ubuntu.com/hardy/tor

The Tor 0.2.0.x branch came out (starting at 0.2.0.30) in July 2008,
and has stabilized very well by now. You can read its release notes
and updates:
http://archives.seul.org/or/announce/Aug-2008/msg00000.html
http://archives.seul.org/or/announce/Sep-2008/msg00000.html
http://archives.seul.org/or/announce/Dec-2008/msg00000.html
http://archives.seul.org/or/announce/Jan-2009/msg00000.html
http://archives.seul.org/or/announce/Feb-2009/msg00000.html

I notice that Intrepid and Jaunty are also shipping old Tor versions, but
they're already within the 0.2.0.x branch so should be easier to upgrade.

We have up-to-date debs, made by the Debian maintainer, here:
https://wiki.torproject.org/noreply/TheOnionRouter/TorOnDebian

So: what's the process for making this happen?

[Martin Pitt (pitti)]

Intrepid and Jaunty already have 0.2, thus the "0.1.2.x abandoned" does not apply there. If there are important fixes in later upstream 0.2.x microreleases, they should get a separate bug report.

[Martin Pitt (pitti)]

I still remember the thread, and back then we concluded that we can pursue the path of updating stables to new upstream versions if we get enough testing *and* the upgrade does not break existing user configuration. I subscribed motu-sru for their feedback as well, since the package is in universe.

Are there any configuration settings in 0.1.x. which are not handled any more by 0.2? If so, what happens for those?

Should we put the current intrepid package (2.0.31) into hardy-proposed? In other words, is 2.0.31 "good enough" for now? This would be slightly safer, since the intrepid version already got testing. We could then update all stable releases to a newer 0.2.x later, in a separate SRU.

Or rather update jaunty and intrepid-proposed to the latest upstream microrelease first (which should become a separate SRU bug, see above), test it, get it into intrepid-updates, and then backport this to hardy?

Thanks for any insight, Roger!

[Roger Dingledine (arma-mit)]

Intrepid and jaunty should move to 0.2.0.34. The current intrepid version (0.2.0.31)
is not good enough. In particular, 0.2.0.31 has a bug where Tor fails to drop privileges
correctly. (Tor 0.1.2.x has this bug too.)

I just had a look over the changelogs, and I think there are no config options that
are newly rejected in 0.2.0.x. Definitely none that are in common use. ;)

Before I go making any more new bug reports though, I found these:
https://bugs.launchpad.net/ubuntu/+source/tor/+bug/321102
https://bugs.launchpad.net/ubuntu/+source/tor/+bug/321122
https://bugs.launchpad.net/hardy-backports/+bug/321520
Should they be merged in, revised, etc? Or should we make a new one that
specifically mentions 0.2.0.34? If so, please feel free.

[Devid Antonio Filoni (d.filoni)]

I'm working on 0.2.0.34 merge from Debian for jaunty.

[Roger Dingledine (arma-mit)]

http://packages.ubuntu.com/jaunty/tor indicates that jaunty now
has 0.2.0.34. Does that mean we're ready for the next step? :)

[Devid Antonio Filoni (d.filoni)]

Roger: are there regressions from 0.1.X to 0.2.X? Is 0.2.X good or are there bugs that should be fixed?

[Roger Dingledine (arma-mit)]

I believe that 0.2.0.34 is better in all ways than 0.1.2.19. (Hard to say for sure, of
course, but as far as we can tell...)

There were some new bugs introduced in 0.2.0.x, but those got ironed out between
0.2.0.30 and 0.2.0.34.

Whereas there are known serious bugs in 0.1.2.19 that are not fixed.

[Devid Antonio Filoni (d.filoni)]

Why don't fix bugs on 0.1.2.19?

Are there bugs in Ubuntu fixed in 0.2.0.34 version? Can you list them?

[Roger Dingledine (arma-mit)]

See the initial summary above, and the links, e.g.
http://<email address hidden>/msg24404.html

The Tor 0.1.2.x release (0.1.2.13) came out in April 2007. We've backported things
to it for well over a year now, and it's time to let it go.

As for the bugs fixed in 0.2.0.x (up through 0.2.0.34), yes, the release notes are
linked from the initial summary above.

(We haven't made a list specifically for Ubuntu, but pretty much all of the Tor
bugs apply.)

[Martin Pitt (pitti)]

OK, let's use this bug to track intrepid as well, I made the bug title more general.

So this is fixed in Jaunty now. Can someone please prepare and test a backport to hardy and intrepid? I'll assist with reviewing, sponsoring, and processing it through the queues. Then we need to give them a good testing.

Thank you!

[Roger Dingledine (arma-mit)]

For whoever is working on the packages, there are hardy and
intrepid 0.2.0.34 debs available here:
https://wiki.torproject.org/noreply/TheOnionRouter/TorOnDebian
built by the Debian maintainer.

You may or may not find them useful. :)

[Roger Dingledine (arma-mit)]

I should mention that we've been holding back on the detailed security advisory
for bugs fixed in 0.2.0.33 and 0.2.0.34, until Ubuntu and the *BSDs have had time
to upgrade.

I think the BSDs have upgraded now, so we're just waiting on Ubuntu. At some point
we're going to have to release the advisory though, since the nice fellow who reported
it to us wants to get credit.

Do you think this will be all resolved in the next week or two?

[Martin Pitt (pitti)]

Roger,

the primary problem here that nobody "took" the bug, there is no assignee. As discussed back then, we'd need someone who actually uses the packge, maintains it, and can test it.

So please don't stall the advisory further, since it's not at all clear when this will get fixed in Ubuntu stables.

Thanks!

[Roger Dingledine (arma-mit)]

Ok.

Should we take Tor out of Jaunty, then?

[Martin Pitt (pitti)]

I guess so. I mailed ubuntu-devel-discuss@ again, but if there will be nobody stepping up, I'll remove it from jaunty.

[Iain Lane (laney)]

But it has been updated in Jaunty. "All" we need to do is push this version down through the releases, right? It seems from reading this report that this should be mostly transparent to our users, but we can put a NEWS file in the releases if this would be more appropriate. This seems much better to me than going for removal, especially when it seems that tor is still well-maintained upstream and in Debian.

[Martin Pitt (pitti)]

Iain Lane [2009-03-09 15:39 -0000]:
> But it has been updated in Jaunty. "All" we need to do is push this
> version down through the releases, right?

Well, that "all" encompasses instaling the current hardy version,
configuring it, checking that it works, backporting the jaunty
package, installing it (i. e. upgrade from jaunty), test it, confirm
that nothing breaks that worked previously, etc.

In other words, it needs someone who understands what the package
does, how to use it, and how to test it properly.

[Travis H. (travis+w-launchpad-net)]

I'm willing to take this on...

[Roger Dingledine (arma-mit)]

Ok. So the current status as I understand it is that Ubuntu would rather
ship known-vulnerable (and in the Intrepid case, known-remote-root-vulnerable!)
versions of Tor rather than use the Ubuntu debs that we provide.

Sounds like the correct solution is to a) take it out of Jaunty (as Martin said
he would do, above, but I think it hasn't been done yet?), and b) use the
Hardy and Intrepid debs that we provide in the noreply.org repository.

I understand that you want testers, but apparently nobody reads this bug
report except people who don't have time to test. I say that the noreply debs --
even if not "officially" tested, whatever that means -- are a huge improvement
over the known-remote-vulnerable versions you ship in Hardy and Intrepid.

[Runa A. Sandvik (runasand)]

Seems like I made a duplicate bug report when I filed #362447 requesting backports:
https://bugs.launchpad.net/ubuntu/+source/tor/+bug/362447

Like I have previously written; there are no source changes needed. Version 0.2.0.34 builds in clean intrepid- and hardy-pbuilder and runs like a charm.

[Martin Pitt (pitti)]

I held back the removal since my "call for maintainership" on the ML got two replies. But there hasn't been any action yet, so I removed tor from jaunty now.

[Runa A. Sandvik (runasand)]

Prevu-build log for intrepid (I used tor_0.2.0.34-1ubuntu1.dsc) attached.

[Runa A. Sandvik (runasand)]

Prevu-build log for hardy (I used tor_0.2.0.34-1ubuntu1.dsc) attached.

[Martin Pitt (pitti)]

Thanks for the build logs, but those are the least of my concerns. We
need someone who actively uses tor, can test upgrades and
configuration compatiblity between 1.x and 2.x (hardy upgrade), test
for regressions, etc. This is a serious maintainer job, I'm afraid.

[Runa A. Sandvik (runasand)]

I have built, installed and tested 0.2.0.34 on both hardy and intrepid. When testing I first installed tor directly from the repository, configured and started it before I upgraded - to make sure that the configuration continues to work. I also checked all bugs marked "fixed released" to make sure that none of them are re-introduced.

diff, orig and dsc for both hardy and intrepid can be found here: http://folk.ntnu.no/runasand/tor/

[Carey Underwood (cwillu)]

"Fix Released" seems rather misleading.

[Martin (martin-sogetthis)]

Hi Guys, probably I am getting it wrong, cause english is not my mother tongue, but what I am reading here is that you are discussing to remove tor rather than just taking the new versions.

I am just a simple Ubuntu user, just like thousands of others out there. I am using tor on daily base and if I read here that you still include versions that have known "remote-root" vulnerabilities and you still include them because you are afraid of configuration compatibilites I could puke on my desktop.

Even if there were some probs with upgrading... we all had that problem before, asking us to rather take the new config or skipping it and be happy with the old one... do you really think its better to have thousands of systems out there unprotected just because of that small-minded *whatever*

Update for god-sake, don't be a wimp. Use your time, install it, upgrade and check if everything works. Or give Runa the job - who cares. Sound like Redmond, knowing of a critical bug for month and not fixing it even if the solution is already there.

This is a potential risk to all of the tor users who believe in the "community" and its repositories, don't risk your trust, fix it...

[Martin (martin-sogetthis)]

@Martin: Thanks for letting the Ubuntu users know of that problem, so we can remove tor from our system and us your debs instead... thats what the ubuntu repos are for, right ;)

[Martin Pitt (pitti)]

Accepted into intrepid-proposed; please test and give feedback here. Please see https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

[Martin Pitt (pitti)]

Accepted into hardy-proposed; please test and give feedback here. Please see https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

[Runa A. Sandvik (runasand)]

I have tested tor on intrepid (using intrepid-proposed) and everything works just fine.

Preparing to replace tor 0.2.0.31-1 (using .../tor_0.2.0.34-1~intrepid+1_i386.deb) ...
Stopping tor daemon: ..............................tor.
Unpacking replacement tor ...
Processing triggers for man-db ...
Setting up tor (0.2.0.34-1~intrepid+1) ...
Raising maximum number of filedescriptors (ulimit -n) to 16384.
Starting tor daemon: tor...
Apr 25 19:42:51.237 [notice] Tor v0.2.0.34 (r18423). This is experimental software. Do not rely on it for strong anonymity. (Running on Linux i686)
Apr 25 19:42:51.239 [notice] Your ContactInfo config option is not set. Please consider setting it, so we can contact you if your server is misconfigured or something else goes wrong.
Apr 25 19:42:51.241 [notice] Initialized libevent version 1.3e using method epoll. Good.
Apr 25 19:42:51.241 [notice] Opening OR listener on 0.0.0.0:9090
Apr 25 19:42:51.241 [notice] Opening Directory listener on 0.0.0.0:9030
done.

[Eric (esb)]

@Martin Pitt

So, let me get this right: Tor is in both hardy- and intrepid-proposed, but has been removed from the jaunty repositories? Following the previous comments is confusing; why is it like this again?

If its a maintainer issue, why is it in *-proposed? If its a potential upgrade issue, why was it removed from an at-the-time unreleased release instead of being moved to jaunty-{backports,proposed}? If its a security issue, why is Debian using the same version as the removed package?

I was using the latest version in jaunty just fine until I installed the jaunty release from scratch and discovered it had been removed. Now I'm left attempting to verify trust chains to get a properly signed version, or mixing an old *-backports repository into my package database.

At least throw it into jaunty-backports as an unsupported package next time? I mean, its being supported by Debian, isn't that enough to at least get unsupported status?

[Martin Pitt (pitti)]

Eric B. [2009-04-28 7:15 -0000]:
> So, let me get this right: Tor is in both hardy- and intrepid-proposed,
> but has been removed from the jaunty repositories?

Correct.

> Following the previous comments is confusing; why is it like this again?

Because nobody stepped up in time in Jaunty to commit to maintaining
it.

> If its a maintainer issue, why is it in *-proposed?

Because tor is and remains in stable releases (hardy, intrepid), and
Runa kindly stepped up to provide and thoroughly test newer tor
versions for those.

> I was using the latest version in jaunty just fine until I installed the
> jaunty release from scratch and discovered it had been removed. Now I'm
> left attempting to verify trust chains to get a properly signed version,
> or mixing an old *-backports repository into my package database.

You should use the upstream provided packages instead.

> At least throw it into jaunty-backports

That wouldn't work -- where to backport it from?

> I mean, its being supported by Debian, isn't that enough to at least
> get unsupported status?

This is true for most packages, but tor is a bit special, since unlike
for many other packages, old tor versions pose a security risk.
Either we find someone who can commit to maintaining tor in Ubuntu on
an ongoing basis, or we shouldn't have the package in Ubuntu at all.
This was discussed with tor's upstream, too.

[Rory McCann (rorymcc)]

tor being removed is quite annoying. I'll try using the packages from the tor project.

[Nizar Kerkeni (nizarus)]

i waited a long time for vidalia to be packaged on ubuntu, and when we got it, tor is removed :)
vidalia, use is using tor, so having vidalia without tor is useless

[Runa A. Sandvik (runasand)]

I've built a new hardy-backport (and set the conflict to an older version of libssl); http://folk.ntnu.no/runasand/tor/hardy/fixed/

[Martin Pitt (pitti)]

Runa,

I don't think this is necessary. You patched

-Conflicts: libssl0.9.8 (<< 0.9.8g-4ubuntu3.1)
+Conflicts: libssl0.9.8 (<< 0.9.8g-4ubuntu3)

But hardy has

libssl0.9.8 | 0.9.8g-4ubuntu3 | hardy | amd64, i386
libssl0.9.8 | 0.9.8g-4ubuntu3.5 | hardy-security | amd64, i386
libssl0.9.8 | 0.9.8g-4ubuntu3.5 | hardy-updates | amd64, i386

First, nobody really REALLY should use version 0.9.8g-4ubuntu3 since it has a grave security bug. Second, _if_ people are using hardy-updates at all, and thus will even see this tor update, they will also have the updated libssl. So I think the current version in -proposed is fine and should be verified.

[Runa A. Sandvik (runasand)]

I can't find tor in hardy-proposed and I thought the conflict was the reason.

'rmadison tor' shows:
tor | 0.2.0.34-1~hardy+1 | hardy-proposed/universe | source, amd64

Also, the page for the i386-build[1] says that a few binaries are still awaiting acceptance.

[1]: https://launchpad.net/ubuntu/+source/tor/0.2.0.34-1~hardy+1/+build/958753

[Martin Pitt (pitti)]

Right, sorry. It was stuck in the NEW queue because of the newly built package "tor-geoipdb". I processed it now, will be available on archive.u.c. in about an hour.

[Runa A. Sandvik (runasand)]

I have tested tor on hardy (using hardy-proposed) and everything works just fine.

Preparing to replace tor 0.1.2.19-2 (using .../tor_0.2.0.34-1~hardy+1_i386.deb) ...
Stopping tor daemon: ..............................tor.
Unpacking replacement tor ...
Selecting previously deselected package tor-geoipdb.
Unpacking tor-geoipdb (from .../tor-geoipdb_0.2.0.34-1~hardy+1_all.deb) ...
Setting up tor (0.2.0.34-1~hardy+1) ...

Configuration file `/etc/tor/torrc'
 ==> Modified (by you or by a script) since installation.
 ==> Package distributor has shipped an updated version.
   What would you like to do about it ? Your options are:
    Y or I : install the package maintainer's version
    N or O : keep your currently-installed version
      D : show the differences between the versions
      Z : background this process to examine the situation
 The default action is to keep your current version.
*** torrc (Y/I/N/O/D/Z) [default=N] ?
Installing new version of config file /etc/logrotate.d/tor ...
Installing new version of config file /etc/default/tor ...
Installing new version of config file /etc/init.d/tor ...
Raising maximum number of filedescriptors (ulimit -n) to 16384.
Starting tor daemon: tor...
May 04 13:36:20.017 [notice] Tor v0.2.0.34 (r18423). This is experimental software. Do not rely on it for strong anonymity. (Running on Linux i686)
May 04 13:36:20.019 [notice] Your ContactInfo config option is not set. Please consider setting it, so we can contact you if your server is misconfigured or something else goes wrong.
May 04 13:36:20.020 [notice] Initialized libevent version 1.3e using method epoll. Good.
May 04 13:36:20.021 [notice] Opening OR listener on 0.0.0.0:9090
May 04 13:36:20.021 [notice] Opening Directory listener on 0.0.0.0:9030
done.

[Martin Pitt (pitti)]

Thanks for testing, it seems you covered both hardy and intrepid now.

The conffile dpkg question in hardy is unfortunate. It seems that /etc/tor/torrc wasn't a conffile in original hardy's version, but is now in the new version? Or did you actually change it manually?

[Nizar Kerkeni (nizarus)]

i tested with success, tor (v0.2.0.34) deb package available in the torproject website on jaunty 64 bits.

[Runa A. Sandvik (runasand)]

@Martin: I didn't change anything. There is a config file in both the hardy-version and in the new version (this goes for the version in intrepid as well).

@Nizar: Thanks for testing, but tor isn't going into jaunty at this point.

[Nizar Kerkeni (nizarus)]

@Runa : ok, but as i see in the top of this page, this bug is also nominated for jaunty :)

[Runa A. Sandvik (runasand)]

@Nizar: like Martin Pitt wrote earlier in this bug report - tor has been removed from jaunty.

[Martin Pitt (pitti)]

This was originally titled differently. I change the jaunty task to "invalid" to be less confusing.

[Launchpad Janitor (janitor)]

This bug was fixed in the package tor - 0.2.0.34-1~hardy+1

---------------
tor (0.2.0.34-1~hardy+1) hardy-proposed; urgency=low

  * Build 0.2.0.34 for hardy. (LP: #328442)
  * Conflict with libssl0.9.8 (<< 0.9.8g-4ubuntu3.1) on hardy

 -- Runa Sandvik <email address hidden> Mon, 09 Feb 2009 10:09:54 +0100

[Launchpad Janitor (janitor)]

This bug was fixed in the package tor - 0.2.0.34-1~intrepid+1

---------------
tor (0.2.0.34-1~intrepid+1) intrepid-proposed; urgency=low

  * Build 0.2.0.34 for intrepid. (LP: #328442)
  * Conflict with libssl0.9.8 (<< 0.9.8g-4ubuntu3.1) on intrepid

 -- Runa Sandvik <email address hidden> Mon, 09 Feb 2009 10:09:54 +0100

[Martin Pitt (pitti)]

Runa, thank you for your efforts!

[Ralph Corderoy (ralph-inputplus)]

Whilst I understand the reasons stated above for tor having been dropped from 9.04, it came as a surprise to upgrade from 8.10 to find it missing! I didn't spot anything about lack of tor in the 9.04 release notes either. That leaves me with a machine that was mainly for running tor without a lot to do. Given this bug is "Invalid" for 9.04, does there been to be another bug to track attempts to get tor back into current and future Ubuntus?

[Runa A. Sandvik (runasand)]

@Ralph: you can get packages for 9.04 here: https://wiki.torproject.org/noreply/TheOnionRouter/TorOnDebian

As for the question about getting tor back in the current and future releases of Ubuntu: having tor in ubuntu requires a maintainer that is willing to keep the packages updated (this includes backports).

[Aron Xu (happyaron)]

I've added a bug here:
https://bugs.edge.launchpad.net/ubuntu/+bug/413657
As a user, tor is necessary for daily use anyway.