Re: crypt_r()?

[Mouse <mouse%Rodents-Montreal.ORG@localhost>]

>> I've been asked by the filezilla software developer if NetBSD will
>> add crypt_r() as a thread-safe crypt() replacement.
> I don't exactly see the point.

Thread safety, presumably.  crypt(3) returns a pointer into a static
buffer.  I daresay it could be made to return a pointer into TLS when
running threaded, but I think crypt_r makes more sense.  I even have,
on some small number of occasions, wanted a crypt_r without threads
(though without threads or at least signals it's just a strcpy or
strdup away).

> If I wanted to provide a more modern interface, it would be for
> password verification only and include constant time guarantees,
> which the existing interface can't provide.

Nobody's stopping you.

For many purposes, crypt_r has the major advantage over what you
describe that it is trivial changes to existing code.  (In most cases,
I suspect using what you're thinking of would be almost as trivial.
But without a design to look at it's hard to tell.  Admittedly, crypt_r
_could_ mean pretty much anything, but it strikes me as unlikely wiz
would use that name without meaning exactly what I daresay everybody
here takes it to mean.)

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		mouse%rodents-montreal.org@localhost
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B