script: Add commits signed with sipas expired key to allow-revsig-commits #22768

Fixes #22737. While investigating the issue above, I noticed that there are 141 commits that are signed with sipas expired key. To allow ./contrib/verify-commits/verify-commits.py to succeed, this PR adds them to allow-revsig-commits. Feel free to confirm that they're indeed signed with an expired key using e.g. git show --show-signature d8cd7b137fb075616f31d2b43b85fa2e27ea7477 :)

Ping @Yihen-Liu. Would you mind testing this as you reported the bug that this PR fixes? :)

@n-thumann Dear man, what I did as follow:
step one, copy the patch you push and paste them into the allowo-revsig-commits; step two, ./contrib/verify-commits/verify-commits.py origin/master

It takes long time to verify, more than one hour; I type CTRL-C when it does not finished automatically;

I want to confirm whether my op steps is right? if not, will you please give me right suggestion about how to checkout the patch and verify step by step?

It takes long time to verify, more than one hour; I type CTRL-C when it does not finished automatically;

This is perfectly fine and not unusual. Please don't quit it, but wait until it's done :) On my machine it took 3:15 hours to check all commits.

Hi @n-thumann, Yes, all commits verify validly and successfully which took about 3 hours on my macbook :)

It seems like there ought to be a way to tell GPG to verify against the commit date (but I couldn't find a way)

Concept ACK, have not verified the commit ids.

It seems like there ought to be a way to tell GPG to verify against the commit date (but I couldn't find a way)

This sounds like it would be good to have, though it'd need some additional assurance that the timestamps are not faked. No idea if opentimestamps would help here.

Perhaps a possibility is:

• Use libfaketime around gnupg, with time set to the commit timestamp.

EDIT: that's not enough; we need a check that newly created merge commits are not too old. OTS may help.

It might be tricky to derive OTS proofs for the commits, as they are not timestamped themselves. Though there are timestamps for other commits around that time.

• I created a (hacky) script to list the commits that are signed with a certain key

#!/usr/bin/env python3
from git import Repo
import subprocess
import sys

repo = Repo(".")
GIT = 'git'
keyid = sys.argv[1]
keyid = keyid.replace(' ', '').lower()

for c in repo.iter_commits():
    r = subprocess.run([GIT, 'verify-commit', c.hexsha], capture_output=True, universal_newlines=True)
    for line in r.stderr.split('\n'):
        if line.startswith(('Primary key fingerprint: ', '     Subkey fingerprint: ')):
            ckeyid = line[25:].replace(' ', '').lower()
            if ckeyid == keyid:
                print(c.hexsha)

• I did

git checkout master
../list-commits-with-key.py "AC66 2617 2E00 A82C FFAE  8972 A636 E976 31F7 67E0" >> contrib/verify-commits/allow-revsig-commits
git diff FETCH_HEAD contrib/verify-commits/allow-revsig-commits

This gives me the following output:

 d9fdac130a5ed1d96fcac6bb87c10bec9d596b17
-a07e8caa5d5000286604458e6887f57fec7fdcbb
-8b262eb2d80bfa27ae8501078ce47bc1407e9c55
-5df84de583c900e00fef63bedaef32786f205a33
-4ba6da55743a55189164e29e45ac9e73a074d808
 5bea05bc1d17aa43cbdf3a3413241f8132790d93

These four commits are signed with the key but not included in this commit:

a07e8caa5d5000286604458e6887f57fec7fdcbb Merge [#13033](/bitcoin-bitcoin/13033/): Build txindex in parallel with validation
8b262eb2d80bfa27ae8501078ce47bc1407e9c55 Merge [#13021](/bitcoin-bitcoin/13021/): MOVEONLY: Move logging code from util.{h,cpp} to new files.
5df84de583c900e00fef63bedaef32786f205a33 Merge [#12970](/bitcoin-bitcoin/12970/): logging: bypass timestamp formatting when not logging
4ba6da55743a55189164e29e45ac9e73a074d808 Merge [#12743](/bitcoin-bitcoin/12743/): Fix csBestBlock/cvBlockChange waiting in rpc/mining

Is this intentional?

Oh, I see, they're already in the file, so would be duplicate. Ok, fair enough.

Code review ACK 365f35481d5c04109d64e88e548d6985705c2f75