Alexander Sosedkin <asosedkin(a)redhat.com> 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.
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.
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?
Be well,
--Robbie