zeroize: 1.5 compatibility tracking ticket

[tarcieri]

Several of our crates lock zeroize to <1.4 to prevent MSRV breakages, as zeroize bumped MSRV to 1.51 in order to leverage const generics.

This has caused several compatibility problems when trying to add new features to zeroize, namely ZeroizeOnDrop which was added in v1.5. This means crates that use these new features are incompatible with crates that lock to old zeroize versions, even though they are otherwise code compatible on newer versions of Rust.

This is a tracking issue for these problems and getting the rest of our crates upgraded so there are no longer compatibility issues.

[trevyn]

Can’t projects that rely on a specific MSRV set an appropriate version of zeroize in their Cargo.toml? Pinning an earlier version of zeroize seems overkill; just being compatible with an earlier version should be sufficient. (This can be tested in CI with minimal-versions, too.)

IMO, it seems reasonable to ask downstream projects that rely on an MSRV to explicitly specify versions of transitive dependencies that allow that MSRV. Or has a decision been made otherwise?

[tarcieri]

Can’t projects that rely on a specific MSRV set an appropriate version of zeroize in their Cargo.toml?

Yes. Alternatively we can also just bump MSRV.

IMO, it seems reasonable to ask downstream projects that rely on an MSRV to explicitly specify versions of transitive dependencies that allow that MSRV. Or has a decision been made otherwise?

We tried the pinning approach but it has this bad downside of unintentionally restricting what are otherwise valid combinations of versions.

Really I think the best approach is to just bump MSRV across the board so it's no longer an issue.

[poliorcetics]

This is becoming a problem with RSA needing zeroize >= 1.5 while chacha asks for <= 1.4. All the READMEs I have looked at say a minor version bump is enough to bump the MSRV, should I make a PR to every RustCrypto repo ?

[tarcieri]

If you see any lingering crates that have zeroize pinned, feel free to open a PR to unpin them.

I agree this is preventing valid combinations of crates from working and we should try to get past it at this point.

[tarcieri]

We've cut the following prereleases which unpin zeroize:

• chacha20poly1305 v0.10.0-pre: https://crates.io/crates/chacha20poly1305/0.10.0-pre
• rsa v0.6.0-pre: https://crates.io/crates/rsa/0.6.0-pre

If you're encountering problems with any other crates, let us know.

[itsTyrion]

Is there an ETA for aes-gcm-siv? The current version 0.10.3 is incompatible with rsa 0.6.1.

[tarcieri]

I can cut a prerelease which will fix the zeroize compatibility issue

[tarcieri]

aes-gcm-siv v0.11.0-pre has been released with an unpinned zeroize

[andrewbaxter]

rsa 0.6.0-pre on requires num-bigint-dig which since March 1 also pins zeroize: ^1.51.

[tarcieri]

It does look like num-bigint-dig isn't using any zeroize v1.5-specific features and that could potentially be relaxed, however really the goal of this ticket is to track things which are incompatible with zeroize v1.5.

Perhaps open an issue on https://github.com/dignifiedquire/num-bigint/issues ?

[andrewbaxter]

Ah sure, I just wanted to note that the above unpinning in rsa probably had limited effect due to the transitive dependency. I guess the discussion about releasing unpinned packages was a tangent to the main discussion here.

[tarcieri]

This should be resolved now. Please leave a comment if there are any remaining incompatibilities.