Squashed commit of the following:
commit 9e7746bc53957f2a1e68784c0c26d082049180a7
Author: dr8 <github@dominicrutherford.co.uk>
Date: Mon Oct 31 14:27:47 2011 +0000
Bug fix: pam_yubico doesn't check server signature
commit 2f3d5e721cbfc905582da6208495c1da6dd2f79c
Author: dr8 <github@dominicrutherford.co.uk>
Date: Sat Oct 29 16:59:08 2011 +0100
Bug fix: pam_yubico does not validate server signature
commit 58a1e6820a88f6aa365ef006e9cca4c62af7c7cf
Author: dr8 <github@dominicrutherford.co.uk>
Date: Fri Oct 28 22:09:49 2011 +0100
only validate server signature when key is specified
commit d705f429bc972f85a50f0b2f96703cbdc28b744f
Author: dr8 <github@dominicrutherford.co.uk>
Date: Tue Oct 25 22:45:22 2011 +0100
fix failure to validate server signature
was given, unless use_first_pass was being used.
This is fatal if pam_yubico is considered 'sufficient' in the PAM
configuration.
Signed-off-by: Nanakos Chrysostomos <nanakos@wired-net.gr>
If we successfully authenticate, but something then goes wrong, such
as failure to generate a new challenge, failure to update the
challenge and so on, tell the user.
Tollef has argued that the login should not fail if, for example, the
disk is full. I'd rather fail on the cautious side and make sure we
don't end up always sending the same challenge to the YubiKey, but I'll
leave it up to Tollef to decide for now.
This reverts commit 14e917ffae52e05121a69a192d03f98090e8ae41.
Conflicts:
pam_yubico.c
If we use ftruncate we might end up in the situation that we do not
have a challenge on disk, leading to the user being unable to log in.
By using a temporary file, fsync and rename we avoid this problem.
Tollef has argued that the login should not fail if, for example, the
disk is full. I'd rather fail on the cautious side and make sure we
don't end up always sending the same challenge to the YubiKey, but I'll
leave it up to Tollef to decide for now.
This reverts commit 14e917ffae52e05121a69a192d03f98090e8ae41.
Conflicts:
pam_yubico.c
Changed generate_challenge() to generating bytes instead of a hex
encoded string, to not have to decode what we just encoded - instead
just generate plain bytes of randomness and then encode them once.
If we use ftruncate we might end up in the situation that we do not
have a challenge on disk, leading to the user being unable to log in.
By using a temporary file, fsync and rename we avoid this problem.
