Stuff for modular crypt api... > - 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 Done. > - a function to generate a hash from a given cleartext password using a > configurable default crypt type Done. > - a function to generate a hash from a given cleartext password and a > given crypt type name I didn't think about this. This is easy though. > - a function to enumerate crypt types available This either.. hehe. Slightly harder. Probably easiest to just return a two dimensional array of char *. I can't think of a simpler method. Can you? > - a free() function (if the API allocates its own result storage) pfft. what's a few bytes? :). Yeah this part is a little bit more tricky to do "correctly." It would [might] be better to leave it to the user though to make things simple for both the programmer using the api and me. > Of course, such an API would have to be multi-thread safe. Of course. Everything has to be mutli-thread safe. Not sure if this can be said for current pam_crypt code. I haven't done a thread safety audit because it's still alpha. So in conclusiong, the pam_crypt code does [will do] these things. I have done some serious thinking about where I'd like to take this, and I've decided to fork the current path of pam_crypt. I will have a seperate library that implements the stuff you just talked about. I will then implement the idea I was talking about just recently with a modular way of storing/retrieving password hashes. I actually decided on the fork before I read your email. I didn't even think about the third/forth ideas you presented. They could be very useful. Pam_unix and friends can then do the work of dealing with nis/nss/whatever. I'll continue development on the stand-alone module for the time being (with seperation of the stand-alone module from the crypt() api). I will probably have this done by tonight (if I don't get too depressed about having nothing to do on a friday night :). We'll see what happens. There are some small issues not related to the code that need to be worked out though: Naming suggestions? Since a modular crypt api isn't really going to be pam specific I can't exactly call it pam_crypt. libmca sounds stupid. Distribution suggestions? How do we make this available to pam modules? I guess it "might" be ok to distribute it seperately and then have the modules check for it (there will have to be a header file, for example), but if every pam module supports this api (in like a year or so) then maybe it needs to be a part of pam. I really don't know how to handle this. Even if this turns out to be a wonderful api/library, nobody will bother to use it if it's a pain to get it working with pam. I believe this is why not very many people use solar designer's glibc patch. This is also probably one of the subconcious reasons I went with a stand-alone module. I'd really like to thank Solar Designer and Nicolas Williams. Pam_crypt would be heading in a very differant direction if it wasn't for you guys. Steve Langasek too, you've provided some good ideas I might use with the stand alone library. - Adam Slattery http://www.sunriselinux.com/pam_crypt
