Should FIPS_mode() and FIPS_mode_set() be updated, deprecated, or completely removed..

Tomas Mraz tmraz at redhat.com
Wed Mar 4 10:32:34 UTC 2020


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




More information about the openssl-project mailing list