Package: oath-toolkit / 2.6.1-1.4


Package Version Patches format
oath-toolkit 2.6.1-1.4 3.0 (quilt)

Patch series

view the series file
Patch File delta Description
gtkdocize.patch | (download)

liboath/gtk-doc.make | 227 134 + 93 - 0 !
liboath/m4/gtk-doc.m4 | 73 62 + 11 - 0 !
libpskc/gtk-doc.make | 227 134 + 93 - 0 !
libpskc/m4/gtk-doc.m4 | 73 62 + 11 - 0 !
4 files changed, 392 insertions(+), 208 deletions(-)

 "gtkdocize --copy" with gtk-doc-tools 1.28-1
 Fixes FTBFS with gtk-doc-tools >= 1.26.
new glibc check.patch | (download)

liboath/gl/fseeko.c | 4 2 + 2 - 0 !
1 file changed, 2 insertions(+), 2 deletions(-)

 check _io_eof_seen instead of _io_ftrylockfile
 Needed to get fseeko.c to build with glibc 2.28.
 Inspired by
0001 fail gracefully for missing users.patch | (download)

pam_oath/README | 2 1 + 1 - 0 !
pam_oath/pam_oath.c | 17 17 + 0 - 0 !
2 files changed, 18 insertions(+), 1 deletion(-)

 [patch] fail gracefully for missing users

when the pam module is enabled, it forces *all* users to immediately
start using OATH, or they can't login at all.

a more progressive approach would seem more reasonable to me,
especially since each user need to get an admin user to update the
central file for them.

this patch adds an early check to the users file and makes sure the
user exists before prompting for a password.

if the user is missing, it exits early with a standard error code
(PAM_USER_UNKNOWN) which can then be ignored in the PAM configuration
(as shown in the README file). this leaves the policy decision up to
the admin (and defaults to "fail closed").

if the user is present, the code path remains the same except the
usersfile is scanned twice, which may be a performance penalty on very
slow filesystems or very large files. the only workaround I can think
of for this would be to load the whole file into memory, but this
could have significant memory impact on large files.

the function used (`oath_authenticate_usersfile`) is a little overkill
as it actually goes and tries to authenticate the user with an empty
password. this is harmless because the file isn't updated if the OTP
is incorrect and because no warning is sent to syslog.

a possible improvement on this would be to have a warning shown to the
user inciting them to configure OATH or to warn them about a possible
typo in their username before they enter their regular passphrase