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

Missing files and patches present in OpenSSL #7

Open
ansasaki opened this issue May 11, 2020 · 12 comments
Open

Missing files and patches present in OpenSSL #7

ansasaki opened this issue May 11, 2020 · 12 comments

Comments

@ansasaki
Copy link

I want to enable Intel CET in GnuTLS, which uses the CRYPTOGAMS implementation. Comparing the code in this repository with the code available in OpenSSL, there are missing patches (specially those from @hjl-tools enabling Intel CET) and missing files.

The CRYPTOGAMS code present in OpenSSL states that it is double licensed under CRYPTOGAMS and OpenSSL, but the license that applies depends on where the code is obtained from.

GnuTLS uses the CRYPTOGAMS implementation and claims to use the code under BSD 3-clause license, but obtains it from the OpenSSL repository.

Trying to fix this by obtaining the code directly from this repository, I found the following missing files which are present in OpenSSL repository, but not in this repository:

  • openssl/crypto/modes/asm/aesni-gcm-x86_64.pl
  • openssl/engines/asm/e_padlock-x86_64.pl
  • openssl/engines/asm/e_padlock-x86.pl
  • openssl/crypto/modes/asm/ghashv8-armx.pl
  • openssl/crypto/modes/asm/ghash-x86_64.pl
  • openssl/crypto/modes/asm/ghash-x86.pl
  • openssl/crypto/sha/asm/sha512-armv8.pl
  • openssl/crypto/sha/asm/sha256-586.pl
  • openssl/crypto/sha/asm/sha512-armv8.pl
  • openssl/crypto/sha/asm/sha512-586.pl

GnuTLS also uses the following file which is not double licensed:

  • openssl/crypto/sha/asm/sha512-x86_64.pl

Would it be possible to add the missing code and patches to this repository?

@hjl-tools
Copy link

I want to enable Intel CET in GnuTLS, which uses the CRYPTOGAMS implementation. Comparing the code in this repository with the code available in OpenSSL, there are missing patches (specially those from @hjl-tools enabling Intel CET) and missing files.

The CRYPTOGAMS code present in OpenSSL states that it is double licensed under CRYPTOGAMS and OpenSSL, but the license that applies depends on where the code is obtained from.

GnuTLS uses the CRYPTOGAMS implementation and claims to use the code under BSD 3-clause license, but obtains it from the OpenSSL repository.

Trying to fix this by obtaining the code directly from this repository, I found the following missing files which are present in OpenSSL repository, but not in this repository:

  • openssl/crypto/modes/asm/aesni-gcm-x86_64.pl
  • openssl/engines/asm/e_padlock-x86_64.pl
  • openssl/engines/asm/e_padlock-x86.pl
  • openssl/crypto/modes/asm/ghashv8-armx.pl
  • openssl/crypto/modes/asm/ghash-x86_64.pl
  • openssl/crypto/modes/asm/ghash-x86.pl
  • openssl/crypto/sha/asm/sha512-armv8.pl
  • openssl/crypto/sha/asm/sha256-586.pl
  • openssl/crypto/sha/asm/sha512-armv8.pl
  • openssl/crypto/sha/asm/sha512-586.pl

If they are missing from CRYPTOGAMS, are they used by GnuTLS?

GnuTLS also uses the following file which is not double licensed:

  • openssl/crypto/sha/asm/sha512-x86_64.pl

Would it be possible to add the missing code and patches to this repository?

What is the proper procedure to fix issues like these?

@ansasaki
Copy link
Author

I want to enable Intel CET in GnuTLS, which uses the CRYPTOGAMS implementation. Comparing the code in this repository with the code available in OpenSSL, there are missing patches (specially those from @hjl-tools enabling Intel CET) and missing files.
The CRYPTOGAMS code present in OpenSSL states that it is double licensed under CRYPTOGAMS and OpenSSL, but the license that applies depends on where the code is obtained from.
GnuTLS uses the CRYPTOGAMS implementation and claims to use the code under BSD 3-clause license, but obtains it from the OpenSSL repository.
Trying to fix this by obtaining the code directly from this repository, I found the following missing files which are present in OpenSSL repository, but not in this repository:

  • openssl/crypto/modes/asm/aesni-gcm-x86_64.pl
  • openssl/engines/asm/e_padlock-x86_64.pl
  • openssl/engines/asm/e_padlock-x86.pl
  • openssl/crypto/modes/asm/ghashv8-armx.pl
  • openssl/crypto/modes/asm/ghash-x86_64.pl
  • openssl/crypto/modes/asm/ghash-x86.pl
  • openssl/crypto/sha/asm/sha512-armv8.pl
  • openssl/crypto/sha/asm/sha256-586.pl
  • openssl/crypto/sha/asm/sha512-armv8.pl
  • openssl/crypto/sha/asm/sha512-586.pl

If they are missing from CRYPTOGAMS, are they used by GnuTLS?

This is the list of files used by GnuTLS from OpenSSL which are not present in this repository.

GnuTLS also uses the following file which is not double licensed:

  • openssl/crypto/sha/asm/sha512-x86_64.pl

Would it be possible to add the missing code and patches to this repository?

What is the proper procedure to fix issues like these?

For me there are two ways:

  1. The missing files and patches are added to this repository and GnuTLS gets the code from here (which I'm trying to address with this issue). This way GnuTLS will have all the necessary code and the license issue would be fixed.
  2. GnuTLS continues to get the code from OpenSSL and changes the license it uses. The patches would need to be applied to OpenSSL's stable branch. I don't know if the new OpenSSL license is compatible with the GnuTLS license.

@hjl-tools
Copy link

I want to enable Intel CET in GnuTLS, which uses the CRYPTOGAMS implementation. Comparing the code in this repository with the code available in OpenSSL, there are missing patches (specially those from @hjl-tools enabling Intel CET) and missing files.
The CRYPTOGAMS code present in OpenSSL states that it is double licensed under CRYPTOGAMS and OpenSSL, but the license that applies depends on where the code is obtained from.
GnuTLS uses the CRYPTOGAMS implementation and claims to use the code under BSD 3-clause license, but obtains it from the OpenSSL repository.
Trying to fix this by obtaining the code directly from this repository, I found the following missing files which are present in OpenSSL repository, but not in this repository:

  • openssl/crypto/modes/asm/aesni-gcm-x86_64.pl
  • openssl/engines/asm/e_padlock-x86_64.pl
  • openssl/engines/asm/e_padlock-x86.pl
  • openssl/crypto/modes/asm/ghashv8-armx.pl
  • openssl/crypto/modes/asm/ghash-x86_64.pl
  • openssl/crypto/modes/asm/ghash-x86.pl
  • openssl/crypto/sha/asm/sha512-armv8.pl
  • openssl/crypto/sha/asm/sha256-586.pl
  • openssl/crypto/sha/asm/sha512-armv8.pl
  • openssl/crypto/sha/asm/sha512-586.pl

If they are missing from CRYPTOGAMS, are they used by GnuTLS?

This is the list of files used by GnuTLS from OpenSSL which are not present in this repository.

So GnuTLS WANTS to use CRYPTOGAMS, not actually IS USING CRYPTOGAMS
due to the issues mentioned here.

GnuTLS also uses the following file which is not double licensed:

  • openssl/crypto/sha/asm/sha512-x86_64.pl

Would it be possible to add the missing code and patches to this repository?

What is the proper procedure to fix issues like these?

For me there are two ways:

  1. The missing files and patches are added to this repository and GnuTLS gets the code from here (which I'm trying to address with this issue). This way GnuTLS will have all the necessary code and the license issue would be fixed.

So CRYPTOGAMS isn't kept to update with OpenSSL.

  1. GnuTLS continues to get the code from OpenSSL and changes the license it uses. The patches would need to be applied to OpenSSL's stable branch. I don't know if the new OpenSSL license is compatible with the GnuTLS license.

I have CET backports to OpenSSL's stable branch is at

https://github.com/hjl-tools/openssl/tree/hjl/cet/OpenSSL_1_1_1-stable

But I can't help you with license.

@dot-asm
Copy link
Owner

dot-asm commented May 13, 2020

I want to enable Intel CET in GnuTLS, which uses the CRYPTOGAMS implementation. Comparing the code in this repository with the code available in OpenSSL, there are missing patches (specially those from @hjl-tools enabling Intel CET) and missing files.

OpenSSL uses inadequate approach, see openssl/openssl#9007 (comment), and corresponding 6d0e025.

As for missing files. I've added missing armv8 and will keep reviewing and adding others. For example sha512-x86_64.pl needs an overhaul, one of code paths confuses profiler...

@noloader
Copy link

Good job Andy. Cryptogams is one of those hidden gems on the web.

@ansasaki
Copy link
Author

I want to enable Intel CET in GnuTLS, which uses the CRYPTOGAMS implementation. Comparing the code in this repository with the code available in OpenSSL, there are missing patches (specially those from @hjl-tools enabling Intel CET) and missing files.

OpenSSL uses inadequate approach, see openssl/openssl#9007 (comment), and corresponding 6d0e025.

Thank you for pointing me to the right direction!

As for missing files. I've added missing armv8 and will keep reviewing and adding others. For example sha512-x86_64.pl needs an overhaul, one of code paths confuses profiler...

Thank you very much!

@dot-asm
Copy link
Owner

dot-asm commented May 25, 2020

sha512-x86_64 is overhauled, but it takes even updated x86_64-xlate...

@xnox
Copy link

xnox commented Jun 27, 2020

I'm not sure if that's of help or not, but I've create the pull reuqest to submit @hjl-tools CET OpenSSL 1.1.1 patches into the 1.1.1-Stable branch. The cla-check approved them, meaning at least 1.1.1 branch with hjl-tools patches is still licensed in a way compatible with lgpl v2.1+ suitable for usage by gnutls.

Separately, gnutls is license as lgpl v2.1+ which is compatible with apache2, if the resulting combination is then upgraded to lgpl v3.

@q66
Copy link

q66 commented Jul 11, 2020

@dot-asm there are also some missing files for ppc, particularly the stuff under bn/ like ppc-mont.pl despite those files claiming to be a part of cryptogams - is that intentional?

@bluerise
Copy link

Looks like aes-gcm-armv8_64.pl also hasn't yet made the jump to cryptogams. :/ Would be nice to have, since for OpenBSD we'd need to pull it from cryptogams (instead of OpenSSL) due to licensing issues.

@dwmw2
Copy link

dwmw2 commented Jun 18, 2021

Please could I add aesni-sha1-x86_64.pl and x86_64cpuid.pl to the list. As well as an update to sha1-x86_64.pl which is very much older than the one in OpenSSL.

jollaitbot pushed a commit to sailfishos-mirror/openconnect that referenced this issue Jun 18, 2021
The CRYPTOGAMS code is suitably licensed for use in OpenConnect under
LGPLv2.1, and gives us a 40% speedup to ESP AES-SHA1 encryption.

However, not everything is in the standalone CRYPTOGAMS repository, so
we have to import from OpenSSL itself for now, which means the licence
is incompatible.

Once dot-asm/cryptogams#7 is resolved, we can
do this for real. But for now it's worth having it to experiment with.

Really needs SHA256 too...

Signed-off-by: David Woodhouse <[email protected]>
jollaitbot pushed a commit to sailfishos-mirror/openconnect that referenced this issue Jul 2, 2021
The CRYPTOGAMS code is suitably licensed for use in OpenConnect under
LGPLv2.1, and gives us a 40% speedup to ESP AES-SHA1 encryption.

However, not everything is in the standalone CRYPTOGAMS repository, so
we have to import from OpenSSL itself for now, which means the licence
is incompatible.

Once dot-asm/cryptogams#7 is resolved, we can
do this for real. But for now it's worth having it to experiment with.

Really needs SHA256 too...

Signed-off-by: David Woodhouse <[email protected]>
jollaitbot pushed a commit to sailfishos-mirror/openconnect that referenced this issue Jul 2, 2021
The CRYPTOGAMS code is suitably licensed for use in OpenConnect under
LGPLv2.1, and gives us a 40% speedup to ESP AES-SHA1 encryption.

However, not everything is in the standalone CRYPTOGAMS repository, so
we have to import from OpenSSL itself for now, which means the licence
is incompatible.

Once dot-asm/cryptogams#7 is resolved, we can
do this for real. But for now it's worth having it to experiment with.

Really needs SHA256 too...

Signed-off-by: David Woodhouse <[email protected]>
@ryancdotorg
Copy link

I'd also appreciate having sha1-x86_64.pl updated for parity with OpenSSL.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

9 participants