Are there any concrete use cases for this?

related #18737

I have one!

I wrote a wrapper around the Enzoic password API, which, as part of its API, requires the caller to compute a bcrypt hash with a given salt. https://www.enzoic.com/docs-credentials-api/#hash-based-credentials-step-3.

In order to implement the client in go, I had to fork the bcrypt package and add a function very similar to the one linked above.

/cc @FiloSottile

This proposal has been added to the active column of the proposals project
and will now be reviewed at the weekly proposal review meetings.
— rsc for the proposal review group

@FiloSottile any opinions on adding GenerateFromPasswordAndSalt?

A few other notes on this:

It has been proposed before: #18737. The use-cases presented in that proposal did not inspire... confidence... that this API will be used responsibly.

I personally think having the option is valuable (although it's really going to be valuable for people doing weird things with password management, as my use-case above illustrates), but it certainly should be gated with some big warning signs that "you probably just want to use GenerateFromPassword, only provide your own salt if you're certain it's sufficiently random, etc etc".

/cc @FiloSottile

/cc @FiloSottile @katiehockman @rolandshoemaker

It seems like there are still pretty limited use cases for this functionality, API compatibility with OpenBSD is nice, but I'm not really sure what else it gets us beyond API parity.

This is a dangerous API to add, and if we have to add a large "this is dangerous, please use it only if you know what you're doing" warning, it seems more prudent to just not implement it in the first place.

thanks @rolandshoemaker

Based on the discussion above, this proposal seems like a likely decline.
— rsc for the proposal review group

Disappointing, but understandable. I suppose I'll have to maintain my little fork.

No change in consensus, so declined.
— rsc for the proposal review group