Re: [RFC] FIPS compliance and other crypt(3) improvements

[Roland McGrath <roland at hack dot frob dot com>]

> On May 15, 2012, Roland McGrath <roland@hack.frob.com> wrote:
> 
> > ENOSYS is the error code for a function that is entirely unimplemented.
> 
> It's the only POSIX-documented error code for crypt.  That's why I went
> with it.

It's a general part of POSIX that functions can return different errno
codes than the ones listed.  It's only required that for the failures
that are described in standard, you return exactly those error codes.
This is a failure mode not specified by the standard, so returning a
different errno value for it is entirely kosher.

> > Is there any standard or precedent for _SC_CRYPTO_FIPS_ENABLED?
> 
> Nope.  I came up with it myself.  I thought of adding _GNU_ in there
> somewhere, and bumping the number way up, as an extension without
> conflicts, but I didn't get that far.

If it's nonstandard then it certainly should have a name that makes that
clear.  But I'm not at all convinced that sysconf is the right place for
such an extension.

> > If the only need for it is an internal one
> 
> Other userland programs and libraries test FIPS status reading /proc
> files directly, but I though they (and any newer programs) could switch
> to a more portable interface.

That is an entirely reasonable notion.  But don't conflate it with the
implementation of the crypt change.  Have crypt use an internal function
that is not exported.  Separately and later, we can consider providing
a public interface for FIPS status, but that is an entirely different
conversation (and one that I'm in no hurry to have).


Thanks,
Roland