On Thu, Nov 20, 2014 at 19:29, Jonas 'Sortie' Termansen wrote: > Hi, > > The flak blog just had an interesting post about why the old crypt() > interface > should be replaced, and on the new crypt_newhash() and crypt_checkpass() that > were added to OpenBSD. I would like to see this API become portable and > perhaps > standardized, but crypt_newhash is currently tied to login_cap_t, which is > not a > portable abstraction. The current synopsis is: > > #include <login_cap.h> > int crypt_newhash(const char *pass, login_cap_t *lc, char *hash, size_t > hashlen); > > The purpose of the lc parameter is to determine which algorithm to use: The > implementation merely does a login_getcapstr(lc, "localcipher", NULL, > NULL) call > to convert that into a string telling what algorithm to use. If lc is > NULL, then > it defaults to a reasonable algorithm. > > It would be superior to move the login_getcapstr call to the caller and > instead > have a string parameter. This removes the association with login_cap and > it can > be moved to <unistd.h> or <pwd.h> alongside the other functions. It also > becomes > more like crypt (where various algorithms can be requested) and thus more > reusable in other situations than local-user authentication (like a > web-server).
Yes. Deciding which level of abstraction to incorporate was part of the fun. The factors in favor of login_cap is that the getcapstr code is basically boilerplate that all OpenBSD callers are going to duplicate. The various passwd/user/encrypt programs all have access to login cap. You have some good points that the interface could be changed to be more accomodating to other users. The bcrypt extension functions are standalone precisely for that reason, so that the code could be packaged and reused by anybody. The crypt_newhash function felt more like a "system" interface, particular to OpenBSD, but it is not strictly necessary for that to be the case. Parity with checkpass would be a bonus. So far only passwd uses the new function; it is still easy for me to change the interface. (The only constraint being that I need to coordinate library changes with other developments so it may not be an immediate change.)
