tor disables the SSLv3 for OpenSSL 1.0.0j on Fedora

added component::core tor/tor parent::4822 priority::medium reporter::kukabu resolution::not a bug status::closed type::defect labels

I think that might be because your OS has set up its opensssl to report an incorrect value for OPENSSL_VERSION_NUMBER: look how it's talking about 1 00 00 00 3 , but that doesn't correspond to 1.0.0j.

What openssl package is this?

I use the Fedora 16, openssl-1.0.0j-1.fc16.i686

Trac:
Username: kukabu

Okay, this is a problem that we have with Fedora perpetually. Within each Fedora release, they freeze the OpenSSL version number reported by SSLeay() and by OPENSSL_VERSION_NUMBER, even when they upgrade to a newer OpenSSL. So even though you have "1.0.0j" according to the human-readable version string, it's calling itself an alpha or beta version of OpenSSL 1.0.0, and Tor can'd tell that it's really been upgraded.

I'm not sure what the right behavior is here, but I think our best bet might be to just treat this as Fedora being Fedora, and accept that we will sometimes mistake a Fedora openssl for an older one than it really is. Other approaches -- like testing for the presence of the bug at runtime, or trying to parse the human-readable version string -- seem like they would be error-prone too, just in different ways.

I'm similarly not a big fan of chasing around fedora trying to figure out how they want you to learn what their openssl "really" is.

If their headers say openssl is one version, and something else says it's something else, that sounds like a pretty clear bug to me. But I know they don't consider it a bug. Is there some mechanism that they expose and promise will be accurate, to figure out what capabilities they added/changed? Or do they just not care about this situation either?

Replying to nickm:

our best bet might be to just treat this as Fedora being Fedora, and accept that we will sometimes mistake a Fedora openssl for an older one than it really is. Other approaches -- like testing for the presence of the bug at runtime, or trying to parse the human-readable version string -- seem like they would be error-prone too, just in different ways.

How about letting config options choose Tor's behavior, and then the Tor rpm can, if it knows what openssl it will secretly be using, turn on behaviors that it wants?

I haven't yet heard about an openssl feature that we're missing so badly that we should spend time on this issue though.

(or build options, since the rpm can turn them on there too)

RPM maintainers don't rebuild Tor packages when OpenSSL gets upgraded. I suppose that we could add an artificial dependency on a too-new version of OpenSSL, but that's a little goofy.

RPM maintainers rebuilds Tor packages when OpenSSL gets upgraded, but openssl patch (http://pkgs.fedoraproject.org/cgit/openssl.git/tree/openssl-1.0.0j-version.patch?h=f16) isn't correct.

It's Fedora issue and I close this bug.

Thanks!

Trac:
Username: kukabu
Status: new to closed
Summary: tor disables the SSLv3 for OpenSSL 1.0.0j to tor disables the SSLv3 for OpenSSL 1.0.0j on Fedora
Resolution: N/A to not a bug

closed

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

tor disables the SSLv3 for OpenSSL 1.0.0j on Fedora

Child items 0

Activity