even more badly broken when the dynamic loader was rewritten in March.
Reimplement it the way it was always meant to work (but never did):
If --with-modules-dir was specified, modules will be installed in that
directory and the dynamic loader will look for them there. If it was
not specified, modules will be installed in libdir and the dynamic
loader will use the standard search path (/usr/lib:/usr/local/lib). In
both cases, a policy file can still name a module by its full path.
git-svn-id: svn+ssh://svn.openpam.org/svn/openpam/trunk@690 185d5e19-27fe-0310-9dcf-9bff6b9f3609
or if the key was unreadable or invalid.
- Fix inverted success / failure logic.
The module is now in a (barely) usable state.
git-svn-id: svn+ssh://svn.openpam.org/svn/openpam/trunk@676 185d5e19-27fe-0310-9dcf-9bff6b9f3609
- move libpam into lib/libpam
- move the OATH code into lib/liboath
- move oath.h into include/security
- update all pointers
git-svn-id: svn+ssh://svn.openpam.org/svn/openpam/trunk@646 185d5e19-27fe-0310-9dcf-9bff6b9f3609
- Add a provisional API for matching a user response.
- Add a provisional API for generating a dummy key. When one of the
matching functions recognizes a dummy key, it will go through the
motions but never report a match.
git-svn-id: svn+ssh://svn.openpam.org/svn/openpam/trunk@643 185d5e19-27fe-0310-9dcf-9bff6b9f3609
mask for base64 (which was copy-pasted from the base32 code)
git-svn-id: svn+ssh://svn.openpam.org/svn/openpam/trunk@641 185d5e19-27fe-0310-9dcf-9bff6b9f3609
