On Sat, Apr 14, 2018 at 3:56 PM, Florian Weimer <fweimer@xxxxxxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
