Re: descriptor published, but router missing from consensus

[Dyno Tor <dynotor@xxxxxxxxx>]

FYI, I experienced the same problems, using tor-0.2.1.25-tor.0.rh5_4
and openssl-0.9.8e-12.el5_4.6.  These are the standard CentOS OpenSSL
and Tor repositiory for Centos 5.4.  As suggested I used "yum
downgrade openssl" and got openssl-0.9.8e-12.el5_4.1, which works
fine.  So it definitely has something to do with openssl, but isn't
just specific to 1.0.  It's something that got backported to RHEL's
maintained openssl, so it probably is some security fix that got
published as part of openssl 1.0, but backported to RHEL/CentOS.

On 4/10/10, Hans Schnehl <torvallenator@xxxxxxxxx> wrote:
> On Fri, Apr 09, 2010 at 05:53:15PM -0500, Scott Bennett wrote:
>>      On Sat, 10 Apr 2010 00:26:39 +0200 Sebastian Hahn
>> <mail@xxxxxxxxxxxxxxxxx>
>> wrote:
>> >On Apr 9, 2010, at 11:44 PM, Scott Bennett wrote:
>> >>     Do you know whether anyone else has tor working properly with
>> >> openssl 1.0.0 ?  I'm considering downgrading it back to 0.9.8n as a
>> >> test to begin eliminating different possible sources of trouble.
> [...]
>
> Tor 0.2.2.10-alpha (git-81b84c0b017267b4) on FreeBSD 8-Stable amd64
> runs a little bumpy (these are, of course, strictly scientific terms) with
> openssl 1.0.0.
>  Tor is statically compiled against the most  recent libevent (git)  and
> openssl-1.0.0.
> There's higher load to the cpu with less utilized bandwidt than with
> previous versions.
>
> Best performance was with Tor 0.2.2.10-alpha (git-81b84c0b017267b4)
> statically compiled against  libevent-1.4.13 (the one in the FreeBSD
> ports tree) and  openssl-1.0.0-beta5. Probably will build that again in
> order
> to regain performance.
> Some change in between O*ssl-1.0.0-beta5 and -stable might be the reason.
>  Don't know.
>
>> >> (That
>> >> is what was working before.)  However, it is a bit of a nuisance to do
>> >> that, so I'd rather not do it if it's clear that the openssl version
>> >> isn't the source of my troubles.
>> >
>> >openssl 1.0.0, but we did some testing with the beta versions before
>> >and it seemed to work; afaik. Getting your results with a downgraded
>>
> [...]
>>      I don't actually know how much work it is because I've never tried
>> it.  There is now a tool called "ports-mgmt/portdowngrade" in the ports
>> tree that I'll need to install first to do the job.  That *shouldn't* be
> [...]
>
> portdowngrade works fine, even if not at all new, by talking to cvs-servers.
> You might want to save time and nerves by statically compiling the
> tor-binary, though.
> There's a post in or-talk
> http://archives.seul.org/or/talk/Jan-2010/msg00011.html ( by grarpamp )
> about how to do that.
>
> Just run 'configure' and 'make', _avoid_ 'make install' and drop the
> resulting tor-binary from  /src/or/tor to your PATH. (Remove or hide the
> old one before, of course)
>
> I do not intend to start a bikeshed discussion about pro's and con's of
> statically compiled binaries, but this saves the nuisance and keeps
> the rest of your system away from  testing different library versions
> three times a day :)
>
> [...]
>
> HTH
>
> Hans
>
>
> P.S.: Blue !
>