[verify-commits] Allow revoked keys to expire #11539

This should fix verify-commits on master.

I see how this allows expired keys to pass if revoked keys are allowed, but I'm missing what constrains expired to revoked? Also not sure why we'd want that constraint?

BITCOIN_VERIFY_COMMITS_ALLOW_REVSIG is set in verify-commits.sh for every commit in contrib/verify-commits/allow-revsig-commits.

That's what I was missing, thanks.

What happens when the next unrevoked key expires, though? Wouldn't all commits signed by that key fail to verify?

If a key is not in-use, it should be revoked, and if it is revoked, its commits should be in allow-revsig-commits. (if its in-use, you can keep bumping the expiration date).

Sure, that makes sense. What I'm missing is how to sunset a key (a committer leaves) without having to mark all of its commits. Or is the script smart enough to stop at the first allow-revsig parent?

No, currently you have to add all of their commits to the file. We could change to a first-revoked-signed-commit model like we do SHA512, but for now the list is short so I figure just leave it.

On October 20, 2017 6:14:55 PM EDT, Cory Fields notifications@github.com wrote:

Sure, that makes sense. What I'm missing is how to sunset a key (a committer leaves) without having to mark all of its commits. Or is the script smart enough to stop at the first allow-revsig parent?

-- You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub: https://github.com/bitcoin/bitcoin/pull/11539#issuecomment-338334775

Seems to me we should just have a file for expired (sub)keys, and verify-commit is allowed to return EXPKEYSIG for those. Because they'd be historical anyway.

That kind of change isn't urgent though, so utACK d23be309c2c45f655d5f5405e031833fb4b6bbb4 for the sake of fixing master.

utACK