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