Re: crypt_r()?

[Joerg Sonnenberger <joerg%bec.de@localhost>]

Am Sat, Feb 12, 2022 at 05:25:11PM +0100 schrieb Niclas Rosenvik:
> On Mon, 7 Feb 2022 16:12:17 +0100
> Thomas Klausner <wiz%NetBSD.org@localhost> 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