Am Sat, Feb 12, 2022 at 05:25:11PM +0100 schrieb Niclas Rosenvik: > On Mon, 7 Feb 2022 16:12:17 +0100 > Thomas Klausner <w...@netbsd.org> wrote: > > > Hi! > > > > I've been asked by the filezilla software developer if NetBSD will add > > crypt_r() as a thread-safe crypt() replacement. > > > > Is anyone interested in working on this? > > Thomas > > Here is a cvs diff that implements crypt_r, as mouse pointed out > it is really trivial since __crypt is already essentially crypt_r.
Please don't commit a new interface when my initial question has not been answered. What is this interface supposed to solve? This is essential as a password verification interface very naturally can internalize all storage necessary for the different backends where as a contract that involves returning a "decrypted" string can not. For the same reason, the interface contract here is completely wrong. There is no need to expose the internals like this. The only non-thread-safe space used by crypt(3) that should ever be exposed is the space necessary for the return storage. Joerg