Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

zeroize: 1.5 compatibility tracking ticket #723

Closed
tarcieri opened this issue Jan 27, 2022 · 12 comments
Closed

zeroize: 1.5 compatibility tracking ticket #723

tarcieri opened this issue Jan 27, 2022 · 12 comments

Comments

@tarcieri
Copy link
Member

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.

tarcieri added a commit to RustCrypto/traits that referenced this issue Jan 27, 2022
We've received a number of complaints about `zeroize` compatibility
(see RustCrypto/utils#723), which was exacerbated by #884 which bumped
the `zeroize` version within a minor version series.

I had hoped the cargo resolver would've been able to select an older
compatible version of zeroize in these cases, but I've gotten a lot of
reports that isn't happening.

This release reverts #884 in hopes of supporting a wider range of
`zeroize` versions for now. It's technically breaking in the event
anyone is actually depending on `ZeroizeOnDrop` marker traits on these
types, but it seems we've already broken things for current users and
that's the much higher impact issue.
tri-joe added a commit to EspressoSystems/cape that referenced this issue Jan 27, 2022
The conflict between `elliptic_curves` and `crypto_box` got temporarily
patched. For context, see:
- RustCrypto/nacl-compat#33 (comment)
- RustCrypto/utils#723
tri-joe added a commit to EspressoSystems/cape that referenced this issue Jan 27, 2022
Fixes #269

The conflict between `elliptic_curves` and `crypto_box` got temporarily
patched. For context, see:
- RustCrypto/nacl-compat#33 (comment)
- RustCrypto/utils#723
@trevyn
Copy link

trevyn commented Jan 28, 2022

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
Copy link
Member Author

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.

tri-joe added a commit to EspressoSystems/cape that referenced this issue Jan 31, 2022
Fixes #269

The conflict between `elliptic_curves` and `crypto_box` got temporarily
patched. For context, see:
- RustCrypto/nacl-compat#33 (comment)
- RustCrypto/utils#723

Apparently ethers:master has been broken for about a week
@poliorcetics
Copy link

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
Copy link
Member Author

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.

trevyn added a commit to trevyn/nacl-compat that referenced this issue Mar 16, 2022
trevyn added a commit to trevyn/AEADs that referenced this issue Mar 16, 2022
tarcieri pushed a commit to RustCrypto/AEADs that referenced this issue Mar 16, 2022
tarcieri pushed a commit to RustCrypto/nacl-compat that referenced this issue Mar 16, 2022
@tarcieri
Copy link
Member Author

tarcieri commented Mar 21, 2022

We've cut the following prereleases which unpin zeroize:

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

@itsTyrion
Copy link

itsTyrion commented Apr 27, 2022

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

@tarcieri
Copy link
Member Author

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

@tarcieri
Copy link
Member Author

tarcieri commented May 1, 2022

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

@andrewbaxter
Copy link

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

@tarcieri
Copy link
Member Author

tarcieri commented Jul 1, 2022

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
Copy link

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
Copy link
Member Author

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants