--check-sig signature check inconsistent with "weak-digest SHA1"

I am getting contradictory answers from my gpg version 2.4.4 regarding self signatures of one of my local keys/identities when doing it with a) “gpg --check-sig” and b) “gpg --edit-key”, then “check” command.

Important note: I have defined SHA1 as “weak-digest” in my gpg.conf as recommended in this article:

weak-digest SHA1

a) Checking signatures with direct gpg call with command line arguments:

 bernd@arch:~ (0) $ gpg --check-sig 44************************************1C
 pub   rsa4096 2016-03-31 [SC]
      44************************************1C
 uid           [ unknown] Bernd <******@emaildomain.com>
 sig!3        D1************1C 2016-03-31  [self-signature]
 sub   rsa4096 2016-03-31 [E]
 sig!         D1************1C 2016-03-31  [self-signature]

 gpg: 2 good signatures

b) Checking signatures in interactive --edit-key session:

 bernd@arch:~ (0) $ gpg --edit-key 44************************************1C
 gpg (GnuPG) 2.4.4; Copyright (C) 2024 g10 Code GmbH
 This is free software: you are free to change and redistribute it.
 There is NO WARRANTY, to the extent permitted by law.

 gpg: Note: signatures using the SHA1 algorithm are rejected
 gpg: key D1************1C: 2 bad signatures
 gpg: key D1************1C: Warning: errors found and only checked self-signatures, run 'check' to check all signatures.
 Secret key is available.

 sec  rsa4096/D1************1C
      created: 2016-03-31  expires: never       usage: SC  
      trust: ultimate      validity: unknown
 ssb  rsa4096/B6************76
      created: 2016-03-31  expires: never       usage: E   
 [ unknown] (1). Bernd <******@emaildomain.com>

 gpg> check
 key D1************1C: 2 bad signatures

 gpg> 

So the contradiction is that a) results in “2 good signatures” while b) results in “2 bad signatures”. Is maybe the implementation of “gpg --check-sig” buggy, as it seems to ignore my “weak-digest SHA1” configuration setting?

Should I raise a bug report for this?

Hi Bernd,

yes, as inconsistency is a defect and this looks like one.
(Again note that self signatures on keys with SHA1 are not a security problem these days as far as I know. And third party signatures in SHA1 are already rejected according to GPG Esoteric Options (Using the GNU Privacy Guard))

You should try with 2.4.5 of GnuPG first. The NEWS as in [Announce] GnuPG 2.4.5 released do not list an improvement in this area, but there still could be one. If you can, trying the latest git main is also helpful (and might save you from writing a report for a thing that is already fixed).

Thanks for using and supporting GnuPG with your analyis!
Bernhard

Hi Bernd,

you don’t need to make a bug report, I was told it’s a feature :wink:

In your case checking signatures with --check-sig ignores the SHA1 signatures anyway, so it only reports the “good” signatures.

When you call gpg with --edit-key it will make a “clean run” and remove those SHA1 signatures, if you leave the gpg prompt after that with “save”. Then those signatures will be gone for good and you won’t get the message again when you edit the same key.

Please correct me if I’m wrong, I didn’t test it.

Hello eebb,

I’m afraid I cannot confirm your assumption. Doing “check” in “–edit-key” mode seems to not modify anything. When I try “save”, it tells me “Key not changed so no update needed”.

And I do all that stuff with version 2.4.5 already. Here is what I get:

bernd@arch:~ (0) $ gpg --version
gpg (GnuPG) 2.4.5
libgcrypt 1.10.3-unknown
Copyright (C) 2024 g10 Code GmbH
License GNU GPL-3.0-or-later <https://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Home: /home/bernd/.gnupg
Supported algorithms:
Pubkey: RSA, ELG, DSA, ECDH, ECDSA, EDDSA
Cipher: IDEA, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH, CAMELLIA128,
        CAMELLIA192, CAMELLIA256
Hash: SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224
Compression: Uncompressed, ZIP, ZLIB, BZIP2

bernd@arch:~ (0) $ gpg --check-sigs alex
gpg: checking the trustdb
gpg: public key of ultimately trusted key A16BB52C9F1D8A01 not found
gpg: public key of ultimately trusted key 46513893A18B6B58 not found
gpg: marginals needed: 3  completes needed: 1  trust model: pgp
gpg: Note: signatures using the SHA1 algorithm are rejected
gpg: depth: 0  valid:  10  signed:   0  trust: 0-, 0q, 0n, 0m, 0f, 10u
gpg: next trustdb check due at 2025-03-29
pub   rsa4096 2012-04-07 [SCEA]
      79151C2E6351E7278DA1A730BF38D4D02A328DFF
uid           [ unknown] Alexander Wolf <alex.v.wolf@gmail.com>
sig!3        BF38D4D02A328DFF 2012-04-07  [self-signature]
sub   rsa1024 2012-04-07 [SEA]
sig!         BF38D4D02A328DFF 2012-04-07  [self-signature]

gpg: 2 good signatures

bernd@arch:~ (2) $ gpg --edit-key alex
gpg (GnuPG) 2.4.5; Copyright (C) 2024 g10 Code GmbH
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

gpg: Note: signatures using the SHA1 algorithm are rejected
gpg: key BF38D4D02A328DFF: 2 bad signatures
gpg: key BF38D4D02A328DFF: Warning: errors found and only checked self-signatures, run 'check' to check all signatures.

pub  rsa4096/BF38D4D02A328DFF
     created: 2012-04-07  expires: never       usage: SCEA
     trust: unknown       validity: unknown
sub  rsa1024/9380E47C0374E169
     created: 2012-04-07  expires: never       usage: SEA 
[ unknown] (1). Alexander Wolf <alex.v.wolf@gmail.com>

gpg> check
key BF38D4D02A328DFF: 2 bad signatures

gpg> save
Key not changed so no update needed.

Seems you are now looking at a different key.

In case the SHA-1 signature is a backsig in the subkey key-binding self-signature, I dount that clean will work on this. The capabilities of the primary and subkey are anyway strange.