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
