Draft advisory and patches available on request.
Announcement public as per https://mta.openssl.org/pipermail/openssl-announce/2016-February/000063.html .
commit 7bf3f3ef8d44f51b7cbfbabc1282da60fcb5f715 Author: Lars Wendler <polynomial-c@gentoo.org> Date: Tue Mar 1 15:05:20 2016 dev-libs/openssl: Security bump to version 1.0.2g (bug #575548). Package-Manager: portage-2.2.27 Signed-off-by: Lars Wendler <polynomial-c@gentoo.org> Arches please test and mark stable =dev-libs/openssl-1.0.2g with target KEYWORDS: alpha amd64 arm arm64 hppa ia64 m68k ~mips ppc ppc64 s390 sh sparc x86 ~amd64-fbsd ~sparc-fbsd ~x86-fbsd ~arm-linux ~x86-linux
ATTENTION: after upgrading to dev-libs/openssl-1.0.2g, basically ALL packages using openssl are broken. Missing symbols (something with SSLv2)... can be be fixed via rebuild, but after upgrading, even "wget" is broken, and then portage can't download anymore...
Hm, how about bump wget with a version which compiles without SSLv2 support first (make it a dependency for the new OpenSSL), then recompile OpenSSL without SSLv2 support, so after that at least wget is not broken? Can the OpenSSL ebuild detect which packages use it for atumatic recompilation?
I would recommend setting a subslot in the openssl ebuild to trigger a rebuild of all reverse deps.
(In reply to Mike Gilbert from comment #5) > I would recommend setting a subslot in the openssl ebuild to trigger a > rebuild of all reverse deps. That works only if the reverse deps already have the := operator in place beforehand.
(In reply to Stefan Briesenick from comment #3) > after upgrading to dev-libs/openssl-1.0.2g, basically ALL packages using > openssl are broken. Missing symbols (something with SSLv2)... > > can be be fixed via rebuild, but after upgrading, even "wget" is broken, and > then portage can't download anymore... Anyone else actually seeing this? Because I don't think I am. I only emerged dev-libs/openssl-1.0.2g today. I still have openssl-0.9.8z_p8, but only acroread is using it on my system. /usr/bin/wget is properly linking to /usr/lib64/libssl.so.1.0.0 and /usr/lib64/libcrypto.so.1.0.0 from openssl-1.0.2g $ wget "https://bugs.gentoo.org/show_bug.cgi?id=575548" ... works fine for me. Stable www-client/lynx and www-client/links browsers, also linking to libssl.so.1.0.0 and libcrypto.so.1.0.0, are also opening this HTTPS URL finely. To test Portage, I emerged net-print/hplip-3.16.2, upgrading from 3.15.11 without any issue, for example. I could sync Portage again without issue either. # revdep-rebuild -pi ... reports nothing to rebuild. I am encountering at least the rebuilding failure for dev-python/cryptography from bug 576142 though (with stable cryptography-1.1.2). ... well, I do have runtime issues with stable net-p2p/deluge-1.3.12, which depends on dev-python/pyopenssl, in turn depending on dev-python/cryptography... so there are some runtime issues too... I am also seeing the runtime error from bug 576128 with latest app-portage/layman-2.3.0-r1 (layman depends on dev-python/ssl-fetch, which also depends on dev-python/pyopenssl, and thus dev-python/cryptography). Deluge and Layman are the only packages depending on dev-python/cryptography on my system at the end of the chain, though. But there indeed could be more problems with other libraries or packages... I don't think I want to test rebooting just now ;) # emerge -pv openssl wget links lynx [ebuild R ~] dev-libs/openssl-1.0.2g::gentoo USE="asm -bindist gmp -kerberos rfc3779 -sctp static-libs {-test} -tls-heartbeat -vanilla zlib" ABI_X86="32 (64) (-x32)" CPU_FLAGS_X86="(sse2)" 0 KiB [ebuild R ] net-misc/wget-1.16.3-r1::gentoo USE="-debug -gnutls idn ipv6 nls -ntlm pcre ssl -static {-test} uuid zlib" 0 KiB [ebuild R ] www-client/links-2.8-r1:2::gentoo USE="X bzip2 -directfb fbcon gpm ipv6 jpeg -livecd lzma ssl (-suid) (-svga) tiff unicode zlib" 0 KiB [ebuild R ] www-client/lynx-2.8.8_p2::gentoo USE="bzip2 cjk -gnutls idn ipv6 nls ssl unicode" 0 KiB
and: https://bugs.gentoo.org/show_bug.cgi?id=576154
(In reply to Stefan Briesenick from comment #8) > and: https://bugs.gentoo.org/show_bug.cgi?id=576154 Yep, rebuilding my versions of python solves the problem for Layman and Deluge.
A sneaky, ugly (but atomic) "workaround" could be to let openssl depend on wget[gnutls]. With that we at least do not deadlock any Gentoo installations. It is still necessary to rebuild everything linking to openssl after the upgrade: # revdep-rebuild.sh -i -L "libssl\.so.*" -- --exclude=openssl
from comment #5) > I would recommend setting a subslot in the openssl ebuild to trigger a > rebuild of all reverse deps. commit 31d636b9d535bf0de1758eab41348b88f9730871 Author: Lars Wendler <polynomial-c@gentoo.org> Date: Tue Mar 1 22:53:44 2016 dev-libs/openssl: Revbump to add subslot that reflects lack of SSLv2 (#575548). Package-Manager: portage-2.2.27 Signed-off-by: Lars Wendler <polynomial-c@gentoo.org> dev-libs/openssl/openssl-1.0.2g-r1.ebuild | 267 ++++++++++++++++++++++++++++++ dev-libs/openssl/openssl-1.0.2g.ebuild | 265 ----------------------------- 2 files changed, 267 insertions(+), 265 deletions(-)(In reply to Mike Gilbert
On the ABI breakage bug (bug #576128) a CoreOS dev said: > FWIW, in CoreOS we are taking the enable-ssl2 approach I won't argue against disabling ssl2 by default, but I would like to be able to turn it on for specific cases/hosts: namely, so that tools like sslscan, socat, stunnel, even openssl s_client can be used to test servers for ssl2 support/configuration. So, I'll attach a proposed ebuild patch that adds an -ssl2 USE flag: by default ssl2 will still be disabled, but people who explicitly enable USE=ssl2 for openssl, will get SSLv2 protocol support (if they hang themselves as a result, that is on them).
Created attachment 427178 [details, diff] Add a USE flag to enable ssl2 in openssl, off by default.
sorry to say but adding sub-slots every now and then does not fix a thing. It means, that ALL ebuilds that revdeps on openssl need corresponding operators. Go figure and waste time on this. And it is known fact that such types updates are so flakey and users facing all sorts of weird slots blocks and portage stuck. it's probably only 1/5 of ebuilds have := operators to triggers rebuilds. This inefficient. i find revdep-rebuild --library /usr/lib64/libssl.so (and libcrypto.so) is way more predictable for a given machine. yes, it maybe not respecting build order but i rather follow this way than dealing with unstable sub-slot feature.
1.0.1s is the corresponding security fix in 1.0.1 series. Perhaps you could add it to the portage tree. TIA see: https://www.openssl.org/news/secadv/20160301.txt
(Adding bug 576128 in depends to prevent accidental stabilization on some arches... I would even unCC them until this is solved/workarounded (probably compiling openssl with the optional sslv2 support always enabled but I am not the maintainer))
Hard-enabling SSLv2 is not a solution as that basically leaves everyone vulnerable. We will very likely add a USE flag to turn it on for people who really want it and know what they're doing. We removed the 1.0.1 versions a few days ago, so we probably won't see 1.0.1s. That wouldn't help with the issue at hand anyway.
I guess it's not technically possible but... why didn't upstream bumped the soname version? That way, in our case, preserved-rebuild portage functionality would warn about the need of rebuilding all the reverse deps and, additionally, as the old .so would be preserved, it shouldn't break important tools for rebuilding all the stuff (like wget) immediatly
its something to ask openssl team why they didn't bump soname :) So far revdep-rebuild is best way to get back system working, because there is no ETA on when all sub-slot operator fixed ebuilds going to appear in portage tree and assuming openssl have numerous reverse deps. I guess NEWS item, and wiki page needed to describe whats going on.
It looks like some suggestions are being done (also the soname bump from downstream) in bug 576128 UnCCing arches as this cannot be stabilized right now
I've added back ssl2 into openssl-1.0.2g-r2 to unbreak users systems but that package should not be stabilized. Unless of course we want to stabilize it to close SOME of the CVEs, which of course are the high priority ones. By leaving ssl2 enabled we'll have a low priority one remaining.
Ok because there's a lot of confusion here.. Setting 'enable-ssl2' does not make you automatically vulnerable. 1.0.2g has been changed to not provide SSLv2 by default. Applications must explicitly request it by calling it directly or setting a flag on the context. See: https://github.com/openssl/openssl/commit/9dfd2be8a1761fffd152a92d8f1b356ad667eea7 The path forward is to stabilize 1.0.2g-r2 which builds with 'enable-ssl2' because that solves a number of CVEs and reduces the attack surface from 1.0.2f.
(-r2 shouldn't be affected by bug 576128)
Also, was 0.9.8 slot fixed? You can find the patches in openSuSE for example: http://download.opensuse.org/update/openSUSE-current/src/libopenssl0_9_8-0.9.8zh-14.1.src.rpm
(In reply to Pacho Ramos from comment #24) > Also, was 0.9.8 slot fixed? You can find the patches in openSuSE for example: > http://download.opensuse.org/update/openSUSE-current/src/libopenssl0_9_8-0.9. > 8zh-14.1.src.rpm No. We are planning on removing 0.9.8 from the tree. It is not Gentoo policy to maintain the security of packages after upstream has stopped maintaining them. There are a few packages in the tree still depending on it which we need to remove first.
Arches are CC'ed, but it isn't clear to me that there is a call for stabilization here. Can this be clarified, or the arches un-CC'ed?
I re-activated a recent stable tinderbox image (amd64-desktop-stable_20160217-143603 ~10,000 installed packages), updated @world, keyworded glibc-1.0.2g-r2 and re-emerged 293 packages afterwards (equery d dev-libs/openssl | grep -v '^ ') - no build failure so far.
I trust Toralf, but I lauched anyway a recompilation of the entire world to check if all goes well. I will stabilize tomorrow if all is ok.
amd64 stable
Stable for HPPA PPC64.
arm/x86 stable
*** Bug 576990 has been marked as a duplicate of this bug. ***
Stable on alpha.
ppc stable
sparc stable
ia64 stable
This issue was resolved and addressed in GLSA 201603-15 at https://security.gentoo.org/glsa/201603-15 by GLSA coordinator Tobias Heinlein (keytoaster).
Reopening for arm64.