> While I agree that per-application policy overrides would be really
helpful, these suggested solutions are overkill.
Overkill is SELinux's middle name isn't it. :P It always struck me as being intentionally heavy handed... which is kind of a good thing if you're looking for control above all else. That being said though...
> In any case, this seems like functionality best provided by crypto-policies itself.
Agreed, the simpler and less code complex the better.
helpful, these suggested solutions are overkill.
Overkill is SELinux's middle name isn't it. :P It always struck me as being intentionally heavy handed... which is kind of a good thing if you're looking for control above all else. That being said though...
> In any case, this seems like functionality best provided by crypto-policies itself.
Agreed, the simpler and less code complex the better.
On Mon, May 2, 2022 at 12:27 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.
Be well,
--Robbie
_______________________________________________ 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
