manual: Revise crypt.texi.

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.

1 files changed, 16 insertions, 5 deletions

diff --git a/manual/users.texi b/manual/users.texi
index 8690b65..4ed79ba 100644
--- a/manual/users.texi
+++ b/manual/users.texi
@@ -1730,6 +1730,16 @@ users.  The database itself is kept in the file @file{/etc/passwd} on
 most systems, but on some systems a special network server gives access
 to it.
 
+Historically, this database included one-way hashes of user
+passphrases (@pxref{Passphrase Storage}) as well as public information
+about each user (such as their user ID and full name).  Many of the
+functions and data structures associated with this database, and the
+filename @file{/etc/passwd} itself, reflect this history.  However,
+the information in this database is available to all users, and it is
+no longer considered safe to make passphrase hashes available to all
+users, so they have been moved to a ``shadow'' database that can only
+be accessed with special privileges.
+
 @menu
 * User Data Structure::         What each user record contains.
 * Lookup User::                 How to look for a particular user.
@@ -1753,8 +1763,10 @@ entries in the system user data base.  It has at least the following members:
 @item char *pw_name
 The user's login name.
 
-@item char *pw_passwd.
-The encrypted password string.
+@item char *pw_passwd
+Historically, this field would hold the one-way hash of the user's
+passphrase.  Nowadays, it will almost always be the single character
+@samp{x}, indicating that the hash is in the shadow database.
 
 @item uid_t pw_uid
 The user ID number.
@@ -2105,7 +2117,7 @@ rewritten on subsequent calls to @code{fgetpwent}.  You must copy the
 contents of the structure if you wish to save the information.
 
 The stream must correspond to a file in the same format as the standard
-password database file.
+user database file.
 @end deftypefun
 
 @deftypefun int fgetpwent_r (FILE *@var{stream}, struct passwd *@var{result_buf}, char *@var{buffer}, size_t @var{buflen}, struct passwd **@var{result})
@@ -2126,7 +2138,7 @@ first @var{buflen} bytes of the additional buffer pointed to by
 strings which are pointed to by the elements of the result structure.
 
 The stream must correspond to a file in the same format as the standard
-password database file.
+user database file.
 
 If the function returns zero @var{result} points to the structure with
 the wanted data (normally this is in @var{result_buf}).  If errors
@@ -2234,7 +2246,6 @@ avoid using it, because it makes sense only on the assumption that the
 on a system which merges the traditional Unix data base with other
 extended information about users, adding an entry using this function
 would inevitably leave out much of the important information.
-@c Then how are programmers to modify the password file? -zw
 
 The group and user ID fields are left empty if the group or user name
 starts with a - or +.