15416 2024-03-02 08:45:59 +0000 python3-cryptography legacy openssl broken after update to 42.0.5 2026-02-11 14:09:52 +0000 1 1 7 Build System, Metadata & Runtime OE-Core devtools / tool chain unspecified x86 Multiple RESOLVED FIXED Medium major 6.0 1 kweihmann colinmca242 colinmca242 meta.mr.watcher meta.watcher randy.macleod ross.burton tim.orling --- --- No (bug/feature does not impact docs) oldest_to_newest 98369 0 kweihmann 2024-03-02 08:45:59 +0000 Ever since https://github.com/pyca/cryptography/commit/ab83fff3c2658f093fe8e89dca83a85dd113a0b9 made it into cryptography legacy binding of openssl are required. It seems to replace the weak/lazy binding to openssl used previously, by something that is already required at buildtime. This lead to the effect that every consuming module trying to import ends up with ------------- from cryptography.hazmat.primitives.asymmetric.ec import EllipticCurve File ".../cryptography/hazmat/primitives/asymmetric/ec.py", line 11, in <module> from cryptography.hazmat._oid import ObjectIdentifier File ".../cryptography/hazmat/_oid.py", line 7, in <module> from cryptography.hazmat.bindings._rust import ( RuntimeError: OpenSSL 3.0's legacy provider failed to load. This is a fatal error by default, but cryptography supports running without legacy algorithms by setting the environment variable CRYPTOGRAPHY_OPENSSL_NO_LEGACY. If you did not expect this error, you have likely made a mistake with your OpenSSL configuration. ------------- Setting CRYPTOGRAPHY_OPENSSL_NO_LEGACY in the calling application of course works, but is a solution that doesn't scale. According to some message boards, a way to fix it is to enable echo "[legacy_sect]" >> ${D}${libdir}/ssl-3/openssl.cnf echo "activate = 1" >> ${D}${libdir}/ssl-3/openssl.cnf in openssl (append to do_install), but that has a high and unwanted impact on security and is likely not the preferred option for most users. And it also doesn't work for native recipes, as the host sided openssl might be invoked. Not sure what to do to tackle the problem, but I think patching "CRYPTOGRAPHY_OPENSSL_NO_LEGACY" by default into python3-cryptography seems to be the only feasible way 98370 1 kweihmann 2024-03-02 08:56:58 +0000 I currently helped myself with a bbappend containing do_install:append() { echo "import os" >> ${D}${PYTHON_SITEPACKAGES_DIR}/cryptography/hazmat/__init__.py echo "os.environ['CRYPTOGRAPHY_OPENSSL_NO_LEGACY'] = '1'" >> ${D}${PYTHON_SITEPACKAGES_DIR}/cryptography/hazmat/__init__.py } 98378 2 tim.orling 2024-03-05 18:30:44 +0000 All of the ptests have been passing, so saying python3-cryptography is broken is an exaggeration. This should most likely be a PACKAGECONFIG[legacy-openssl] where by default it would be NO LEGACY. We do not want to support old algorithms unless it is for intentional reasons (such as FIPS compliance). 98379 3 tim.orling 2024-03-05 18:35:16 +0000 Sadly, it will also require a configuration/PACKAGECONFIG of OpenSSL in order for the "legacy" algorithms to work at all. Folks that need a different configuration for OpenSSL (such as FIPS) will most likely also have a requirement to use an older (e.g. 3.0.8 for FIPS) version of OpenSSL anyway. Please send a patch which sets a PACKAGECONFIG that enables NO LEGACY by default. 98415 4 ross.burton 2024-03-07 15:37:25 +0000 FWIW we have some recipes that use pycryptography-native and they do this: # python3-cryptography needs the legacy provider, so set OPENSSL_MODULES to the # right path until this is relocated automatically. export OPENSSL_MODULES="${STAGING_LIBDIR_NATIVE}/ossl-modules" 100092 5 randy.macleod 2024-10-31 15:09:24 +0000 Bulk move of 5.1 bugs to 5.2. -- YP bug review (Randy) 101834 6 randy.macleod 2025-05-01 14:07:10 +0000 Bulk move of all unassigned 5.2 medium importance bugs to 5.3. 103947 7 colinmca242 2026-01-16 14:39:48 +0000 As of Python cryptography 45.0.0 it appears that there's a build-time environment variable, CRYPTOGRAPHY_BUILD_OPENSSL_NO_LEGACY, that can be used to prevent the library from ever attempting to load the legacy provider. https://github.com/pyca/cryptography/commit/ddc364d28b480010f527c9838906992a27d4b55a It does seem like this commit also "fixes" the issue somewhat where this runtime exception is now downgraded to a warning. To Tim's point, could a PACKAGECONFIG option be added that enables legacy functionality, but otherwise sets this build time environment variable? It's not immediately clear to me what changes are necessary on the openssl side. I do see the openssl-ossl-module-legacy package provided by openssl. I assume the PACKAGECONFIG option would need to rdepend on this? I'm not quite sure what to do about what Ross mentioned where the OPENSSL_MODULES environment variable needs to be exported. I'm happy to pick up this bug and ensure that it gets closed out. 104039 8 colinmca242 2026-01-22 16:32:56 +0000 After looking into this a bit more, I think this defect can be closed out on it's own since 45.0.0 downgraded this warning to an exception and python3-cryptography was upgraded to 45.0.7 in Whinlatter. However, I think there's still room for improvement, so I sent in a proposal last night for a PACKAGECONFIG option to enable/disable legacy-openssl support. https://lists.openembedded.org/g/openembedded-core/topic/patch_python3_cryptography/117394116 This option specifies a runtime dependency for the openssl-ossl-module-legacy module, which didn't exist and also uses the CRYPTOGRAPHY_BUILD_OPENSSL_NO_LEGACY build time environment variable to disable legacy support if the PACKAGECONFIG option is disabled. To keep forwards compatibility and not introduce any breaking changes, I left this PACKAGECONFIG option enabled, but it could also be disabled by default as that is the more secure configuration. However, that could cause breaking issues for those currently using the OpenSSL legacy module. I'm not sure about a better solution for the native openssl modules path, other than what Ross is doing with exporting OPENSSL_MODULES. If anyone thinks that's worthy of a separate bug that requires a better solution, please let me know. 104228 9 colinmca242 2026-02-11 14:09:52 +0000 Fixed by: https://git.openembedded.org/openembedded-core/commit/?id=c3c612608d816eb6b40575a86e0907701cf525dc and https://git.openembedded.org/openembedded-core/commit/?id=96548d97cbad4c125cdc07aa21182390513ca2c6 As noted in my previous comments, the assert was downgraded to a warning in python3-cryptography v45.0.0. However, the second change linked above sets the build-time environment variable to explicitly disable legacy support if the legacy packageconfig option is not set. This ensures the warning will not be shown if legacy support is not intended to be used and is not included. As noted in the ML, the legacy packageconfig option is enabled by default to preserve current behavior, but will be disabled by default once OpenSSL is disables the legacy module by default.