I upgraded from openssl-1.0.2f to openssl-1.0.2g Using 1.0.2f layman works fine. Using 1.0.2g using layman causes the following error: (note that rolling back to 1.0.2f fixes the issue) # layman -L * Fetching remote list... * Connector.connect_url(); Failed to update the mirror list from: https://api.gentoo.org/overlays/repositories.xml * SSLError was:Can't connect to HTTPS URL because the SSL module is not available. Note that I am using dev-python/pyopenssl-0.15.1-r1 which was upgraded at the same time as openssl-1.0.2f # qlop -l | grep openssl Wed Mar 11 14:13:14 2015 >>> dev-python/pyopenssl-0.14 Wed Mar 11 14:34:56 2015 >>> dev-libs/openssl-1.0.2-r2 Sat Mar 14 11:13:25 2015 >>> dev-libs/openssl-1.0.2-r2 Tue Mar 17 16:38:04 2015 >>> dev-libs/openssl-1.0.2-r2 Wed Mar 18 11:51:09 2015 >>> dev-libs/openssl-0.9.8z_p5 Fri Mar 20 12:44:23 2015 >>> dev-libs/openssl-1.0.2a Wed Mar 25 01:03:51 2015 >>> dev-libs/openssl-1.0.2a Mon Jun 15 12:35:15 2015 >>> dev-libs/openssl-1.0.2c Fri Jul 10 00:57:10 2015 >>> dev-libs/openssl-1.0.2d Sun Oct 4 00:40:38 2015 >>> dev-libs/openssl-1.0.2d-r2 Fri Dec 4 08:59:30 2015 >>> dev-libs/openssl-1.0.2e Fri Jan 29 09:37:50 2016 >>> dev-libs/openssl-1.0.2f Fri Jan 29 09:40:36 2016 >>> dev-python/pyopenssl-0.15.1-r1 Tue Mar 1 09:00:07 2016 >>> dev-libs/openssl-1.0.2g So my best quess would be that there is something in openssl-1.0.2g that is not working with pyopenssl-0.15.1-r1
See bug #575548 comment #3. Almost everything linked against the old openssl now dies with "undefined symbol: SSLv2_server_method" and has to be rebuilt.
(In reply to Holger Hoffstätte from comment #1) > See bug #575548 comment #3. Almost everything linked against the old openssl > now dies with "undefined symbol: SSLv2_server_method" and has to be rebuilt. Rebuild everything linking to openssl: # revdep-rebuild.sh -i -L "libssl\.so.*" -- --exclude=openssl
*** Bug 576154 has been marked as a duplicate of this bug. ***
For reference, this has come up before: https://bugs.gentoo.org/show_bug.cgi?id=537452
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 Lars Wendler (Polynomial-C) from comment #5) > 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). Adding a subslot requires all dependencies to use a `:=` slot dep to be reliably effective right? Perhaps adding enable-ssl2 to fix the current ABI break and follow up with the slot fix later? Also, if a subslot deps are enough to protect users perhaps making it more generic to prepare for sslv3 deprecation would be helpful: SUBSLOT=1 use sslv2 && SUBSLOT=$((SUBSLOT+2)) use sslv3 && SUBSLOT=$((SUBSLOT+4)) SLOT="0/$SUBSLOT" Or some such scheme. If it is possible for emerge to fail after openssl but before deps are rebuilt (when parallel fetch disabled perhaps?) then adding the subslot to the soname could help survive the transition.
I've written a forum thread so people have some clues how to fix this mess :-( https://forums.gentoo.org/viewtopic-p-7886940.html
FWIW, in CoreOS we are taking the enable-ssl2 approach and things look OK so far: https://github.com/coreos/coreos-overlay/commit/831e702fea5f9c6c95ff6778e45653586e6a6953 It's going to take a fair amount of testing before we can ship openssl without ssl2, last I tried (some time last year?) I tabled it since it was more trouble then I had time for at the time. :-/
wget 1.17.1-r1 uses a subslot now: https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=885437bfa2b7d96e6aa6dc846f0123051496b5d3
*** Bug 576206 has been marked as a duplicate of this bug. ***
*** Bug 576226 has been marked as a duplicate of this bug. ***
*** Bug 576208 has been marked as a duplicate of this bug. ***
*** Bug 576228 has been marked as a duplicate of this bug. ***
Excuse me, but WHO IN THEIR RIGHT MIND does such a breaking ABI change in a basically-core system library with no SONAME change? I mean, people in Gentoo are used to base-system team causing random breakage like 'you upgrade this random lib, and everything is broken now, enjoy' but then, we have things like preserved-libs to lighten the load. Which doesn't help at all if you just randomly change stuff keeping the same SONAME... Not to mention nobody bothered to give other developers a heads up -- to let us prepare our packages, and make it even possible to start rebuilding all the suddenly-broken stuff...
*** Bug 576166 has been marked as a duplicate of this bug. ***
right, is where simple tool exists for years, namely, revdep-rebuild gives way better results than sub-slot artificial framework which only complexifying things. Add revdep-rebuild to portage and sub-slots probably going die.
(In reply to Oleg from comment #16) > right, is where simple tool exists for years, namely, revdep-rebuild gives > way better results than sub-slot artificial framework which only > complexifying things. Add revdep-rebuild to portage and sub-slots probably > going die. Subslots are a great addition to PMS, but they're not a substitute for correct revisioning of SONAME. The latter is far more important, even if we'd prefer that both be done. I suspect this caught the maintainers unaware.
So, any chance of an urgent news item or something? The forum post is nice, but easily missed until everything is broken.
From above: I tried the revdeb-rebuild approach: Rebuild everything linking to openssl: # revdep-rebuild.sh -i -L "libssl\.so.*" -- --exclude=openssl and it failed midway thorugh. So I reverted back to 1.0.2f Is there a compelling reason to upgrade to 1.0.2g? If yes, is this the right way to do it? I've written a forum thread so people have some clues how to fix this mess :-( https://forums.gentoo.org/viewtopic-p-7886940.html
*** Bug 576280 has been marked as a duplicate of this bug. ***
(In reply to Michał Górny from comment #14) > Excuse me, but WHO IN THEIR RIGHT MIND does such a breaking ABI change in a > basically-core system library with no SONAME change? > > I mean, people in Gentoo are used to base-system team causing random > breakage like 'you upgrade this random lib, and everything is broken now, > enjoy' but then, we have things like preserved-libs to lighten the load. > Which doesn't help at all if you just randomly change stuff keeping the same > SONAME... > > Not to mention nobody bothered to give other developers a heads up -- to let > us prepare our packages, and make it even possible to start rebuilding all > the suddenly-broken stuff... Michal, Please bring a level head to a bug and don't use all caps and CC comrel and qa without having a clue. Upstream did this and you can read their write up that I've attached in the URL field. Basically there is no way to close a high risk CVE without disabling SSLv2 because most applications do not do the right thing when using the OpenSSL API. They chose to disable SSLv2 by default. Their plan was to disable it in their upcoming OpenSSL 1.1.0 release but unfortunately this flaw was discovered and they took action quicker. (In reply to mike@marineau.org from comment #8) > FWIW, in CoreOS we are taking the enable-ssl2 approach and things look OK so > far: > https://github.com/coreos/coreos-overlay/commit/ > 831e702fea5f9c6c95ff6778e45653586e6a6953 > > It's going to take a fair amount of testing before we can ship openssl > without ssl2, last I tried (some time last year?) I tabled it since it was > more trouble then I had time for at the time. :-/ I'd recommend you understand the security advisory and how it impacts CoreOS and make sure you are not making your customers vulnerable.
*** Bug 576276 has been marked as a duplicate of this bug. ***
*** Bug 576274 has been marked as a duplicate of this bug. ***
(In reply to Doug Goldstein from comment #21) > (In reply to mike@marineau.org from comment #8) > > FWIW, in CoreOS we are taking the enable-ssl2 approach and things look OK so > > far: > > https://github.com/coreos/coreos-overlay/commit/ > > 831e702fea5f9c6c95ff6778e45653586e6a6953 > > > > It's going to take a fair amount of testing before we can ship openssl > > without ssl2, last I tried (some time last year?) I tabled it since it was > > more trouble then I had time for at the time. :-/ > > I'd recommend you understand the security advisory and how it impacts CoreOS > and make sure you are not making your customers vulnerable. Yes we understand that, my current plan is 1.0.2g w/ ssl2 this week, without ssl2 next week.
(In reply to Michał Górny from comment #14) > Excuse me, but WHO IN THEIR RIGHT MIND does such a breaking ABI change in a > basically-core system library with no SONAME change? I'd say upstream. But back to a technical discussion. We need a solution for this ASAP. What about introducing a gentoo-specific soname (for this version only)? With this we would have the @preserved-libs features available. It breaks a ton of *-bin packages that would have to be rebuilt anyway due to the ABI breakage.
This may or may not be relevant at this point in time, but note also that since portage depends on wget for fetching sources, and wget failing with wget: symbol lookup error: wget: undefined symbol: SSLv2_client_method after the openssl upgrade (and neither @preserved-rebuild nor revdep-rebuild could detect wget, curl, etc breakage), some users might have to manually copy distfiles onto their systems during attempts to fix the damage caused by this. Perhaps this might even warrant an `eselect news` warning?
What about a patch that includes the missing symbols in the exports but returns an error/NULL on call? This would keep binaries working, as long as they don't actually use SSL2.
@mike: (Comment #8) : Are you sure you want to go that path? Because OpenSSL changed that default because of CVE-2016-0800 https://www.openssl.org/news/secadv/20160301.txt
(In reply to Doug Goldstein from comment #21) > Please bring a level head to a bug and don't use all caps and CC comrel and > qa without having a clue. Upstream did this and you can read their write up > that I've attached in the URL field. Basically there is no way to close a > high risk CVE without disabling SSLv2 because most applications do not do > the right thing when using the OpenSSL API. They chose to disable SSLv2 by > default. Their plan was to disable it in their upcoming OpenSSL 1.1.0 > release but unfortunately this flaw was discovered and they took action > quicker. Upstream doing something insane doesn't mind Gentoo developers need to silently expose all our users to unusable systems without any warning or thinking. Upstream is not an excuse. Otherwise, you'd be all running systemd. (In reply to Matthias Maier from comment #25) > What about introducing a gentoo-specific soname (for this version only)? > With this we would have the @preserved-libs features available. It breaks a > ton of *-bin packages that would have to be rebuilt anyway due to the ABI > breakage. I don't see a good solution here. Can we change SONAME, get preserved-libs working and keep compatibility with binary software at the same time? I doubt it. So the best we can get this way is temporarily breaking binary packages, then breaking upgrades for stable systems. (In reply to Kai Dietrich from comment #27) > What about a patch that includes the missing symbols in the exports but > returns an error/NULL on call? This would keep binaries working, as long as > they don't actually use SSL2. Exactly my point. Though I'd rather make the symbols silently map to TLSv12 or whatever else people are supposed to use. This will solve the underlying security issues while keeping apps working. Alternatively, we mask this and we do the huge work of fixing revdeps. We force all relevant symbols off (so revdeps work with old and new versions), and add a lot of blockers to ensure that at least important revdeps are rebuilt before openssl.
Maybe we could contact FreeBSD downstream maintainers, that are hitting the same problem, to try to help us to convince upstream about bumping soname version :) https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=195796#c47
(In reply to georg from comment #28) > @mike: (Comment #8) : Are you sure you want to go that path? Because OpenSSL > changed that default because of CVE-2016-0800 > > https://www.openssl.org/news/secadv/20160301.txt Fedora is following that same path for now... but I will try to follow their bug reports to see what they end up doing finally :| http://pkgs.fedoraproject.org/cgit/rpms/openssl.git/commit/?id=8f6be98bf7b9e9015ad035f34b8414e82c7b68ca
Here's what I'll do: - add openssl-1.0.2g-r2.ebuild that adds back 'enable-ssl2' and drops the SUBSLOT. We'll investigate a path forward with other downstreams and make a decision from there. @security: do you concur?
*** Bug 576324 has been marked as a duplicate of this bug. ***
*** Bug 576322 has been marked as a duplicate of this bug. ***
I would instead strongly recommend that you add an "insecure-sslv2" USE flag for this, which is by default OFF. Packages that need the v2 symbols can then be adjusted to have a USE dep on this USE flag. I realize that even with that enabled at compile time, applications now are required to specifically opt-in to SSLv2 by clearing a no-sslv2 runtime flag, so that should ensure that even applications that do depend on this USE flag won't necessarily be vulnerable. However, since removing SSLv2 at compile time drastically reduces potential attack surface, it's something that should happen by default. Over time the number of packages that depend on the "insecure-sslv2" USE flag will shrink to zero, and then we can get rid of it all together. This is, from a security perspective, a preferred way of handling things, while still not breaking users' systems. This is the official perspective of the Gentoo Security Auditing project.
(In reply to Jason A. Donenfeld from comment #35) > I would instead strongly recommend that you add an "insecure-sslv2" USE flag > for this, which is by default OFF. Packages that need the v2 symbols can > then be adjusted to have a USE dep on this USE flag. I realize that even > with that enabled at compile time, applications now are required to > specifically opt-in to SSLv2 by clearing a no-sslv2 runtime flag, so that > should ensure that even applications that do depend on this USE flag won't > necessarily be vulnerable. However, since removing SSLv2 at compile time > drastically reduces potential attack surface, it's something that should > happen by default. Over time the number of packages that depend on the > "insecure-sslv2" USE flag will shrink to zero, and then we can get rid of it > all together. This is, from a security perspective, a preferred way of > handling things, while still not breaking users' systems. This is the > official perspective of the Gentoo Security Auditing project. Default OFF is what's breaking users systems and not allowing them to move forward. Your suggestion solves nothing. I could get behind USE="+ssl2". I would prefer we keep those symbols in there and have a patch to return some form of failure when ssl2 symbols are called.
Just to clarify -- Breakage can be fixed either by sorting out the slotting situation, or, this command did it for me: $ emerge -1 $(equery d dev-libs/openssl | sed 's/^/=/') Absolutely do not, however, enable `enable-ssl2` for all users. If necessary have this behind a USE flag (which can have a USE dep) called "insecure-sslv2" or similar.
Why not bump soname version? If I don't misremember either Ubuntu or Debian already did this for disabling sslv3 (not 2) Regarding the USE flag for sslv2, I don't think it's necessary: distributions like Debian and openSuSE are living without sslv2 for a long time and already passed by this. The issue here is how to prevent the breakage on reverse deps. In those distributions it wasn't such a burden because they were able to rebuild all the stuff during their development cycle. Fedora and Mageia (I think Cygwin people also needed to re-enable sslv2 because of this issue) are the few that are hitting this problem now as they cannot rebuilt all the reverse deps for latest Fedora released version and, hence, they are re-enabling sslv2, probably until they finally kill sslv2 support completely for next Fedora major release.
Ahh, thanks for that summary, okay. If you're content with disabling sslv2 and not having an option to reenable it, that's fine too. My response so far has been responding to "@security: do you concur?", warranting my response of "no". But if there's no chance of enabling ssl2 again, even better. A soname change seems okay to me, but I'll leave that discussion to the rest of yall.
If we are going to bump soname version, maybe it would be a good chance to also try to disable sslv3 as Debian did in 2014 and ArchLinux people are trying to do now: https://projects.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/openssl&id=4b82ed4285c7cb76caf6d75a015c5a7542c625d1 https://bugs.archlinux.org/task/39793?project=1&cat%5B0%5D=31&string=openssl
If it helps I've been disabling both in server software everywhere for years, so minimal impact. I do think we should do both at the same time.
I would certainly be in favor of this. TLSv1.0 can be enabled in all version of Internet Explorer >=4. It was enabled by default in IE7.
I have also seen that Debian is living for a long time with all the stuff under "Clean out patent-or-otherwise-encumbered code" part in ebuild disabled without major issues: http://anonscm.debian.org/viewvc/pkg-openssl/openssl/trunk/debian/rules?revision=760&view=markup And this is their soname.patch that they needed when disabling sslv3 in 2014 (they disabled sslv2 in 2010 or similar), maybe we could do the same for disabling all the "danger" stuff together in one round... http://anonscm.debian.org/viewvc/pkg-openssl/openssl/trunk/debian/patches/soname.patch?revision=747&view=markup Other option would be to do the opposite, I mean, re-enable sslv2 and wait for upstream soname bump for 1.1 series... but I have no idea about their Roadmap and how much time would run until 1.1 is ready
> Other option would be to do the opposite, I mean, re-enable sslv2 and wait Veto.
Also, all this issue has reminded me the problem of we don't starting to add := deps until the problem happens the first time :( It's the same with we not specifying SLOTs until a new slot is added and we need to fix all reverse deps quickly
(In reply to Pacho Ramos from comment #45) > Also, all this issue has reminded me the problem of we don't starting to add > := deps until the problem happens the first time :( It's the same with we > not specifying SLOTs until a new slot is added and we need to fix all > reverse deps quickly It can be problematic to add := without knowing how the subslot is actually used for that dependency (see what happened with poppler). I would suggest describing in the package metadata exactly what the subslot means/tracks first.
(In reply to Jason A. Donenfeld from comment #44) > > Other option would be to do the opposite, I mean, re-enable sslv2 and wait > > Veto. I know that option is risky, but seeing that it's the pathway taken by all distributions hitting this issue *now* (for now, Fedora, PLD, Mageia, Cygwin and FreeBSD I think) maybe it cannot be vetoed so "easily" :/ I mean, vetoying is easy, but preventing people from getting a broken system is harder (specially when, for example, a user can get wget broken and, if he/she doesn't have the sources downloaded, it can be a huge problem) Anyway, I would prefer the soname version change and disabling all the obsolete stuff together if it's technically possible (that I don't know :( ). For that, I will wait for the openssl maintainers that will know far more than me :)
(In reply to Michael Palimaka (kensington) from comment #46) > It can be problematic to add := without knowing how the subslot is actually > used for that dependency (see what happened with poppler). I would suggest > describing in the package metadata exactly what the subslot means/tracks > first. Well, the main problem is how to decide what the subslot will mean in the future :| Anyway, for some libs (like this, or bzip2 for example) it would be easy to always depend on them with := (those packages providing only one lib or a few libs that tend to go together), in that cases I think there would not be many cases of "useless" rebuilds in the case of bumping. But for that maybe we would need to have a repoman check with a static list we could update adding the packages that we want to always depend on using :=
Yes of course -- the goal here is to fix users' systems. Still, even with that as a goal, I believe we can come up with a smart solution for not borking systems worldwide. The reason why Fedora & friends are keeping things enabled is because they /can't/ rebuild. Fortunately, we don't have that issue. So, let's leave that aside. It goes without saying that SSLv2 is to be left removed. Now the question is: should we also remove SSLv3? The writing is on the wall upstream: SSLv3 removal is next. So, I think in order to save having to make users rebuild twice, and having two soname bumps, we should instead just do a soname bump now, and remove both SSLv2 and SSLv3. That should ensure, with some degree of certainty, that we don't have to deal with this in depth for some time. It also fixes the problem for users (@preserved-rebuild to the rescue) and ensure that they aren't inconvenienced twice. So -- how about it? Soname bump and remove both SSLv2 and SSLv3?
(In reply to Pacho Ramos from comment #48) > (In reply to Michael Palimaka (kensington) from comment #46) > > It can be problematic to add := without knowing how the subslot is actually > > used for that dependency (see what happened with poppler). I would suggest > > describing in the package metadata exactly what the subslot means/tracks > > first. > > Well, the main problem is how to decide what the subslot will mean in the > future :| > > Anyway, for some libs (like this, or bzip2 for example) it would be easy to > always depend on them with := (those packages providing only one lib or a > few libs that tend to go together), in that cases I think there would not be > many cases of "useless" rebuilds in the case of bumping. But for that maybe > we would need to have a repoman check with a static list we could update > adding the packages that we want to always depend on using := metadata.xml does already support describing subslots, so maybe we could base such a repoman check on that instead of hard-coding a package list.
> preventing people from getting a broken system is harder (specially when, for > example, a user can get wget broken and, if he/she doesn't have the sources > downloaded, it can be a huge problem) At the least, I would still like to have ssl2 and/or ssl3 USE flags, call them insecure-ssl2 and insecure-ssl3 if you like, kept available long term, for other reasons: ability to make client-side testing tools like sslscan, etc. that can interrogate a badly configured SSL service. See bug #575548 In the meantime, to avoid being left in a situation where I just broke my wget but don't have wget sources available, I've started doing this *before* upgrading openssl w/o ssl2 support: revdep-rebuild -L libssl.so -- -f ...That is to say, prefetch all the distfiles I'm going to need as soon as I upgrade past the point where everything needing ssl2 symbols will break (which is only a subset of binaries linking against libssl.so, but that's OK with me). But that got me thinking: can such a thing be triggered by pkg_setup in the openssl ebuild? At the very least, for wget's sources, which would be enough to proceed with the rest? I don't know check-reqs.eclass well at all, but at a quick look it seems no... but maybe someone who knows portage better will see a way to make that work?
What I would do is: 1. Enable sslv2 again in existing ebuild in testing for stop breaking systems (we are the only major distribution that, after knowing this problem, is still keeping the breakage) 2. Do a masked revision bump with the soname change and disabling *all* (also sslv3) stuff that will die soon anyway. 3. Ask Toralf to run a tinderbox and try to see if we can fix reverse deps still needing the old protocols (fixes for this will likely exist in the distributions that did this some time ago like Debian). 4. Finally unmask and stabilize relying on preserve-libs to save us this time Pending for the future: decide how should we start specifying slots and subslots for preventing this breakages in the future and finally take advantage of the "predicted" rebuild subslotting allow us :)
(In reply to Pacho Ramos from comment #52) > What I would do is: > 1. Enable sslv2 again in existing ebuild in testing for stop breaking > systems (we are the only major distribution that, after knowing this > problem, is still keeping the breakage) yes please. we all know the dangers but a broken system is worse. > 2. Do a masked revision bump with the soname change and disabling *all* > (also sslv3) stuff that will die soon anyway. agreed. i don't understand why upstream didn't do an SONAME bump. if someone has a reason why its bad to do so downstream, please comment. > 3. Ask Toralf to run a tinderbox and try to see if we can fix reverse deps > still needing the old protocols (fixes for this will likely exist in the > distributions that did this some time ago like Debian). > 4. Finally unmask and stabilize relying on preserve-libs to save us this time safe way forward. i like it. > > Pending for the future: decide how should we start specifying slots and > subslots for preventing this breakages in the future and finally take > advantage of the "predicted" rebuild subslotting allow us :) add subslotting to everything that consumes libraries. the only bad thing is you might have overkill in rebuilding, but at least you know it'll work.
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.
*** Bug 576374 has been marked as a duplicate of this bug. ***
(In reply to Doug Goldstein from comment #54) > 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. There are a lot of "even if's" in that commit message. They've gone a long way to mitigate the problem. I think we're safe enough with your plan and we avoid overdoing it by changing sonames etc.
Created attachment 427366 [details, diff] Proposition for a new openssl-1.0.2g-r3.ebuild If no soname bump is made by upstream or us (best solution by far of course, except for the hopefully few who disabled FEATURES="preserve-libs", which was enabled by default about three years ago I think), I'd say this calls for a big fat messy pkg_pretend() in a new openssl-1.0.2g-r3...? :) I propose in this patch, to temporarily require wget[static], if wget is compiled with [ssl,-gnutls,-libressl] (that is, it actually depends on OpenSSL). Plus instructions for `revdep-rebuild -i -L \"libssl.so.*\"` at the end (the library must be specified, as `revdep-rebuild` only detects missing libraries, not missing symbols as is the case here without a soname bump). I readded the subslot, because it can help if the user does not run the `revdep-rebuild` command immediately. These modifications will have to be kept in new OpenSSL ebuilds until there is a new soname, to take advantage of FEATURES="preserve-libs" with the proper ebuild modifications (preserve_old_lib() on libssl.so.1.0.0, and on libcrypto.so.1.0.0 if bumped too). Note that if we bump the soname ourselves to 1.0.2, there is a risk that when upstream decides to bump it, they may take this as an opportunity to make other ABI changes (possibly other security-related ones at least)... If they don't bump the package version number too, we would have the same situation again on our hands, except we'd be responsible for it this time... I thus suggest that if we do bump the soname version ourselves, we bump it to 1.0.1, instead of 1.0.2... It will mean more recompiling when upstream does bump it themselves to 1.0.2, but at least no risk of a new ABI break without a soname change... All that being said, like I talked about in bug 575548, comment 7, my USE="-static -gnutls ssl" stable wget, which thus properly linked to /usr/lib64/libssl.so.1.0.0 (I checked with `ldd`), was not crashing after emerging dev-libs/openssl-1.0.2g (and nothing else), even when downloading a file using HTTPS... And I could emerge new packages not downloaded beforehand just fine too. Am I an exception? (other programs sure crashed, though, like Layman or Deluge, and probably some more important ones...). Are some of you using more SSL-related features in Portage (or simply SSH sync/mirrors?), which triggered the crash in wget (or maybe the crash wasn't actually with wget...?), while it won't happen with most users? Nothing which could be temporarily disabled, even if dirty? Well, it would require a manual intervention anyway, until wget is recompiled, but for those who already encountered the issue, it could possibly be easier to recover. Some of my configuration: FEATURES="assume-digests binpkg-logs clean-logs collision-protect compress-build-logs compressdebug config-protect-if-modified distlocks ebuild-locks fixlafiles merge-sync multilib-strict news parallel-fetch preserve-libs sandbox sfperms split-elog split-log splitdebug strict suidctl unknown-features-filter unknown-features-warn unmerge-logs unmerge-orphans userfetch userpriv usersandbox usersync" GENTOO_MIRRORS="ftp://ftp.free.fr/mirrors/ftp.gentoo.org ftp://mir1.ovh.net/gentoo-distfiles ftp://mir2.ovh.net/gentoo-distfiles" Default PORTAGE_RSYNC_OPTS and FETCHCOMMAND*. For syncing Portage: sync-uri = rsync://rsync.fr.gentoo.org/gentoo-portage
Created attachment 427374 [details, diff] Revised proposition for a new openssl-1.0.2g-r3.ebuild I adjusted the error message to say that even if the user wants to keep wget statically-linked, he must of course recompile it once to include the upgraded OpenSSL libraries...
Created attachment 427376 [details, diff] Rerevised proposition for a new openssl-1.0.2g-r3.ebuild Forgot to add the slot to openssl version check... without it, people who still have openssl-0.9.8 would have seen the error message every time... Sorry for the flood...
It may be better if users can turn the check into warning with an environment variable, because they may have wget sources available and don't want to rebuild.
(In reply to Kanito Tasoga from comment #59) > Created attachment 427376 [details, diff] [details, diff] > Rerevised proposition for a new openssl-1.0.2g-r3.ebuild <QA> Thank you for the patch, but this would be a regression from -r2 (see comment 54), since it would remove the enable-ssl2 option again. If an incompatible change breaks the ABI then there must be a SONAME bump, in order to ensure that mechanisms like preserved-libs will catch any resulting fallout. Trying to limit the damage instead by displaying messages to the user is not a viable approach. </QA>
(In reply to Ulrich Müller from comment #61) > [...] > If an incompatible change breaks the ABI then there must be a SONAME bump, > in order to ensure that mechanisms like preserved-libs will catch any > resulting fallout. Trying to limit the damage instead by displaying messages > to the user is not a viable approach. > </QA> We have 2 problems: 1) Libs/applications which just link to libssl.so* which are now failing because some symbols are gone, because upstream has disabled SSLv2 per default. 2) Libs/application which are really using SSLv2 don't work anymore and require a patch (see https://github.com/openssl/openssl/commit/9dfd2be8a1761fffd152a92d8f1b356ad667eea7). Problem #1 doesn't warrant a SONAME change: That can happen in any application/lib on Gentoo via USE flag change. I.e. package libfoo also supports "bar". The "bar" feature can be removed via USE flag. If an application links against libfoo and the user will rebuild libfoo with toggled "bar" USE flag, the application will fail. That's a problem we cannot catch but try to avoid by depending on USE flags: I.e. the failing application could have set DEPEND="libfoo[bar]" -- however this wouldn't help if this application don't really need "bar" support but was just linked against libfoo with bar support which is now gone. So yes, with openssl-1.0.2g we should re-enable sslv2 like we have done now with -r2. But please introduce a new USE flag "sslv2" so people can disable sslv2 support if they want to stick with upstream's default and applications which require sslv2 can tell via DEPEND. This will allow us to work on a smooth migration path away from SSLv2. Problem #2 seems to warrant a SONAME change. This is still unresolved in Gentoo. And I don't understand why -r2 has removed the sub slot. Regarding the proposed -r3 patch: revdep-rebuild (the one without ".sh") don't support GLOB nor regular expressions, see https://bugs.gentoo.org/show_bug.cgi?id=568480#c17. So we should either recommend "revdep-rebuild.sh" usage or provide a really working example for the new Python version.
How about we do the following: leave SSLv2 symbol compat enabled as it is now, and start tracking applications that use SSLv2 symbols. Finding them should be relatively easy (we can just check for specific symbols being in use after all), then we patch SSLv2 out of them. This way, we satisfy all goals: nothing user-visible breaks, applications are secure (even if using older OpenSSL), and at some random point they will be ready for the symbols being removed upstream for good.
(In reply to Michał Górny from comment #63) > How about we do the following: leave SSLv2 symbol compat enabled as it is > now, and start tracking applications that use SSLv2 symbols. Finding them > should be relatively easy (we can just check for specific symbols being in > use after all), then we patch SSLv2 out of them. > > This way, we satisfy all goals: nothing user-visible breaks, applications > are secure (even if using older OpenSSL), and at some random point they will > be ready for the symbols being removed upstream for good. That's actually an excellent idea. +1
(In reply to Pacho Ramos from comment #38) > Why not bump soname version? If I don't misremember either Ubuntu or Debian > already did this for disabling sslv3 (not 2) > > Regarding the USE flag for sslv2, I don't think it's necessary: > distributions like Debian and openSuSE are living without sslv2 for a long > time and already passed by this. The issue here is how to prevent the > breakage on reverse deps. In those distributions it wasn't such a burden > because they were able to rebuild all the stuff during their development > cycle. Fedora and Mageia (I think Cygwin people also needed to re-enable > sslv2 because of this issue) are the few that are hitting this problem now > as they cannot rebuilt all the reverse deps for latest Fedora released > version and, hence, they are re-enabling sslv2, probably until they finally > kill sslv2 support completely for next Fedora major release. Indeed, removing sslv3 sounds also a good idea to me, since it is deprecated as well (https://tools.ietf.org/html/rfc7568). Fedora dropped it too: http://pkgs.fedoraproject.org/cgit/rpms/openssl.git/tree/openssl-1.0.2g-disable-sslv2v3.patch testing @sabayon (https://github.com/Sabayon/for-gentoo/tree/master/dev-libs/openssl) now , and no problems so far
(In reply to mudler from comment #65) > (In reply to Pacho Ramos from comment #38) > > Why not bump soname version? If I don't misremember either Ubuntu or Debian > > already did this for disabling sslv3 (not 2) > > > > Regarding the USE flag for sslv2, I don't think it's necessary: > > distributions like Debian and openSuSE are living without sslv2 for a long > > time and already passed by this. The issue here is how to prevent the > > breakage on reverse deps. In those distributions it wasn't such a burden > > because they were able to rebuild all the stuff during their development > > cycle. Fedora and Mageia (I think Cygwin people also needed to re-enable > > sslv2 because of this issue) are the few that are hitting this problem now > > as they cannot rebuilt all the reverse deps for latest Fedora released > > version and, hence, they are re-enabling sslv2, probably until they finally > > kill sslv2 support completely for next Fedora major release. > > Indeed, removing sslv3 sounds also a good idea to me, since it is deprecated > as well (https://tools.ietf.org/html/rfc7568). Fedora dropped it too: > http://pkgs.fedoraproject.org/cgit/rpms/openssl.git/tree/openssl-1.0.2g- > disable-sslv2v3.patch > > testing @sabayon > (https://github.com/Sabayon/for-gentoo/tree/master/dev-libs/openssl) now , > and no problems so far s/Fedora dropped it too:/Fedora dropped it too by default:/
Do we have an estimate for when dev-libs/openssl-1.0.2g-r3 will be released? I've got some other packages (nodejs) that I want to install which are requiring openssl-1.0.2g-r2 but don't want to break my system again with the r2...
looks like upstream has addressed this for 1.0.2h: o Only remove the SSLv2 methods with the no-ssl2-method option. that means the options have been split into "no-ssl2" and "no-ssl2-method". the former changes the runtime to return an error/NULL results while the latter changes the ABI by dropping the SSLv2_* funcs entirely. i've added 1.0.2h-r1 with USE=sslv2 (disabled by default) which toggles no-ssl2.
https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=0c368fb17a68819926e0c7175be13b22c561b037
