Open jku opened 2 years ago
I believe multisig are one argument in favour of the way legacy python-tuf and current go-tuf repository tools have staging
directories where metadata is written to initially.
yes, multisig discussion is going to be interesting: I think the staging concept has merit... even if I don't think the idea of just copying the whole repo to another directory and using that as base quite works (when there could be hundreds of unrelated changes going on in the same "staging"). But the developer tool and the repository being able to load specific metadata as "unfinished" with e.g. lower threshold requirements does make sense.
Another argument for staging which we should bear in mind is if a) the repository files you are editing are the live files a client interacts with or b) the repository publication is non-atomic client may run into raciness issues as described in https://github.com/theupdateframework/specification/issues/223
the only case where that can't be avoided by doing things in the correct order is, AFAICT, timestamp key rotation and that is inherently non-atomic: no amount of staging can save it from failing once in a blue moon.
What I mean is: Assuming consistent_snapshot
I can add new targets versions as much (or even snapshot versions ) as much as I want: it won't affect clients in any way until the whole chain timestamp->snapshot->targets
is updated
Agreed.
Filing issues for everything feels like a daunting task so I'm writing things down here to start with: