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

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.

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

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.

achow101 commented at 12: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.

darosior commented at 12: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: @.***>

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.

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.

fanquake closed this on Jan 10, 2026

sedited commented at 10:54 AM on January 16, 2026: contributor

I updated the key with refreshed base signatures. Seems to work for me locally again, but would be good if others checked too. I pushed the key to some common key servers.

hebasto commented at 11:51 AM on January 16, 2026: member

I updated the key with refreshed base signatures. Seems to work for me locally again, but would be good if others checked too. I pushed the key to some common key servers.

I can confirm that for the signing subkey with keyid: 9B79B45691DB4173, the previous signature packet using digest algo 2 (SHA-1) has been updated with the new signature packet using digest algo 10 (SHA-512):

$ gpg --refresh-keys --keyserver hkps://keys.openpgp.org
$ gpg --export A8FC55F3B04BA3146F3492E79303B33A305224CB | gpg --list-packets
# off=0 ctb=99 tag=6 hlen=3 plen=525
:public key packet:
	version 4, algo 1, created 1507239087, expires 0
	pkey[0]: [4096 bits]
	pkey[1]: [17 bits]
	keyid: 9303B33A305224CB
# off=528 ctb=b4 tag=13 hlen=2 plen=50
:user ID packet: "Sebastian Kung (TheCharlatan) <seb.kung@gmail.com>"
# off=580 ctb=89 tag=2 hlen=3 plen=569
:signature packet: algo 1, keyid 9303B33A305224CB
	version 4, created 1507239087, md5len 0, sigclass 0x13
	digest algo 2, begin of digest 75 22
	hashed subpkt 2 len 4 (sig created 2017-10-05)
	hashed subpkt 27 len 1 (key flags: 01)
	hashed subpkt 11 len 6 (pref-sym-algos: 9 8 7 3 2 1)
	hashed subpkt 21 len 5 (pref-hash-algos: 8 2 9 10 11)
	hashed subpkt 22 len 3 (pref-zip-algos: 2 3 1)
	hashed subpkt 30 len 1 (features: 01)
	hashed subpkt 23 len 1 (keyserver preferences: 80)
	subpkt 16 len 8 (issuer key ID 9303B33A305224CB)
	data: [4096 bits]
# off=1152 ctb=89 tag=2 hlen=3 plen=574
:signature packet: algo 1, keyid 9303B33A305224CB
	version 4, created 1513874756, md5len 0, sigclass 0x13
	digest algo 2, begin of digest 7a 44
	hashed subpkt 27 len 1 (key flags: 01)
	hashed subpkt 30 len 1 (features: 01)
	hashed subpkt 23 len 1 (keyserver preferences: 80)
	hashed subpkt 2 len 4 (sig created 2017-12-21)
	hashed subpkt 11 len 9 (pref-sym-algos: 9 13 8 12 7 11 10 3 2)
	hashed subpkt 21 len 6 (pref-hash-algos: 10 9 8 11 2 3)
	hashed subpkt 22 len 4 (pref-zip-algos: 2 3 1 0)
	subpkt 16 len 8 (issuer key ID 9303B33A305224CB)
	data: [4093 bits]
# off=1729 ctb=b4 tag=13 hlen=2 plen=28
:user ID packet: "sedited <seb.kung@gmail.com>"
# off=1759 ctb=89 tag=2 hlen=3 plen=596
:signature packet: algo 1, keyid 9303B33A305224CB
	version 4, created 1768501423, md5len 0, sigclass 0x13
	digest algo 10, begin of digest 4b 18
	hashed subpkt 27 len 1 (key flags: 01)
	hashed subpkt 11 len 4 (pref-sym-algos: 9 8 7 2)
	hashed subpkt 34 len 1 (pref-aead-algos: 2)
	hashed subpkt 21 len 5 (pref-hash-algos: 10 9 8 11 2)
	hashed subpkt 22 len 3 (pref-zip-algos: 2 3 1)
	hashed subpkt 30 len 1 (features: 07)
	hashed subpkt 23 len 1 (keyserver preferences: 80)
	hashed subpkt 33 len 21 (issuer fpr v4 A8FC55F3B04BA3146F3492E79303B33A305224CB)
	hashed subpkt 2 len 4 (sig created 2026-01-15)
	hashed subpkt 25 len 1 (primary user ID)
	subpkt 16 len 8 (issuer key ID 9303B33A305224CB)
	data: [4092 bits]
# off=2358 ctb=b9 tag=14 hlen=3 plen=525
:public sub key packet:
	version 4, algo 1, created 1507239607, expires 0
	pkey[0]: [4096 bits]
	pkey[1]: [17 bits]
	keyid: 9B79B45691DB4173
# off=2886 ctb=89 tag=2 hlen=3 plen=1115
:signature packet: algo 1, keyid 9303B33A305224CB
	version 4, created 1631953913, md5len 0, sigclass 0x18
	digest algo 8, begin of digest 8b c9
	hashed subpkt 27 len 1 (key flags: 02)
	hashed subpkt 33 len 21 (issuer fpr v4 A8FC55F3B04BA3146F3492E79303B33A305224CB)
	hashed subpkt 2 len 4 (sig created 2021-09-18)
	hashed subpkt 9 len 4 (key expires after 7y348d10h51m)
	subpkt 16 len 8 (issuer key ID 9303B33A305224CB)
	subpkt 32 len 540 (signature: v4, class 0x19, algo 1, digest algo 2)
	data: [4096 bits]
# off=4004 ctb=89 tag=2 hlen=3 plen=1129
:signature packet: algo 1, keyid 9303B33A305224CB
	version 4, created 1768556812, md5len 0, sigclass 0x18
	digest algo 10, begin of digest 69 ab
	hashed subpkt 27 len 2 (key flags: 02 04)
	hashed subpkt 33 len 21 (issuer fpr v4 A8FC55F3B04BA3146F3492E79303B33A305224CB)
	hashed subpkt 2 len 4 (sig created 2026-01-16)
	hashed subpkt 9 len 4 (key expires after 12y104d12h6m)
	subpkt 16 len 8 (issuer key ID 9303B33A305224CB)
	subpkt 32 len 553 (signature: v4, class 0x19, algo 1, digest algo 10)
	data: [4095 bits]
# off=5136 ctb=b9 tag=14 hlen=3 plen=525
:public sub key packet:
	version 4, algo 1, created 1507241023, expires 0
	pkey[0]: [4096 bits]
	pkey[1]: [17 bits]
	keyid: DAB71C6FBCD75257
# off=5664 ctb=89 tag=2 hlen=3 plen=572
:signature packet: algo 1, keyid 9303B33A305224CB
	version 4, created 1631953913, md5len 0, sigclass 0x18
	digest algo 8, begin of digest c8 28
	hashed subpkt 27 len 1 (key flags: 0C)
	hashed subpkt 33 len 21 (issuer fpr v4 A8FC55F3B04BA3146F3492E79303B33A305224CB)
	hashed subpkt 2 len 4 (sig created 2021-09-18)
	hashed subpkt 9 len 4 (key expires after 7y348d10h28m)
	subpkt 16 len 8 (issuer key ID 9303B33A305224CB)
	data: [4095 bits]
# off=6239 ctb=89 tag=2 hlen=3 plen=572
:signature packet: algo 1, keyid 9303B33A305224CB
	version 4, created 1768556781, md5len 0, sigclass 0x18
	digest algo 10, begin of digest 34 16
	hashed subpkt 27 len 1 (key flags: 0C)
	hashed subpkt 33 len 21 (issuer fpr v4 A8FC55F3B04BA3146F3492E79303B33A305224CB)
	hashed subpkt 2 len 4 (sig created 2026-01-16)
	hashed subpkt 9 len 4 (key expires after 12y104d11h42m)
	subpkt 16 len 8 (issuer key ID 9303B33A305224CB)
	data: [4095 bits]
# off=6814 ctb=b9 tag=14 hlen=3 plen=525
:public sub key packet:
	version 4, algo 1, created 1507241176, expires 0
	pkey[0]: [4096 bits]
	pkey[1]: [17 bits]
	keyid: 7651CCCB55BC4D56
# off=7342 ctb=89 tag=2 hlen=3 plen=572
:signature packet: algo 1, keyid 9303B33A305224CB
	version 4, created 1631953914, md5len 0, sigclass 0x18
	digest algo 8, begin of digest 90 8f
	hashed subpkt 27 len 1 (key flags: 20)
	hashed subpkt 33 len 21 (issuer fpr v4 A8FC55F3B04BA3146F3492E79303B33A305224CB)
	hashed subpkt 2 len 4 (sig created 2021-09-18)
	hashed subpkt 9 len 4 (key expires after 7y348d10h25m)
	subpkt 16 len 8 (issuer key ID 9303B33A305224CB)
	data: [4096 bits]
# off=7917 ctb=89 tag=2 hlen=3 plen=572
:signature packet: algo 1, keyid 9303B33A305224CB
	version 4, created 1768556801, md5len 0, sigclass 0x18
	digest algo 10, begin of digest dd 89
	hashed subpkt 27 len 1 (key flags: 20)
	hashed subpkt 33 len 21 (issuer fpr v4 A8FC55F3B04BA3146F3492E79303B33A305224CB)
	hashed subpkt 2 len 4 (sig created 2026-01-16)
	hashed subpkt 9 len 4 (key expires after 12y104d11h40m)
	subpkt 16 len 8 (issuer key ID 9303B33A305224CB)
	data: [4095 bits]

Additionally, I'd suggest testing the updated key by running contrib/verify-commits/verify-commits.py locally.