Testing, https://bodhi.fedoraproject.org/updates/FEDORA-2016-1f15fef6d4 I'm now seeing some undefined symbols in Qt libraries: ldd -r /usr/lib64/libQt5Network.so ... symbol SSLv2_client_method, version libssl.so.10 not defined in file libssl.so.10 with link time reference (/usr/lib64/libQt5Network.so) symbol SSLv2_server_method, version libssl.so.10 not defined in file libssl.so.10 with link time reference (/usr/lib64/libQt5Network.so) $ ldd -r /usr/lib64/libQtNetwork.so ... symbol SSLv2_client_method, version libssl.so.10 not defined in file libssl.so.10 with link time reference (/usr/lib64/libQtNetwork.so) symbol SSLv2_server_method, version libssl.so.10 not defined in file libssl.so.10 with link time reference (/usr/lib64/libQtNetwork.so)
Ouch, more things affected, fedpkg doesn't work: ImportError: /usr/lib64/python2.7/lib-dynload/_ssl.so: symbol SSLv2_method, version libssl.so.10 not defined in file libssl.so.10 with link time reference
Fwiw, we're seeing similar issues in rawhide (but at least we can and should easily rebuild affected packages there)
Thanks Rex. As I understand it, the non-DROWN aspects of this bug are considered low severity, so we should take the time to find the right answer.
I was under the impression that Fedora was not vulnerable to DROWN by default and you'd have to go out of your way to become vulnerable. If that is the case, then do we really want to allow updates to break currently working software for users?
It's not unless someone specifically re-enabled SSLv2. There are various other LOW rated issues fixed in this version, so we still do want it to go out, it's just not as urgent. I have revoked the f23 update and untagged the f24 and rawhide builds for now. We should come up with a plan if we need to rebuild a bunch of things.
These are symbols removed from libssl.so.10 between openssl-libs-1.0.2f-2.fc24.x86_64.rpm and openssl-libs-1.0.2g-1.fc25.x86_64.rpm: SSLv2_client_method SSLv2_method SSLv2_server_method ssl2_accept ssl2_callback_ctrl ssl2_ciphers ssl2_clear ssl2_connect ssl2_ctrl ssl2_ctx_callback_ctrl ssl2_ctx_ctrl ssl2_default_timeout ssl2_do_write ssl2_enc ssl2_enc_init ssl2_free ssl2_generate_key_material ssl2_get_cipher ssl2_get_cipher_by_char ssl2_mac ssl2_new ssl2_num_ciphers ssl2_part_read ssl2_peek ssl2_pending ssl2_put_cipher_by_char ssl2_read ssl2_return_error ssl2_set_certificate ssl2_shutdown ssl2_version_str ssl2_write ssl2_write_error Affected library is for example: $ nm -D /usr/lib64/python3.5/lib-dynload/_ssl.cpython-35m-x86_64-linux-gnu.so |grep SSLv2_method U SSLv2_method $ rpm -qf /usr/lib64/python3.5/lib-dynload/_ssl.cpython-35m-x86_64-linux-gnu.so --qf '%{SOURCERPM}/%{NEVRA}\n' python3-3.5.1-6.fc25.src.rpm/system-python-libs-3.5.1-6.fc25.x86_64 I'm not going to grep all ELFs in Fedora, but see Gentoo bug report <https://bugs.gentoo.org/show_bug.cgi?id=575548> for some examples.
Simple fix is to rebuild 397 packages: # dnf repoquery --whatrequires 'libssl.so.10()(64bit)' --source |wc -l 397 Another option is put the symbols back as stub functions returning a failure and then slowly rebuild all the 397 packages. Provided the symbols disappeared from header files, you will get FTBFS on packages that need code change.
This was inadvertent change, I'm sorry for that breakage. The ssl2 has to be explicitly enabled now. It is only a precaution measure that upstream changed the default to disabled and it does not make the build vulnerable to the DROWN attack if it is enabled. So the appropriate thing is to reenable it again. Also I plan to disable it without the ABI break (i.e. the public symbols will stay but will return failures) later in Rawhide.
Why not dropping the public symbols in Rawhide and rebuild affected packages? SSLv2 needs to die.
I do not want to bump SONAME of openssl now. I am planning upgrade to 1.1.0 for Fedora 25 which certainly will require bump of the SONAME and also fairly non-trivial patching of dependencies but I want to start that work only once upstream releases the first beta version. Also I want to first provide it as COPR repository so the patching can start independently of rawhide contents.
(In reply to Petr Pisar from comment #7) > Simple fix is to rebuild 397 packages: > > # dnf repoquery --whatrequires 'libssl.so.10()(64bit)' --source |wc -l > 397 This isn't something I'd want to do for stable releases, but for F-24 I think it's likely worthwhile, it's quite straight forward for rel-eng to do a partial rebuild of a package list and then tag it in once built/verified.
openssl-1.0.2g-2.fc23 has been submitted as an update to Fedora 23. https://bodhi.fedoraproject.org/updates/FEDORA-2016-2802690366
I do not think it is worth the hassle. It would not be the last obsolete and insecure protocol/crypto in Fedora anwyay.
openssl-1.0.2g-2.fc23 has been pushed to the Fedora 23 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-2802690366
openssl-1.0.2g-2.fc23 has been pushed to the Fedora 23 stable repository. If problems still persist, please make note of it in this bug report.