-
Notifications
You must be signed in to change notification settings - Fork 38.7k
[verify-commits] Allow revoked keys to expire #11539
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[verify-commits] Allow revoked keys to expire #11539
Conversation
|
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 ***@***.***> 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:
#11539 (comment)
|
|
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 d23be30 for the sake of fixing master. |
|
utACK |
d23be30 [verify-commits] Allow revoked keys to expire (Matt Corallo) Pull request description: This should fix verify-commits on master. Tree-SHA512: 9bfca41fdfcdb11f6d07fcbc80a7b2de37706051e963292e0fbb4c608f146c87b65ab1e8395792197b4a7099e89fa045f278a60276672f6540b68d5e15b5a4a7
Github-Pull: bitcoin#11539 Rebased-From: d23be30
d23be30 [verify-commits] Allow revoked keys to expire (Matt Corallo) Pull request description: This should fix verify-commits on master. Tree-SHA512: 9bfca41fdfcdb11f6d07fcbc80a7b2de37706051e963292e0fbb4c608f146c87b65ab1e8395792197b4a7099e89fa045f278a60276672f6540b68d5e15b5a4a7
This should fix verify-commits on master.