@robryk oh I see - got just calls out to SSH to handle this
That has a weird effect where you cannot repush a commit that was there already, if it got gced in the meantime, and where e.g. accepting a pull request might work differently depending where the source branch is (because it either does or does not involve adding the commits).
SSH certs can expire. What should happen if a commit is signed with a key that had an expiring cert attached? Should we outright reject it (because the signature will become "invalid" for some meaning thereof in the future), accept if it's valid now, accept if it's valid at its stated commit time (and maybe enforce that commits are younger than their parents), or something else?
@mjg59 Now that I think of this some more, I wonder whether it would make sense to have a way to specify rules like "every commit has to be signed in a way that satisfies <foo> or has to be an ancestor of commit <bar>", so that one can do effective rotations of signing keys while not having to trust the repo storage to do all the verification (i.e. while allowing the same verification to happen when e.g. cloning).
@robryk what do you mean?