don't bundle libevent with Tor

changed milestone to %post 0.2.1.x

added component::core tor/tor milestone::post 0.2.1.x priority::low reporter::V-Li resolution::fixed status::closed type::defect version::0.2.0.33 labels

One of the core Tor developers (Nick Mathewson) is now a core libevent developer too. We wrote that code, then we put it into libevent upstream. So we do keep bugfixes in sync between Tor and libevent.

The problem is that Tor needs to still work for people who don't have the new libevent. As an example, debian users have a crazy old libevent.

I guess that doesn't quite solve your problem though. Hm.

We could add an autoconf command-line option to use Libevent's DNS code, I suppose. Does anybody want to write the patch here?

The autoconf option sounds perfect to me. My solution was to patch out all calls to the bundled eventdns.h and eventdns.c (see the linked bug), it worked on my system but I cannot guarantee it, so I asked here.

Anyway, even if libevent and tor share exactly the same developers, including a library is a bad idea, because it is not the sense of shared libraries. So thanks for your fast reaction, you make my life as maintainer really easy.

Trac:
Username: V-Li

Do you have a patch ready I can incorporate into our patchset so I don't have to wait until a fixed version is released?

Trac:
Username: V-Li

Nope.

For the 0.2.0.x stable series, there's nothing wrong with the patch you attached to the report at the Gentoo bugtracker.

The 0.2.1.x-alpha series uses eventdns functionality that is not yet in any stable libevent release.

(Though remember that using the libevent stable release's DNS code instead of the one you get with Tor 0.2.0.33 will actually make your users less secure in some ways , since the stable libevent eventdns doesn't support the 0x20 hack. You should probably warn them about this so they don't complain to us.)

This is the comment about my solution on the Gentoo issue tracker...just for the records:

net-misc/tor has USE=bundledlibevent turned on by default (EAPI=1), so people will still get the current bundling out of the box. If that USE flag is disabled a patch is applied that compiles tor with the system's libevent. The reason is that tor's upstream incorporated some security related fixes into the tor version of libevent that are not released with the official libevent yet. This looks like the best possible solution until upstream provides the autoconf switch to move away from the bundled version. As soon as the enhanced libevent version makes it into Portage, the USE flag will leave.

Trac:
Username: V-Li

It's not completely accurate to refer to eventdns.c as "the tor version of Libevent", fwiw. You wouldn't call a replacement malloc function "the Tor version of libc", would you? ;)

As far as I can see the autoconf option hasn't made it into the 0.2.1 series (I added the 0.2.1.5 RC to Gentoo's package system). Which libevent version is at least needed for Tor to build when the bundled parts from eventdns.h are abandoned?

Trac:
Username: V-Li

You'll require Libevent 2.0.x, and Tor 0.2.2.1-alpha [not yet released]. If you wanted to backport the relevant parts of Tor 0.2.2.1-alpha, you would want to look at the parts of commit e5b88dc83fb44622f that apply to configure.in and src/or/Makefile.am. This is obviously not supported.

Is this still an issue for you, Christian?

As long as there is a bundled copy, it is an issue for me. I haven't checked recently.

Trac:
Username: V-Li

Closing as 'fixed'. When you build Tor 0.2.2.x with Libevent 2.0.x or later, it links in no eventdns.c code.

Alternatively, you can regard this as 'wontfix': we aren't going to backport support for that to Tor 0.2.1.x, and the versions of Libevent before Libevent 2.0.x have evdns code too broken for Tor to use.

Trac:
Parent: N/A to N/A
Resolution: None to fixed
Status: new to closed
Keywords: N/A deleted, N/A added

Trac:
Component: Tor Client to Tor

closed

moved to tpo/core/tor#920 (closed)

don't bundle libevent with Tor

Child items 0

Activity