python3-cryptography: Add legacy-openssl packageconfig

Fixes [YOCTO #15416]

Adds legacy-openssl packageconfig option to allow users to specify
if they would like the cryptography module to support the legacy OpenSSL
module or not. The legacy-openssl packageconfig option ensures the
openssl-ossl-module-legacy package is set as a runtime dependency. If
the packageconfig option is disabled,
CRYPTOGRAPHY_BUILD_OPENSSL_NO_LEGACY will prevent the library from ever
attempting to load the legacy provdier.

Signed-off-by: Colin Pinnell McAllister <colinmca242@gmail.com>
---

I wasn't sure if this new packageconfig option should be enabled or
disabled by default. Leaving it enabled seems like the less disruptive
option, although it's leaving the module in a less secure state by
default.

I'm happy to update the patch to leave the option disabled by default
if others think that would be better.

 meta/recipes-devtools/python/python3-cryptography.bb | 5 +++++
 1 file changed, 5 insertions(+)

On Thu, 22 Jan 2026 at 03:57, Colin McAllister via
lists.openembedded.org <colinmca242=gmail.com@lists.openembedded.org>
wrote:
>
> Fixes [YOCTO #15416]
>
> Adds legacy-openssl packageconfig option to allow users to specify
> if they would like the cryptography module to support the legacy OpenSSL
> module or not. The legacy-openssl packageconfig option ensures the
> openssl-ossl-module-legacy package is set as a runtime dependency. If
> the packageconfig option is disabled,
> CRYPTOGRAPHY_BUILD_OPENSSL_NO_LEGACY will prevent the library from ever
> attempting to load the legacy provdier.
>
> Signed-off-by: Colin Pinnell McAllister <colinmca242@gmail.com>
> ---
>
> I wasn't sure if this new packageconfig option should be enabled or
> disabled by default. Leaving it enabled seems like the less disruptive
> option, although it's leaving the module in a less secure state by
> default.
>
> I'm happy to update the patch to leave the option disabled by default
> if others think that would be better.

It would help to understand what this legacy module is for. 'Legacy'
and 'crypto' together aren't a great pair of words.

In master it's possible to break such defaults. If the outcome is a
more secure system, it's even desirable.

Alex

Hi Alex,

See my responses inline below.

Best,
Colin


On Mon, Jan 26, 2026 at 4:05 AM Alexander Kanavin <alex.kanavin@gmail.com>
wrote:

> On Thu, 22 Jan 2026 at 03:57, Colin McAllister via
> lists.openembedded.org <colinmca242=gmail.com@lists.openembedded.org>
> wrote:
> >
> > Fixes [YOCTO #15416]
> >
> > Adds legacy-openssl packageconfig option to allow users to specify
> > if they would like the cryptography module to support the legacy OpenSSL
> > module or not. The legacy-openssl packageconfig option ensures the
> > openssl-ossl-module-legacy package is set as a runtime dependency. If
> > the packageconfig option is disabled,
> > CRYPTOGRAPHY_BUILD_OPENSSL_NO_LEGACY will prevent the library from ever
> > attempting to load the legacy provdier.
> >
> > Signed-off-by: Colin Pinnell McAllister <colinmca242@gmail.com>
> > ---
> >
> > I wasn't sure if this new packageconfig option should be enabled or
> > disabled by default. Leaving it enabled seems like the less disruptive
> > option, although it's leaving the module in a less secure state by
> > default.
> >
> > I'm happy to update the patch to leave the option disabled by default
> > if others think that would be better.
>
> It would help to understand what this legacy module is for. 'Legacy'
> and 'crypto' together aren't a great pair of words.
>

Would you like me to add additional information within the commit message
or the recipe itself?

Verbose thoughts follow:

The OpenSSL legacy provider provides algorithms that are either used
infrequently or have been deemed insecure.

https://docs.openssl.org/3.5/man7/OSSL_PROVIDER-legacy/

The openssl-ossl-module-legacy package in oe-core provides this legacy
module and the module is installed as a separate shared lib
in ${libdir}/ossl-modules/legacy.so.

The Python3 cryptography module supports the OpenSSL legacy provider.
Historically, if support wasn't disabled via an env var and this module
could not be found, the cryptography module would raise an exception. More
details of this causing issues in oe-core can be found in Yocto #15416
https://bugzilla.yoctoproject.org/show_bug.cgi?id=15416

In Python3 cryptography v45.0.0, this exception was downgraded to a
warning. However, a build-time env var was also added that can explicitly
disable support as if the existing runtime flag is always set.
This patch is my attempt to integrate this support into oe-core where a
packageconfig option is used to enable/disable support for this legacy
module and also set an explicit runtime dependency on the
openssl-oss-module-legacy package.

In master it's possible to break such defaults. If the outcome is a
> more secure system, it's even desirable.


I am a little hesitant to disable this packageconfig option by default.
With this option disabled, after an upgrade, a user of python3-cryptography
will suddenly lose support for some algorithms. Based on my testing, the
exception is not super helpful and may be tricky to track down the root
cause. Since this is a general-purpose cryptography library, users should
make their own informed decisions on what OpenSSL algorithms are safe to
use. End users will not be unknowingly subjected to insecure algorithms
being used on their product. However, for those that may need to exclude
the algorithms from their platforms due to compliance/certification
requirements, the functionality can be disabled.

I do think the discussion within the Cryptography GitHub is worth
referencing:
https://github.com/pyca/cryptography/issues/11450

Lastly, the openssl-oss-module-legacy package is enabled by default in the
OpenSSL recipe, so by disabling this support by default, I'd be introducing
inconsistent behavior.

I'm happy to push up a v2 patch disabling this packageconfig option by
default, but I think that should be accompanied with a patch disabling the
openssl-oss-module-legacy package by default as well.

Please let me know what you think would be best.

Alex
>

On Mon, 26 Jan 2026 at 14:56, Colin <colinmca242@gmail.com> wrote:

> Lastly, the openssl-oss-module-legacy package is enabled by default in the OpenSSL recipe, so by disabling this support by default, I'd be introducing inconsistent behavior.
>
> I'm happy to push up a v2 patch disabling this packageconfig option by default, but I think that should be accompanied with a patch disabling the openssl-oss-module-legacy package by default as well.
>
> Please let me know what you think would be best.

Thanks for the extended answer. Basically yes, I think we should start
by looking at openssl itself. It would be good to make a couple of
patches:

- adding a packageconfig for legacy, and enabling that by default (to
preserve existing behavior)
- removing legacy from the defaults (for a more secure build, if
openssl itself isn't willing to pick that default for its users, which
I disagree with)

Then the changes in these patches can be reviewed separately.

python3-cryptography ideally should auto-configure itself at runtime:
if legacy is present, it can be used, if not, then it's not available.
Otherwise, there should also be a couple patches for it:

- packageconfig for legacy, enabled by default (basically the current
patch as it is is alright)
- removing legacy from defaults (would be merged in lockstep with the
same change in openssl)

You can add the various supporting links and other information in your
message across the patches, as you see fit.

Alex