contrib: Revert “verify-commits sha1 exceptions” #34318

1. 
   maflcko commented at 1:49 pm on January 16, 2026: member

   This reverts commit 8ac134be5e57680eb1c6ef596e5de085825e83ee, because it is no longer needed.

   See #34245 (comment)

   Also, use the shorter pathlib read_text, which is available since Python 3.5

2. contrib: Revert "verify-commits sha1 exceptions"

   This reverts commit 8ac134be5e57680eb1c6ef596e5de085825e83ee, because it
   is no longer needed.

   fab8bc0308
3. contrib: [refactor] Use shorter read_text from pathlib fa38ffac6f
4. DrahtBot added the label Scripts and tools on Jan 16, 2026
5. 
   DrahtBot commented at 1:49 pm on January 16, 2026: contributor

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

   Code Coverage & Benchmarks

   For details see: https://corecheck.dev/bitcoin/bitcoin/pulls/34318.

   Reviews

   See the guideline for information on the review process.

   Type	Reviewers
   ACK	sedited, hebasto, dergoegge

   If your review is incorrectly listed, please copy-paste <!–meta-tag:bot-skip–> into the comment that the bot should ignore.

6. sedited approved
7. 
   sedited commented at 5:14 pm on January 16, 2026: contributor

   ACK fa38ffac6ff560bf76a2bfa48a300a79d31ba466

   If anybody is interested, the problem with the key was indeed that the so-called “backsig” on one of the subkeys was using sha-1. From what I learned it seems that a backsig is only generated once on creation, while a fresh “binding signature” is generated every time an expiry is bumped, or a preference changed. So even if a good binding signature using a strong hash algorithm is present, verification may fail with an old backsig. To solve this, I re-generated the subkey with the existing key material and a faked creation time.

8. 
   l0rinc commented at 5:30 pm on January 16, 2026: contributor

   Can we add a pre-merge check for this to avoid it next time?
9. 
   hebasto commented at 5:40 pm on January 16, 2026: member

   ACK fa38ffa

   If anybody is interested, the problem with the key was indeed that the so-called “backsig” on one of the subkeys was using sha-1. From what I learned it seems that a backsig is only generated once on creation, while a fresh “binding signature” is generated every time an expiry is bumped, or a preference changed. So even if a good binding signature using a strong hash algorithm is present, verification may fail with an old backsig. To solve this, I re-generated the subkey with the existing key material and a faked creation time.

   The following passes on my machine:

   0git -c gpg.program="$(pwd)/contrib/verify-commits/gpg.sh" verify-commit aeaa67a9eac0decb89c60a67f9755ca10cbcc1d9
   

10. hebasto approved
11. 
    hebasto commented at 5:42 pm on January 16, 2026: member

    ACK fa38ffac6ff560bf76a2bfa48a300a79d31ba466.
12. 
    dergoegge commented at 6:00 pm on January 16, 2026: member

    utACK fa38ffac6ff560bf76a2bfa48a300a79d31ba466

    Revert and refactor look clean to me

13. hebasto merged this on Jan 16, 2026
14. hebasto closed this on Jan 16, 2026

    ---

15. maflcko deleted the branch on Jan 19, 2026

Contributors
maflcko DrahtBot sedited l0rinc hebasto dergoegge

Labels
Scripts and tools