verify-commits: Bump trusted git root to after most recent laanwj merge #27076

1. 
   achow101 commented at 4:53 pm on February 10, 2023: member

   To prepare for the removal of laanwj’s key from trusted key (#27054), the trusted git root needs to be newer than the most recent merge commit signed by his key.

   This can be tested by removing the laanwj’s key from trusted keys (e.g. by merging with #27054) and running verify-commits.py with --clean-merge 0: ./contrib/verify-commits/verify-commits.py --clean-merge 0 HEAD~. (--clean-merge 0 disables the clean merge check which will checkout some commits, which results in the trusted-keys used in checking of subsequent commits to be different than expected).

2. verify-commits: Bump trusted git root to after most recent laanwj merge

   To prepare for the removal of laanwj's key from trusted key, the trusted
   git root needs to be newer than the most recent merge commit signed by
   his key.

   6ada37d44c
3. 
   DrahtBot commented at 4:53 pm on February 10, 2023: contributor

   The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

   Reviews

   See the guideline for information on the review process.

   Type	Reviewers
   ACK	fanquake, hebasto
   Approach ACK	MarcoFalke

   If your review is incorrectly listed, please react with 👎 to this comment and the bot will ignore it on the next update.

4. 
   Sjors commented at 1:01 pm on February 11, 2023: member

   I would prefer a solution (#27058?) that allows checking commits by retired maintainers, at least up to a few years back (e.g. the branch-off point for the last backport supported version).
5. 
   maflcko commented at 1:06 pm on February 11, 2023: member

   You can do git checkout "$(cat contrib/verify-commits/trusted-git-root)~1" and then verify the previous commits, as often as you want, to go as far back as you want.
6. 
   Sjors commented at 1:13 pm on February 11, 2023: member

   That’s a good hint to add to the README. But having the root key not too recent still seems better, all things equal. I think we should only bump it if a former maintainer revokes their key or it expires, plus maybe every couple of years to preempt such issues. So far #27058 seems compatible with that approach (update: not anymore, moving discussion there)
7. 
   maflcko commented at 1:22 pm on February 11, 2023: member

   I think we should only bump

   Is there any reason for this? See also #27058 (review) What would the alternative be? Listing hundreds or thousands of “revsig” commits in a file, to ensure it is impossible to review manually, only with special git commands, potentially making it trivial to sneak in malicious commits that are not actually revsig commits? And then, as you say, bump the root anyway later.

8. 
   Sjors commented at 1:33 pm on February 11, 2023: member

   @MarcoFalke answered in #27058 (comment). Depending on what we do there this PR can either be closed or merged.
9. 
   maflcko commented at 10:20 am on February 14, 2023: member

   lgtm, Approach ACK

   I haven’t tested this, because I use a trusted git root set by myself anyway, but I can’t see a reason not to do this. This was also done last time in commit d4b3dc5b0a726cc4cc7a8467be43126e78f841cf, so it makes sense to do the same approach again.

10. fanquake approved
11. 
    fanquake commented at 5:20 pm on February 14, 2023: member

    ACK 6ada37d44cce7fa3a729de72cede4c1f3bc675ce

     0-----BEGIN PGP SIGNED MESSAGE-----
     1Hash: SHA256
     2
     3ACK 6ada37d44cce7fa3a729de72cede4c1f3bc675ce
     4-----BEGIN PGP SIGNATURE-----
     5
     6iQIzBAEBCAAdFiEEz7FuIclQ9n+pXlWPLuufXMCVJsEFAmPrwdkACgkQLuufXMCV
     7JsHyExAApfaVBqnmRs6raV8ky90kLLiesvYjgebHyJAq059OZvlROziNC43FAlls
     8xnhDxMYqUB8rFRGpPccqI4oi+tpSFUrS44MP+UgMzkq1mrt7Tfx7cjTQPkB21YFD
     9FYrTZT5hE7FLQvkf7yDD8OobkZOZQl5wIKE+VNW3TW0oBWnfjXY5tw1vh51Qta1x
    109B7UrSRJJ3SFD/xmLYDtCtzRDraKg44fRxKf9A5rvXaWdfR3s8pBZuVXJePveCTv
    11YQjKQtFxRIjiWaFNW+ERD0xxq0B6z3/LvocqXJwo2Mryc4tUMsqZuopze6V8oIUB
    12GWxSRxDV6bumWxxBqQbvfZJhwJY+Jstm2JD7TxDtwvgJe0Wnb0sTsGBpkFFNXORy
    139QPCcYPlW3+YIT2Z/fDhg1DQd4+2JhWtaGyguB/yHly7j2A+jRGBqtFATNFUtz/r
    14cfTdDPXR3fvXFh3hjcKKCvcwKrPbfU4SXqAU0qlXX7DprbWkpQpt01Jg5rNBINlC
    15j/tsKNxeMj1kNeCYy4muDqC5HRA2gsqlb+bEeyndg3PlPyypi0d8Aj2S7/BgXUU/
    16FKSgXWMEagBXHklmYJnMRtt85RDsOfDKW7znecGDqDBlX2qA8pZ1SNaVWYhFvU2Y
    17iePmdIgEuhpn19xQwjSu+M4ITVNb0C9jSqY0IUF5gK3OZh70WGw=
    18=Bln+
    19-----END PGP SIGNATURE-----
    

12. hebasto approved
13. 
    hebasto commented at 6:28 pm on February 14, 2023: member

    ACK 6ada37d44cce7fa3a729de72cede4c1f3bc675ce, I’ve verified the history of laanwj’s merge commits.
14. fanquake merged this on Feb 15, 2023
15. fanquake closed this on Feb 15, 2023

    ---

16. 
    glozow commented at 2:53 pm on February 15, 2023: member

    post merge ACK 6ada37d44cce7fa3a729de72cede4c1f3bc675ce
17. bitcoin locked this on Feb 15, 2024

Contributors
achow101 DrahtBot Sjors maflcko fanquake hebasto glozow