[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
>> 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
> 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
Main Index |
Thread Index |