-
-
Notifications
You must be signed in to change notification settings - Fork 29.6k
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
OpenSSL 1.1.1 still implements some disable-flags for Blake2, Scrypt #89790
Comments
This follows update https://bugs.python.org/issue43669 Which is present in Python 3.10 Some OpenSSL 1.1.1 can be built without Blake2 support or Scrypt. SHA3 and SHAKE do not seem to have any enable/disable flags. This results in compiler errors where EVP_blake2b512, EVP_blake2s256, EVP_PBE_scrypt and PKCS5_v2_scrypt_keyivgen can be un-defined. This is unfortunate behavior on the part of OpenSSL 1.1.1. So, for BLAKE2 and SCRYPT, we should still check that the OPENSSL_NO_SCRYPT and OPENSSL_NO_BLAKE2 defines are not-define. |
Note: PKCS5_v2_scrypt_keyivgen() will not cause an error, but EVP_PBE_scrypt() will |
Python 3.10 and newer require OpenSSL 1.1.1+ with blake2, sha3, scrypt, and similar features enabled. The required feature set is specified in PEP-644, https://www.python.org/dev/peps/pep-0644/#compatibility . Python requires the features, because I want to keep our test matrix small and guarantee the presence of a minimal feature set. Why do you want to build OpenSSL without blake2 or scrypt? |
Apologies for the slow reply. It was the end of work-day when I submitted the bug & patch. So, OpenWrt's OpenSSL does not build BLAKE2 by default. Scrypt is on by default. In the sense that there is no disable flag. I only care about BLAKE2, but I was trying not to half-ass the implementation, given that Scrypt is also disable-able. Now there are 2 options that I feel could be reasonable (anyone is free to disagree with me here):
There are several options that feel a bit more difficult (to me): I may have missed a few possible options. But these are the more obvious ones. Moving forward, I am fine with either of the first 2 options. Thank you :) |
So, I've read through: https://www.python.org/dev/peps/pep-0644/#compatibility I also stumbled over: Which also led to: The answer is loud and clear now: will keep this downstream. Thank you and apologies for the noise. |
Ah, OpenWRT. :) Thanks for you detailed explanation. I kinda agree that it makes sense for small, embedded systems like OpenWRT to reduce the size of binaries. After all storage and memory are precious on these systems. PEP-644 favors usability over flexibility. 3rd party library developers can now rely on the presence of hashlib features. Before 3.10 they could not be sure that a Python build had certain features. A downstream patch in OpenWRT makes sense. By the way, you might be interested in --with-builtin-hashlib-hashes configure flag. It lets you disable builtin modules like _md5 and _sha3. The shared libraries are large. If you disable the builtin blake2 module, then certain features like MAC and tree hashing are not working. |
So, OpenWrt is not as tiny as it used to be. I think where users still install Python is where they have at least 64/128 MB of persistent storage/flash memory. I am still surprised about the desire of users to install Python on such devices (even after doing this for ~7 years of [co-]maintaining it it on OpenWrt).
Ack.
I've started down that path.
I would not add too many flags in the Python build (on our side). I know... crazy stuff, but people seem to do it. I do admit some Python fans and developers would cringe at this but ¯\(ツ)/¯ |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: