Would it make sense to add a trusted-keys (could start with just @ryanofsky) and trusted-sha512-root-commit file like we do in Bitcoin Core?
The goal would be to make it easy to run the verify-commits script on this repo, ideally every time we update the subtree: https://github.com/bitcoin/bitcoin/tree/master/contrib/verify-commits
Haven’t thought much about this but I feel like it would be nice if the trusted keys for the main bitcoin repository applied here as well, and all bitcoin core maintainers could merge PR’s here without issues.
I’m not sure how verification needs to be set up though. I wonder if someone more familiar with this can suggest next steps?
I wonder if someone more familiar with this can suggest next steps?
I guess a next step might be to run verify-commits in CI like 06_script.sh does.
I was able to run to run the verify-commits successfully locally with:
0mapfile -t KEYS < ~/work/bitcoin/contrib/verify-commits/trusted-keys
1gpg --keyserver hkps://keys.openpgp.org --recv-keys "${KEYS[@]}"
2root=7d10f3b1e39caa04b3fcddebf720fd3a2b54c21d
3echo "$root" > ~/work/bitcoin/contrib/verify-commits/trusted-sha512-root-commit
4echo "$root" > ~/work/bitcoin/contrib/verify-commits/trusted-git-root
5~/work/bitcoin/contrib/verify-commits/verify-commits.py
Going back to 7d10f3b1e39caa04b3fcddebf720fd3a2b54c21d. It looks like all the earlier signatures are valid too according to
0git log --merges --show-signature
but they show up with gpg: Note: This key has expired! so verify-commits seems to reject them. Or at least it failed at that commit when I tried to run it with root=$(git rev-list --max-parents=0 HEAD) using the first commit as the trusted root.