Opened 11 years ago

Closed 9 years ago

Last modified 7 years ago

#920 closed defect (fixed)

don't bundle libevent with Tor

Reported by: V-Li Owned by:
Priority: Low Milestone: post 0.2.1.x
Component: Core Tor/Tor Version: 0.2.0.33
Severity: Keywords:
Cc: V-Li, nickm, arma, Sebastian Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

Hi,

I am the maintainer of Tor in Gentoo Linux and we have an open report in our issues tracker: http://bugs.gentoo.org/show_bug.cgi?id=206969

The report states that the asynchronous DNS part of libevent is bundled with Tor, which is true (see src/or/evendns.{c,h}). This gives our security team and myself a headache as a security problem found in libevent has to be tracked in all messages that bundle it or just only parts. Please remove that bit and try to bring your modifications upstream to libevent if needed.

[Automatically added by flyspray2trac: Operating System: All]

Child Tickets

Change History (14)

comment:1 Changed 11 years ago by arma

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.

comment:2 Changed 11 years ago by nickm

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

comment:3 Changed 11 years ago by V-Li

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.

comment:4 Changed 11 years ago by 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?

comment:5 Changed 11 years ago by nickm

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.

comment:6 Changed 11 years ago by nickm

(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.)

comment:7 Changed 11 years ago by V-Li

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.

comment:8 Changed 11 years ago by nickm

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? ;)

comment:9 Changed 10 years ago by V-Li

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?

comment:10 Changed 10 years ago by nickm

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.

comment:11 Changed 10 years ago by Sebastian

Is this still an issue for you, Christian?

comment:12 Changed 10 years ago by V-Li

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

comment:13 Changed 9 years ago by nickm

Resolution: Nonefixed
Status: newclosed

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.

comment:14 Changed 7 years ago by nickm

Component: Tor ClientTor
Note: See TracTickets for help on using tickets.