I see a modular crypt API as providing: - a function to compare a cleartext password to a given hash string without the caller having to know what the type of the hash is - a function to generate a hash from a given cleartext password using a configurable default crypt type - a function to generate a hash from a given cleartext password and a given crypt type name - a function to enumerate crypt types available - a free() function (if the API allocates its own result storage) Of course, such an API would have to be multi-thread safe. Nico On Fri, Apr 20, 2001 at 08:56:00AM +0400, solar@openwall.com wrote: > On Mon, Apr 16, 2001 at 06:05:38PM -0500, Steve Langasek wrote: > > Since portability to other OSes is a concern for Linux-PAM, even integrated > > bcrypt support in glibc doesn't eliminate the need for bcrypt support in PAM. > > This is assuming that we want to provide support for all password > hashes Linux-PAM modules could handle on all platforms supported by > Linux-PAM. I'm not sure this needs to be one of Linux-PAM goals. > > > One of my long-term aspirations for pam_unix is to reorder the module such > > that it can detect what crypt algorithms are supported by the OS crypt() > > function, and compile in its own implementation for *only* those it needs to > > provide. > > This would be an improvement, but I think a more consistent approach > is to provide a library with crypt_rn() and crypt_gensalt_rn(), but > only link the modules against it on platforms which lack one or both > of these functions. This is assuming we/I will be able to get these > functions into glibc's libcrypt. If not, then we could do the same > for just crypt(). > > -- > /sd > > > > _______________________________________________ > > Pam-list@redhat.com > https://listman.redhat.com/mailman/listinfo/pam-list --
