Page MenuHome GnuPG

gnupgProject
ActivePublic

Milestones

Subprojects

Members

  • This project does not have any members.
  • View All

Details

Description

Bugs, feature requests, memos, and support related to GnuPG.

Note that the tags gnug24, gnupg26 etc are used to indicate that a certain task is scheduled to be fixed in that version. This tag here is used if there is no concrete version affected or a schedule has not yet been set.

Recent Activity

Thu, Jun 5

philiperm added a watcher for gnupg: philiperm.
Thu, Jun 5, 8:45 PM
ikloecker added a comment to T7620: gpgme_get_key fails to detect secret encryption subkey after key generation on card (until context is recreated).

In Kleopatra we explicitly trigger a re-reading of the smart card after each operation involving a smart card to ensure that Kleopatra doesn't show wrong information. There's so much that can go wrong with physical smart cards that this is the only way to make sure you don't tell the user lies. I think gpg --edit-card also re-reads the smart card after each operation.

Thu, Jun 5, 2:57 PM · gnupg, Bug Report
ikloecker removed a project from T7620: gpgme_get_key fails to detect secret encryption subkey after key generation on card (until context is recreated): gpgme.

There is no bug in the contexts and there's nothing to document anywhere. If anything then it's a bug in gpg's generate command or a more general issue (in gpg-agent) with keeping track of the storage location of private keys as I have already explained in T7620#200613. I'm removing the gpgme tag because there's nothing wrong in gpgme and there's nothing we can do in gpgme. It needs to be addressed in gnupg.

Thu, Jun 5, 2:45 PM · gnupg, Bug Report
Saturneric added a comment to T7620: gpgme_get_key fails to detect secret encryption subkey after key generation on card (until context is recreated).

In practice, calling gpgme_get_key() will often pick up most changes because GPGME asks the underlying GPG agent daemon, which may re-read the keyring. That gives the impression that a long-lived context automatically reflects live updates. However, as aheinecke noted, some updates can still go unnoticed in a single gpgme_ctx_t, so it isn’t a strictly frozen snapshot nor a perfectly live view—behaviors are mixed.

Thu, Jun 5, 12:33 PM · gnupg, Bug Report
Saturneric added a comment to T7620: gpgme_get_key fails to detect secret encryption subkey after key generation on card (until context is recreated).

Maybe we should make the documentation clearer about context key reuse. But the context is specifically designed to cache information about a key, so as to avoid memory overhead. I learned early on that its best for each new operation to use a new context. A context is basically an instance of gpg or gpgsm. So you start one process, ask it for a keylist, keep the process running, start another process, modify the key database, and then ask the first process again about his worldview. Either the first process is a bit confused because it has read data and then that data changed (what happens here) or it has no idea about the change since it was efficient and only read the database once. But here in this example you should be able to reproduce this also by making any other modifications to the key, adding other subkeys, userids etc. That GPGME even notices the secret key is more of a side effect of how the programming works because the GPGME gpg process will ask the gpg-agent (so a third process).

Thu, Jun 5, 12:14 PM · gnupg, Bug Report
gniibe added a comment to T7589: Unable to export SSH keys for ED25519 keys generate on a SmartCard.

The problem was: In scdaemon, PKSIGN with OPENPGP.3 didn't work well for Ed25519 (done by do_auth function in app-openpgp.c), when --hash=sha512 (not SHA1).

Thu, Jun 5, 2:52 AM · gnupg, ssh, Bug Report

Wed, Jun 4

gniibe changed the status of T7589: Unable to export SSH keys for ED25519 keys generate on a SmartCard from Open to Testing.

I located the bug in scdaemon.

Wed, Jun 4, 6:58 AM · gnupg, ssh, Bug Report

Tue, Jun 3

gniibe changed the status of T7668: gnupg: regexp and build with -fsanitize=address from Open to Testing.

Pushed the change: rG16ee68259d1d: gpg,regexp: Use -DREGEXP_PREFIX=gnupg_.

Tue, Jun 3, 4:42 AM · Bug Report, gnupg

Mon, Jun 2

werner updated the task description for T7586: Release GnuPG 2.5.6.
Mon, Jun 2, 6:09 PM · gnupg, Release Info
werner closed T7586: Release GnuPG 2.5.6 as Resolved.
Mon, Jun 2, 6:08 PM · gnupg, Release Info
werner updated the task description for T7671: Release GnuPG 2.5.7.
Mon, Jun 2, 6:08 PM · Release Info, gnupg
werner updated the task description for T7671: Release GnuPG 2.5.7.
Mon, Jun 2, 5:57 PM · Release Info, gnupg
werner triaged T7672: Release GnuPG 2.5.8 as Normal priority.
Mon, Jun 2, 5:50 PM · Release Info, gnupg
werner triaged T7671: Release GnuPG 2.5.7 as Normal priority.
Mon, Jun 2, 3:09 PM · Release Info, gnupg
gniibe added a project to T7664: tests/openpgp/ecc.scm fails when building GPG with address sanitizer: gnupg.
Mon, Jun 2, 6:39 AM · gnupg, Bug Report
gniibe claimed T7589: Unable to export SSH keys for ED25519 keys generate on a SmartCard.
Mon, Jun 2, 6:38 AM · gnupg, ssh, Bug Report

Sat, May 31

ametzler1 created T7670: updated nl.po for gnupg 2.4.
Sat, May 31, 3:29 PM · i18n, gnupg, Bug Report

Wed, May 28

aheinecke added a comment to T7620: gpgme_get_key fails to detect secret encryption subkey after key generation on card (until context is recreated).

I do not think that this is the only place where such an issue occurs. Maybe we should make the documentation clearer about context key reuse. But the context is specifically designed to cache information about a key, so as to avoid memory overhead. I learned early on that its best for each new operation to use a new context. A context is basically an instance of gpg or gpgsm. So you start one process, ask it for a keylist, keep the process running, start another process, modify the key database, and then ask the first process again about his worldview. Either the first process is a bit confused because it has read data and then that data changed (what happens here) or it has no idea about the change since it was efficient and only read the database once. But here in this example you should be able to reproduce this also by making any other modifications to the key, adding other subkeys, userids etc. That GPGME even notices the secret key is more of a side effect of how the programming works because the GPGME gpg process will ask the gpg-agent (so a third process).

Wed, May 28, 9:19 PM · gnupg, Bug Report
aheinecke added a comment to T7434: Kleopatra: Initial keylisting hangs for ~60 seconds (gpg-agent: Socket ...S.gpg-agent cannot be bound).

The more I think of this, the more likely this appears to me as the source for all that random startup weirdness of GnuPG. Say you are on a large keyring and on a train, then that keyring is first passed through your enterprise malware protection for scanning or something like that. Then it works again until some metric, hash or something else changes.

Wed, May 28, 8:37 PM · gnupg, kleopatra
aheinecke added a comment to T7434: Kleopatra: Initial keylisting hangs for ~60 seconds (gpg-agent: Socket ...S.gpg-agent cannot be bound).

My recommendation would at this point be to use procmon with a file filter for just "If path contains gnupg then include" I mean maybe go only for the locking dirs but this way you will not only see what the GnuPG processes are doing but what everyone on the system is doing to the locks. So you will see when my old friends, third party security software might interfere.
For example: You will see on a default Windows which files are checked through telemetry. And here in this example you see directly that the Microsoft Malware Protection Engine is accessing the agents socket.

Wed, May 28, 8:16 PM · gnupg, kleopatra

Fri, May 23

werner closed T7428: Release GnuPG 2.4.8 as Resolved.
Fri, May 23, 11:58 AM · gnupg, Release Info

Mon, May 19

chengr28 added a comment to T7577: GnuPG could not work when TCP congestion provider is set to BBR2 in Windows.

Spent some time discovering and unfortunately it's Windows's bug in loopback interface.
I wrote a test demo (blocking mode) to exchange data and watched their packets, found that network stack would drop packets when congestion control algorithm is set to BBR2. It seems the second data exchange was broken.

Mon, May 19, 3:20 PM · Support, Not A Bug, gnupg, Bug Report

May 16 2025

dkg added a comment to T5993: gpg should reject compressed packets outside of messages.

For example Poppler uses GnuPG comment packets to lower its own attack surface by leaving all OpenPGP handling to gpg. The patch (or at least the version we noticed in Fedora and Debian) entirely breaks this use.

May 16 2025, 4:12 PM · Feature Request, gnupg
werner closed T5993: gpg should reject compressed packets outside of messages as Resolved.
May 16 2025, 2:46 PM · Feature Request, gnupg
werner added a comment to T5993: gpg should reject compressed packets outside of messages.

(The commits had a wrong bug it in their message)

May 16 2025, 2:44 PM · Feature Request, gnupg
werner added a comment to T5993: gpg should reject compressed packets outside of messages.

It might be useful to have samples of compressed keys:

May 16 2025, 2:20 PM · Feature Request, gnupg
werner updated subscribers of T5993: gpg should reject compressed packets outside of messages.

No, we can't do much about this. It has always been easy to create compression bombs and the more relevant thing here is compressed signed or encrypted data. Or just compressed mails. The patch by @DemiMarie is way to complicated for what it wants to achieve and actually breaks existing use cases. For example Poppler uses GnuPG comment packets to lower its own attack surface by leaving all OpenPGP handling to gpg. The patch (or at least the version we noticed in Fedora and Debian) entirely breaks this use.

May 16 2025, 12:04 PM · Feature Request, gnupg

May 14 2025

werner added a comment to T7589: Unable to export SSH keys for ED25519 keys generate on a SmartCard.

Using the primary key for ssh was not intended and thus not tested. I have not yet found the time too look closer at your report. Just one remark:

May 14 2025, 12:32 PM · gnupg, ssh, Bug Report
werner added a project to T7589: Unable to export SSH keys for ED25519 keys generate on a SmartCard: gnupg.
May 14 2025, 12:07 PM · gnupg, ssh, Bug Report

May 13 2025

werner closed T7171: Allow for empty Subject in X.509 as Resolved.
May 13 2025, 3:21 PM · libksba, Bug Report, gnupg, S/MIME
werner closed T6941: gpgsm/dirmngr: support for end-entity certificates with an empty "Subject DN", a subtask of T7171: Allow for empty Subject in X.509, as Resolved.
May 13 2025, 3:00 PM · libksba, Bug Report, gnupg, S/MIME
werner added a subtask for T7171: Allow for empty Subject in X.509: T6941: gpgsm/dirmngr: support for end-entity certificates with an empty "Subject DN".
May 13 2025, 2:58 PM · libksba, Bug Report, gnupg, S/MIME

May 9 2025

werner set External Link to https://lists.gnupg.org/pipermail/gnupg-announce/2025q2/000492.html on T7586: Release GnuPG 2.5.6.
May 9 2025, 5:02 PM · gnupg, Release Info

May 8 2025

ikloecker added a comment to T7620: gpgme_get_key fails to detect secret encryption subkey after key generation on card (until context is recreated).

I think it would be much better if GnuPG automatically performed a key listing immediately after key generation when a smartcard is involved. This would allow GnuPG to detect the presence of the subkey on the card right away, rather than leaving it marked as a stub until the user manually lists keys.

May 8 2025, 9:14 PM · gnupg, Bug Report
Saturneric added a comment to T7620: gpgme_get_key fails to detect secret encryption subkey after key generation on card (until context is recreated).

I see that you generated the secret encryption subkey with backup. This means that the secret subkey is generated on your computer, then copied to the card, and then deleted from your computer. The deletion is the reason why the subkey is marked as stub. Only after listing the keys on the card gpg notices that the secret key is actually on the card.

May 8 2025, 6:37 PM · gnupg, Bug Report
werner updated the task description for T7586: Release GnuPG 2.5.6.
May 8 2025, 3:43 PM · gnupg, Release Info
werner closed T7632: gnupg test suite fails to build on AIX. as Resolved.
May 8 2025, 3:32 PM · AIX, gnupg, Bug Report
werner closed T7638: gpg on Solaris does not print a signal description as Resolved.
May 8 2025, 3:32 PM · Solaris, gnupg, Bug Report
werner closed T7576: keyboxd: Searching <email@Example.COM> as Resolved.
May 8 2025, 3:31 PM · gnupg, Bug Report
werner closed T7583: 2.5.5 removes sig on clean that 2.5.4 and earlier kept as Resolved.
May 8 2025, 3:30 PM · gnupg, Bug Report
werner closed T7547: signatures from revoked or expired keys show up as missing keys, a subtask of T7527: Keyring/keybox denial of service, as Resolved.
May 8 2025, 3:29 PM · OpenPGP, gnupg, Bug Report
werner updated the task description for T7586: Release GnuPG 2.5.6.
May 8 2025, 3:29 PM · gnupg, Release Info

May 7 2025

dkg added a comment to T7583: 2.5.5 removes sig on clean that 2.5.4 and earlier kept.

btw, my clue was that in that last --check-sigs, if i used --debug-all i got this:

May 7 2025, 10:35 PM · gnupg, Bug Report
dkg added a comment to T7583: 2.5.5 removes sig on clean that 2.5.4 and earlier kept.

This affects certification-only primary keys when doing web-of-trust calculations.

May 7 2025, 9:46 PM · gnupg, Bug Report
collinfunk added a comment to T7638: gpg on Solaris does not print a signal description.

Hi Werner, I submitted a patch right after this bug report using AC_CHECK_DECLS([_sys_siglist]) [1].

May 7 2025, 3:03 AM · Solaris, gnupg, Bug Report

May 6 2025

dkg added a comment to T7611: WoT: adding a marginal trustsig reduces the validity of a downstream certificate.

To avoid further noise on this ticket, i've done as requested and posted to gnupg-devel : https://lists.gnupg.org/pipermail/gnupg-devel/2025-May/035875.html

May 6 2025, 10:26 PM · Not A Bug, gnupg
ikloecker added a comment to T7620: gpgme_get_key fails to detect secret encryption subkey after key generation on card (until context is recreated).

The first call of get_key receives the following key listing from gpg:

2025-05-05 21:50:23 gpgme[57059]     _gpgme_io_read: check: sec:-:256:19:C4A24EB0B5F2E025:1746474606:::u:::s
2025-05-05 21:50:23 gpgme[57059]     _gpgme_io_read: check: cESCA:::D2760001240100000006180489130000::brainp
2025-05-05 21:50:23 gpgme[57059]     _gpgme_io_read: check: oolP256r1:23::0:<LF>
2025-05-05 21:50:23 gpgme[57059]     _gpgme_io_read: check: fpr:::::::::DEC0948C398A6E7B50746EC6C4A24EB0B5F2
2025-05-05 21:50:23 gpgme[57059]     _gpgme_io_read: check: E025:<LF>
2025-05-05 21:50:23 gpgme[57059]     _gpgme_io_read: check: grp:::::::::06BDACFBDEDBC5783A75AE5E7251FA3369C4
2025-05-05 21:50:23 gpgme[57059]     _gpgme_io_read: check: 0FF4:<LF>
2025-05-05 21:50:23 gpgme[57059]     _gpgme_io_read: check: uid:-::::1746474606::2222D8E2F373B9BDEE0DEA2A20A
2025-05-05 21:50:23 gpgme[57059]     _gpgme_io_read: check: 9402214E9F984::Eric <eric@bktus.com>::::::::::0:
2025-05-05 21:50:23 gpgme[57059]     _gpgme_io_read: check: <LF>
2025-05-05 21:50:23 gpgme[57059]     _gpgme_io_read: check: ssb:-:256:19:EAFC5EA29B758B22:1746474606::::::a:
2025-05-05 21:50:23 gpgme[57059]     _gpgme_io_read: check: ::D2760001240100000006180489130000::brainpoolP25
2025-05-05 21:50:23 gpgme[57059]     _gpgme_io_read: check: 6r1:23:<LF>
2025-05-05 21:50:23 gpgme[57059]     _gpgme_io_read: check: fpr:::::::::1AD596DDEC9B8CF3C1AC6C41EAFC5EA29B75
2025-05-05 21:50:23 gpgme[57059]     _gpgme_io_read: check: 8B22:<LF>
2025-05-05 21:50:23 gpgme[57059]     _gpgme_io_read: check: grp:::::::::52F0797C0B0439BBD718E2534D46656A6C45
2025-05-05 21:50:23 gpgme[57059]     _gpgme_io_read: check: 6A78:<LF>
2025-05-05 21:50:23 gpgme[57059]     _gpgme_io_read: check: ssb:-:256:18:A874804DB497B91C:1746474606::::::e:
2025-05-05 21:50:23 gpgme[57059]     _gpgme_io_read: check: ::#::brainpoolP256r1:23:<LF>
2025-05-05 21:50:23 gpgme[57059]     _gpgme_io_read: check: fpr:::::::::33B273C7BD46E4EB63DD6874A874804DB497
2025-05-05 21:50:23 gpgme[57059]     _gpgme_io_read: check: B91C:<LF>
2025-05-05 21:50:23 gpgme[57059]     _gpgme_io_read: check: grp:::::::::34A1F8D9B2AA0CF07C2E042D70E10F9D4EBE
2025-05-05 21:50:23 gpgme[57059]     _gpgme_io_read: check: E734:<LF>

Note the line

ssb:-:256:18:A874804DB497B91C:1746474606::::::e:::#::brainpoolP256r1:23:<LF>

where the # marks the subkey as stub.

May 6 2025, 9:21 AM · gnupg, Bug Report
werner added a comment to T7638: gpg on Solaris does not print a signal description.

Right now we have

May 6 2025, 8:32 AM · Solaris, gnupg, Bug Report
collinfunk added a comment to T7638: gpg on Solaris does not print a signal description.

Interesting, that sounds like a portable method. I am not very familiar with GPG internals, but to me that sounds like quite a bit of work. Unless there is another benefit to doing so, I don't think it is worth it just to print signal names.

May 6 2025, 4:26 AM · Solaris, gnupg, Bug Report

May 5 2025

Saturneric added a comment to T7620: gpgme_get_key fails to detect secret encryption subkey after key generation on card (until context is recreated).

I have now identified the exact conditions and a reproducible path for the issue I previously reported. I will also attach the relevant gpgme.log.

May 5 2025, 10:01 PM · gnupg, Bug Report