[Pkg-openssl-devel] Bug#965041: Bug#965041: Bug#965041: libssl3: Please stop building legacy provider

[Sebastian Andrzej Siewior]

On 2022-09-18 21:06:59 [+0200], Kurt Roeckx wrote:
> I'm not sure that having the legacy provider automatically enabled by
> default when it's installed is a good idea. That means once it's
> installed, all applications have it by default. I think it needs to be
> enabled per application.

The only legitime users are applications that need rc4/3des (or others)
for legacy reasons like I need to access this.

> I think the same goes for fips. Only applications that need it, and
> probably support a library context should enable it. I don't know enough
> details currently about fips, but I think applications need to provider
> an approved RNG, and /dev/random is no longer acceptable.
> But upgrading the fips provider should be as easy as possible,
> just installing a new version. So I think we need to provider at least
> some config file should have the hash in it.

I'm not 100% sure but based on blured memory rng with get_random() for
seed as we use it is a compile time option. But then I'm not sure if it
can be provided for fips needs by a provider or so.
Anyway, what do we do here?

Do we keep everything as-is and just add something like 
	.include /etc/ssl/providers.d/

to openssl.cnf to support custom providers? While outsourcing the legacy
providers to its own package sounds nice, the downside is, as you say,
that once it is enabled by installed package it is enabled for everyone.
Not to mention the bug reports where the enabled legacy providers don't
work because the package is missing.

> Kurt

Sebastian