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