Problem reported by Stefan Liebler in:
https://sourceware.org/ml/libc-alpha/2019-08/msg00658.html
* posix/tst-regex.c: Convert this file from Latin-1 to UTF-8.
(do_test, test_expr): Adjust to the fact that this source file,
and the test data in ChangeLog.8, is now UTF-8 instead of Latin-1.
* posix/tst-regex.input: Copy from ChangeLog.old/ChangeLog.8,
so that it is now UTF-8.
The recent commit e6855a3bdf
changed the encoding of ChangeLog.old/ChangeLog.8 from ISO-8859 to UTF-8.
Unfortunately the test posix/tst-regex assumes the former encoding.
Furthermore Francesco Potortì is now written with 'ì' instead of 'i`'
which would lead to two further matches in the first call to test_expr.
This patch just copies the former ChangeLog.8 file to tst-regex.input
and adjusts the test in order to use this new input file.
ChangeLog:
* posix/tst-regex.c (do_test): Use tst-regex.input as input file.
* posix/tst-regex.input: New file.
This was found by Coverity (CID 1484201). [BZ#24844]
* posix/regex_internal.c (create_cd_newstate): Fix use of bad
pointer and/or memory leak when storage is exhausted.
The fix for BZ#21270 (commit 158d5fa0e1) added a mask to avoid offset larger
than 1^44 to be used along __NR_mmap2. However mips64n32 users __NR_mmap,
as mips64n64, but still defines off_t as old non-LFS type (other ILP32, such
x32, defines off_t being equal to off64_t). This leads to use the same
mask meant only for __NR_mmap2 call for __NR_mmap, thus limiting the maximum
offset it can use with mmap64.
This patch fixes by setting the high mask only for __NR_mmap2 usage. The
posix/tst-mmap-offset.c already tests it and also fails for mips64n32. The
patch also change the test to check for an arch-specific header that defines
the maximum supported offset.
Checked on x86_64-linux-gnu, i686-linux-gnu, and I also tests tst-mmap-offset
on qemu simulated mips64 with kernel 3.2.0 kernel for both mips-linux-gnu and
mips64-n32-linux-gnu.
[BZ #24699]
* posix/tst-mmap-offset.c: Mention BZ #24699.
(do_test_bz21270): Rename to do_test_large_offset and use
mmap64_maximum_offset to check for maximum expected offset value.
* sysdeps/generic/mmap_info.h: New file.
* sysdeps/unix/sysv/linux/mips/mmap_info.h: Likewise.
* sysdeps/unix/sysv/linux/mmap64.c (MMAP_OFF_HIGH_MASK): Define iff
__NR_mmap2 is used.
Keep these functions compatible with Gnulib while adding
__time64_t support. The basic idea is to move private API
declarations from include/time.h to time/mktime-internal.h, since
the former file cannot easily be shared with Gnulib whereas the
latter can.
Also, do some other minor cleanup while in the neighborhood.
* include/time.h: Include stdbool.h, time/mktime-internal.h.
(__mktime_internal): Move this prototype to time/mktime-internal.h,
since Gnulib needs it.
(__localtime64_r, __gmtime64_r) [__TIMESIZE == 64]:
Move these macros to time/mktime-internal.h, since Gnulib needs them.
(__mktime64, __timegm64) [__TIMESIZE != 64]: New prototypes.
(in_time_t_range): New static function.
* posix/bits/types.h (__time64_t) [__TIMESIZE == 64 && !defined __LIBC]:
Do not define as a macro in this case, so that portable code is
less tempted to use __time64_t.
* time/mktime-internal.h: Rewrite so that it does both glibc
and Gnulib work. Include time.h if not _LIBC.
(mktime_offset_t) [!_LIBC]: Define for gnulib.
(__time64_t, __gmtime64_r, __localtime64_r, __mktime64, __timegm64)
[!_LIBC || __TIMESIZE == 64]: New macros, mostly moved here
from include/time.h.
(__gmtime_r, __localtime_r, __mktime_internal) [!_LIBC]:
New macros, taken from GNulib.
(__mktime_internal): New prototype, moved here from include/time.h.
* time/mktime.c (mktime_min, mktime_max, convert_time)
(ranged_convert, __mktime_internal, __mktime64):
* time/timegm.c (__timegm64):
Use __time64_t, not time_t.
* time/mktime.c: Stop worrying about whether time_t is floating-point.
(__mktime64) [! (_LIBC && __TIMESIZE != 64)]:
Rename from mktime.
(mktime) [_LIBC && __TIMESIZE != 64]: New function.
* time/timegm.c [!_LIBC]: Include libc-config.h, not config.h,
for libc_hidden_def.
Include errno.h.
(__timegm64) [! (_LIBC && __TIMESIZE != 64)]:
Rename from timegm.
(timegm) [_LIBC && __TIMESIZE != 64]: New function.
First cut at publicizing __time64_t
The stub implementations are turned into compat symbols.
Linux actually has two reserved system call numbers (for getpmsg
and putpmsg), but these system calls have never been implemented,
and there are no plans to implement them, so this patch replaces
the wrappers with the generic stubs.
According to <https://bugzilla.redhat.com/show_bug.cgi?id=436349>,
the presence of the XSI STREAMS declarations is a minor portability
hazard because they are not actually implemented.
This commit does not change the TIRPC support code in
sunrpc/rpc_svcout.c. It uses additional XTI functionality and
therefore never worked with glibc.
Reviewed-by: Carlos O'Donell <carlos@redhat.com>
The test for obsolete typedefs in installed headers was implemented
using grep, and could therefore get false positives on e.g. “ulong”
in a comment. It was also scanning all of the headers included by
our headers, and therefore testing headers we don’t control, e.g.
Linux kernel headers.
This patch splits the obsolete-typedef test from
scripts/check-installed-headers.sh to a separate program,
scripts/check-obsolete-constructs.py. Being implemented in Python,
it is feasible to make it tokenize C accurately enough to avoid false
positives on the contents of comments and strings. It also only
examines $(headers) in each subdirectory--all the headers we install,
but not any external dependencies of those headers. Headers whose
installed name starts with finclude/ are ignored, on the assumption
that they contain Fortran.
It is also feasible to make the new test understand the difference
between _defining_ the obsolete typedefs and _using_ the obsolete
typedefs, which means posix/{bits,sys}/types.h no longer need to be
exempted. This uncovered an actual bug in bits/types.h: __quad_t and
__u_quad_t were being used to define __S64_TYPE, __U64_TYPE,
__SQUAD_TYPE and __UQUAD_TYPE. These are changed to __int64_t and
__uint64_t respectively. This is a safe change, despite the comments
in bits/types.h claiming a difference between __quad_t and __int64_t,
because those comments are incorrect. In all current ABIs, both
__quad_t and __int64_t are ‘long’ when ‘long’ is a 64-bit type, and
‘long long’ when ‘long’ is a 32-bit type, and similarly for __u_quad_t
and __uint64_t. (Changing the types to be what the comments say they
are would be an ABI break, as it affects C++ name mangling.) This
patch includes a minimal change to make the comments not completely
wrong.
sys/types.h was defining the legacy BSD u_intN_t typedefs using a
construct that was not necessarily consistent with how the C99 uintN_t
typedefs are defined, and is also too complicated for the new script to
understand (it lexes C relatively accurately, but it does not attempt
to expand preprocessor macros, nor does it do any actual parsing).
This patch cuts all of that out and uses bits/types.h's __uintN_t typedefs
to define u_intN_t instead. This is verified to not change the ABI on
any supported architecture, via the c++-types test, which means u_intN_t
and uintN_t were, in fact, consistent on all supported architectures.
Reviewed-by: Carlos O'Donell <carlos@redhat.com>
* scripts/check-obsolete-constructs.py: New test script.
* scripts/check-installed-headers.sh: Remove tests for
obsolete typedefs, superseded by check-obsolete-constructs.py.
* Rules: Run scripts/check-obsolete-constructs.py over $(headers)
as a special test. Update commentary.
* posix/bits/types.h (__SQUAD_TYPE, __S64_TYPE): Define as __int64_t.
(__UQUAD_TYPE, __U64_TYPE): Define as __uint64_t.
Update commentary.
* posix/sys/types.h (__u_intN_t): Remove.
(u_int8_t): Typedef using __uint8_t.
(u_int16_t): Typedef using __uint16_t.
(u_int32_t): Typedef using __uint32_t.
(u_int64_t): Typedef using __uint64_t.
This patch adds fall-through comments in some cases where -Wextra
produces implicit-fallthrough warnings.
The patch is non-exhaustive. Apart from architecture-specific code
for non-x86_64 architectures, it does not change sunrpc/xdr.c (legacy
code, probably should have such changes, but left to be dealt with
separately), or places that already had comments about the
fall-through but not matching the form expected by
-Wimplicit-fallthrough=3 (the default level with -Wextra; my
inclination is to adjust those comments to match rather than
downgrading to -Wimplicit-fallthrough=1 to allow any comment), or one
place where I thought the implicit fallthrough was not correct and so
should be handled separately as a bug fix. I think the key thing to
consider in review of this patch is whether the fall-through is indeed
intended and correct in each place where such a comment is added.
Tested for x86_64.
* elf/dl-exception.c (_dl_exception_create_format): Add
fall-through comments.
* elf/ldconfig.c (parse_conf_include): Likewise.
* elf/rtld.c (print_statistics): Likewise.
* locale/programs/charmap.c (parse_charmap): Likewise.
* misc/mntent_r.c (__getmntent_r): Likewise.
* posix/wordexp.c (parse_arith): Likewise.
(parse_backtick): Likewise.
* resolv/ns_ttl.c (ns_parse_ttl): Likewise.
* sysdeps/x86/cpu-features.c (init_cpu_features): Likewise.
* sysdeps/x86_64/dl-machine.h (elf_machine_rela): Likewise.
Non-sysdeps headers cannot be overriden by sysdeps headers across the
entire build, so it is necessary to turn such extension headers into
sysdeps headers themselves. The approach here follows the existing
<bits/shm.h> header (although it uses sysdeps/gnu instead of
sysdeps/generic).
Fixes commit 1d0fc21382 ("Linux: Add
gettid system call wrapper [BZ #6399]") and commit
8f89ab216f ("posix: Fix missing wrapper
header for <bits/unistd_ext.h>").
This commit adds gettid to <unistd.h> on Linux, and not to the
kernel-independent GNU API.
gettid is now supportable on Linux because too many things assume a
1:1 mapping between libpthread threads and kernel threads.
Reviewed-by: Carlos O'Donell <carlos@redhat.com>
This fixes the same bug in fnmatch that was fixed by commit 7e2f0d2d77 for
regexp matching. As a side effect it also removes the use of an unbound
VLA.
From time to time I get fails in tst-spawn like:
tst-spawn.c:111: numeric comparison failure
left: 0 (0x0); from: xlseek (fd2, 0, SEEK_CUR)
right: 28 (0x1c); from: strlen (fd2string)
error: 1 test failures
tst-spawn.c:252: numeric comparison failure
left: 1 (0x1); from: WEXITSTATUS (status)
right: 0 (0x0); from: 0
error: 1 test failures
It turned out, that a child process is testing it's open file descriptors
with e.g. a sequence of testing the current position, setting the position
to zero and reading a specific amount of bytes.
Unfortunately starting with commit 2a69f853c0
the test is spawning a second child process which is sharing some of the
file descriptors. If the test sequence as mentioned above is running in parallel
it leads to test failures.
As the second call of posix_spawn shall test a NULL pid argument,
this patch is just moving the waitpid of the first child
before the posix_spawn of the second child.
ChangeLog:
* posix/tst-spawn do_test(): Move waitpid before posix_spawn.
Problem found by AddressSanitizer, reported by Hongxu Chen in:
https://debbugs.gnu.org/34140
* posix/regexec.c (proceed_next_node):
Do not read past end of input buffer.
Austin Group issue #411 [1] proposes that posix_spawn file action
posix_spawn_file_actions_adddup2 resets the close-on-exec when
source and destination refer to same file descriptor.
It solves the issue on multi-thread applications which uses
close-on-exec as default, and want to hand-chose specifically
file descriptor to purposefully inherited into a child process.
Current approach to achieve this scenario is to use two adddup2 file
actions and a temporary file description which do not conflict with
any other, coupled with a close file action to avoid leaking the
temporary file descriptor. This approach, besides being complex,
may fail with EMFILE/ENFILE file descriptor exaustion.
This can be more easily accomplished with an in-place removal of
FD_CLOEXEC. Although the resulting adddup2 semantic is slight
different than dup2 (equal file descriptors should be handled as
no-op), the proposed possible solution are either more complex
(fcntl action which a limited set of operations) or results in
unrequired operations (dup3 which also returns EINVAL for same
file descriptor).
Checked on aarch64-linux-gnu.
[BZ #23640]
* posix/tst-spawn.c (do_prepare, handle_restart, do_test): Add
posix_spawn_file_actions_adddup2 test to check O_CLOCEXEC reset.
* sysdeps/unix/sysv/linux/spawni.c (__spawni_child): Add
close-on-exec reset for adddup2 file action.
* sysdeps/posix/spawni.c (__spawni_child): Likewise.
[1] http://austingroupbugs.net/view.php?id=411
From the glibc point of view, this removes duplicate macro
definitions and is obviously safe.
From the Gnulib point of view, this pacifies xlc 12.01 on AIX 7.1.
* posix/regex_internal.h:
(__attribute__, __attribute_warn_unused_result__):
Remove; already defined elsewhere.
This simplifies the code, by removing stuff intended for porting
to Gnulib but no longer needed there.
* posix/regcomp.c [!_LIBC]: No need to put #ifdef _LIBC around
uses of libc_hidden_def, weak_alias.
* posix/regcomp.c, posix/regexec.c: Use __restrict rather than
_Restrict_ except for public-facing headers.
* posix/regex_internal.h (attribute_hidden) [!_LIBC]:
Remove; already defined elsewhere.
* posix/regex.c, posix/regex_internal.h:
Use __GNUC_PREREQ instead of rolling our own.
* posix/regex_internal.h (__GNUC_PREREQ): Remove duplicate defn.
[BZ #18040]
Problem reported by Saito Takaaki <tails.saito@gmail.com> in
https://debbugs.gnu.org/32592
Call stack get_subexp->get_subexp_sub->clean_state_log_if_needed may
call extend_buffers which reallocates the re_string_t internal buffer.
Local variable 'buf' was not updated in such case, resulting in
use-after-free.
* posix/regexec.c (get_subexp): Update 'buf' after call to
get_subexp_sub.
Along with posix_spawn_file_actions_addchdir,
posix_spawn_file_actions_addfchdir is the subject of a change proposal
for POSIX: <http://austingroupbugs.net/view.php?id=1208>
These files were both auto-generated and shipped in the source tree.
We can assume that sed is available and always generate the files
during the build.
Building posix/bug-regex22.c fails with GCC mainline because of
-Wformat-overflow= warnings for NULL arguments to %s formats.
This is *not* testing how glibc handles such format arguments; in the
context of the messages in question it makes no sense to pass NULL to
such a %s format (the code passes s, inside "if (s == NULL)"). So
this patch changes the code not to pass such a format argument at all
(which means the string passed is constant, so no need to use printf
at all - however, there are two separate tests here with different
length arguments passed to re_compile_pattern, so it *does* make sense
to make the strings used different so that in the event of failure
it's clear which one of the tests failed).
Tested with build-many-glibcs.py with GCC mainline for
aarch64-linux-gnu.
* posix/bug-regex22.c (main): Use puts with distinct error
messages for unexpected success of re_compile_pattern, not printf
with NULL argument to %s.
glibc support for 64-bit time_t on 32-bit architectures
will involve:
- Using 64-bit times inside glibc, with conversions
to and from 32-bit times taking place as necessary
for interfaces using such times.
- Adding 64-bit-time support in the glibc public API.
This support should be dynamic, i.e. glibc should
provide both 32-bit and 64-bit implementations and
let user code choose at compile time whether to use
the 32-bit or 64-bit interfaces.
This requires a glibc-internal name for a type for times
that are always 64-bit.
Based on __TIMESIZE, a new macro is defined, __TIME64_T_TYPE,
which is always the right __*_T_TYPE to hold a 64-bit-time.
__TIME64_T_TYPE equals __TIME_T_TYPE if __TIMESIZE equals 64
and equals __SQUAD_T_TYPE otherwise.
__time64_t can then replace uses of internal_time_t.
This patch was tested by running 'make check' on branch
master then applying this patch and its predecessor and
running 'make check' again, and checking that both 'make
check' yield identical results. This was done on
x86_64-linux-gnu and i686-linux-gnu.
* bits/time64.h: New file.
* include/time.h: Replace internal_time_t with __time64_t.
* posix/bits/types (__time64_t): Add.
* stdlib/Makefile: Add bits/time64.h to includes.
* time/tzfile.c: Replace internal_time_t with __time64_t.
[BZ#23744]
This refactoring was prompted by a problem when the regex code is
used as part of Gnulib and when the builder’s compiler does not grok
__builtin_expect. Problem reported for Gawk by Nelson H.F. Beebe in:
https://lists.gnu.org/r/bug-gnulib/2018-09/msg00137.html
Although this refactoring does not fix the problem directly,
we might as well have Gawk use the now-preferred glibc style for when
__builtin_expect is unavailable.
* posix/regex_internal.h (BE): Remove.
All uses replaced by __glibc_unlikely or __glibc_likely.
Adjust the non-glibc code to agree with what Gawk needs for
rational range interpretation (RRI) for regular expression ranges.
In unibyte locales, Gawk wants ranges to use the underlying byte
rather than the character code point. This change does not affect
glibc proper.
* posix/regcomp.c (parse_byte) [!LIBC && RE_ENABLE_I18N]:
In unibyte locales, use the byte value rather than
running it through btowc.
Problem and fix reported by Assaf Gordon in:
https://lists.gnu.org/r/bug-gnulib/2018-07/txtqLKNwBdefE.txt
* posix/regcomp.c (free_charset) [!_LIBC]: Free range_starts and
range_ends members too, as they are defined in 'struct
re_charset_t' even if not _LIBC. This affects only Gnulib.
In commit 9479b6d5e0 we updated all of
the collation data to harmonize with the new version of ISO 14651
which is derived from Unicode 9.0.0. This collation update brought
with it some changes to locales which were not desirable by some
users, in particular it altered the meaning of the
locale-dependent-range regular expression, namely [a-z] and [A-Z], and
for en_US it caused uppercase letters to be matched by [a-z] for the
first time. The matching of uppercase letters by [a-z] is something
which is already known to users of other locales which have this
property, but this change could cause significant problems to en_US
and other similar locales that had never had this change before.
Whether this behaviour is desirable or not is contentious and GNU Awk
has this to say on the topic:
https://www.gnu.org/software/gawk/manual/html_node/Ranges-and-Locales.html
While the POSIX standard also has this further to say: "RE Bracket
Expression":
http://pubs.opengroup.org/onlinepubs/9699919799/xrat/V4_xbd_chap09.html
"The current standard leaves unspecified the behavior of a range
expression outside the POSIX locale. ... As noted above, efforts were
made to resolve the differences, but no solution has been found that
would be specific enough to allow for portable software while not
invalidating existing implementations."
In glibc we implement the requirement of ISO POSIX-2:1993 and use
collation element order (CEO) to construct the range expression, the
API internally is __collseq_table_lookup(). The fact that we use CEO
and also have 4-level weights on each collation rule means that we can
in practice reorder the collation rules in iso14651_t1_common (the new
data) to provide consistent range expression resolution *and* the
weights should maintain the expected total order. Therefore this
patch does three things:
* Reorder the collation rules for the LATIN script in
iso14651_t1_common to deinterlace uppercase and lowercase letters in
the collation element orders.
* Adds new test data en_US.UTF-8.in for sort-test.sh which exercises
strcoll* and strxfrm* and ensures the ISO 14651 collation remains.
* Add back tests to tst-fnmatch.input and tst-regexloc.c which
exercise that [a-z] does not match A or Z.
The reordering of the ISO 14651 data is done in an entirely mechanical
fashion using the following program attached to the bug:
https://sourceware.org/bugzilla/show_bug.cgi?id=23393#c28
It is up for discussion if the iso14651_t1_common data should be
refined further to have 3 very tight collation element ranges that
include only a-z, A-Z, and 0-9, which would implement the solution
sought after in:
https://sourceware.org/bugzilla/show_bug.cgi?id=23393#c12
and implemented here:
https://www.sourceware.org/ml/libc-alpha/2018-07/msg00854.html
No regressions on x86_64.
Verified that removal of the iso14651_t1_common change causes tst-fnmatch
to regress with:
422: fnmatch ("[a-z]", "A", 0) = 0 (FAIL, expected FNM_NOMATCH) ***
...
425: fnmatch ("[A-Z]", "z", 0) = 0 (FAIL, expected FNM_NOMATCH) ***
This bug is very similar to bug 23036: The existing code assumed that
the length count included the length byte itself.
Reviewed-by: Carlos O'Donell <carlos@redhat.com>
Various glibc testcases use tmpnam in ways subject to race conditions
(generate a temporary file name, then later open that file without
O_EXCL).
This patch fixes those tests to use mkstemp - generally a minimal
local fix to use mkstemp instead of tmpnam, rather than a larger fix
to use other testsuite infrastructure for temporary files. The
unchanged use of tmpnam in posix/wordexp-test.c would fail safe in the
event of a race (it's generating a name for use with mkdir rather than
for a file to be opened for writing).
Tested for x86_64.
* grp/tst_fgetgrent.c: Include <unistd.h>.
(main): Use mkstemp instead of tmpnam.
* io/test-utime.c (main): Likewise.
* posix/annexc.c (macrofile): Change to modifiable array.
(get_null_defines): Use mkstemp instead of tmpnam. Do not remove
macrofile here.
* posix/bug-getopt1.c: Include <stdlib.h>.
(do_test): Use mkstemp instead of tmpnam.
* posix/bug-getopt2.c: Include <stdlib.h>.
(do_test): Use mkstemp instead of tmpnam.
* posix/bug-getopt3.c: Include <stdlib.h>.
(do_test): Use mkstemp instead of tmpnam.
* posix/bug-getopt4.c: Include <stdlib.h>.
(do_test): Use mkstemp instead of tmpnam.
* posix/bug-getopt5.c: Include <stdlib.h>.
(do_test): Use mkstemp instead of tmpnam.
* stdio-common/bug7.c: Include <stdlib.h> and <unistd.h>.
(main): Use mkstemp instead of tmpnam.
* stdio-common/tst-fdopen.c: Include <stdlib.h>.
(main): Use mkstemp instead of tmpnam.
* stdio-common/tst-ungetc.c: Include <stdlib.h>.
(main): use mkstemp instead of tmpnam.
* stdlib/isomac.c (macrofile): Change to modifiable array.
(get_null_defines): Use mkstemp instead of tmpnam. Do not remove
macrofile here.
Each weight is prefixed by its length, and the length does not include
itself in the count. This can be seen clearly from the find_idx
function in string/strxfrm_l.c, for example. The old code behaved as if
the length itself counted, thus comparing an additional byte after the
weight, leading to spurious comparison failures and incorrect further
partitioning of character equivalence classes.
On some platforms the inclusion of regex-internal.h in bug-regex33
testcase show a MAX redefinition if test-skeleton.c is include later.
This patch fixes by removing regex-internal.h inclusion and using
SBC_MAX value directly.
Checked on aarch64-linux-gnu.
* posix/bug-regex33.c: Fix build after regex sync.
This patch syncs the regex implementation with gnulib (commit 0ee5212).
Only two changes in GLIBC regex testing are required:
1. posix/bug-regex28.c: as previously discussed [1] the change of
expected results on the pattern should be safe.
2. posix/PCRE.tests: the ERE (a)|\1 is malformed (in the sense that
the \1 doesn't mean anything) and although current GLIBC accepts
it has undefined behavior. This patch removes the specific test.
This sync contains some patches from thread 'Regex: Make libc regex
more usable outside GLIBC.' [2] which have been pushed upstream in
gnulib. This patches also fixes some regex issues (BZ #23233,
BZ #21163, BZ #18986, BZ #13762) and I did not add testcases for
both #23233 and #13762 because I couldn't think a simple way to
trigger the expected failure path to trigger them.
Checked on x86_64-linux-gnu and i686-linux-gnu.
[BZ #23233]
[BZ #21163]
[BZ #18986]
[BZ #13762]
* posix/Makefile (tests): Add bug-regex37 and bug-regex38.
* posix/PCRE.tests: Remove invalid test.
* posix/bug-regex28.c: Fix expected values for used syntax.
* posix/bug-regex37.c: New file.
* posix/bug-regex38.c: Likewise.
* posix/regcomp.c: Sync with gnulib.
* posix/regex.c: Likewise.
* posix/regex.h: Likewise.
* posix/regex_internal.c: Likewise.
* posix/regex_internal.h: Likewise.
* posix/regexec.c: Likewise.
[1] https://sourceware.org/ml/libc-alpha/2017-12/msg00807.html
[2] https://sourceware.org/ml/libc-alpha/2017-12/msg00237.html
This is a major rewrite of the description of 'crypt', 'getentropy',
and 'getrandom'.
A few highlights of the content changes:
- Throughout the manual, public headers, and user-visible messages,
I replaced the term "password" with "passphrase", the term
"password database" with "user database", and the term
"encrypt(ion)" with "(one-way) hashing" whenever it was applied to
passphrases. I didn't bother making this change in internal code
or tests. The use of the term "password" in ruserpass.c survives,
because that refers to a keyword in netrc files, but it is adjusted
to make this clearer.
There is a note in crypt.texi explaining that they were
traditionally called passwords but single words are not good enough
anymore, and a note in users.texi explaining that actual passphrase
hashes are found in a "shadow" database nowadays.
- There is a new short introduction to the "Cryptographic Functions"
section, explaining how we do not intend to be a general-purpose
cryptography library, and cautioning that there _are_, or have
been, legal restrictions on the use of cryptography in many
countries, without getting into any kind of detail that we can't
promise to keep up to date.
- I added more detail about what a "one-way function" is, and why
they are used to obscure passphrases for storage. I removed the
paragraph saying that systems not connected to a network need no
user authentication, because that's a pretty rare situation
nowadays. (It still says "sometimes it is necessary" to
authenticate the user, though.)
- I added documentation for all of the hash functions that glibc
actually supports, but not for the additional hash functions
supported by libxcrypt. If we're going to keep this manual section
around after the transition is more advanced, it would probably
make sense to add them then.
- There is much more detailed discussion of how to generate a salt,
and the failure behavior for crypt is documented. (Returning an
invalid hash on failure is what libxcrypt does; Solar Designer's
notes say that this was done "for compatibility with old programs
that assume crypt can never fail".)
- As far as I can tell, the header 'crypt.h' is entirely a GNU
invention, and never existed on any other Unix lineage. The
function 'crypt', however, was in Issue 1 of the SVID and is now
in the XSI component of POSIX. I tried to make all of the
@standards annotations consistent with this, but I'm not sure I got
them perfectly right.
- The genpass.c example has been improved to use getentropy instead
of the current time to generate the salt, and to use a SHA-256 hash
instead of MD5. It uses more random bytes than is strictly
necessary because I didn't want to complicate the code with proper
base64 encoding.
- The testpass.c example has three hardwired hashes now, to
demonstrate that different one-way functions produce different
hashes for the same input. It also demonstrates how DES hashing
only pays attention to the first eight characters of the input.
- There is new text explaining in more detail how a CSPRNG differs
from a regular random number generator, and how
getentropy/getrandom are not exactly a CSPRNG. I tried not to make
specific falsifiable claims here. I also tried to make the
blocking/cancellation/error behavior of both getentropy and
getrandom clearer.
