Closed jku closed 4 months ago
I'm still going to do a bit more manual testing but I think this will work
Code looks reasonable! Waiting for more test results.
Test in https://github.com/jku/tuf-demo/pull/107:
awslabs/tough client does now "succeed" in that root is considered valid but
$ tuftool download --root 3.root.json -m https://jku.github.io/tuf-demo/metadata/ -t https://jku.github.io/tuf-demo/targets -n file1.txt out/`
Failed to load repository: Failed to parse timestamp metadata: missing field `length` at line 14 column 4
This one I'm not as inclined to "fix" in tuf-on-ci. I don't know if my decision to avoid lengths and hashes in timestamp and snapshot is the best choice but both options seem to have upsides and downsides and both are spec compliant
@kommendorkapten I'm done I think: As far as I can tell the code is good. and the results metadata update is solid. awslabs/tough tuftool still doesn't fully work, but the specific issue of noncompliant keyids seems to gets solved by this code
Hmm, actually tuf-on-ci-repo-import could now also modify the keyids immediately when the custom metadata is added... I'll try to add this in this PR.
Hmm, actually tuf-on-ci-repo-import could now also modify the keyids immediately when the custom metadata is added... I'll try to add this in this PR.
the change is simple but I think I have to rerun the root-signing import test to verify this
Hmm, actually tuf-on-ci-repo-import could now also modify the keyids immediately when the custom metadata is added... I'll try to add this in this PR.
There is a complication in the root case:
tuf-on-ci-delegate --force-compliant-keyids
also work nicely since from tuf-on-ci perspective the N and N+1 signers are completely different: this leads to two signatures for each signer whose keyids was modifiedtuf-on-ci-sign
figure out it needs to sign for two keyids when both import and keyid fix have been done?Example import signing event https://github.com/jku/root-signing-test/pull/16
combining these two is an issue: how can tuf-on-ci-sign figure out it needs to sign for two keyids when both import and keyid fix have been done?
Maybe a hack but what if tuf-on-ci creates an in-memory representation of the yubikey using the "old format", i.e without x-tuf-on-ci-keyowner
, and compares with the current root, and if a match, when signing it writes the signature to both entries?
Maybe a hack but what if tuf-on-ci creates an in-memory representation of the yubikey using the "old format", i.e without
x-tuf-on-ci-keyowner
, and compares with the current root, and if a match, when signing it writes the signature to both entries?
We discussed this live but documenting for others: this is pretty much what the current PR does. For each signer it takes the "tuf-on-ci managed key", calculates keyid without the custom metadata, and looks for keys with that keyid in the non-managed (N-1) metadata. These keys will then also be used to sign.
Fixes #336 , relates to #292
This change will ensure that a a keyid fix can be done in a single signing event
--force-compliant-keyids
flag to delegate: this will update all keyids in the role and will mark all affected delegations to be resignedThis approach (just switching the all keyids) looks surprising but should be 100% spec compliant. Example:
tuf-on-ci-delegate --force-compliant-keyids sign/fix-keyids root
is used: the signing event now contains a root v2 with one root signer with key A using valid keyid efgh (same key, different keyid)tuf-on-ci-sign sign/fix-keyids
as usual: this signs twice with A; The metadata signatures now contain a sig from abcd and a sig from efgh