Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 531540 - dev-libs/openssl: revise inclusion of elliptic curves with bindist USE flag
Summary: dev-libs/openssl: revise inclusion of elliptic curves with bindist USE flag
Status: IN_PROGRESS
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal with 3 votes (vote)
Assignee: Gentoo's Team for Core System packages
URL:
Whiteboard:
Keywords:
: 559214 (view as bug list)
Depends on:
Blocks: 541414
  Show dependency tree
 
Reported: 2014-12-03 14:21 UTC by Alexis Ballier
Modified: 2018-12-08 08:17 UTC (History)
13 users (show)

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


Attachments
openssl-1.1.0f-r1.ebuild-Fedora-Hobbled-EC.patch (openssl-1.1.0f-r1.ebuild-Fedora-Hobbled-EC.patch,1.95 KB, patch)
2017-10-12 05:32 UTC, Robin Johnson
Details | Diff
openssl-1.1.0f-r2.ebuild-Fedora-Hobbled-EC.patch (openssl-1.1.0f-r2.ebuild-Fedora-Hobbled-EC.patch,1.61 KB, patch)
2017-10-13 17:39 UTC, Robin Johnson
Details | Diff
openssl-1.1.0f-r2.ebuild-Fedora-Hobbled-EC-v2.patch (openssl-1.1.0f-r2.ebuild-Fedora-Hobbled-EC.patch,2.15 KB, patch)
2017-10-13 21:04 UTC, Robin Johnson
Details | Diff
openssl-1.1.0f-r2.ebuild-Fedora-Hobbled-EC-v3.patch (openssl-1.1.0f-r2.ebuild-Fedora-Hobbled-EC-v3.patch,2.16 KB, patch)
2017-10-13 21:06 UTC, Robin Johnson
Details | Diff
openssl-1.0.2l-r1-with-ec-ABI-compat.html (compat_report.html,59.22 KB, text/html)
2017-10-22 22:46 UTC, Robin Johnson
Details
openssl-1.0.2l-r1-with-ec-ABI-compat-libcrypto.html (compat_report.html,63.58 KB, text/html)
2017-10-22 22:55 UTC, Robin Johnson
Details
openssl-1.1.0f-r1-with-ec-ABI-compat-libcrypto.html (compat_report.html,50.17 KB, text/html)
2017-10-23 03:50 UTC, Robin Johnson
Details
openssl-1.1.0f-r1-with-ec-ABI-compat-libssl.html (compat_report.html,14.35 KB, text/html)
2017-10-23 03:51 UTC, Robin Johnson
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Alexis Ballier gentoo-dev 2014-12-03 14:21:09 UTC
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.
Comment 1 Ulrich Müller gentoo-dev 2014-12-04 09:20:53 UTC
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.
Comment 2 Alexis Ballier gentoo-dev 2014-12-08 10:09:54 UTC
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)
Comment 3 Hanno Boeck gentoo-dev 2015-02-21 21:41:13 UTC
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.
Comment 4 SpanKY gentoo-dev 2015-03-03 04:42:36 UTC
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 :).
Comment 5 SpanKY gentoo-dev 2015-03-03 04:45:03 UTC
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.
Comment 6 Alexis Ballier gentoo-dev 2015-03-03 08:00:48 UTC
(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
Comment 7 SpanKY gentoo-dev 2015-03-03 09:36:56 UTC
(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.
Comment 8 Alexis Ballier gentoo-dev 2015-03-03 09:48:44 UTC
(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.
Comment 9 SpanKY gentoo-dev 2015-09-01 04:41:53 UTC
*** Bug 559214 has been marked as a duplicate of this bug. ***
Comment 10 Anthony Basile gentoo-dev 2015-09-19 18:01:27 UTC
(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
Comment 11 SpanKY gentoo-dev 2015-09-19 18:15:50 UTC
(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.
Comment 12 Ian Stakenvicius gentoo-dev 2017-10-05 13:44:47 UTC
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.
Comment 13 Kristian Fiskerstrand gentoo-dev Security 2017-10-05 14:48:38 UTC
(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.
Comment 14 Mike Gilbert gentoo-dev 2017-10-05 15:48:32 UTC
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?
Comment 15 Richard Freeman gentoo-dev 2017-10-05 16:16:26 UTC
(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.
Comment 16 Ulrich Müller gentoo-dev 2017-10-06 10:42:35 UTC
(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.
Comment 17 Mike Gilbert gentoo-dev 2017-10-08 17:41:44 UTC
(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.
Comment 18 Richard Freeman gentoo-dev 2017-10-08 17:45:38 UTC
(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.
Comment 19 Ian Stakenvicius gentoo-dev 2017-10-10 15:51:06 UTC
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...
Comment 20 Ian Stakenvicius gentoo-dev 2017-10-10 15:52:19 UTC
(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.
Comment 21 Richard Freeman gentoo-dev 2017-10-10 16:02:01 UTC
(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.
Comment 22 Jorge Manuel B. S. Vicetto Gentoo Infrastructure gentoo-dev 2017-10-12 00:19:49 UTC
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.
Comment 23 Richard Freeman gentoo-dev 2017-10-12 01:19:07 UTC
(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.
Comment 24 Robin Johnson archtester Gentoo Infrastructure gentoo-dev Security 2017-10-12 05:32:29 UTC
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.
Comment 25 Robin Johnson archtester Gentoo Infrastructure gentoo-dev Security 2017-10-13 17:39:33 UTC
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.
Comment 26 Ulrich Müller gentoo-dev 2017-10-13 19:17:43 UTC
(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;
Comment 27 Robin Johnson archtester Gentoo Infrastructure gentoo-dev Security 2017-10-13 21:04:04 UTC
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.
Comment 28 Robin Johnson archtester Gentoo Infrastructure gentoo-dev Security 2017-10-13 21:06:23 UTC
Created attachment 498584 [details, diff]
openssl-1.1.0f-r2.ebuild-Fedora-Hobbled-EC-v3.patch
Comment 29 Matthew Thode ( prometheanfire ) archtester Gentoo Infrastructure gentoo-dev Security 2017-10-22 20:16:09 UTC
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
Comment 30 Larry the Git Cow gentoo-dev 2017-10-22 21:16:37 UTC
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(-)}
Comment 31 Larry the Git Cow gentoo-dev 2017-10-22 21:51:39 UTC
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(+)}
Comment 32 Robin Johnson archtester Gentoo Infrastructure gentoo-dev Security 2017-10-22 21:56:10 UTC
- 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).
Comment 33 Robin Johnson archtester Gentoo Infrastructure gentoo-dev Security 2017-10-22 22:46:35 UTC
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.
Comment 34 Robin Johnson archtester Gentoo Infrastructure gentoo-dev Security 2017-10-22 22:55:26 UTC
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.
Comment 35 Robin Johnson archtester Gentoo Infrastructure gentoo-dev Security 2017-10-23 03:50:42 UTC
Created attachment 499736 [details]
openssl-1.1.0f-r1-with-ec-ABI-compat-libcrypto.html
Comment 36 Robin Johnson archtester Gentoo Infrastructure gentoo-dev Security 2017-10-23 03:51:15 UTC
Created attachment 499738 [details]
openssl-1.1.0f-r1-with-ec-ABI-compat-libssl.html
Comment 37 Robin Johnson archtester Gentoo Infrastructure gentoo-dev Security 2017-10-23 03:52:19 UTC
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?
Comment 38 Matthew Thode ( prometheanfire ) archtester Gentoo Infrastructure gentoo-dev Security 2017-10-31 19:55:17 UTC
I've added dev-python/cryptography-2.1.2-r1 to the tree, it can use the new openssls
Comment 39 Robin Johnson archtester Gentoo Infrastructure gentoo-dev Security 2017-10-31 21:19:20 UTC
anybody else tracking this, do NOT unmask 1.0.2l-r1; the SRP stuff causes too much ABI breakage this point.
Comment 40 Joakim Tjernlund 2017-12-04 08:30:54 UTC
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?
Comment 41 Joakim Tjernlund 2017-12-04 08:31:20 UTC
forgot: openssl-1.0.2m
Comment 42 Thomas Deutschmann gentoo-dev Security 2017-12-04 10:50:22 UTC
(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.
Comment 43 Joakim Tjernlund 2017-12-04 12:03:02 UTC
(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?
Comment 44 Thomas Deutschmann gentoo-dev Security 2017-12-04 12:13:15 UTC
(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
Comment 45 Joakim Tjernlund 2017-12-04 13:01:20 UTC
(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
Comment 46 Michael Palimaka (kensington) gentoo-dev 2017-12-04 13:03:16 UTC
(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 :-)
Comment 47 Joakim Tjernlund 2017-12-04 13:06:30 UTC
(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?
Comment 48 Joakim Tjernlund 2017-12-05 07:50:58 UTC
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 ?
Comment 49 Simon 2018-01-06 20:04:09 UTC
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).
Comment 50 Robin Johnson archtester Gentoo Infrastructure gentoo-dev Security 2018-06-11 14:04:30 UTC
openssl-1.0.2o-r5 now with Hobble-EC patches in the tree. Please test all consumers with it.
Comment 51 Joakim Tjernlund 2018-07-05 09:14:39 UTC
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?
Comment 52 ephemer0l 2018-07-05 10:42:12 UTC
(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.
Comment 53 Joakim Tjernlund 2018-07-05 11:31:28 UTC
(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?