Re: How can I contact the crypto team?

On Mon, 2026-06-29 at 06:39 -0400, Neal Gompa wrote:
> On Mon, Jun 29, 2026 at 6:17 AM Alexander Sosedkin <[email protected]> wrote:
> > 
> > On Mon, Jun 29, 2026 at 4:57 AM Gordon Messmer <[email protected]> wrote:
> > > 
> > > On 2026-06-24 7:42 AM, Alexander Sosedkin wrote:
> > > 
> > > OK. I think you're saying that the library might not even need to adapt to Fedora's configs, we may just need documentation on their configuration format, and we could use that information to write a configuration file for the library. Is that right?
> > > 
> > > Exactly. That's how it has been with all the other software,
> > > with the notable exception of Go,
> > > that, in its infinite wisdom, didn't offer a configuration file
> > > 
> > > 
> > > I haven't heard back from the s2n-tls developers, but:
> > > 
> > > https://github.com/aws/aws-lc/blob/main/include/openssl/conf.h#L82-L83
> > > 
> > > "AWS-LC has no support for loading config files to configure AWS-LC, so the following functions have been deprecated as no-ops." and slightly later, "AWS-LC is defined to have no config file options, thus loading from |filename| always succeeds by doing nothing."
> > > 
> > > This seems to be a general trend in modern cryptographic software: little or no runtime configuration, fewer and safer ciphers, less discovery and negotiation. And having fiddled with s2n-tls to try to fix its compatibility with newer releases of OpenSSL 3, that makes sense to me (https://github.com/aws/s2n-tls/pull/5866/changes/fe9b37c10268cbeade76bd626ce3272ccf51f049).
> > 
> > That's not a good trend in my book.
> > 
> > > There are a couple of questions that might be worth considering with respect to aws-lc.
> > > 
> > > For software that can only be configured at build time, is there a configuration that is strict enough that Fedora could ship that, such that it would comply with the system configuration regardless of which configuration was selected (other than "EMPTY")?
> > 
> > I don't have a good answer.
> > Since we support custom policies, I guess that makes it a "no".
> > 
> > > Could Fedora ship a cryptographic library if its only use within Fedora was specific to the library's own vendor? Specifically, if AWS's libraries and tools drop support for general purpose libraries like OpenSSL in favor of their own secure-by-default "aws-lc" library, does it make more sense for Fedora to refuse to ship any of AWS's integration libraries and tools, or to ship aws-lc and treat it as an integrated part of the protocol between AWS clients and AWS services?
> > 
> > This feels really weird,
> > but I concede there is at least some sense in such an arrangement,
> > provided the library's bundled, making its generic interface unusable.
> > 
> 
> This would not qualify, though. AWS' crypto libraries are increasingly
> relied on by third parties. Of particular note, rustls uses it now.

It is just one of the options, rustls can be used with other libraries,
so this is not a deal breaker.

> 
> The generic interface *must* be usable.

Who says that ?

It is perfectly fine to confine the blast radius of things that do not
integrate well with the distribution's policies. Especially a corporate
owned library that can go away or be changed incompatibly or be
defunded at any time. Aws-lc is an open source licensed package, but it
is *not* an open source project by any other definition. And relying on
it, like relying on boringssl, is setting ourselves up for a very bad
experience *when* not if they decide to break things and move on
something else.

Simo.

-- 
Simo Sorce
Distinguished Engineer
RHEL Crypto Team
Red Hat, Inc

-- 
_______________________________________________
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