At the moment, if services fails to encrypt a password, it will fall back to
storing it in plain text in the database. This is clearly undesirable. This
can happen for a couple of reasons off of the top of my head:

- No encryption-capable crypto providers are loaded.

  This is extremely negligent, but is still possible. Services complains
  loudly every time it attempts to encrypt a password in this configuration,
  but that will not stop some negligent sysadmins from ignoring these
  messages and continuing to run it in this configuration.

- pbkdf2v2 is the only encryption-capable crypto provider loaded, it is
  configured in SCRAM mode with GNU libidn for SASLprep normalisation, and
  the user supplies a password containing invalid UTF-8 byte sequences or
  ASCII control characters.

- Either argon2 or scrypt are the only encryption-capable crypto provider
  loaded, and they are configured to use far more memory than the system has
  available; high enough to cause libc to fall back to a direct mmap(2), and
  high enough for the kernel's overcommit logic to reject it as extreme,
  returning NULL.

This is because set_password() has no way to indicate to its caller whether
it was able to encrypt the password or not.

This commit forces set_password() to encrypt the password or return failure
to its caller. The callers now check whether it was successful and abort
their operation if it was not.

Also add a note to the SASL SCRAM documentation mentioning the prohibited
password characters, and the same to the help files for commands that take
passwords (but only if the SASL SCRAM module is loaded).

This is a worthwhile modification to the verification logic which
should help ensure that plaintext passwords stay around in the
database for as little amount of time as possible.

It does have the slight disadvantage that this would then immediately
call back into the crypto module it just used to encrypt it in order to
verify it, which would have twice the computational overhead. However,
this would be a one-time cost for a single login attempt; after that, it
would be encrypted already, and then it's the same computational cost as
any other login attempt.

Reported-By: [email protected]