Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

crypto: examine and probably remove OpenSSL derived code #22637

Closed
ianlancetaylor opened this issue Nov 8, 2017 · 26 comments
Closed

crypto: examine and probably remove OpenSSL derived code #22637

ianlancetaylor opened this issue Nov 8, 2017 · 26 comments

Comments

@ianlancetaylor
Copy link
Contributor

@ianlancetaylor ianlancetaylor commented Nov 8, 2017

I just had my attention drawn to the following files:

  • crypto/sha256/sha256block_ppc64le.s
  • crypto/aes/asm_ppc64le.s
  • crypto/sha512/sha512block_ppc64le.s

These files say:

// This is a derived work from OpenSSL of SHA-2 using assembly optimizations. The
// original code was written by Andy Polyakov <appro@openssl.org> and it's dual
// licensed under OpenSSL and CRYPTOGAMS licenses depending on where you obtain
// it. For further details see http://www.openssl.org/~appro/cryptogams/.

I don't think this is OK for the Go standard library. The OpenSSL license imposes various restrictions. Specifically, it says

 * 6. Redistributions of any form whatsoever must retain the following
 *    acknowledgment:
 *    "This product includes software developed by the OpenSSL Project
 *    for use in the OpenSSL Toolkit (http://www.openssl.org/)"

This restriction applies not just to Go distributions, but also to any Go program that links in this code. That is not a requirement that we want to apply to all Go programs. I of course want to keep high performance for crypto code on PPC64LE, but I don't see how we can keep this code in its present form.

The code was added in

CC @laboger @ceseo @dr2chase @agl @FiloSottile @rsc

@rsc
Copy link
Contributor

@rsc rsc commented Nov 9, 2017

Yes, those must be removed. It says the license depends on where you got it from, and clearly it was gotten from OpenSSL. The code is not at http://www.openssl.org/~appro/cryptogams/.

@bradfitz
Copy link
Contributor

@bradfitz bradfitz commented Nov 9, 2017

@rsc, you seemed happy for some reason in:

https://go-review.googlesource.com/c/go/+/33587/2/src/crypto/aes/asm_ppc64le.s#11

Where you wrote:

Thanks for adding this link. This resolves my concerns about CRYPTOGAMS.

@mstrosaker
Copy link

@mstrosaker mstrosaker commented Nov 10, 2017

When cryptogams-licenced ARM modules were ported to the Linux kernel, Andy Polyakov (the author of the code and the license) specifically stated that "The whole idea behind cryptogams initiative was exactly to reuse code in different contexts." (https://patchwork.kernel.org/patch/6027481/) The intent is clear, though I understand that the text in the source files is a bit muddy.

I believe the intent would be made more clear if Andy updated the cryptogams tarball to include the latest code, and I've e-mailed him to see if he will do so.

As the author of one of the patchsets under discussion, it would have been appreciated if I'd been CCed on this issue.

@randall77
Copy link
Contributor

@randall77 randall77 commented Nov 10, 2017

As the author of one of the patchsets under discussion, it would have been appreciated if I'd been CCed on this issue.

Yes, that should have happened, sorry.

Also missing @pfsmorigo, I think.

@ianlancetaylor
Copy link
Contributor Author

@ianlancetaylor ianlancetaylor commented Nov 11, 2017

@mstrosaker Sorry, for some reason Github didn't pull up your user name when I tried to find it.

@ianlancetaylor
Copy link
Contributor Author

@ianlancetaylor ianlancetaylor commented Nov 11, 2017

If the code is from cryptogams, and we can verify that, that's great. In that case we should be pulling the original code from cryptogams, not OpenSSL, and the comments in the code should reflect that.

@rsc
Copy link
Contributor

@rsc rsc commented Nov 22, 2017

@bradfitz, yes, I remember writing that comment. It looks like I was wrong; I probably missed "depending on where you obtain it."

@rsc
Copy link
Contributor

@rsc rsc commented Dec 1, 2017

@mstrosaker, did Andy Polyakov get back to you?

@bradfitz
Copy link
Contributor

@bradfitz bradfitz commented Dec 4, 2017

Andy Polyakov appears to be @dot-asm. Andy, could you update the tarball at https://www.openssl.org/~appro/cryptogams/ ?

@dot-asm
Copy link

@dot-asm dot-asm commented Dec 5, 2017

I've chosen to change the feed to https://github.com/dot-asm/cryptogams. For the moment it's just original tar-ball, but it's going to be updated this week...

@rsc
Copy link
Contributor

@rsc rsc commented Dec 13, 2017

Thanks so much @dot-asm - looks like dot-asm/cryptograms been updated to include AES and SHA3, which is fantastic. In Go we've also recently added SHA256/512 for ppc64. Are you planning to add those as well? Thanks again.

@dot-asm
Copy link

@dot-asm dot-asm commented Dec 13, 2017

Yes, there will be SHA2 as well...

@rsc
Copy link
Contributor

@rsc rsc commented Jan 4, 2018

@dot-asm sorry to nag, but could you please add the SHA256/512 for ppc64?

If not, then we should probably remove sha256/sha256block_ppc64le.s from the Go 1.10 tree and bring it back in Go 1.11.

@laboger
Copy link
Contributor

@laboger laboger commented Jan 9, 2018

Hi Russ, I just checked with @mstrosaker on the status of this. If @dot-asm is unable to get this done by the time it is needed for go 1.10, we'd like the sha256/sha512 implementations to revert back to the previous asm implementations for ppc64le from go1.8, which did not have the licensing concerns. Just want to be sure they don't get reverted back to the original go implementations.

@dot-asm
Copy link

@dot-asm dot-asm commented Jan 9, 2018

What's time frame? I'm a bit constrained in my capabilities for a week. It's not like I can't pull it off, but it won't be as tested as one might wish. What would help for the moment is explicit confirmation that verbatim copy of sha512-ppc.pl from OpenSSL master works for you. Or does one have to update even ppc-xlate.pl script?

@bradfitz
Copy link
Contributor

@bradfitz bradfitz commented Jan 9, 2018

@dot-asm, the Go 1.10 release is scheduled for early February. We're deep in our code freeze at this point, so the sooner the better. I can't speak to your other questions.

@FiloSottile
Copy link
Member

@FiloSottile FiloSottile commented Jan 9, 2018

@laboger or @mstrosaker can answer that. Did you only base the patch on sha512-ppc.pl or also on ppc-xlate.pl?

@dot-asm Anyway, I don't think we care about the code being well tested or even compiling. As long as the same code that was used as a base for this is published under the CRYPTOGAMS project, with the CRYPTOGAMS license, we are happy. It can even be a branch, I think. (IANAL)

@dot-asm
Copy link

@dot-asm dot-asm commented Jan 9, 2018

Did you only base the patch on sha512-ppc.pl or also on ppc-xlate.pl?

This is not exactly what I want to hear. Question at hand is what do I do now. Is it sufficient to commit sha512-ppc.pl from master, or do I have to make do it with more care. I understand that you might only care about mere availability of a file in repository. But you have to understand me too, as I'm reluctant to put something that it known to not work...

@bradfitz
Copy link
Contributor

@bradfitz bradfitz commented Jan 9, 2018

@dot-asm, can you just add the file to some "WIP" or "untested" branch for now?

@FiloSottile
Copy link
Member

@FiloSottile FiloSottile commented Jan 9, 2018

Is it sufficient to commit sha512-ppc.pl from master, or do I have to make it with more care.

The former. But if the CL was based also on the ppc-xlate.pl source, then we need that file too.

@dot-asm
Copy link

@dot-asm dot-asm commented Jan 9, 2018

OK, let's put this way. I'll give some time to those who were asked the opportunity to answer. And if no answer is provided in several hours, all create a merge request to cryptogams with sha512-ppc.pl. Then I'll reassess situation tomorrow...

@mstrosaker
Copy link

@mstrosaker mstrosaker commented Jan 9, 2018

@dot-asm The CL was based solely on the contents of sha512-ppc.pl. Basically, I just ported the sequence of instructions as laid out in sha512-ppc.pl, with no need to reference ppc-xlate.pl. It will be sufficient to commit sha512-ppc.pl by itself.

@dot-asm
Copy link

@dot-asm dot-asm commented Jan 9, 2018

Unfortunately this doesn't quite work for me. As already mentioned, I'm reluctant to commit something that is not verified to work. So for now I've created a temporary branch, https://github.com/dot-asm/cryptogams/tree/sha512-ppc/, where you can download the module in question. I'll verify it working and commit what's necessary to master, when I'm back home in a week...

@dot-asm
Copy link

@dot-asm dot-asm commented Jan 9, 2018

On second look it seems that I'm being inconsistent. As I have committed aesp8-ppc, but it doesn't currently work as it should... Well, I'm just a human...

@ianlancetaylor
Copy link
Contributor Author

@ianlancetaylor ianlancetaylor commented Jan 10, 2018

@dot-asm Thanks very much for doing that.

@gopherbot
Copy link

@gopherbot gopherbot commented Jan 10, 2018

Change https://golang.org/cl/87315 mentions this issue: crypto: clarify that some files come from CRYPTOGAMS

@gopherbot gopherbot closed this in 40a17ee Jan 11, 2018
@golang golang locked and limited conversation to collaborators Jan 11, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
9 participants
You can’t perform that action at this time.