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
