jku
commented
1 year ago The other special case here is online roles: if the online roles (in practice the keys in the role) change in root metadata, we need to resign snapshot & timestamp.
Possible online role solution 1: even though root changes in general don't necessitate a snapshot+timestamp, it might be useful to generate them anyway every time there is a root change (because publish is currently triggered by timestamp -- so root changes would not trigger it). Since do_snapshot() process does not necessarily have knowledge of "did root change?" this might not be a useful path.
Possible online role solution 2: if do_snapshot() thinks a new snapshot is not needed, it should still check if the current snapshot is valid. If not, it should create a new snapshot even if the actual content does not change. This would catch the case where the online key defined in root has changed
if e.g. targets key is changed (or threshold raised), this currently does not automatically lead to targets re-signing.
Something (either the playground-delegate that modifies root, or the signing-event GH action itself) should trigger signing for targets in the same event, I think. It probably makes sense for playground-delegate to do it (since it may actually be able to sign for targets itself right away)
So offline solution: When a delegation (or just one of the public key contents of the delegation) in a delegator is modified, playground-delegate should create a new version of the delegated metadata. The idea is that the delegated metadata should be signed in the same signing event where the delegation changes: this way we never end up with repository versions where metadata is just incorrectly signed