On Wed, 2020-03-04 at 10:18 +0000, Matt Caswell wrote: > > On 04/03/2020 08:15, Tomas Mraz wrote: > > The current implementation in the PR - unconditionally returning > > error > > - is completely useless. It would make some (not much) sense if we > > aimed for ABI compatibility with 3.0 however that is definitely not > > the > > case so the only reasonable thing is to either try to emulate the > > behavior as much as possible or remove completely so the users of > > the > > API would know immediately that they have to be changed. > > > > I don't have a strong view, but I think I tend to agree that removal > is > the better option. 3.0 *is* a major release and we've never > guaranteed > that there will be *no* breaking changes at all. We've only aimed for > most applications that work in 1.1.1 not having to change. Since > these > functions exist in 1.1.1, but always fail, it seems reasonable to > think > that very few 1.1.1 application actually call them.
But they do not fail always - the FIPS_mode_set just works fine if you do not use it to actually enable the FIPS mode and FIPS_mode always returns 0 (without error). And that is fine because there is no FIPS module in 1.1.1. But of course this behavior would not be fine with 3.0, it would be completely confusing. > If there are any > that do so, then they probably need to re-examine their code anyway > to > confirm what the behaviour should be with 3.0. Exactly. > If we remove them then we should have some good documentation > somewhere > that explains what people should do instead. +1 > I also think this will probably need an OMC vote. > > Matt -- 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.]