Re: crypt_r()?

[Konrad Schroder <perseant%hhhh.org@localhost>]

On 2/15/2022 5:04 PM, Mouse wrote:
> > (2) Hashing password, which takes the password and the settings and 
> > returns an allocated string with the resulting hash. [...] 
> I really don't like making them depend on malloc, though I have a hard 
> time articulating what bothers me about it.

I can't say what bothers *you* about it :^) but what bothers me is that 
it makes it impossible to pre-allocate memory for the purpose.  This 
might be a concern, for example, on a system with no swap.

Combine that with a need for thread safety, say for a threaded login 
daemon on a system with no swap, and you get crypt_r(3) as described.

Of course the clearest use-case for crypt_r(3) is a password cracker: 
each thread sets up its own local memory and blasts through calls to 
crypt_r(3) as fast as it can.  I've run a cracker as a white-hat.  But I 
can see not wanting to add the capability to base if that's the only 
convincing use case.

Take care,

    Konrad Schroder
    perseant%hhhh.org@localhost