libs-team VS password-hashes

In rust, both release and debug builds use a release version of the runtime. The bugs the debug version is meant to catch are much more difficult to hit in rust (often but not always requiring unsafe). There isn't currently a feature to use the debug runtime in rust-- you can only change C to match for those debug builds.

Note that this has been discussed at length (and I do mean "at length") here: https://github.com/rust-lang/libs-team/issues/72

The Compiler Team, especially the Diagnostics Working Group that improves compiler error messages. The Libs Team, for work on the contents of the standard library documentation

See https://github.com/rust-lang/libs-team/issues/72#issuecommen... for what I believe is an exhaustive list of possible ways of helping the situation.

The point is how the MSRV of a popular crate affects this dynamic for other crates. For an even more extreme example than time, see here for libc, with many heavyweights offering opinions: https://github.com/rust-lang/libs-team/issues/72

In case you haven't seen it yet, there is a very long discussion surrounding MSRV policy of the libc crate on rust-langs github repo. It's about a library, not a binary, but I think there's a lot of information in the thread, some of which will also apply to binaries.

Would you mind sharing your use case for being stuck with a particular version of Rust and why you can't upgrade? In particular with the libs team: https://github.com/rust-lang/libs-team/issues/72

Compare Stepanov's brilliant design of the STL to Rust's current reworking of their 'binary search api'. https://github.com/rust-lang/libs-team/issues/81

Maybe 'memory safety' isn't the most important thing in this world. To me, writing software that does useful things in the simplest and most correct way is what matters. I get the feeling it's harder to understand my program's correctness with Rust (I mean algorithmic correctness). The C++ standard library has time and space complexity for every algorithm. I'm not seeing that's the case with Rust (correct me if I'm wrong).

There's also the pretty fundamental libc crate that wants to choose an MSRV policy and you can see the full discussion here: https://github.com/rust-lang/libs-team/issues/72

I would say a toy (or personal-use-only) password manager is a relatively simple project. If we are to forget about the GUI parts, you need to determine serialization of your password database (bincode + serde should be enough) and how to encrypt it. For the latter you need only two algorithms: a password hash for deriving encryption key from password and optional salt (the latter is usually randomly generated and stored as a "key file"), and an AEAD algorithm for encrypting and decrypting serialized database. There are certain pitfalls with encryption (e.g. you should not reuse nonce with the same key, especially with modes like GCM) and with properly erasing sensitive data from memory, as well as preventing it from leaking to things like swap, but learning about those is part of the learning experience.

I 'cheated' by forwarding everything to their separate Rust libraries which are maintained by https://github.com/RustCrypto/password-hashes . Ofcourse by adding the Elixir wrapper this could have introduced security issues (sadly I don't have enough knowledge about how NIF's handle memory ect. to test/check this myself)

As noted in the announcement, it's using the latest OWASP recommended parameters for Argon2, namely Argon2id with 19 MiB of memory, an iteration count of 2, and 1 degree of parallelism.

For password handling, I have had good experience with password-hash and the various algorithm implementations in the password-hashes repo.