Propagate all error kinds from pam::converse not just timeouts

[bjorn3]

This way they rather than silently discarding the error message and doing another authentication attempt, they properly report the error message and cause sudo to exit. This way for example pam_faillock won't cause a persistent error like incorrect SUDO_ASKPASS value (once implemented) to be treated as multiple successive failed password attempts.

[squell]

The one thing I'm looking at is the capitalization of error messages. In the main error module I think we go for "lower case" (as ogsudo), but the PAM module capitalizes error messages. We should probably make this consistent, but I feel that is better handled as part of the main l10n work. (Which I do think this PR probably also helps with). I.e. that can be left as-is in this PR.

But, Is it possible to write a compliance test for this? E.g. read the password from stdin, make sure there is nothing on stdin, and then verifying that both ogsudo and sudo-rs only give one error message?

[bjorn3]

E.g. read the password from stdin, make sure there is nothing on stdin, and then verifying that both ogsudo and sudo-rs only give one error message?

og-sudo gives multiple error messages: without tty sudo ls gives:

sudo: a terminal is required to read the password; either use the -S option to read from standard input or configure an askpass helper
sudo: a password is required

while echo -n | sudo -S ls gives:

sudo: no password was provided
sudo: a password is required

[squell]

E.g. read the password from stdin, make sure there is nothing on stdin, and then verifying that both ogsudo and sudo-rs only give one error message?

og-sudo gives multiple error messages: without tty sudo ls gives:

sudo: a terminal is required to read the password; either use the -S option to read from standard input or configure an askpass helper
sudo: a password is required

while echo -n | sudo -S ls gives:

sudo: no password was provided
sudo: a password is required

What I'm particularly interested in, this PR changes behaviour, and it would be nice to have a e2e-test (or preferably: a compliance test) for that; I'm guessing that right now we give something like "Maximum 3 incorrect authentication attempts" in the echo -n | sudo -S ls case.

This can then act as a regression test going forward.

[squell]

Needless to say the rest of the changes LGTM.

[bjorn3]

Turns out the EOF handling was incorrect. It only worked for literal ctrl-d, not for a broken pipe. Pushed a commit to fix this and update all tests.