2021 edition upgrades

[tarcieri]

This is a tracking issue for upgrading crates in this repo to the 2021 edition:

• aead
• cipher
• crypto
• crypto-common
• digest
• elliptic-curve
• kem
• password-hash
• signature
• universal-hash

Currently we have a mixture of crates where the workspace is still 2018 edition and there are 2021 edition crates which live in their own workspaces as you can't mix editions without bumping MSRV. This is beginning to become something of a maintenance problem (see #905)

At some point we should flip over so the workspace is all 2021 edition crates (so MSRV 1.56 at a minimum) and the remaining crates which haven't updated edition are in separate workspaces until we get them all updated.

[tarcieri]

I was looking at CVE-2022-21658 and noting that everything prior to Rust 1.58.1 is impacted.

All of the crates in this repo which haven't been updated to the 2021 edition are MSRV 1.41 which is quite old at this point. I think it's time to do an across-the-board MSRV bump. Between the 2021 edition and this vulnerability it seems like about time.

[newpavlov]

I do not think we should actively bump MSRV without a good reason until the MSRV-dependent dependency version resolution will be implemented in Cargo. Nevertheless, I am quite open to MSRV bumps if there is one. For example, I plan to bump MSRV for cipher and its dependents to 1.49 in the next breaking releases even though it was possible to keep it at 1.41 (1.49 allows us to simplify certain trait bounds). If zeroize support will be added to cipher, I probably will even bump it to 1.51.

I think a good marker for judging whether a given MSRV is too old or not is Rust version used in current Debian stable (currently 1.48).

As for the CVE, I don't think it matters in our case. Note that it still applies to macOS and Redox targets, but it does not mean we should not use Rust on those.

[tarcieri]

I do not think we should actively bump MSRV without a good reason until the MSRV-dependent dependency version resolution will be implemented in Cargo.

There is a good reason here: the 2021 edition upgrade, and the complexities of maintaining a repo containing crates of mixed editions which therefore can't be placed in the same workspace.

Beyond that, leveraging rust-version at all needs MSRV 1.56. While it can be added to earlier crates, that generates a warning.

Can we at least move the default workspace declared in the toplevel Cargo.toml to the 2021 edition and put all of the additional maintenance work of outside-the-default-workspace onto the 2018 edition crates that haven't upgraded yet?

I think a good marker for judging whether a given MSRV is too old or not is Rust version used in current Debian stable (currently 1.48).

This is all a bit of a personal aside from the larger MSRV discussion, but...

Speaking as a Debian user, I've been pretty disappointed with how they manage Rust releases, especially compared to the RedHat/Fedora ecosystem where Rust is regularly updated and generally lags one major version release behind. I would look at this more of a failing of Debian than anything else.

As CVE-2022-21658 illustrates, fixes critical security vulnerabilities in Rust aren't backported. This means all of the Rust releases that Debian is currently shipping are insecure. It will be interesting to see if they manage to create a security release for 1.58.1. If they don't, this seems like a serious issue: sticking to older Rust releases like that means sticking to insecure software. And this is even an issue despite the fact all of our servers are running Bullseye, which was released only 6 months ago in August 2021.

As a Debian user, I'm concerned this is an impedance mismatch between Debian's ways of doing things and how the Rust project operates. Whereas on RedHat distros I've been able to leverage the release RPMs which are kept up-to-date, on Debian we use rustup and create Docker containers for doing builds which cache the highest MSRV we currently need to perform builds. This is because the releases Debian provides are simply inadequate and too antiquated for our needs.

Especially after an edition bump, 1.48 is untenable. Several major ecosystem projects I depend on, such as prost/tonic and clap, have moved on to either the 2021 edition or a few releases behind (e.g. clap is 1.54).

But really the important thing to consider is a user of an older rustc isn't locked out of our software: they can just use older versions until they are able to upgrade. In talking about a 2021 edition bump for the remaining crates in this repo which haven't yet upgraded, I'm talking about forthcoming releases after the current iteration, which may not happen for several months at the very least.

[tarcieri]

I've opened a tracking issue for zeroize compatibility problems here: RustCrypto/utils#723

[newpavlov]

BTW instead of keeping every 2021 edition crate in its own workspace it could be worth to simply remove the root-level Cargo.toml for MSRV tests of non-2021 crates, similarly to how we do with the "minimal versions" jobs. It would mean that the lock file will not be used for MSRV tests, but I think it's a fine trade-off.

[tarcieri]

#958 implements that proposal, and it largely addresses the motivation for opening this issue

[newpavlov]

All crates have been updated to 2021 edition. We haven't released them yet, but I think we can close this issue.