Re: How can I contact the crypto team?

Alexander Sosedkin <[email protected]>
Newsgroups gmane.linux.redhat.fedora.devel
Message-ID <CABMV8QN_J5Wq8-V7UX6-byVptiVEB1-EtB3DG7B9+xiFmEpMxw@mail.gmail.com>
On Tue, Jun 23, 2026 at 4:30 PM Gordon Messmer <[email protected]> wrote:
>
> On 2026-06-23 1:57 AM, Alexander Sosedkin wrote:
>
> On Tue, Jun 23, 2026 at 12:46 AM Gordon Messmer <[email protected]> wrote:
>
> I would like to add AWS s2n-tls to Fedora https://github.com/aws/s2n-tls
>
> Would you mind sharing the higher-level motivation for that?
>
>
> I would like to package aws-kms-pkcs11: https://copr.fedorainfracloud.org/coprs/gordonmessmer/aws-kms-pkcs11/packages/
>
> This package allows the use of AWS KMS as an HSM, which I am using to sign code and rpm packages.

Okay. Sorry for being ceaselessly curious,
but poking around copr webui didn't lead me to matching specfiles
quickly enough, so...
how is it related to s2n-tls?
I'm not sure I understand how a pkcs11 module ended up pulling in an
entire TLS implementation =)

> Alright, as you've probably already read at
> https://docs.fedoraproject.org/en-US/packaging-guidelines/CryptoPolicies,
> from the crypto-policies perspective,
> we don't want applications/libraries to force any specific algorithms
> as such hardcoded decisions go stale and haunt us decades later.
> Instead the defaults should follow a configuration file we generate.
> Offering a sane allowlisting configuration format is strongly desired,
> so that rebases bringing in new algorithms don't become unnecessarily awkward.
> I'd be happy to clarify further, but for that I'd need your questions.
>
>
> I would like to revive a number of AWS libraries in Fedora, including s2n-tls. The s2n-tls project is considering dropping support for OpenSSL, and focusing on "aws-lc" which is a fork of BoringSSL.
>
> https://github.com/aws/aws-lc
>
> https://github.com/aws/s2n-tls/issues/5783 (OpenSSL Support Roadmap ticket)
>
> I mentioned to them that in order to package aws-lc in Fedora, it would need to comply with system crypto policies, as indicated at https://docs.fedoraproject.org/en-US/packaging-guidelines/CryptoPolicies/
>
> While I wait on their reply: If they were interested in supporting Fedora crypto policies, is there any documentation available that describes the required compliance?

Oh. Sorry for the confusion. I don't even know what to say here, as
there's so little to say.

All crypto-policies does is generating configuration files (or fragments of one)
for multiple libraries/apps from a single system configuration file.
So "supporting crypto-policies" is usually transparent to the upstream
library/app, and boils down to:
1. upstream: a library/application has a config file that defines what
algorithms are enabled by default,
   which most of them just... naturally already do by a certain maturity stage?
2. packaging: it will then, in Fedora, have to
   be compiled to read this config from
/etc/crypto-policies/back-ends/$name.config,
   get patched if the upstream isn't receptive to making it a
compile-time option,
   or even just ship a symlink that points there from the default
location, why not.
3. within crypto-policies: I should then implement a generator for
said configuration file,
   that, given a sane config format,
   mostly just maps the crypto-policies algorithm names to the
library/application ones.

... and that's kinda it?

> Any tests suites that validate it?

crypto-policies upstream testing? that largely boils down to
1. apps/libraries not choking on configs it generates
2. generated files being compared with static fixtures
The actual semantics are usually covered by app/library upstream testsuites.

> Can we point them to the patches that implement system integration for any other libcrypto that we ship?

Examples that come to mind, in no particular order:
* the first version of the sequoia back-end:
https://gitlab.com/redhat-crypto/fedora-crypto-policies/-/merge_requests/122/diffs#diff-content-67e7d7d9f8d1b61f9b3581a998fa3895cffc6ec8
* /etc/ssl/openssl.cnf patches the config to include
/etc/crypto-policies/back-ends/opensslcnf.config from a section (so it
could also be an include of a snippet of a config):
  https://src.fedoraproject.org/rpms/openssl/blob/4fd22a7ec96e7c88e792754cab14aaf347c74208/f/0002-Add-a-separate-config-file-to-use-for-rpm-installs.patch#_145
* gnutls specfile redefines default config location
https://src.fedoraproject.org/rpms/gnutls/blob/16da2226353926c2a54a94e5ca9eca384c512d96/f/gnutls.spec#_380
* gnutls config format change, the *only* example of upstream
specifically catering to crypto-policies that I remember:
https://fedoraproject.org/wiki/Changes/GnutlsAllowlisting

> Thanks, Alexander

You're welcome.

And sheesh, whatever the rest of the thread is doing to that
particular molehill is... outright tectonic.

-- 
_______________________________________________
devel mailing list -- [email protected]
To unsubscribe send an email to [email protected]
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/[email protected]
Do not reply to spam, report it: https://forge.fedoraproject.org/infra/tickets/issues/new
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.