contrib: Revert "verify-commits sha1 exceptions" #34318

pull maflcko wants to merge 2 commits into bitcoin:master from maflcko:2601-contrib-verify-commits changing 2 files +9 −19

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

contrib: Revert "verify-commits sha1 exceptions"

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

fab8bc0308

contrib: [refactor] Use shorter read_text from pathlib fa38ffac6f
DrahtBot added the label Scripts and tools on Jan 16, 2026
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 <code></code> into the comment that the bot should ignore.
sedited approved
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.
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?
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:
```
git -c gpg.program="$(pwd)/contrib/verify-commits/gpg.sh" verify-commit aeaa67a9eac0decb89c60a67f9755ca10cbcc1d9
```
hebasto approved
hebasto commented at 5:42 PM on January 16, 2026: member

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

utACK fa38ffac6ff560bf76a2bfa48a300a79d31ba466

Revert and refactor look clean to me
hebasto merged this on Jan 16, 2026
hebasto closed this on Jan 16, 2026
maflcko deleted the branch on Jan 19, 2026