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/.

@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.

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.

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.

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

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.

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

@mstrosaker, did Andy Polyakov get back to you?

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

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...

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.

Yes, there will be SHA2 as well...

@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.

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.

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?

@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.

@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)

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...

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

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.

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...

@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.

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...

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...

@dot-asm Thanks very much for doing that.

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