On Mon, May 2, 2022 at 6:28 PM Robbie Harwood <rharw...@redhat.com> wrote:
>
> JT <j...@obs-sec.com> writes:
>
> >> IMO, there's a rather desperate need to be able to override the
> >> system-wide policy for individual processes, maybe via some sort of
> >> wrapper around one of the containerization technologies.
> >
> > Alternatively I wouldn't be surprised if at some point the industry
> > doesn't unofficially opt for a legacy openssl option which could be
> > utilized by legacy code, but still allow all the modern code to use
> > the new stuff.  But of course if that did exist, tons of people would
> > just refuse to update their code and deps because they have an option
> > not to.
>
> While I agree that per-application policy overrides would be really
> helpful, these suggested solutions are overkill.
>
> Concretely, crypto-policies works by managing various configuration
> files.  All that's needed to override on a per-application or even
> per-process basis is to look at a different configuration file.
> Exposing an environment variable (when it's not already) or
> initialization option from the crypto library suffices for this.
>
> In any case, this seems like functionality best provided by
> crypto-policies itself.

crypto-policies' goal is to define system-wide *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..
The sad thing though is that it's been long limited to just TLS
and routinely needs expansion to cover more.

Envvars and custom config files do exist and do function,
but I don't consider them enough.
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Reply via email to