Am I correct in saying that you’re used to languages that aren’t type safe? Or at least not as strict about it.
Everything you’re describing sounds more like you’re struggling with type safety in general and I wouldn’t say any of those packages are at fault, in fact I’d even go further and say they’re like that by design.
The reason you don’t actually want any of those separate packages to be more interoperable out of the box is because that would couple them together. That would mean dependencies on those packages, it would mean if it wanted to use something else then you’d be a bit stuck.
Like I’d question using a uuid as a salt, like it’s fine and I get why they’re suggesting it, but you can use anything as a salt so why couple yourself to a specific uuid library? Why couple yourself to uuids at all.
Side note: I’m guessing the reason the crate expects you to supply your own salt is because you need to also store the salt next to the password hash, if it generated the salt for you there’s a chance you might ignore the salt and suddenly not be able to validate passwords.
Anyway…
The only way you could make these separate packages work dramatically together and without coupling them would be to use a universal type - probably a byte array - and at that point you lose most of the benefits of a strong type system. What are currently compile errors become runtime errors, which are much worse and harder to diagnose.
My suggestion to you would be to reframe your thinking a little, think less about how you can make different crates speak to each other and more about how you convert from one type to another - once you crack that, all of these integration problems will go away.
None of this has much to do with type safety at all. A dynamically typed language might have a Salt object that has a constructor that takes a base64 string. If its common uuid library doesn’t output base64, then you can’t use it directly.
Nor does a specific uuid library matter much. It just needs to be able to output base64 strings, which is an uncommon uuid encoding, but it’s out there.
Nor does type safety prevent providing a sensible default implementation.
The crate uses phc strings, which store the salt together with the hashed password, so no, it can handle it all on its own.
There was just no thought into how components work together.
Yeah, that’s my thinking, too. But the library only takes b64.
Edit: also, if anything, this system reduces the benefit of strong typing. You can feed whatever string you want into it and the compiler will say it’s OK, even if it would fail at run time. If it were a Vec<u8>, then the compiler can check things. Especially if you do something to let the compiler enforce the length (if possible).
Or hand over a UUID object directly. Yeah, it ties it to a specific library, but it’s either that or you’re not taking full advantage of strong typing.
Am I correct in saying that you’re used to languages that aren’t type safe? Or at least not as strict about it.
Everything you’re describing sounds more like you’re struggling with type safety in general and I wouldn’t say any of those packages are at fault, in fact I’d even go further and say they’re like that by design.
The reason you don’t actually want any of those separate packages to be more interoperable out of the box is because that would couple them together. That would mean dependencies on those packages, it would mean if it wanted to use something else then you’d be a bit stuck.
Like I’d question using a uuid as a salt, like it’s fine and I get why they’re suggesting it, but you can use anything as a salt so why couple yourself to a specific uuid library? Why couple yourself to uuids at all.
Side note: I’m guessing the reason the crate expects you to supply your own salt is because you need to also store the salt next to the password hash, if it generated the salt for you there’s a chance you might ignore the salt and suddenly not be able to validate passwords.
Anyway…
The only way you could make these separate packages work dramatically together and without coupling them would be to use a universal type - probably a byte array - and at that point you lose most of the benefits of a strong type system. What are currently compile errors become runtime errors, which are much worse and harder to diagnose.
My suggestion to you would be to reframe your thinking a little, think less about how you can make different crates speak to each other and more about how you convert from one type to another - once you crack that, all of these integration problems will go away.
None of this has much to do with type safety at all. A dynamically typed language might have a Salt object that has a constructor that takes a base64 string. If its common uuid library doesn’t output base64, then you can’t use it directly.
Nor does a specific uuid library matter much. It just needs to be able to output base64 strings, which is an uncommon uuid encoding, but it’s out there.
Nor does type safety prevent providing a sensible default implementation.
The crate uses phc strings, which store the salt together with the hashed password, so no, it can handle it all on its own.
There was just no thought into how components work together.
Why even bother with things like strings for a salt? I would expect it to just take a byte array. Just create some random bytes and provide that.
Yeah, that’s my thinking, too. But the library only takes b64.
Edit: also, if anything, this system reduces the benefit of strong typing. You can feed whatever string you want into it and the compiler will say it’s OK, even if it would fail at run time. If it were a
Vec<u8>, then the compiler can check things. Especially if you do something to let the compiler enforce the length (if possible).Or hand over a UUID object directly. Yeah, it ties it to a specific library, but it’s either that or you’re not taking full advantage of strong typing.
Or just have a sensible default implementation.