Do we really want to have the legacy provider as opt-in only?
Tomas Mraz
tmraz at redhat.com
Mon Jul 15 14:50:23 UTC 2019
On Mon, 2019-07-15 at 16:25 +0200, Richard Levitte wrote:
> On Mon, 15 Jul 2019 16:15:01 +0200,
> Tomas Mraz wrote:
> > 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.
>
> I'm a little confused. "configuration changes" is about "having it
> in
> the config file", so I don't quite understand "oversimplified".
Basically no application that would like to work with algo from legacy
provider and that always needs it to work properly - let's say for
example something that needs to connect legacy Windows shares which use
MD4 to compute some password hash - that application cannot depend on
having the legacy enabled in the openssl config file. It should
explicitly load the legacy provider.
> Regardless of where this discussion gets us, it has always been the
> aim that this will be configurable with the config file.
Sure. What I'm just saying is that having it configurable does not
always mean it can be depended on.
I can see for example an application that works with various hashes and
by default uses secure ones and you as user need the app to check some
old file with old MD4 or RIPEMD160 hash as an exception - this can be
done by the user enabling the legacy provider in the openssl config
file.
--
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.]
More information about the openssl-project
mailing list