verify-commits: temporarily allow sha1 signatures for merge commits #34245

1. 
   darosior commented at 11:37 pm on January 9, 2026: member

   This is to unbreak CI after a merge commit (aeaa67a9eac0decb89c60a67f9755ca10cbcc1d9) with a signature indirectly involving SHA1 was pushed to master.
2. verify-commits: temporarily allow sha1 signatures for merge commits

   This is to unbreak CI after a merge commit with a signature indirectly involving SHA1 was pushed to master.

   12ffca9ccd
3. 
   DrahtBot commented at 11:37 pm on January 9, 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/34245.

   Reviews

   See the guideline for information on the review process. A summary of reviews will appear here.

4. 
   achow101 commented at 0:30 am on January 10, 2026: member

   I don’t think we should blanket allow sha1, even temporarily. Furthermore, this would still break anyone doing a full verify-commits to the trusted root.

   I’ve opened #34246 as an alternative to give an exception to the problematic commit.

5. 
   darosior commented at 0:39 am on January 10, 2026: member

   Your solution also looks good to me. I don’t think it matters too much: we’ll revert either in a week from now anyways.

   ——– Original Message ——– On Friday, 01/09/26 at 19:31 Ava Chow @.***> wrote:

   achow101 left a comment (bitcoin/bitcoin#34245)

   I don’t think we should blanket allow sha1, even temporarily. Furthermore, this would still break anyone doing a full verify-commits to the trusted root.

   I’ve opened #34246 as an alternative to give an exception to the problematic commit.

   — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: @.***>

6. 
   maflcko commented at 11:49 am on January 10, 2026: member

   Not sure about this. If this is only a temporary CI fix, to be reverted in a few days, then i’d say it isn’t needed and the CI can simply be ignored for those days (it only affects the main branch)

   My recommendation for a temporary workaround would be to just have another maintainer create a “re-merge” commit manually. That is, treat aeaa67a9eac0decb89c60a67f9755ca10cbcc1d9 as if it was a pull request, then merge it again into 595504a43209bead162da54a204df7d140a25f0e and push the new “re-merge” commit. Instead of a hard force push to re-write history, this will softly treat the failing merge commit no different than any other commit in any pull request, which may be signed, but is not checked by the verify script.

7. 
   fanquake commented at 3:33 pm on January 10, 2026: member

   Closing for now, given there doesn’t seem to be agreement on this approach.
8. fanquake closed this on Jan 10, 2026

   ---

Contributors
darosior DrahtBot achow101 maflcko fanquake