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

Allow CPython to build against cryptography libraries lacking BLAKE2 support #117233

Closed
WillChilds-Klein opened this issue Mar 25, 2024 · 0 comments
Assignees
Labels
build The build process and cross-build type-feature A feature request or enhancement

Comments

@WillChilds-Klein
Copy link
Contributor

WillChilds-Klein commented Mar 25, 2024

Feature or enhancement

Proposal:

As part of a series of changes discussed on the python Ideas board, this issue proposes placing guards around references to BLAKE2's NIDs. This would allow cryptography libraries lacking full BLAKE2 support to be used with CPython.

Has this already been discussed elsewhere?

I have already discussed this feature proposal on Discourse

Links to previous discussion of this feature:

https://discuss.python.org/t/support-building-ssl-and-hashlib-modules-against-aws-lc/44505

Linked PRs

@WillChilds-Klein WillChilds-Klein added the type-feature A feature request or enhancement label Mar 25, 2024
@gpshead gpshead self-assigned this Mar 28, 2024
@gpshead gpshead added the build The build process and cross-build label Mar 28, 2024
encukou pushed a commit that referenced this issue Apr 11, 2024
…H-117234)

Detect libcrypto BLAKE2, Shake, SHA3, and Truncated-SHA512 support at hashlib build time

## BLAKE2

While OpenSSL supports both "b" and "s" variants of the BLAKE2 hash
function, other cryptographic libraries may lack support for one or both
of the variants. This commit modifies `hashlib`'s C code to detect
whether or not the linked libcrypto supports each BLAKE2 variant, and
elides references to each variant's NID accordingly. In cases where the
underlying libcrypto doesn't fully support BLAKE2, CPython's
`./configure` script can be given the following flag to use CPython's
interned BLAKE2 implementation: `--with-builtin-hashlib-hashes=blake2`.

## SHA3, Shake, & truncated SHA512.

Detect BLAKE2, SHA3, Shake, & truncated SHA512 support in the
OpenSSL-ish libcrypto library at build time.  This helps allow hashlib's
`_hashopenssl` to be used with libraries that do not to support every
algorithm that upstream OpenSSL does.  Such as AWS-LC & BoringSSL.

Co-authored-by: Gregory P. Smith [Google LLC] <greg@krypto.org>
@encukou encukou closed this as completed Apr 11, 2024
miss-islington pushed a commit to miss-islington/cpython that referenced this issue Apr 11, 2024
…ime (pythonGH-117234)

Detect libcrypto BLAKE2, Shake, SHA3, and Truncated-SHA512 support at hashlib build time

GH-GH- BLAKE2

While OpenSSL supports both "b" and "s" variants of the BLAKE2 hash
function, other cryptographic libraries may lack support for one or both
of the variants. This commit modifies `hashlib`'s C code to detect
whether or not the linked libcrypto supports each BLAKE2 variant, and
elides references to each variant's NID accordingly. In cases where the
underlying libcrypto doesn't fully support BLAKE2, CPython's
`./configure` script can be given the following flag to use CPython's
interned BLAKE2 implementation: `--with-builtin-hashlib-hashes=blake2`.

GH-GH- SHA3, Shake, & truncated SHA512.

Detect BLAKE2, SHA3, Shake, & truncated SHA512 support in the
OpenSSL-ish libcrypto library at build time.  This helps allow hashlib's
`_hashopenssl` to be used with libraries that do not to support every
algorithm that upstream OpenSSL does.  Such as AWS-LC & BoringSSL.

(cherry picked from commit b8eaad3)

Co-authored-by: Will Childs-Klein <willck93@gmail.com>
Co-authored-by: Gregory P. Smith [Google LLC] <greg@krypto.org>
gpshead added a commit that referenced this issue Apr 11, 2024
…time (GH-117234) (#117767)

gh-117233: Detect support for several hashes at hashlib build time (GH-117234)

Detect libcrypto BLAKE2, Shake, SHA3, and Truncated-SHA512 support at hashlib build time

GH-GH- BLAKE2

While OpenSSL supports both "b" and "s" variants of the BLAKE2 hash
function, other cryptographic libraries may lack support for one or both
of the variants. This commit modifies `hashlib`'s C code to detect
whether or not the linked libcrypto supports each BLAKE2 variant, and
elides references to each variant's NID accordingly. In cases where the
underlying libcrypto doesn't fully support BLAKE2, CPython's
`./configure` script can be given the following flag to use CPython's
interned BLAKE2 implementation: `--with-builtin-hashlib-hashes=blake2`.

GH-GH- SHA3, Shake, & truncated SHA512.

Detect BLAKE2, SHA3, Shake, & truncated SHA512 support in the
OpenSSL-ish libcrypto library at build time.  This helps allow hashlib's
`_hashopenssl` to be used with libraries that do not to support every
algorithm that upstream OpenSSL does.  Such as AWS-LC & BoringSSL.

(cherry picked from commit b8eaad3)

Co-authored-by: Will Childs-Klein <willck93@gmail.com>
Co-authored-by: Gregory P. Smith [Google LLC] <greg@krypto.org>
diegorusso pushed a commit to diegorusso/cpython that referenced this issue Apr 17, 2024
…ime (pythonGH-117234)

Detect libcrypto BLAKE2, Shake, SHA3, and Truncated-SHA512 support at hashlib build time

## BLAKE2

While OpenSSL supports both "b" and "s" variants of the BLAKE2 hash
function, other cryptographic libraries may lack support for one or both
of the variants. This commit modifies `hashlib`'s C code to detect
whether or not the linked libcrypto supports each BLAKE2 variant, and
elides references to each variant's NID accordingly. In cases where the
underlying libcrypto doesn't fully support BLAKE2, CPython's
`./configure` script can be given the following flag to use CPython's
interned BLAKE2 implementation: `--with-builtin-hashlib-hashes=blake2`.

## SHA3, Shake, & truncated SHA512.

Detect BLAKE2, SHA3, Shake, & truncated SHA512 support in the
OpenSSL-ish libcrypto library at build time.  This helps allow hashlib's
`_hashopenssl` to be used with libraries that do not to support every
algorithm that upstream OpenSSL does.  Such as AWS-LC & BoringSSL.

Co-authored-by: Gregory P. Smith [Google LLC] <greg@krypto.org>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
build The build process and cross-build type-feature A feature request or enhancement
Projects
None yet
Development

No branches or pull requests

3 participants