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
support "ecdsa" keytype as well as the old "ecdsa-sha2-nistp256" #754
Comments
This came up since sigstore root-signing is trying to use "ecdsa" as a keytype: sigstore/root-signing#1164. The actual error from tuftool is: So it is still possible that the issue is something not related to the ecdsa change itself but that seemed like the most obvious culprit (as no public key content has actually changed). Also apologies for how the whole ecdsa keytype evolution has happened: I realize this is not the first or second time things have had to change in tough around this. We (TUF community as whole) could really improve the communication on these issues... |
👋 |
Hi there, we haven't planned a new release of tuftool due to there only being changes in tough itself and we did a minor release. If you use cargo install to install tuftool or run a cargo update it should bring in the new version of tough. If it does not or you see any weirdness do please reach out and let us know. |
@jmt-lab Perfect, thanks. Verified this too and it works, which can be seen in this PR: sigstore/root-signing#1190 |
Seems to be fixed, thanks a lot. |
The TUF spec has last year fixed the inconsistency in keytypes so "ecdsa" is now the suggested keytype name (instead of "ecdsa-sha2-nistp256"):
https://theupdateframework.github.io/specification/latest/#keytype
For clients it's fine (and the suggested approach) to support both names.
Based on my (limited) understanding of serde this might be an easy fix:
becomes something like
?
The text was updated successfully, but these errors were encountered: