Current openssl ebuilds have '$(use_ssl !bindist ec)', disabling elliptic curve cryptography with bindist useflag However, this might need revision nowadays: - Fedora (and RHEL) re-enabled it https://bugzilla.redhat.com/show_bug.cgi?id=319901 - Patents mentionned in crypto/ec/ec2_oct.c are: - US Patents 6,141,420 and 6,618,483 are from July 29, 1994. US patents expire after 20 years, which makes us July 29, 2014, expired. - As I understand it, Certicom lost its case against Sony regarding violation of other patents (from 1995 and 1996) on ec cryptography because there was prior art and Certicom patents could be considered plagiarism. CC'ing licenses@ and trustees@, not sure who handle such things, but I am certainly not a lawyer and might have missed some points.
This doesn't look like a clear situation at all. But AFAICS, Debian has always distributed that code. They have some discussions in their lists that say that the algorithms are not patented (and cannot be patented?), but that there are only patents on specific curves. Somebody from the U.S. should comment on this, really.
By the way, the main reason why I'm bringing this is that some packages depend on openssl[-bindist] because they need elliptic curves, which makes them effectively non binary redistributable for a reason that seems no longer valid to me. Another reason is that swicthing on the bindist useflag on openssl changes the API (by removing public headers) and the ABI (by removing the underlying functions from libssl/libcrypto), which is far from ideal for an useflag. (elliptic curves is likely not sufficient to fix the latter though)
I would like to see us move forward here. Just had a tricky debugging of a problem where the problem turned out to be an openssl built with bindist. Some things: * redhat seemed to have a lot of worries and didn't ship ecc enabled openssl for some time, but these days they enabled ecc. I think they have done some extensive research on it. * there's rfc 6090 which indicated that ecdsa and ecdh are patent free tech. So I feel enabling it shouldn't make too much trouble.
Feodra/RHEL haven't just enabled them all. they apply some sizable patches, bundle their own ec_curve.c, manually hack out some files, and they disable ec2m. Certicom did not lose its case ... they settled and both parties agreed to drop the case. terms of said settlement are not public: https://en.wikipedia.org/wiki/ECC_patents#Certicom.27s_lawsuit_against_Sony that packages need to depend on openssl[-bindist] is the system working as designed. i don't see what point you're trying to make there. we have USE=bindist specifically for questionable things. i don't see the ECC situation being clear enough to warrant moving beyond that flag. i also don't see why this is an issue for people building their systems -- if you think it's a non-issue, then disable USE=-bindist for your builds. the only gotcha i see here is that USE=bindist currently controls more than ECC in openssl -- it also controls RC5. except the only listed patent for that expires tomorrow, so the next version will only control ECC :).
also, while the ABI aspect is pretty ugly, there really is no viable solution at this time. it's how upstream does it, and the code is a hairy mess for us to try and manually insert stubs into all the right places. bug 510798 has more details along those lines.
(In reply to SpanKY from comment #4) > that packages need to depend on openssl[-bindist] is the system working as > designed. i don't see what point you're trying to make there. assuming all patents are listed in openssl code, those patents have expired last year... thus depending on openssl[-bindist] because one needs ecc is not the system working as expected: it is the openssl ebuild not having been updated properly and propagating this crap to the other packages but again, it is hard to guarantee openssl people have done proper research and are listing all and every patent... (In reply to SpanKY from comment #4) > Certicom did not lose its case ... they settled and both parties agreed to > drop the case. terms of said settlement are not public: > https://en.wikipedia.org/wiki/ECC_patents#Certicom.27s_lawsuit_against_Sony dropping a case for patent infrigement is what i'd consider losing, but it is a matter of interpretation i guess (In reply to SpanKY from comment #4) > if you > think it's a non-issue, then disable USE=-bindist for your builds. thanks for the hint but... no thanks. see comment #2
(In reply to Alexis Ballier from comment #6) when two companies settle, they often both drop their cases. that's simply how the system works. i guess you consider all the major tech companies that settle patent lawsuits and subsequently drop their cases as meaning they all lost and thus their patents are invalid ? that's kind of ridiculous. just search for "patent settlement" and any set of company names like "apple samsung" or "apple google" or "microsoft samsung". the ABI breakage is unfortunate, but irrelevant. even if openssl exported dummy headers and stub symbols that always returned errors ("not implemented"), packages that rely on that code would still have to depend on openssl[-bindist]. i already read your comment #2 and the answer is the same: the system is WAI. i'm not seeing any clear guidance as to the patent landscape, and the behavior of other distros isn't really compelling: debate & RHEL stepping lightly means having an optional USE=bindist makes sense. really the only way this would change is if all the known patents expired or the trustees give it the go ahead.
(In reply to SpanKY from comment #7) > i'm not seeing any clear guidance as to the patent landscape, and the > behavior of other distros isn't really compelling: debate & RHEL stepping > lightly means having an optional USE=bindist makes sense. really the only > way this would change is if all the known patents expired or the trustees > give it the go ahead. agreed, and that's why i looked at openssl code for "known patents"... which have expired. do you or anyone else have other patents in mind ? Note: The certicom example was a bad example of me searching for patents on ecc, by no means have I checked whether openssl uses or not these patents.
*** Bug 559214 has been marked as a duplicate of this bug. ***
(In reply to Hanno Boeck from comment #3) > I would like to see us move forward here. Just had a tricky debugging of a > problem where the problem turned out to be an openssl built with bindist. > > Some things: > * redhat seemed to have a lot of worries and didn't ship ecc enabled openssl > for some time, but these days they enabled ecc. I think they have done some > extensive research on it. I'm hitting the ecc issue with tor, see bug #560780. For what its worth, it looks like redhat is allowing some ecc's. https://bugzilla.redhat.com/show_bug.cgi?id=319901
(In reply to Anthony Basile from comment #10) we analysed what redhat does already in this bug. it's a good amount of code and custom patches, not just toggling a configure flag.
Ok, so the situation has progressed somewhat -- with dev-python/pyopenssl-17.0.2 being stabilized and that version requiring EC in dev-libs/openssl (via dev-python/cryptography), we now have the first situation of an unresolvable conflict for gentoo's release media. I have no doubt there will be more as time goes on. I had started a thread on -core@ to discuss this, but the history of comments above is more complete and so I'm going to end that thread and point it here instead. Are the reasons for keeping EC disabled in USE=bindist still entirely valid or is it worth looking into this further? It's been three years, more things have expired, etc. etc.
(In reply to Ian Stakenvicius from comment #12) > Ok, so the situation has progressed somewhat -- with > dev-python/pyopenssl-17.0.2 being stabilized and that version requiring EC > in dev-libs/openssl (via dev-python/cryptography), we now have the first > situation of an unresolvable conflict for gentoo's release media. I have no > doubt there will be more as time goes on. > In the short term this might be an argument for reverting the stabilization done in bug 626836 in the event the conflict is valid for others users as well. in the release media case we can likely get away with just package.masking it as it isn't a security affecting upgrade or similar. But our stable users shouldn't suffer in the wake of it. > I had started a thread on -core@ to discuss this, but the history of > comments above is more complete and so I'm going to end that thread and > point it here instead. > > Are the reasons for keeping EC disabled in USE=bindist still entirely valid > or is it worth looking into this further? It's been three years, more > things have expired, etc. etc. This is difficult to answer without a thorough review of the source code, and defining use cases. iirc some of the NSA patents were only applicable if having FIPS-140-2 certification of the product, but if you can't build an embedded device based on Gentoo and have it certified, are we really providing fee software? (at least without notice) For the implementation specific matters I'm thinking immediately of whether point compression and/or MQV is used, these should be possible to verify looking at source only. A tip for where you might find more information is in Intellectual Property Right (IPR) disclosures for IETF protocols, iirc Certicom has some specific protocol grants e.g for the use in TLS. As far as I can see the relevant RedHat bug is https://bugzilla.redhat.com/show_bug.cgi?id=319901 that provides background to their rationale of patching and providing limited support (without having looked into the details, it seems they are relying somewhat on the NSA license obtained from certicom for Suite B curves, so implemented NIST curves but not brainpool/secp521r1). In any case, I recommend using caution when moving ahead with changing anything here, and it certainly requires a deep dive into the maths and procedures involved in ECC to interpret it.
There does not seem to be a copyright issue here. We are free to distribute the code and the binaries from that perspective. On the patent issue, we already distribute the code in source form via Gentoo mirrors. Why would distributing the compiled product be any different?
(In reply to Mike Gilbert from comment #14) > There does not seem to be a copyright issue here. We are free to distribute > the code and the binaries from that perspective. > > On the patent issue, we already distribute the code in source form via > Gentoo mirrors. Why would distributing the compiled product be any different? ++ It almost seems like a situation like this where end-use might or might not be covered by a patent could use a different USE flag. At the very least I think we could just set a package.use +bindist for this one package on the release media, since we know that one particular use doesn't infringe. Then individuals could still make their own determinations for their own uses.
(In reply to Mike Gilbert from comment #14) > There does not seem to be a copyright issue here. We are free to distribute > the code and the binaries from that perspective. > > On the patent issue, we already distribute the code in source form via > Gentoo mirrors. Why would distributing the compiled product be any different? Patent law is complicated, and differs between jurisdictions. In the United States, the Patent Act enumerates in https://www.uspto.gov/web/offices/pac/mpep/s2106.html what is eligible for a patent, namely i. a process, ii. machine, iii. manufacture, or iv. composition of matter. If I understand correctly, software would be eligible under categories ii. and iii. only if also a hardware component is included. And for i. (process) it is necessary to have "a set of instructions capable of being executed by a computer" which applies to object code but not to source code. IANAL, TINLA.
(In reply to Richard Freeman from comment #15) > At the very least I think we could just set a package.use +bindist for this > one package on the release media, since we know that one particular use > doesn't infringe. Then individuals could still make their own > determinations for their own uses. Did you mean to say we should add "-bindist" to package.use for openssl? Our release media already have USE="bindist" set globally.
(In reply to Mike Gilbert from comment #17) > (In reply to Richard Freeman from comment #15) > > At the very least I think we could just set a package.use +bindist for this > > one package on the release media, since we know that one particular use > > doesn't infringe. Then individuals could still make their own > > determinations for their own uses. > > Did you mean to say we should add "-bindist" to package.use for openssl? Our > release media already have USE="bindist" set globally. Yes, assuming that it is legal for this particular use.
So given all of this, what would be the next steps involved here to resolve it and get answers to the legal questions we need answers to, to move forward? Debian's legal team seems to have decided everything's fine, Redhat's decided only certain bits are fine. It sounds like we can't (or aren't going to) rely on either one of those evaluations, right? So should we i.e. enquire with the trustees to initiate our own legal audit of the situation? K_F gave some decent general guidance in comment 13 but actually doing it will involve the dedication of a sufficiently knowledgable person/group to do the research; so far it doesn't seem like we have any volunteers...
(In reply to Mike Gilbert from comment #17) > (In reply to Richard Freeman from comment #15) > > At the very least I think we could just set a package.use +bindist for this > > one package on the release media, since we know that one particular use > > doesn't infringe. Then individuals could still make their own > > determinations for their own uses. > > Did you mean to say we should add "-bindist" to package.use for openssl? Our > release media already have USE="bindist" set globally. That would seem to entirely circumvent the point of having USE=bindist on openssl in the first place.. I think if we were going to distribute openssl with EC support we should likely just drop the "bindist" flag as the means to control whether or not EC is included.
(In reply to Ian Stakenvicius from comment #20) > (In reply to Mike Gilbert from comment #17) > > (In reply to Richard Freeman from comment #15) > > > At the very least I think we could just set a package.use +bindist for this > > > one package on the release media, since we know that one particular use > > > doesn't infringe. Then individuals could still make their own > > > determinations for their own uses. > > > > Did you mean to say we should add "-bindist" to package.use for openssl? Our > > release media already have USE="bindist" set globally. > > That would seem to entirely circumvent the point of having USE=bindist on > openssl in the first place.. I don't see how. If in general openssl isn't reliably distributable, but it is in the specific case of the release media, then this gets us the best of both worlds. Our users who set USE=bindist won't get it automatically installed in the offending way, but our release media can still use the EC features. Usually copyrights/patents are all-or-nothing. However, a patent could only cover certain intended uses, or either a patent or copyright could be subject to a license that allows redistribution/use under some conditions but not others. In these cases the generic flags should be set to be restrictive, but it can be legal for us to override the flag when we know the specific use is non-infringing. This is not different from how a user might use license or bindist filtering. They would set the flag globally, but if they need a specific package or feature they could investigate more carefully and enable the flag or license when they've determined it won't adversely impact them. > I think if we were going to distribute openssl > with EC support we should likely just drop the "bindist" flag as the means > to control whether or not EC is included. I think that would be a change that would defeat the purpose of the bindist flag. I don't have a problem with the double flag as it makes it clear what bindist is actually doing, and there might be users who want USE=-bindist in general but don't want EC support. However, we shouldn't substitute EC for bindist because then users who set USE=bindist globally will end up with patent-encumbered code. Bindist doesn't just exist for release media. It is a service we provide just like license masking.
As the releng team lead, let me state that we (releng) are not willing to "take the buck" on this. We have a well established use flag "bindist", we will keep using it as it was meant. It is up to the openssl maintainers, the license team and Trustees to decide to drop the bindist use flag on openssl if they consider there is no reason to prevent the use of eliptic curves. As a developer and Foundation member, I hope / expect us not to make decisions that can cause us issues distributing our stages / ISOs.
(In reply to Jorge Manuel B. S. Vicetto from comment #22) > As the releng team lead, let me state that we (releng) are not willing to > "take the buck" on this. We have a well established use flag "bindist", we > will keep using it as it was meant. > It is up to the openssl maintainers, the license team and Trustees to decide > to drop the bindist use flag on openssl if they consider there is no reason > to prevent the use of eliptic curves. > > As a developer and Foundation member, I hope / expect us not to make > decisions that can cause us issues distributing our stages / ISOs. I don't think anybody has suggested setting USE=-bindist if it will create issues distributing our stages/ISOs. I only proposed this in the case that doesn't cause issues with distributing stages/ISOs but does create issues in distributing things other than stages/ISOs. Whether or not that is the case is TBD.
Created attachment 498420 [details, diff] openssl-1.1.0f-r1.ebuild-Fedora-Hobbled-EC.patch Patch for openssl-1.1.0f.ebuild to use Fedora's "Hobbled" EC code. The 1.0 series wasn't as easy to get it working on. Passes src_test with USE=bindist.
Created attachment 498554 [details, diff] openssl-1.1.0f-r2.ebuild-Fedora-Hobbled-EC.patch As requested by ulm, here is a variant that is based on upstream tarball & patches instead of RPM. openssl-1.1.0f-r1.ebuild-Fedora-Hobbled-EC.patch uses the Fedora RPM to get distfile & patches. openssl-1.1.0f-r2.ebuild-Fedora-Hobbled-EC.patch uses the Fedora script & patches on top of upstream tarball. The Makefile generated by them is slightly different, the ordering of DEPS and GENERATED differs, but contains the same items.
(In reply to Robin Johnson from comment #25) > Created attachment 498554 [details, diff] [details, diff] > openssl-1.1.0f-r2.ebuild-Fedora-Hobbled-EC.patch The ebuild resulting from this fails for me: $ ebuild openssl-1.1.0f-r2.ebuild digest Appending /repo/gentoo to PORTDIR_OVERLAY... /repo/gentoo/dev-libs/openssl/openssl-1.1.0f-r2.ebuild: line 47: syntax error near unexpected token `FEDORA_SRC_URI+=("${FEDORA_GIT_BASE}/${i}?h=${FEDORA_GIT_BRANCH} -> ${i}")' /repo/gentoo/dev-libs/openssl/openssl-1.1.0f-r2.ebuild: line 47: ` FEDORA_SRC_URI+=( "${FEDORA_GIT_BASE}/${i}?h=${FEDORA_GIT_BRANCH} -> ${i}" )' * ERROR: dev-libs/openssl-1.1.0f-r2::gentoo failed (depend phase): * error sourcing ebuild Looks like a semicolon is missing in the second for loop (line 46). After fixing that, it now fails in src_prepare: >>> Preparing source in /var/tmp/portage/dev-libs/openssl-1.1.0f-r2/work/openssl-1.1.0f ... bash: /var/tmp/portage/dev-libs/openssl-1.1.0f-r2/work/hobble-openssl: No such file or directory * ERROR: dev-libs/openssl-1.1.0f-r2::gentoo failed (prepare phase): * (no error message) * * Call stack: * ebuild.sh, line 124: Called src_prepare * environment, line 2866: Called die * The specific snippet of code: * bash "${WORKDIR}"/"${SOURCE1}" || die;
Created attachment 498580 [details, diff] openssl-1.1.0f-r2.ebuild-Fedora-Hobbled-EC-v2.patch ulm: sorry about that, attached the wrong edition of it, it was just a single missing semicolon.
Created attachment 498584 [details, diff] openssl-1.1.0f-r2.ebuild-Fedora-Hobbled-EC-v3.patch
The trustees talked about this at our meeting today, we've decided that the following should happen. 1. patch 1.1 (using fedora patch) 2. talk to debian (to see if their reasoning for shipping the without ECC disabled works for us) 3. (try to backport the patch for 1.0 OR work on getting 1.1 stable) robbat2 is patching 1.1 zlg is reaching out to debian
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=bdd5c9e7d6a375e99b3ae89afd4517a3a5786df2 commit bdd5c9e7d6a375e99b3ae89afd4517a3a5786df2 Author: Robin H. Johnson <robbat2@gentoo.org> AuthorDate: 2017-10-22 20:19:37 +0000 Commit: Robin H. Johnson <robbat2@gentoo.org> CommitDate: 2017-10-22 21:16:29 +0000 dev-libs/openssl: add Fedora Hobbled-EC. As resolved in the Foundation Trustees meeting 2017/10/22, and the Licensing team, Fedora's Hobbled-EC patchset is added for USE=bindist in OpenSSL 1.1 series. This provides the subset of Elliptic Curve Cryptography that Fedora & RedHat believe to be free of patent concerns at this time, and use for their RPMs. The patch disables or modifies: - some Elliptic Curves - some EC methods - code that interacts the above OpenSSL 1.1 is still in package.mask at this time, and a 1.0 version of this patch will follow soon. Upstream: https://src.fedoraproject.org/cgit/rpms/openssl.git Bug: https://bugs.gentoo.org/531540 Package-Manager: Portage-2.3.8, Repoman-2.3.3 Signed-off-by: Robin H. Johnson <robbat2@gentoo.org> dev-libs/openssl/Manifest | 5 + dev-libs/openssl/metadata.xml | 2 +- dev-libs/openssl/openssl-1.1.0f-r1.ebuild | 282 ++++++++++++++++++++++++++++++ 3 files changed, 288 insertions(+), 1 deletion(-)}
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=acd5dfadfd157c7dcb73a3ff1f6295416a2ab04e commit acd5dfadfd157c7dcb73a3ff1f6295416a2ab04e Author: Robin H. Johnson <robbat2@gentoo.org> AuthorDate: 2017-10-22 20:19:37 +0000 Commit: Robin H. Johnson <robbat2@gentoo.org> CommitDate: 2017-10-22 21:51:28 +0000 dev-libs/openssl: add Fedora Hobbled-EC for 1.0. As resolved in the Foundation Trustees meeting 2017/10/22, and the Licensing team, Fedora's Hobbled-EC patchset is added for USE=bindist in OpenSSL 1.0 series. This provides the subset of Elliptic Curve Cryptography that Fedora & RedHat believe to be free of patent concerns at this time, and use for their RPMs. The patch disables or modifies: - some Elliptic Curves - some EC methods - code that interacts the above This code passes the upstream testsuite with: FEATURES=test RESTRICT=bindist USE=test emerge =openssl-1.0.2l-r1 See-Also bdd5c9e7d6a375e99b3ae89afd4517a3a5786df2 Upstream: https://src.fedoraproject.org/cgit/rpms/openssl.git Bug: https://bugs.gentoo.org/531540 Package-Manager: Portage-2.3.8, Repoman-2.3.3 Signed-off-by: Robin H. Johnson <robbat2@gentoo.org> dev-libs/openssl/Manifest | 3 + dev-libs/openssl/openssl-1.0.2l-r1.ebuild | 296 ++++++++++++++++++++++++++++++ 2 files changed, 299 insertions(+)}
- OpenSSL 1.0.2l-r1 with patchset in the tree now, under NEW package.mask. - OpenSSL 1.1.0f-r1 with patchset in the tree now, under existing package.mask. I think we should get some really solid testing on 1.0.2l-r1 before it comes out of package.mask. releng: since you are the big consumer here, can you please test with 1.0.2l-r1? zlg is still going to reach out to Debian, so that we can potentially completely unrestrict it (unlikely, but good to know what their take is).
Created attachment 499726 [details] openssl-1.0.2l-r1-with-ec-ABI-compat.html Attached ABI compatibility report comparing USE=bindist/USE=-bindist on 1.0.2l-r1. It's not quite ready yet, the SRP functionality is breaking ABI compat.
Created attachment 499728 [details] openssl-1.0.2l-r1-with-ec-ABI-compat-libcrypto.html ABI report for libcrypto. Only missing symbols here: SRP, and various EC2M.
Created attachment 499736 [details] openssl-1.1.0f-r1-with-ec-ABI-compat-libcrypto.html
Created attachment 499738 [details] openssl-1.1.0f-r1-with-ec-ABI-compat-libssl.html
Assuming I can resolve the SRP issue in 1.0.2, the question remains, is the ABI incompatibility ok? Do those symbols get used ANYWHERE else in Gentoo?
I've added dev-python/cryptography-2.1.2-r1 to the tree, it can use the new openssls
anybody else tracking this, do NOT unmask 1.0.2l-r1; the SRP stuff causes too much ABI breakage this point.
Not sure this is the right place to ask but this weekend I tried to get some cross builds done in a chroot and qemu_user and I had problems getting wget to download files: wget -v http://devsrv.infinera.com --2017-12-03 18:21:37-- http://devsrv.infinera.com/ Resolving devsrv.infinera.com... 10.210.32.100 Connecting to devsrv.infinera.com|10.210.32.100|:80... connected. HTTP request sent, awaiting response... 301 Moved Permanently Location: https://devsrv.infinera.com/ [following] --2017-12-03 18:21:37-- https://devsrv.infinera.com/ Connecting to devsrv.infinera.com|10.210.32.100|:443... connected. OpenSSL: error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure I got the impression that this error boils down to server having openssl -bindist and client had openssl +bindist After rebuilding client with -bindist wget worked again. Is this expected behaviour for bindist?
forgot: openssl-1.0.2m
(In reply to Joakim Tjernlund from comment #40) > wget -v http://devsrv.infinera.com > --2017-12-03 18:21:37-- http://devsrv.infinera.com/ > Resolving devsrv.infinera.com... 10.210.32.100 > Connecting to devsrv.infinera.com|10.210.32.100|:80... connected. > HTTP request sent, awaiting response... 301 Moved Permanently > Location: https://devsrv.infinera.com/ [following] > --2017-12-03 18:21:37-- https://devsrv.infinera.com/ > Connecting to devsrv.infinera.com|10.210.32.100|:443... connected. > OpenSSL: error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert > handshake failure > > I got the impression that this error boils down to server having openssl > -bindist > and client had openssl +bindist > After rebuilding client with -bindist wget worked again. > > Is this expected behaviour for bindist? Hard to tell for an internal server ;) Check which cipher the server supports/allows and if you got a match with openssl[bindist]. If it only allows EC-based ciphers things are pretty clear.
(In reply to Thomas Deutschmann from comment #42) > (In reply to Joakim Tjernlund from comment #40) > > wget -v http://devsrv.infinera.com > > --2017-12-03 18:21:37-- http://devsrv.infinera.com/ > > Resolving devsrv.infinera.com... 10.210.32.100 > > Connecting to devsrv.infinera.com|10.210.32.100|:80... connected. > > HTTP request sent, awaiting response... 301 Moved Permanently > > Location: https://devsrv.infinera.com/ [following] > > --2017-12-03 18:21:37-- https://devsrv.infinera.com/ > > Connecting to devsrv.infinera.com|10.210.32.100|:443... connected. > > OpenSSL: error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert > > handshake failure > > > > I got the impression that this error boils down to server having openssl > > -bindist > > and client had openssl +bindist > > After rebuilding client with -bindist wget worked again. > > > > Is this expected behaviour for bindist? > Hard to tell for an internal server ;) Sure, but this is just a simple apache/ssl server with no special conf. altered that I am aware of. > > Check which cipher the server supports/allows and if you got a match with > openssl[bindist]. If it only allows EC-based ciphers things are pretty clear. Not sure how to check that, I am not familiar with openssl command, maybe you can suggest a command I can test with?
(In reply to Joakim Tjernlund from comment #43) > Not sure how to check that, I am not familiar with openssl command, maybe > you can suggest a command I can test with? In this case I recommend > cd /tmp > git clone https://github.com/drwetter/testssl.sh.git > cd testssl.sh > ./testssl.sh --each-cipher devsrv.infinera.com
(In reply to Thomas Deutschmann from comment #44) > (In reply to Joakim Tjernlund from comment #43) > > Not sure how to check that, I am not familiar with openssl command, maybe > > you can suggest a command I can test with? > In this case I recommend > > > cd /tmp > > git clone https://github.com/drwetter/testssl.sh.git > > cd testssl.sh > > ./testssl.sh --each-cipher devsrv.infinera.com That gives: Testing 364 ciphers via OpenSSL plus sockets against the server, ordered by encryption strength Hexcode Cipher Suite Name (OpenSSL) KeyExch. Encryption Bits Cipher Suite Name (RFC) ----------------------------------------------------------------------------------------------------------------------------- xc030 ECDHE-RSA-AES256-GCM-SHA384 ECDH 256 AESGCM 256 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 xc028 ECDHE-RSA-AES256-SHA384 ECDH 256 AES 256 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 xc014 ECDHE-RSA-AES256-SHA ECDH 256 AES 256 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA so only ECDxx ciphers :( I don't get what caused this though, openssl on devsrv is build with USE=asm kerberos sslv3 tls-heartbeat zlib
(In reply to Thomas Deutschmann from comment #44) > (In reply to Joakim Tjernlund from comment #43) > > Not sure how to check that, I am not familiar with openssl command, maybe > > you can suggest a command I can test with? > In this case I recommend > > > cd /tmp > > git clone https://github.com/drwetter/testssl.sh.git > > cd testssl.sh > > ./testssl.sh --each-cipher devsrv.infinera.com emerge net-analyzer/testssl :-)
(In reply to Michael Palimaka (kensington) from comment #46) > (In reply to Thomas Deutschmann from comment #44) > > (In reply to Joakim Tjernlund from comment #43) > > > Not sure how to check that, I am not familiar with openssl command, maybe > > > you can suggest a command I can test with? > > In this case I recommend > > > > > cd /tmp > > > git clone https://github.com/drwetter/testssl.sh.git > > > cd testssl.sh > > > ./testssl.sh --each-cipher devsrv.infinera.com > > emerge net-analyzer/testssl :-) Ahh, now merged to our dev boxes :) Can one test ssh with that tool as well?
Looking at apache conf: SSLCipherSuite "ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256" What would be a suitable cipher that works for USE=bindist ?
Has there been any progress on this? There are quiet some packages in the tree that cannot be fetched from the current stage3's. For example sources hosted on sourceforge tend to fail (not all the time for some reason, probably inconsistent server config on their side).
openssl-1.0.2o-r5 now with Hobble-EC patches in the tree. Please test all consumers with it.
net-ftp/vsftpd-3.0.3-r2 build error: ssl.c: In function ‘ssl_init’: ssl.c:124:7: error: unknown type name ‘EC_KEY’ EC_KEY* key = EC_KEY_new_by_curve_name(NID_X9_62_prime256v1); ^ ssl.c:124:7: warning: implicit declaration of function ‘ EC_KEY_new_by_curve_name’ [-Wimplicit-function-declaration] ssl.c:124:21: warning: initialization makes pointer from integer without a cast EC_KEY* key = EC_KEY_new_by_curve_name(NID_X9_62_prime256v1); ^ ssl.c:130:7: warning: implicit declaration of function ‘ EC_KEY_free’ [-Wimplicit-function-declaration] EC_KEY_free(key); ^ dev-libs/openssl-1.0.2o-r3 (bindist) Does vsftp or openssl need fixing?
(In reply to Joakim Tjernlund from comment #51) > net-ftp/vsftpd-3.0.3-r2 build error: > ssl.c: In function ‘ssl_init’: > ssl.c:124:7: error: unknown type name ‘EC_KEY’ > EC_KEY* key = EC_KEY_new_by_curve_name(NID_X9_62_prime256v1); > ^ > ssl.c:124:7: warning: implicit declaration of function ‘ > EC_KEY_new_by_curve_name’ [-Wimplicit-function-declaration] > ssl.c:124:21: warning: initialization makes pointer from > integer without a cast > EC_KEY* key = EC_KEY_new_by_curve_name(NID_X9_62_prime256v1); > ^ > ssl.c:130:7: warning: implicit declaration of function ‘ > EC_KEY_free’ [-Wimplicit-function-declaration] > EC_KEY_free(key); > ^ > > dev-libs/openssl-1.0.2o-r3 (bindist) > > Does vsftp or openssl need fixing? I think this should be it's own bug for vsftpd requiring USE="-bindist" depending on how you built vsftpd.
(In reply to ephemer0l from comment #52) > (In reply to Joakim Tjernlund from comment #51) > > net-ftp/vsftpd-3.0.3-r2 build error: > > ssl.c: In function ‘ssl_init’: > > ssl.c:124:7: error: unknown type name ‘EC_KEY’ > > EC_KEY* key = EC_KEY_new_by_curve_name(NID_X9_62_prime256v1); > > ^ > > ssl.c:124:7: warning: implicit declaration of function ‘ > > EC_KEY_new_by_curve_name’ [-Wimplicit-function-declaration] > > ssl.c:124:21: warning: initialization makes pointer from > > integer without a cast > > EC_KEY* key = EC_KEY_new_by_curve_name(NID_X9_62_prime256v1); > > ^ > > ssl.c:130:7: warning: implicit declaration of function ‘ > > EC_KEY_free’ [-Wimplicit-function-declaration] > > EC_KEY_free(key); > > ^ > > > > dev-libs/openssl-1.0.2o-r3 (bindist) > > > > Does vsftp or openssl need fixing? > > I think this should be it's own bug for vsftpd requiring USE="-bindist" > depending on how you built vsftpd. There is a bug about that but now that openssl supports EC with USE="bindist" (I wrote -bindist above when I meant bindist) I figured vsftp should work either way. Am I wrong?
Ping - as mentioned on gentoo-dev recently, all the ECC-related patents have apparently expired so we really should get this back on track.
(In reply to Marek Szuba from comment #54) > Ping - as mentioned on gentoo-dev recently, all the ECC-related patents have > apparently expired so we really should get this back on track. I don't see what would prevent us from including that code again, so I'd say go ahead.
As of 2021/01/22, Fedora is still removing EC: https://src.fedoraproject.org/rpms/openssl/blob/master/f/hobble-openssl https://src.fedoraproject.org/rpms/openssl/blob/f33/f/hobble-openssl When Fedora brings back the EC support, then we should as well.
I don't see why we would need to wait for Fedora to take action. Bug 762850 has been assigned to trustees to review this.
(In reply to Robin Johnson from comment #56) > As of 2021/01/22, Fedora is still removing EC: > https://src.fedoraproject.org/rpms/openssl/blob/master/f/hobble-openssl > https://src.fedoraproject.org/rpms/openssl/blob/f33/f/hobble-openssl Which says that all patents are expired: # MDC-2: 4,908,861 13/03/2007 - expired, we do not remove it but do not enable it anyway # IDEA: 5,214,703 07/01/2012 - expired, we do not remove it anymore # RC5: 5,724,428 01/11/2015 - expired, we do not remove it anymore # EC: ????????? ??/??/2020 # SRP: ????????? ??/??/2017 - expired, we do not remove it anymore > When Fedora brings back the EC support, then we should as well. I agree to this implication, but not necessarily to its inverse. :-)
(In reply to Mike Gilbert from comment #57) > I don't see why we would need to wait for Fedora to take action. > > Bug 762850 has been assigned to trustees to review this. Ack, I've updated that bug (but its the same as this bug's comment 56.) I'll propose an update of March 1 and if there is no movement on that bug we can circle back and decide whether to take action without counsel or seek an alternative. -A
(In reply to Ulrich Müller from comment #58) > (In reply to Robin Johnson from comment #56) > > As of 2021/01/22, Fedora is still removing EC: > > https://src.fedoraproject.org/rpms/openssl/blob/master/f/hobble-openssl > > https://src.fedoraproject.org/rpms/openssl/blob/f33/f/hobble-openssl > > Which says that all patents are expired: > > # MDC-2: 4,908,861 13/03/2007 - expired, we do not remove it but do not > enable it anyway > # IDEA: 5,214,703 07/01/2012 - expired, we do not remove it anymore > # RC5: 5,724,428 01/11/2015 - expired, we do not remove it anymore > # EC: ????????? ??/??/2020 > # SRP: ????????? ??/??/2017 - expired, we do not remove it anymore > > > When Fedora brings back the EC support, then we should as well. > > I agree to this implication, but not necessarily to its inverse. :-) So here is my view. - The build currently removes EC related code. - Some believe the EC code is related to patent 6782100 which is expired (and expired at the end of 2020.) - I have no way of knowing what other patents cover the removed code; if any. I have basically three choices. - Assume that patent 6782100 is the only patent applicable to the EC code, and approve reinstating the code (this is what you are asking me to do.) - know that there are additional patents that cover this code, and reinstate it anyway. FWIW I don't knowingly know that there are additional patents covering it; this would likely constitute willful infringement and is not an option I'd pick. - Resolve the ambiguity to some reasonable risk level that there are no additional patents covering this. This is the path we have taken. We have two choices of implementation. We can hire someone to do it (I have not looked into the cost of this, but I assume its non-trivial) or we can rely on the diligence of other distributions to do it. We have chose the latter in this case. Note there is no right answer here. In the past Debian kept this code and fedora removed it; clearly they came to different conclusions and its why I'm trying to set a time limit that is not measured in years. -A
(In reply to Alec Warner from comment #60) > - I have no way of knowing what other patents cover the removed code; > if any. Isn't that true for basically _all_ code? So if this was our measure, then we couldn't distribute any package.
BTW, Trustees voted in their 2017-10-22 meeting that they are going to talk to Debian: (In reply to Matthew Thode ( prometheanfire ) from comment #29) > The trustees talked about this at our meeting today, we've decided that the > following should happen. > > 1. patch 1.1 (using fedora patch) > 2. talk to debian (to see if their reasoning for shipping the without ECC > disabled works for us) > 3. (try to backport the patch for 1.0 OR work on getting 1.1 stable) What was the outcome of this?
Please don't post in this bug anymore. This bug was resolved with comment #30. Any follow up discussion should happen in bug 762850.
