Closed jku closed 5 months ago
This came up since sigstore root-signing is trying to use "ecdsa" as a keytype: https://github.com/sigstore/root-signing/pull/1164. The actual error from tuftool is:
Failed to load repository: Failed to parse root metadata: Invalid SubjectPublicKeyInfo document at line 18 column 4
https://github.com/sigstore/root-signing/actions/runs/8262338514/job/22601461047
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...
cc @kommendorkapten
👋
Will there also be a new release of tuftool
with this update? We are using tuftool
in Sigstore's TUF repo to verify client compatibility.
👋 Will there also be a new release of
tuftool
with this update? We are usingtuftool
in Sigstore's TUF repo to verify client compatibility.
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: https://github.com/sigstore/root-signing/pull/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
?