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
openssl?

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
oversimplified.

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
conscience.]


Reply via email to