Stop requiring signoff from non-existent "Fedora crypto team" for new cryptography libraries

decathorpe commented

2026-06-23 12:02:55 +00:00

Owner

Packaging of new cryptography libraries currently requires signoff from the "Fedora crypto team": https://docs.fedoraproject.org/en-US/packaging-guidelines/CryptoPolicies/#_new_crypto_libraries

This "team" is defunct and hasn't existed for the better part of a decade (or longer?), the linked mailing list is private, moderated, and appears to have zero messages in its mailing list archive. Sending mails to it is equivalent to sending something to /dev/null.

The Red Hat Crypto team now ~~kind of~~ fills the role that the "Fedora crypto team" used to have, except for some tasks (like approvals for new cryptography libraries) that are still referenced in our documentation but that nobody seems to be responsible for now. This means that packaging any such library has basically stalled due to lack of the necessary "OK" (or even a definitive "no") from a group that no longer exists (see RHBZ#2350145 for an example).

I propose that this signoff requirement is dropped from the Packaging Guidelines.

Packaging of new cryptography libraries currently requires signoff from the "Fedora crypto team": https://docs.fedoraproject.org/en-US/packaging-guidelines/CryptoPolicies/#_new_crypto_libraries This "team" is defunct and hasn't existed for the better part of a decade (or longer?), the linked mailing list is private, moderated, and appears to have zero messages in its mailing list archive. Sending mails to it is equivalent to sending something to /dev/null. The Red Hat Crypto team now ~kind of~ fills the role that the "Fedora crypto team" used to have, except for some tasks (like approvals for new cryptography libraries) that are still referenced in our documentation but that nobody seems to be responsible for now. This means that packaging any such library has basically stalled due to lack of the necessary "OK" (or even a definitive "no") from a group that no longer exists (see [RHBZ#2350145](https://bugzilla.redhat.com/show_bug.cgi?id=2350145) for an example). I propose that this signoff requirement is dropped from the Packaging Guidelines.

supakeen commented

2026-06-23 12:44:08 +00:00

Owner

It'd be nice to have a little bit of the backstory on why sign-off is/was required. In case it makes sense to have sign-off and the Red Hat crypto team is willing to take this up as a responsibility I'd instead suggest to change the documentation to refer to them and the ways to reach them.

If not, then getting rid of the signoff requirement is indeed the only option.

Do we want to reach out, or have we already done so? I saw some back-and-forth on devel@ about it but it wasn't particularly clear.

It'd be nice to have a little bit of the backstory on why sign-off is/was required. In case it makes sense to have sign-off *and* the Red Hat crypto team is willing to take this up as a responsibility I'd instead suggest to change the documentation to refer to them and the ways to reach them. If not, then getting rid of the signoff requirement is indeed the only option. Do we want to reach out, or have we already done so? I saw some back-and-forth on devel@ about it but it wasn't particularly clear.

simo commented

2026-06-23 14:02:53 +00:00

The team is not defunct, but the contact point described there somehow stopped working.

I think carefully curating what cryptography is allowed in Fedora is a vital service to the integrity of the distribution. not all crypto-librraies are equal, and some are really bad, while others simply do not integrate with the rest of the distribution (crypto-policy, system CA store, etc...)

So far the request are always "oh I'd like to put this in", and the only justification is XYZ needs it and does not support a proper library and I do not care for addressing the issues.

I think the policing could be lifted if there was serious respect of the guidelines (ie integration with crypto-policies and system-ca store as a minimum).

That would still leave unanswered a check on the quality of the library. And especially now there are many bad libraries in hip ecosystems ...

The team is not defunct, but the contact point described there somehow stopped working. I think carefully curating what cryptography is allowed in Fedora is a vital service to the integrity of the distribution. not all crypto-librraies are equal, and some are really bad, while others simply do not integrate with the rest of the distribution (crypto-policy, system CA store, etc...) So far the request are always "oh I'd like to put this in", and the only justification is XYZ needs it and does not support a proper library and I do not care for addressing the issues. I think the policing could be lifted if there was serious respect of the guidelines (ie integration with crypto-policies and system-ca store as a minimum). That would still leave unanswered a check on the quality of the library. And especially now there are many *bad* libraries in hip ecosystems ...

hkario commented

2026-06-23 14:58:56 +00:00

Just a simple example of the systemic issues of the cryptographic implementations: https://hexproof.dev/datagrams/bleichenbacher-oracle-survey/

gotmax23 commented

2026-06-28 18:29:17 +00:00

Owner

(xref https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/DAY777IVZT32WVPWTEK5BLVFT4A6FRSS/)

What can we do to unblock this? To start with, can we make it possible to actually contact the crypto team?

As for aws-lc, how can we move forward there? The last update I see in the review ticket from 2026-02-14 says

Three months later, the situation has not improved - rather, the fact that aws-lc-sys / aws-lc-rs crates are not available in Fedora is causing more friction, if anything.

Has there been any improvement there or in making it possible to use an openssl-based crypto backend? Should we consider making an exception to the crypto policies for aws-lc in Rust like we already have for the crypto libraries/implementations built in to Go?

(xref https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/DAY777IVZT32WVPWTEK5BLVFT4A6FRSS/) What can we do to unblock this? To start with, can we make it possible to actually contact the crypto team? As for aws-lc, how can we move forward there? The last update I see in the review ticket from 2026-02-14 says > Three months later, the situation has not improved - rather, the fact that aws-lc-sys / aws-lc-rs crates are not available in Fedora is causing more friction, if anything. Has there been any improvement there or in making it possible to use an openssl-based crypto backend? Should we consider making an exception to the crypto policies for aws-lc in Rust like we already have for the crypto libraries/implementations built in to Go?

decathorpe commented

2026-06-30 18:11:41 +00:00

Author

Owner

Has there been any improvement there or in making it possible to use an openssl-based crypto backend?

There is ongoing work in rustls upstream that makes it easier to switch out its crypto backends, but this is not yet available in a stable release. There is work happening on two OpenSSL based crypto backends for rustls, but both aren't compatible with the upcoming backend modularization work in rustls upstream yet.

Having an OpenSSL backend for rustls will help (though it will also require more patching work downstream for all consumers), but it will not solve the problem entirely - some applications (or libraries) also want to use AWS-LC (or ring) directly, and don't support using OpenSSL. If there is going to be a hard veto (is there even an existing framework / precedent for this, other than the "Legal" banhammer?) from Red Hat on shipping aws-lc and the ring crate in Fedora, affected applications will likely have to be dropped.

> Has there been any improvement there or in making it possible to use an openssl-based crypto backend? There is ongoing work in `rustls` upstream that makes it easier to switch out its crypto backends, but this is not yet available in a stable release. There is work happening on two OpenSSL based crypto backends for `rustls`, but both aren't compatible with the upcoming backend modularization work in `rustls` upstream yet. Having an OpenSSL backend for `rustls` will help (though it will also require more patching work downstream for all consumers), but it will not solve the problem *entirely* - some applications (or libraries) also want to use AWS-LC (or ring) directly, and don't support using OpenSSL. If there is going to be a hard veto (is there even an existing framework / precedent for this, other than the "Legal" banhammer?) from Red Hat on shipping aws-lc and the `ring` crate in Fedora, affected applications will likely have to be dropped.

ngompa commented

2026-06-30 18:19:18 +00:00

Owner

Should we continue to enforce this restriction for Red Hat's benefit? I'm of the mind that this one probably should go away unless there are some resources committed to make it feasible to maintain.

gotmax23 commented

2026-06-30 19:00:01 +00:00

Owner

I'm open to making a FESCo exception to this policy for aws-lc unless there's a legitimate RH legal/compliance reason that we can't.

simo commented

2026-06-30 19:27:44 +00:00

@ngompa wrote in #3624 (comment):

Should we continue to enforce this restriction for Red Hat's benefit? I'm of the mind that this one probably should go away unless there are some resources committed to make it feasible to maintain.

This statement is absolutely inaccurate, and frankly slandering to the people that work on this stuff.

The crypto team wants to protect Fedora and its users, and have a system that work as a whole, not a hodgepodge of 300 different applications all doing their worst at choosing what algorithms are ok or not to use in a system.

That is why we created crypto-polciies and maintain the ca-certificate store among other things.

FESCo can decide that th security and safety of Fedora users is not that important, and go ahead and allow bad crypto libraries in the distribution, it is not my call, but it is not acceptable to paint our work as only beneficial to Red Hat somehow.

@ngompa wrote in https://forge.fedoraproject.org/fesco/tickets/issues/3624#issuecomment-874282: > Should we continue to enforce this restriction for Red Hat's benefit? I'm of the mind that this one probably should go away unless there are some resources committed to make it feasible to maintain. This statement is absolutely inaccurate, and frankly slandering to the people that work on this stuff. The crypto team wants to protect *Fedora* and its users, and have a system that work as a whole, not a hodgepodge of 300 different applications all doing their worst at choosing what algorithms are ok or not to use in a system. That is why we created crypto-polciies and maintain the ca-certificate store among other things. FESCo can decide that th security and safety of Fedora users is not that important, and go ahead and allow bad crypto libraries in the distribution, it is not my call, but it is not acceptable to paint our work as only beneficial to Red Hat somehow.

gotmax23 commented

2026-06-30 20:02:17 +00:00

Owner

As I understand it, the current solution for Rust packages that use rustls is the ring cryptography backend which also bundles boringcrypto but is described as experimental software and hasn't had a release in over a year and doesn't support PQC algorithms..

Is my understanding correct? If it is, allowing rust-aws-lc-sys seems decidedly better than keeping ring or retiring all the packages that use it until openssl is supported.

As I understand it, the current solution for Rust packages that use rustls is the ring cryptography backend which also bundles boringcrypto but is described as experimental software and hasn't had a release in over a year and doesn't support PQC algorithms.. Is my understanding correct? If it is, allowing rust-aws-lc-sys seems decidedly better than keeping ring or retiring all the packages that use it until openssl is supported.

ngompa commented

2026-06-30 20:13:15 +00:00

Owner

@simo wrote in #3624 (comment):

@ngompa wrote in #3624 (comment):

Should we continue to enforce this restriction for Red Hat's benefit? I'm of the mind that this one probably should go away unless there are some resources committed to make it feasible to maintain.

This statement is absolutely inaccurate, and frankly slandering to the people that work on this stuff.

The crypto team wants to protect Fedora and its users, and have a system that work as a whole, not a hodgepodge of 300 different applications all doing their worst at choosing what algorithms are ok or not to use in a system.

That is why we created crypto-polciies and maintain the ca-certificate store among other things.

FESCo can decide that th security and safety of Fedora users is not that important, and go ahead and allow bad crypto libraries in the distribution, it is not my call, but it is not acceptable to paint our work as only beneficial to Red Hat somehow.

Right now the status quo is decidedly worse. We are shipping an unmaintained crypto library that also uses BoringSSL. Multiple upstreams do not want to use the OpenSSL library, so we are stuck between a rock and a hard place. You don't want to engage with those upstreams, and we can't not have these things. Even cryptography from Python is no longer actively supporting OpenSSL.

I am of the opinion we shouldn't have any more of these things, but I wish people had picked crypto libraries with better APIs, like GnuTLS, instead of OpenSSL as the "default". But they didn't, and here we are. At this point AWS-LC is the best of the bad bunch.

@simo wrote in https://forge.fedoraproject.org/fesco/tickets/issues/3624#issuecomment-874338: > @ngompa wrote in #3624 (comment): > > > Should we continue to enforce this restriction for Red Hat's benefit? I'm of the mind that this one probably should go away unless there are some resources committed to make it feasible to maintain. > > This statement is absolutely inaccurate, and frankly slandering to the people that work on this stuff. > > The crypto team wants to protect _Fedora_ and its users, and have a system that work as a whole, not a hodgepodge of 300 different applications all doing their worst at choosing what algorithms are ok or not to use in a system. > > That is why we created crypto-polciies and maintain the ca-certificate store among other things. > > FESCo can decide that th security and safety of Fedora users is not that important, and go ahead and allow bad crypto libraries in the distribution, it is not my call, but it is not acceptable to paint our work as only beneficial to Red Hat somehow. Right now the status quo is decidedly worse. We are shipping an unmaintained crypto library that also uses BoringSSL. Multiple upstreams do not want to use the OpenSSL library, so we are stuck between a rock and a hard place. You don't want to engage with those upstreams, and we can't _not_ have these things. Even `cryptography` from Python is [no longer actively supporting OpenSSL](https://cryptography.io/en/latest/statements/state-of-openssl/). I am of the opinion we shouldn't have any more of these things, but I wish people had picked crypto libraries with better APIs, like GnuTLS, instead of OpenSSL as the "default". But they didn't, and here we are. At this point AWS-LC is the best of the bad bunch.

simo commented

2026-06-30 20:15:49 +00:00

@gotmax23 wrote in #3624 (comment):

Is my understanding correct? If it is, allowing rust-aws-lc-sys seems decidedly better than keeping ring or retiring all the packages that use it until openssl is supported.

Yes if the choice is between ring and aws-lc, aws-lc is orders of magnitudes more desirable and I would support an exception to get rid f ring

@gotmax23 wrote in https://forge.fedoraproject.org/fesco/tickets/issues/3624#issuecomment-874341: > Is my understanding correct? If it is, allowing rust-aws-lc-sys seems decidedly better than keeping ring or retiring all the packages that use it until openssl is supported. Yes if the choice is between ring and aws-lc, aws-lc is orders of magnitudes more desirable and I would support an exception to get rid f ring

ngompa commented

2026-06-30 20:17:52 +00:00

Owner

We will also need aws-lc for python-cryptography too, because no PQC work is being done by PyCA using OpenSSL.

simo commented

2026-06-30 20:18:10 +00:00

@ngompa wrote in #3624 (comment):

I am of the opinion we shouldn't have any more of these things, but I wish people had picked crypto libraries with better APIs, like GnuTLS, instead of OpenSSL as the "default". But they didn't, and here we are. At this point AWS-LC is the best of the bad bunch.

APIs are secondary, what matter is the cryptography library has solid cryptography, and although my team maintain both so I do not pick favorite children, openssl has less problematic CVEs than GnuTLS and a wider ecosystem...

@ngompa wrote in https://forge.fedoraproject.org/fesco/tickets/issues/3624#issuecomment-874347: > I am of the opinion we shouldn't have any more of these things, but I wish people had picked crypto libraries with better APIs, like GnuTLS, instead of OpenSSL as the "default". But they didn't, and here we are. At this point AWS-LC is the best of the bad bunch. APIs are secondary, what matter is the cryptography library has solid cryptography, and although my team maintain both so I do not pick favorite children, openssl has less problematic CVEs than GnuTLS and a wider ecosystem...

simo commented

2026-06-30 20:19:56 +00:00

@ngompa wrote in #3624 (comment):

We will also need aws-lc for python-cryptography too, because no PQC work is being done by PyCA using OpenSSL.

we definitely do not need aws-lc for python-cryptography, it works well with openssl and integrates correctly with the rest of the system through it.

Aws-lc should be confined to those rust packages that are welded to it.

@ngompa wrote in https://forge.fedoraproject.org/fesco/tickets/issues/3624#issuecomment-874350: > We will also need aws-lc for python-cryptography too, because no PQC work is being done by PyCA using OpenSSL. we definitely do *not* need aws-lc for python-cryptography, it works well with openssl and integrates correctly with the rest of the system through it. Aws-lc should be confined to those rust packages that are welded to it.

ngompa commented

2026-06-30 20:22:32 +00:00

Owner

@simo wrote in #3624 (comment):

@ngompa wrote in #3624 (comment):

I am of the opinion we shouldn't have any more of these things, but I wish people had picked crypto libraries with better APIs, like GnuTLS, instead of OpenSSL as the "default". But they didn't, and here we are. At this point AWS-LC is the best of the bad bunch.

APIs are secondary, what matter is the cryptography library has solid cryptography, and although my team maintain both so I do not pick favorite children, openssl has less problematic CVEs than GnuTLS and a wider ecosystem...

I disagree there. APIs are more important, because they are what guarantee adoption. If the APIs are good, developers will use it, and the crypto being good or bad basically does not matter in the face of that. Good APIs and good crypto is the holy grail, and somehow we got OpenSSL instead...

@simo wrote in https://forge.fedoraproject.org/fesco/tickets/issues/3624#issuecomment-874351: > @ngompa wrote in #3624 (comment): > > > I am of the opinion we shouldn't have any more of these things, but I wish people had picked crypto libraries with better APIs, like GnuTLS, instead of OpenSSL as the "default". But they didn't, and here we are. At this point AWS-LC is the best of the bad bunch. > > APIs are secondary, what matter is the cryptography library has solid cryptography, and although my team maintain both so I do not pick favorite children, openssl has less problematic CVEs than GnuTLS and a wider ecosystem... I disagree there. APIs are more important, because they are what guarantee adoption. If the APIs are good, developers will use it, and the crypto being good or bad basically does not matter in the face of that. Good APIs and good crypto is the holy grail, and somehow we got OpenSSL instead...

simo commented

2026-06-30 20:24:53 +00:00

[comment deleted because not appropriate, apologies]

salimma added the

meeting

label

2026-07-07 09:19:04 +00:00

decathorpe added

document it

and removed

meeting

labels

2026-07-10 15:11:36 +00:00

decathorpe commented

2026-07-10 15:14:27 +00:00

Author

Owner

This was discussed during Tuesday's FESCo meeting.

The following proposal was approved (see meeting log at 17:36:31).

AGREED: Lacking an actual documented process, the 'Crypto team' signoff requirement is dropped, with FESCo stepping in as gatekeeper for the time being. Once a new public review process has been established, a signoff requirement in some form could be reintroduced. (7, 1, -0)

This was discussed during Tuesday's FESCo meeting. The following proposal was approved (see [meeting log](https://meetbot.fedoraproject.org/meeting_matrix_fedoraproject-org/2026-07-07/fesco.2026-07-07-17.00.log.html) at 17:36:31). > AGREED: Lacking an actual documented process, the 'Crypto team' signoff requirement is dropped, with FESCo stepping in as gatekeeper for the time being. Once a new public review process has been established, a signoff requirement in some form could be reintroduced. (7, 1, -0)

decathorpe referenced this issue from packaging/guidelines

2026-07-10 15:24:15 +00:00

CryptoPolicies: crypto-team -> fesco for exception approvals #1555

decathorpe commented

2026-07-12 17:53:12 +00:00

Author

Owner

The documentation is now updated:
packaging/guidelines#1555

The documentation is now updated: https://forge.fedoraproject.org/packaging/guidelines/pulls/1555

decathorpe

2026-07-12 17:53:23 +00:00