I’d like it better if things were designed to work together better.
Right now, I’m working on a password storage system using the password_hash crate. You need to provide the salt yourself; this is already a bit silly for not providing a simple default that just gives you 16 bytes from a CSPRNG, but let’s continue.
You read the Salt struct documentation, and it talks about UUIDs being pretty good salts (well, using v4, anyway). So that pushes you toward the uuid crate, right? Except no. That crate doesn’t produce formats that the functions on the Salt struct will accept, like base64. So maybe the uuid_b64 crate will do it? I don’t think so, because that crate uses a URL-safe version of base64, and it’s not clear Salt will take that, either.
You’re now forced to use a cumbersome interface from the rand crate to make your salt. I’m still working through some of the “size not known at compile time” errors from this approach.
All of which would work better if there was a little thought into connecting the pieces together, or just providing a default salt generator that’s going to do the right thing 90% of the time.
Don’t get me started on how Actix hasn’t thought through how automated testing is supposed to work.
Rust is completely correct to be a dick about it as well. Type safety is there for a reason.
I’d like it better if things were designed to work together better.
Right now, I’m working on a password storage system using the
password_hashcrate. You need to provide the salt yourself; this is already a bit silly for not providing a simple default that just gives you 16 bytes from a CSPRNG, but let’s continue.You read the Salt struct documentation, and it talks about UUIDs being pretty good salts (well, using v4, anyway). So that pushes you toward the
uuidcrate, right? Except no. That crate doesn’t produce formats that the functions on the Salt struct will accept, like base64. So maybe theuuid_b64crate will do it? I don’t think so, because that crate uses a URL-safe version of base64, and it’s not clear Salt will take that, either.You’re now forced to use a cumbersome interface from the
randcrate to make your salt. I’m still working through some of the “size not known at compile time” errors from this approach.All of which would work better if there was a little thought into connecting the pieces together, or just providing a default salt generator that’s going to do the right thing 90% of the time.
Don’t get me started on how Actix hasn’t thought through how automated testing is supposed to work.
Yeah, gotta newtype it up to make it even more relentless.