descriptor published, but router missing from consensus

[Dyno Tor]

Given that this problem is specific to something between
openssl-0.9.8e-12.el5_4.1 and openssl-0.9.8e-12.el5_4.6, this document
may be useful, as it describes the differences between these versions:

http://rhn.redhat.com/errata/RHSA-2010-0162.html

On 4/10/10, Dyno Tor <dynotor at gmail.com> wrote:
> 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 at gmail.com> 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 at sebastianhahn.net>
>>> 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 !
>>
>