On Mon, May 2, 2022 at 6:28 PM Robbie Harwood <rharwood@xxxxxxxxxx> wrote: > > JT <jt@xxxxxxxxxxx> 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@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
