Closed RobbieMcKinstry closed 9 months ago
Hi @RobbieMcKinstry , thanks for flagging this. We are already aware of this issue, because we are affected by it internally as well. Due to some dependency upgrades not interacting very well, we have been working on a way to be able to update these transitive dependencies. It's been a slow process but we should be in a state where we can upgrade it soon.
We would gladly merge any PRs as soon as we're able to accept the changes internally.
Hi Progdrasil. Thank you for your quick reply! I'm happy to hear this is already on your roadmap! 🚀
I'm working up a PR to bump the version of p256
to v0.13
. I've resolved the breaking changes introduced by the migration, and the test suite is green. I have to double-check that this change is sufficient to resolve the issue, and then I'll submit.
I understand if you're not able to merge until you've resolved this issue internally. If that means my PR has to sit for some time, no big deal. Thank you for your time and attention.
(As an aside: I love your product! I've been using 1Password for years now and I've always been very satisfied. ❤️)
I'm creating this issue to suggest updating the version of the
p256
crate used by this repository.The latest version is of
p256
isv0.13.2
. This repository usesp256 = "^0.10"
. This particular version is troublesome because of its transitive dependence onsignature = ">=1.3.1, <1.5"
. The1.5
release ofsignature
introduced a backward-incompatible change, which is why downstream crates have specified a version range capped out at<1.5
.Cargo's dependency resolution algorithm allows multiple major versions of the same crate. Unfortunately, since
signature 1.6
introduced a breaking change without bumping the major version number, projects must decide whether to selectsignature < 1.6
orsignature >= 1.6
. All dependencies, transitive or direct, must agree on which version range to use forsignature
. There can be no mix-and-matchFrom my anecdotal investigation, other crates in the ecosystem have resolved this issue by bumping to
>= signature 1.5
. For example,ecdsa-core
,p256@0.11
, andk256
.Steps to Reproduce
To reproduce this issue, we create a new project with
passkey
and one common cryptographic dependency, and attempt to add them to the same Rust workspace.cargo new passkey-reproduction && cd passkey-reproduction
I've found a workaround specific to
ecdsa
, which is to expand the version constraint fromecdsa@0.14
toecdsa@>=0.14
, which installs0.16.8
, but this doesn't work for other ecosystem crates which have opted to use new versions ofsignature
e.g.ethers
,k256
Contributions
✨ Please let me know if you're willing to accept a pull request for this issue. ❤️