elliptic-curve: fix minimal-versions check#2414
Merged
Merged
Conversation
The issue as reported in #2413 is buried deep in the transitive dependencies of `bitvec` which is in turn a transitive dependency of `ff`, so it's a bit annoying to debug. It turns out to be `wyz` does not correctly specify the version of `tap` it needs: it needs 1.0.1 but asks for 1 (I feel like I've probably encountered this before) Sidebar: alternatively we could drop the `bits` feature. I'm not sure if anyone's actually using it and I suppose I could look into that, but `bitvec` development seems stalled at this point and asking about it on Zulip's #t-opsem channel did not inspire confidence for cryptographic applications.
Member
|
IMO it's probably worth to trim the |
tarcieri
added a commit
that referenced
this pull request
May 12, 2026
I was not able to find any users of it searching GitHub. This feature is backed by `bitvec` which both has a high number of transitive dependencies which have been minorly problematic (#2414), but also my understanding based on Zulip discussions on #t-opsem is that `bitvec` is not sound under either stacked or tree borrows, which makes it a bit worrisome for use in cryptographic applications. We can always add the feature back if it turns out there are users, but if not it seems like it's not worth the maintenance burden.
tarcieri
added a commit
that referenced
this pull request
May 12, 2026
I was not able to find any users of it searching GitHub. This feature is backed by `bitvec` which both has a high number of transitive dependencies which have been minorly problematic (#2414), but also my understanding based on Zulip discussions on #t-opsem is that `bitvec` is not sound under either stacked or tree borrows, which makes it a bit worrisome for use in cryptographic applications. We can always add the feature back if it turns out there are users, but if not it seems like it's not worth the maintenance burden.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The issue as reported in #2413 is buried deep in the transitive dependencies of
bitvecwhich is in turn a transitive dependency offf, so it's a bit annoying to debug.It turns out to be
wyzdoes not correctly specify the version oftapit needs: it needs 1.0.1 but asks for 1 (I feel like I've probably encountered this before)Sidebar: alternatively we could drop the
bitsfeature. I'm not sure if anyone's actually using it and I suppose I could look into that, butbitvecdevelopment seems stalled at this point and asking about it on Zulip's #t-opsem channel did not inspire confidence for cryptographic applications.