On Mon, May 2, 2022 at 7:18 PM Robbie Harwood <rharwood@xxxxxxxxxx> wrote: > > Alexander Sosedkin <asosedkin@xxxxxxxxxx> writes: > > > crypto-policies' goal is to define system-wide *defaults*. > > Well, that's certainly part of it, but... > > "The purpose is to unify the crypto policies used by different > applications and libraries. That is allow setting a consistent security > level for crypto on all applications in a Fedora system, irrespective of > the crypto library in use." > > (from https://gitlab.com/redhat-crypto/fedora-crypto-policies#purpose ) > > "Unify the crypto policies used by different applications and > libraries. That is allow setting a consistent security level for crypto > on all applications in a Fedora system. The implementation approach will > be to initially modify SSL libraries to respect the policy and gradually > adding more libraries and applications." > > (from https://fedoraproject.org/wiki/Changes/CryptoPolicy#Summary ) > > So to restate: from what Nikos wrote, I read an additional goal of > unification and centralization that I don't hear echoed in what you're > saying. Unification and centralization of defaults. And yes, I can't vouch that the early crypto-policies goal was to set defaults, in fact some of the changes by Nikos set hard non-sidesteppable limits. Now we're moving away from that to setting soft-defaults. > > Cryptographic libraries already provide all kinds of finer API to > > deviate from configuration file defaults that isn't just envvars or > > pointing to configuration files; API that applications are already > > supposed to be using if they want to ensure that a specific algorithm > > is available no matter what the local/vendor/whatever configuration > > is. > > In many cases these APIs exist, but what you're proposing is a world > where applications generally need to care about their own crypto > settings. In that world, there's little incentive to use the systemwide > settings at all, and we're back to each application deciding crypto for > themselves - which doesn't strike me as appealing. Absolutely not, quite the opposite, even. I advocate for the world of applications that 1. practice cryptographic agility and trust the system defaults 2. when faced with an overly legacy scenario, fail by default 3. only if/when the operator explicitly opts to go unsafe, grant itself an exception and relax the list of what's allowed + more or less conveniently adjustable system defaults don't hurt What I tried to say is, for each and every configurable aspect of the library nobody guarantees the app author that it's allowed on a select system. Thus applications must be ready for any algorithm to be restricted and act sensibly when it is. This is the case for all distros and works the same in the crypto-policies-less world. > > The sad thing though is that it's been long limited to just TLS and > > routinely needs expansion to cover more. > > Yes, many things make the assumption that crypto == TLS. > crypto-policies already covers more than just TLS settings for > applications, so it needs to have solutions for more than just that. > > > Envvars and custom config files do exist and do function, but I don't > > consider them enough. > > So what solution do you propose that would be enough? Something akin to gnutls' recently added gnutls_sign_set_secure, we'll also need to propose something similar for OpenSSL. _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx 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/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
