[PATCH 2/2] crypt.3, encrypt.3: Add notes about _XOPEN_CRYPT.

[Zack Weinberg]

On Sat, Apr 14, 2018 at 3:56 PM, Florian Weimer <fweimer@redhat.com> wrote:
> On 04/14/2018 09:11 PM, Nikos Mavrogiannopoulos wrote:
>>
>>   What about the second part of the suggestion. The crypt.3 manpage
>> currently suggests including <unistd.h>, with _XOPEN_SOURCE defined,
>> and that does not work with current glibc.
>
> Current Fedora glibc.  We need to align the Fedora behavior with upstream
> again, either by lobbying for an upstream change, or changing Fedora back to
> how things were before.

Portable code has always needed to cope with the possibility of
crypt() not being declared by unistd.h -- that goes all the way back
to the old export control policy in the 1990s.  This is what I wrote
for the new crypt(3) manpage shipped with libxcrypt:

SYNOPSIS
       #include <crypt.h>

       char *crypt(const char *phrase, const char *setting);
       char *crypt_r(const char *phrase, const char *setting, struct
               crypt_data *data);
       char *crypt_rn(const char *phrase, const char *setting, void *data, int
               size);
       char *crypt_ra(const char *phrase, const char *setting, void **data,
               int *size);

       Link with -lcrypt.

[...]
PORTABILITY NOTES
       crypt is included in POSIX, but crypt_r, crypt_rn, and crypt_ra are not
       part of any standard.
[...]
       Due to historical restrictions on the export of cryptographic  software
       from  the  USA,  crypt  is  an  optional POSIX component.  Applications
       should therefore be prepared for crypt  not  to  be  available,  or  to
       always fail (setting errno to ENOSYS) at runtime.

       POSIX  specifies  that  crypt  is declared in unistd.h, but only if the
       macro _XOPEN_CRYPT is defined and has a value greater than or equal  to
       zero.   Since  libcrypt  does  not provide unistd.h, it declares crypt,
       crypt_r, crypt_rn, and crypt_ra in crypt.h instead.

I think this would be a good tack to take in the Linux manpages'
crypt(3) as well, minus explicit mentions of lib(x)crypt.

Incidentally, libxcrypt doesn't prototype encrypt or setkey in public
headers, nor does it allow new programs to link against them. Please
consider dropping encrypt(3) or at least declaring it to be obsolete
at the top of the manpage. Nobody should be using single DES for
anything anymore.

I'm a little surprised to hear Fedora has taken the plunge on
switching to libxcrypt.  I did put in a whole lot of work last year on
making it an ABI-compatible replacement, but I still have a long list
of things that need changing before I consider it *done*, and I
believe so does Bjoern.  But I do look forward to the bug reports from
more extensive testing :-)

I'll send a patch shortly that adds a --disable-libcrypt configure
switch to glibc, hopefully that can work for Fedora and you don't have
to be carrying patches around.

zw