Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 575548 (CVE-2016-0702, CVE-2016-0703, CVE-2016-0704, CVE-2016-0705, CVE-2016-0797, CVE-2016-0798, CVE-2016-0799, CVE-2016-0800) - <dev-libs/openssl-1.0.2g-r2: Multiple vulnerabilities (CVE-2016-{0702,0703,0704,0705,0797,0798,0799,0800})
Summary: <dev-libs/openssl-1.0.2g-r2: Multiple vulnerabilities (CVE-2016-{0702,0703,07...
Alias: CVE-2016-0702, CVE-2016-0703, CVE-2016-0704, CVE-2016-0705, CVE-2016-0797, CVE-2016-0798, CVE-2016-0799, CVE-2016-0800
Product: Gentoo Security
Classification: Unclassified
Component: Vulnerabilities (show other bugs)
Hardware: All Linux
: Normal normal with 1 vote (vote)
Assignee: Gentoo Security
Whiteboard: A3 [glsa stable]
: 576990 (view as bug list)
Depends on: 576776
  Show dependency tree
Reported: 2016-02-24 12:29 UTC by Tobias Heinlein (RETIRED)
Modified: 2016-05-24 19:27 UTC (History)
25 users (show)

See Also:
Package list:
Runtime testing required: ---

Add a USE flag to enable ssl2 in openssl, off by default. (openssl-1.0.2g_-ssl2.patch,858 bytes, patch)
2016-03-02 03:36 UTC, Hank Leininger
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Tobias Heinlein (RETIRED) gentoo-dev 2016-02-24 12:29:37 UTC
Draft advisory and patches available on request.
Comment 1 Tobias Heinlein (RETIRED) gentoo-dev 2016-02-26 15:17:24 UTC
Announcement public as per .
Comment 2 Lars Wendler (Polynomial-C) (RETIRED) gentoo-dev 2016-03-01 14:26:19 UTC
commit 7bf3f3ef8d44f51b7cbfbabc1282da60fcb5f715
Author: Lars Wendler <>
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 <>

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
Comment 3 Stefan Briesenick (RETIRED) gentoo-dev 2016-03-01 16:09:54 UTC

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...
Comment 4 Zoltán Halassy 2016-03-01 16:18:31 UTC
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?
Comment 5 Mike Gilbert gentoo-dev 2016-03-01 17:58:31 UTC
I would recommend setting a subslot in the openssl ebuild to trigger a rebuild of all reverse deps.
Comment 6 Andreas K. Hüttel archtester gentoo-dev 2016-03-01 18:15:18 UTC
(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.
Comment 7 Ryoto Yayame 2016-03-01 19:49:55 UTC
(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/ and /usr/lib64/ from openssl-1.0.2g

$ wget ""

... works fine for me.

Stable www-client/lynx and www-client/links browsers, also linking to and, 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
Comment 8 Stefan Briesenick (RETIRED) gentoo-dev 2016-03-01 20:40:02 UTC
Comment 9 Ryoto Yayame 2016-03-01 21:00:58 UTC
(In reply to Stefan Briesenick from comment #8)
> and:

Yep, rebuilding my versions of python solves the problem for Layman and Deluge.
Comment 10 Matthias Maier gentoo-dev 2016-03-01 21:18:48 UTC
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:

  # -i -L "libssl\.so.*" -- --exclude=openssl
Comment 11 Lars Wendler (Polynomial-C) (RETIRED) gentoo-dev 2016-03-01 21:58:55 UTC
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 <>
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 <>

 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
Comment 12 Hank Leininger 2016-03-02 03:34:33 UTC
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).
Comment 13 Hank Leininger 2016-03-02 03:36:41 UTC
Created attachment 427178 [details, diff]
Add a USE flag to enable ssl2 in openssl, off by default.
Comment 14 Oleh 2016-03-02 06:25:46 UTC
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/ (and 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.
Comment 15 Teika kazura 2016-03-02 11:12:51 UTC
1.0.1s is the corresponding security fix in 1.0.1 series. Perhaps you could add it to the portage tree. TIA

Comment 16 Pacho Ramos gentoo-dev 2016-03-02 11:54:14 UTC
(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))
Comment 17 Tobias Heinlein (RETIRED) gentoo-dev 2016-03-02 14:17:38 UTC
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.
Comment 18 Pacho Ramos gentoo-dev 2016-03-02 14:45:51 UTC
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
Comment 19 Oleh 2016-03-03 04:55:39 UTC
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.
Comment 20 Pacho Ramos gentoo-dev 2016-03-03 09:31:40 UTC
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
Comment 21 Doug Goldstein (RETIRED) gentoo-dev 2016-03-03 15:38:56 UTC
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.
Comment 22 Doug Goldstein (RETIRED) gentoo-dev 2016-03-03 18:11:23 UTC
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.


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.
Comment 23 Pacho Ramos gentoo-dev 2016-03-04 11:59:18 UTC
(-r2 shouldn't be affected by bug 576128)
Comment 24 Pacho Ramos gentoo-dev 2016-03-04 12:04:43 UTC
Also, was 0.9.8 slot fixed? You can find the patches in openSuSE for example:
Comment 25 Doug Goldstein (RETIRED) gentoo-dev 2016-03-06 00:16:05 UTC
(In reply to Pacho Ramos from comment #24)
> Also, was 0.9.8 slot fixed? You can find the patches in openSuSE for example:
> 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.
Comment 26 Richard Freeman gentoo-dev 2016-03-06 11:29:17 UTC
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?
Comment 27 Toralf Förster gentoo-dev 2016-03-06 16:25:46 UTC
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.
Comment 28 Agostino Sarubbo gentoo-dev 2016-03-06 19:37:32 UTC
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.
Comment 29 Agostino Sarubbo gentoo-dev 2016-03-07 08:04:51 UTC
amd64 stable
Comment 30 Jeroen Roovers (RETIRED) gentoo-dev 2016-03-08 13:42:22 UTC
Stable for HPPA PPC64.
Comment 31 Markus Meier gentoo-dev 2016-03-10 20:24:01 UTC
arm/x86 stable
Comment 32 Pacho Ramos gentoo-dev 2016-03-14 12:36:47 UTC
*** Bug 576990 has been marked as a duplicate of this bug. ***
Comment 33 Tobias Klausmann (RETIRED) gentoo-dev 2016-03-16 09:25:02 UTC
Stable on alpha.
Comment 34 Agostino Sarubbo gentoo-dev 2016-03-16 12:07:57 UTC
ppc stable
Comment 35 Agostino Sarubbo gentoo-dev 2016-03-19 11:39:58 UTC
sparc stable
Comment 36 Agostino Sarubbo gentoo-dev 2016-03-20 12:03:38 UTC
ia64 stable
Comment 37 GLSAMaker/CVETool Bot gentoo-dev 2016-03-20 13:54:09 UTC
This issue was resolved and addressed in
 GLSA 201603-15 at
by GLSA coordinator Tobias Heinlein (keytoaster).
Comment 38 Tobias Heinlein (RETIRED) gentoo-dev 2016-03-20 13:54:46 UTC
Reopening for arm64.