Currently we build with api=1.0.0: ./${config} \ --api=1.0.0 \ According to the docs, API 1.1.0 is also available.
--api=1.1.0 disables many deprecated features which would have a similar result as with previous revisions of openssl-1.1 that utilized "disable-deprecated" configure option.
In other words - upstream is generally not prepared for such a thing yet?
(In reply to Tomáš Mózes from comment #2) > In other words - upstream is generally not prepared for such a thing yet? Not sure I understand you. The more of the old openssl APIs you remove from openssl (which you do most aggressively with --api=1.1.0) the less software compiles against openssl without errors. See the tracker bug which I've added as a dependency of this bug now.
(In reply to Lars Wendler (Polynomial-C) from comment #3) > Not sure I understand you. The more of the old openssl APIs you remove from > openssl (which you do most aggressively with --api=1.1.0) the less software > compiles against openssl without errors. See the tracker bug which I've > added as a dependency of this bug now. Sorry I didn't make that clear - I meant the upstream that produces software that depends on OpenSSL (like apache httpd for example). So all software that depends on OpenSSL must first change their code to be compatible with OpenSSL api 1.1.0 and just then we can bump the api version in OpenSSL.
I would drop the complete "--api=" line. It will make it a little bit harder for some older applications but given that neither Debian, Ubuntu nor Fedora set this option... there will be a break between OpenSSL 1.0 to 1.1 and this doesn't really help. It will only delay the required work. Fedora in addition has an interesting approach: They still set "enable-ssl3", "enable-ssl3-method" and "enable-weak-ssl-ciphers". However they patched their OpenSSL version to disable SSLv3 at runtime. I.e. application really depending on SSLv3 need to call > SSL_CTX_clear_options(ctx, SSL_OP_NO_SSLv3); or use SSL_CONF library to enable. In addition, they have a package "crypto-policies" (https://gitlab.com/redhat-crypto/fedora-crypto-policies) which provides policies (default configurations). That allows you to enable deprecated cipher at anytime for specific applications when needed (testing/research) without the need to rebuild or enable these deprecated ciphers in general.
(In reply to Thomas Deutschmann from comment #5) > I would drop the complete "--api=" line. It will make it a little bit harder > for some older applications but given that neither Debian, Ubuntu nor Fedora > set this option... there will be a break between OpenSSL 1.0 to 1.1 and this > doesn't really help. It will only delay the required work. Yeah, that might be a reasonable approach. > Fedora in addition has an interesting approach: They still set > "enable-ssl3", "enable-ssl3-method" and "enable-weak-ssl-ciphers". However > they patched their OpenSSL version to disable SSLv3 at runtime. I.e. > application really depending on SSLv3 need to call > > > SSL_CTX_clear_options(ctx, SSL_OP_NO_SSLv3); > > or use SSL_CONF library to enable. > > In addition, they have a package "crypto-policies" > (https://gitlab.com/redhat-crypto/fedora-crypto-policies) which provides > policies (default configurations). That allows you to enable deprecated > cipher at anytime for specific applications when needed (testing/research) > without the need to rebuild or enable these deprecated ciphers in general. Definitely no for at least two reasons: First, SSLv{2,3} needs to die. Period. No exceptions. Nobody should use these protocols for whatever reason anymore. This should also happen to TLSv1.0 and TLSv1.1 but that's a different story. Second, apparently this is a patch that has low to none chance getting picked up by openssl upstream. So we'd have to carry such patches forever dealing with every fallout caused by them. If Fedora wants to deal with that it's their decision. I do not want to take responsibility for this within Gentoo.
(In reply to Lars Wendler (Polynomial-C) from comment #6) > Definitely no for at least two reasons: > > First, SSLv{2,3} needs to die. Period. No exceptions. Nobody should use > these protocols for whatever reason anymore. This should also happen to > TLSv1.0 and TLSv1.1 but that's a different story. Keep in mind that while you can use SSLv{2,3} with Fedora, it doesn't work out of the box. I.e. you need to *patch* the application which wants to use SSLv{2,3} like show, i.e. you need to compile your application with SSL_CTX_clear_options(ctx, SSL_OP_NO_SSLv3); So there is no risk that something will use SSLv{2,3} unexpected. I really like that because I still have to deal with old stuff. Not because I am really using SSLv{2,3} but if you want to do research/inventory scans, you still need to be able to do the handshake with ancient devices. And Gentoo is about choices. Do we want that users need to use unknown binaries from projects like testssl.sh or forks? The patch is very small. 2x 3 lines + documentation. Given that the patch uses an API (no hack) and 1.1.x is already feature complete and will only get bug fixes, maintaining this patch shouldn't be a problem. > Second, apparently this is a patch that has low to none chance getting > picked up by openssl upstream. This is an interesting question. But this patch is very small, too. Not sure if Fedora tried to get this upstreamed but at the moment I see no reason why this should get rejected (well, for 1.1.0 it is too late, like said, this branch will only receive bug fixes).
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=dbf565e8638eb2f7f13afb4e24e6c146abffcb74 commit dbf565e8638eb2f7f13afb4e24e6c146abffcb74 Author: Thomas Deutschmann <whissi@gentoo.org> AuthorDate: 2018-03-27 15:50:47 +0000 Commit: Thomas Deutschmann <whissi@gentoo.org> CommitDate: 2018-03-27 15:50:58 +0000 dev-libs/openssl: Bump to v1.1.0h Ebuild changes: =============== - API=1.0.0 config option dropped. [Bug 651074] Bug: https://bugs.gentoo.org/651074 Package-Manager: Portage-2.3.24, Repoman-2.3.6 dev-libs/openssl/Manifest | 4 + dev-libs/openssl/openssl-1.1.0h.ebuild | 283 +++++++++++++++++++++++++++++++++ 2 files changed, 287 insertions(+)}
