Do we really want to have the legacy provider as opt-in only?

Tomas Mraz tmraz at
Mon Jul 15 14:15:01 UTC 2019

On Mon, 2019-07-15 at 14:48 +0100, Matt Caswell wrote:
> On 15/07/2019 14:43, Tomas Mraz wrote:
> > On Mon, 2019-07-15 at 14:19 +0100, Matt Caswell wrote:
> > > On 15/07/2019 13:58, Tomas Mraz wrote:
> > > > 
> > > IMO this is a major release and therefore we should be taking the
> > > opportunity to
> > > encourage applications to move away from these legacy algorithms.
> > > That's kind of
> > > the point of having a legacy provider in the first place. Most
> > > applications
> > > should not need to use these legacy algos so in my mind it is a
> > > sensible default
> > > to not have them available. Only if you *really* need them should
> > > you
> > > load the
> > > legacy provider.
> > 
> > OK, but then for the applications that *really* need the legacy
> > algorithms the move to 3.0.0 will definitiely not be just a
> > recompilation.
> It can still be a simple recompilation even in this case - combined
> with a
> configuration change.

This might be fine for a special build of openssl included within an
application. But what would you recommend for a distribution wide

If the legacy provider is not supposed to be loaded for normal
applications then the system-wide configuration file must not load the
provider. And then you have the special legacy apps that need it and so
they need to explicitly load the legacy provider. So saying this is
"just recompliation and configuration change" is at least somewhat

But I am OK with that. I'm just saying it should be better advertised
and that internally openssl should not use the "load legacy provider by
having it in default config file" to actively encourage the "load
legacy provider only if you *really* need it" behavior.

Tomáš Mráz
No matter how far down the wrong road you've gone, turn back.
                                              Turkish proverb
[You'll know whether the road is wrong if you carefully listen to your

More information about the openssl-project mailing list