Fri, Jan 9
in Gpg4win-5.0.0-beta479
Wed, Jan 7
Traditionally we have considered expired and revoked more or less similar. The idea is that an expired key might have been compromised but the owner did not found a way to revoke it. We may want to change this policy because some users don't care too much about expired keys (cf. T7990) .
>gpgsm -v --sign --local-user "Edward Tester" test.pdf > test.gpg.p7s
gpgsm: enabled compatibility flags:
gpgsm: looking up issuer from the Dirmngr cache
gpgsm: number of matching certificates: 0
gpgsm: dirmngr cache-only key lookup failed: No data
gpgsm: issuer certificate {04A0A7E932B29D43A9B6673139AF52C0A5FC467BF5A64D044D1AC33613ABBB73CA532569F5779999114C0118CD66FDF6E92B1B0EEE2A4D5A815DA7FD892DDDE9C1} not found using authorityKeyIdentifier
gpgsm: looking up issuer from the Dirmngr cache
gpgsm: number of matching certificates: 0
gpgsm: dirmngr cache-only key lookup failed: No data
gpgsm: certificate is good
gpgsm: root certificate is not marked trusted
gpgsm: fingerprint=D4:EC:A6:B4:69:AB:B5:44:08:27:CB:3F:C7:D7:91:08:3C:10:27:DB
gpgsm: DBG: BEGIN Certificate 'issuer':
gpgsm: DBG: serial: 01
gpgsm: DBG: notBefore: 2020-03-26 19:41:01
gpgsm: DBG: notAfter: 2063-04-05 17:00:00
gpgsm: DBG: issuer: CN=Root-CA 2020,OU=GnuPG.com,O=g10 Code GmbH,C=DE
gpgsm: DBG: subject: CN=Root-CA 2020,OU=GnuPG.com,O=g10 Code GmbH,C=DE
gpgsm: DBG: hash algo: 1.2.840.113549.1.1.11
gpgsm: DBG: SHA1 Fingerprint: D4:EC:A6:B4:69:AB:B5:44:08:27:CB:3F:C7:D7:91:08:3C:10:27:DB
gpgsm: DBG: END Certificate
gpgsm: after checking the fingerprint, you may want to add it manually to the list of trusted certificates.
gpgsm: validation model used: shell
gpgsm: can't sign using 'Edward Tester': Not trusted
[GNUPG:] FAILURE gpgsm-exit 50331649How does gpgsm react if you try to sign with the certificate?
Tue, Jan 6
Maybe it would be better to just not offer S/MIME certs with distrusted root cert?
If all processes are killed before okular is opened, i get an error:
gpgsm.log (debug-all, whole process of signing)
Dec 12 2025
Nov 19 2025
Nov 16 2025
Fix applied. Thanks.
Nov 14 2025
Nov 6 2025
Oct 9 2025
Might this be related to T4953?
Oct 6 2025
(auto resolved due to the keyword "resolved" in the commit message)
The window was not reenabled on failure see 8d174d5
Oct 2 2025
(removed: wrong statement)
Note: I also activated Sign/Encrypt by default, if that matters
Sep 24 2025
ECC support for X.509 and in particular pkcs#12 format is limited. That is in general not a problem because such certificates are stored on a token and not on disk.
Aug 27 2025
The problem here is that we don't have the sha-2 fingerprint in our SQL tables. Thus we would not only need to do a full table search but also parse the actual blob to compute the sha-2 fingerprint.
I have done testing using my QES certificate with all combinations of the two options.
Jul 25 2025
Jul 24 2025
This does not happen with gnupg24 because the cache has not been implemented there.
Jul 2 2025
May 13 2025
Meanwhile we have some support for an empty subject but gpgsm still prints an error notice. See the T7171 for more.
Apr 22 2025
BTW, fingerprints for X.509 are not well defined because you get a different one when changing the *unsigned" attributes. Not a common case but one should be aware of it.

