Page MenuHome GnuPG

gpgmeProject
ActivePublic

Milestones

Details

Description

GnuPG Made Easy (GPGME) is a C language library that allows to add support for cryptography to a program. It is designed to make access to public key crypto engines like GnuPG or GpgSM easier for applications. GPGME provides a high-level crypto API for encryption, decryption, signing, signature verification and key management.

GPGME comes with language bindings for Common Lisp, C++, QT, Python2 and Python 3.

GPGME uses GnuPG and GpgSM as its backends to support OpenPGP and the Cryptographic Message Syntax (CMS).

Recent Activity

Mon, Jun 30

timegrid moved T6694: Random numbers from gpgme from Backlog to Done on the gpd5x board.

Ingo tested this and it worked.

Mon, Jun 30, 11:02 AM · gpd5x, gpgpass, gpgme, Feature Request

Thu, Jun 26

gniibe changed the status of T7696: POSIX: spawn fixes, a subtask of T7660: GPGME invocation by cri-o hangs on gpgme_op_verify, from Open to Testing.
Thu, Jun 26, 6:49 AM · golang, gpgme, Bug Report

Mon, Jun 23

gniibe changed the status of T7694: GPGME: gpgme_io_spawn issues from Open to Testing.

Done by: rM8caa7cc517eb: Use sysconf as a fallback mechanism in the initialization.

Mon, Jun 23, 7:17 AM · gpgme, Bug Report
gniibe changed the status of T7694: GPGME: gpgme_io_spawn issues, a subtask of T7660: GPGME invocation by cri-o hangs on gpgme_op_verify, from Open to Testing.
Mon, Jun 23, 7:17 AM · golang, gpgme, Bug Report

Fri, Jun 20

gniibe added a comment to T7694: GPGME: gpgme_io_spawn issues.

OK. I'll add a code for setting the fallback value in _gpgme_io_subsystem_init and use it from get_max_fds.

Fri, Jun 20, 10:35 AM · gpgme, Bug Report
werner added a comment to T7694: GPGME: gpgme_io_spawn issues.

iirc we introduced sysconf (_SC_OPEN_MAX) for non-linux platforms and that fixed real world problems. What about getting this value at module initialization time and keep on using it as a fallback?

Fri, Jun 20, 10:13 AM · gpgme, Bug Report
gniibe updated the task description for T7694: GPGME: gpgme_io_spawn issues.
Fri, Jun 20, 2:28 AM · gpgme, Bug Report
gniibe added a comment to T7660: GPGME invocation by cri-o hangs on gpgme_op_verify.

For issues of get_max_fds, I created a sub task, although it seems not the direct cause of this particular problem.

Fri, Jun 20, 2:13 AM · golang, gpgme, Bug Report
gniibe removed a project from T7694: GPGME: gpgme_io_spawn issues: golang.
Fri, Jun 20, 2:09 AM · gpgme, Bug Report
gniibe triaged T7694: GPGME: gpgme_io_spawn issues as Normal priority.
Fri, Jun 20, 2:07 AM · gpgme, Bug Report

Thu, Jun 19

gniibe added a comment to T7660: GPGME invocation by cri-o hangs on gpgme_op_verify.

I test following test program (gcc -o t-gmf t-gmf.c) on Debian machine of S390x.

Thu, Jun 19, 9:26 AM · golang, gpgme, Bug Report

Tue, Jun 17

gniibe added a comment to T7660: GPGME invocation by cri-o hangs on gpgme_op_verify.

In the log, we can observe duplicated lines generated by
https://dev.gnupg.org/source/gpgme/browse/master/src/posix-io.c$545
Example is like:

2025-05-19 20:16:35 gpgme[21970.55d7]   _gpgme_io_spawn: check: fd[0] = 0x1c -> 0x1
2025-05-19 20:16:35 gpgme[21970.55d7]   _gpgme_io_spawn: check: fd[0] = 0x1c -> 0x1
Tue, Jun 17, 10:01 AM · golang, gpgme, Bug Report

Jun 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).

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.

Jun 5 2025, 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).

Jun 5 2025, 12:14 PM · gnupg, Bug Report
Saturneric added a comment to T7673: Release GPGME 2.0.0.

We will keep the 1.24 branch for bug fixing. Do you really have a problem with gpgme 2.0? Ist that due to factoring out the c++ and qt bindings? That was actually a long standing request from the KDE community so that they can use their cmake stuff.

Jun 5 2025, 11:50 AM · Release Info, gpgme
werner added a comment to T7673: Release GPGME 2.0.0.

We will keep the 1.24 branch for bug fixing. Do you really have a problem with gpgme 2.0? Ist that due to factoring out the c++ and qt bindings? That was actually a long standing request from the KDE community so that they can use their cmake stuff.

Jun 5 2025, 11:37 AM · Release Info, gpgme
Saturneric added a comment to T7673: Release GPGME 2.0.0.

I'm wondering whether gpgme v1 will still be supported? Or it will be abandoned from now on.

Jun 5 2025, 10:37 AM · Release Info, gpgme

Jun 4 2025

sj98ta added a comment to T7660: GPGME invocation by cri-o hangs on gpgme_op_verify.

No other processes that I have seen. However please see this last update by Kulbarsch. https://github.com/cri-o/cri-o/issues/8906#issuecomment-2936351035

Jun 4 2025, 12:55 PM · golang, gpgme, Bug Report
gniibe added a comment to T7660: GPGME invocation by cri-o hangs on gpgme_op_verify.

@sj98ta
Does cri-o invokes processes (other than the ones of gpgme) by its threads?

Jun 4 2025, 2:07 AM · golang, gpgme, Bug Report

Jun 3 2025

werner closed T3325: Allow encryption/signing in GPGME using a specified subkey as Resolved.
Jun 3 2025, 5:29 PM · gpgme
sj98ta added a comment to T7660: GPGME invocation by cri-o hangs on gpgme_op_verify.

I am not sure that I am clear on what you are asking. I am not an expert on cri-o, but is does seem that there are multiple processes (threads), which all call gpgme_op_verify There are also calls to gpgme_op_import

Jun 3 2025, 3:59 PM · golang, gpgme, Bug Report
werner updated the task description for T7440: Release GPGME 1.24.1.
Jun 3 2025, 1:10 PM · gpgme, Release Info
werner triaged T7673: Release GPGME 2.0.0 as Normal priority.
Jun 3 2025, 1:09 PM · Release Info, gpgme
gniibe added a comment to T7660: GPGME invocation by cri-o hangs on gpgme_op_verify.

@sj98ta Please let us know if cri-o invokes other processes (except the ones by gpgme) or not.
If cri-o invokes other processes (by other threads), my theory matters; With the interference by other processes holding pipe file descriptors, gpgme keeps polling pipe file descriptors.

Jun 3 2025, 9:05 AM · golang, gpgme, Bug Report

Jun 2 2025

sj98ta added a comment to T7660: GPGME invocation by cri-o hangs on gpgme_op_verify.

I have now seen instances where 1, 2, or 3 processes hang.

Jun 2 2025, 5:31 PM · golang, gpgme, Bug Report

May 30 2025

werner added a comment to T7660: GPGME invocation by cri-o hangs on gpgme_op_verify.

Re: pipe2: In gpgme_io_pipe we set FD_CLOEXEC only for one end of the pipe. Thus simply using pipe2 would change the behaviour.

May 30 2025, 11:09 AM · golang, gpgme, Bug Report
gniibe added a comment to T7660: GPGME invocation by cri-o hangs on gpgme_op_verify.

Here is a hypothetical application which may have similar problem.
(1) It is a multi threaded application using gpgme, forking another process (possibly, exec).
(2) One of threads invokes gpgme_new, gpgme_op_import and gpg_op_verify.
(3) When the control goes to gpgme_op_* then gpgme_io_spawn by a thread A, another thread B forks a process.
(3-1) While the thread A is polling pipe I/O, forked process holds pipe file descriptors too.
(3-2) Until the forked process exists, pipe I/O polling by the thread A continues (because pipe's other end is still active).

May 30 2025, 7:06 AM · golang, gpgme, Bug Report
collinfunk added a comment to T7660: GPGME invocation by cri-o hangs on gpgme_op_verify.

There is FD_CLOFORK on Solaris 11.4 as well. It is a part of POSIX-1.2024, but who knows how long until that becomes common.

May 30 2025, 5:05 AM · golang, gpgme, Bug Report
gniibe added a comment to T7660: GPGME invocation by cri-o hangs on gpgme_op_verify.

I don't know if it is related to this particular case, but I found a possible race condition in _gpgme_io_pipe.
Between pipe and fcntl with FD_CLOEXEC, another thread may fork a process which keeps running.
It would be good to use pipe2 here:
https://pubs.opengroup.org/onlinepubs/9799919799/functions/pipe.html

May 30 2025, 4:46 AM · golang, gpgme, Bug Report

May 29 2025

gniibe added a comment to T7660: GPGME invocation by cri-o hangs on gpgme_op_verify.

Another possible cause is... gpgme uses closefrom in GNU C library, if available. if it doesn't work well, it would be possible invoked gpg keeps waiting its input.

May 29 2025, 11:02 AM · golang, gpgme, Bug Report
gniibe added a comment to T7660: GPGME invocation by cri-o hangs on gpgme_op_verify.

Here is my observation.

May 29 2025, 9:11 AM · golang, gpgme, Bug Report

May 28 2025

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).

May 28 2025, 9:19 PM · gnupg, Bug Report

May 27 2025

werner triaged T7660: GPGME invocation by cri-o hangs on gpgme_op_verify as Normal priority.
May 27 2025, 4:29 PM · golang, gpgme, Bug Report

May 23 2025

ebo moved T7600: Kleopatra: gpg.exe hangs on trying to exportably certify an already locally signed certificate with multiple UIDs from Restricted Project Column to Restricted Project Column on the Restricted Project board.
May 23 2025, 10:14 AM · Restricted Project, vsd33 (vsd-3.3.1), gpgme, gpd5x, kleopatra
ebo added a project to T7600: Kleopatra: gpg.exe hangs on trying to exportably certify an already locally signed certificate with multiple UIDs: Restricted Project.
May 23 2025, 10:13 AM · Restricted Project, vsd33 (vsd-3.3.1), gpgme, gpd5x, kleopatra

May 20 2025

timegrid moved T6907: gpgme: Explicitly tell gpg that we want to verify signed data from Restricted Project Column to Restricted Project Column on the Restricted Project board.

looks good to me on gpg4win-4.4.1-beta59@win10

May 20 2025, 12:07 PM · gpgme, Restricted Project
ebo added a comment to T7600: Kleopatra: gpg.exe hangs on trying to exportably certify an already locally signed certificate with multiple UIDs.

Checked with Gpg4win-4.4.1-beta59, too, which contains gpgme 1.24.3. Works!

May 20 2025, 11:10 AM · Restricted Project, vsd33 (vsd-3.3.1), gpgme, gpd5x, kleopatra
ebo closed T7524: Release GPGME 1.24.2 as Resolved.
May 20 2025, 9:32 AM · gpgme, Release Info

May 19 2025

werner closed T7659: Release GPGME 1.24.3 as Resolved.
May 19 2025, 4:43 PM · Release Info, gpgme
werner updated the task description for T7524: Release GPGME 1.24.2.
May 19 2025, 4:36 PM · gpgme, Release Info
werner added a comment to T7627: gpgme(qt) testsuite error on 32bit archs with 64bit time_t.

We won't apply any fixes to the cpp, QT, or Python language bindings in the 1.24 branch. The Qt branch has been factored out to the gpgmeqt project on request from the KDE folks. And yes, we should add projects (tags) for gpgmepp and gpgmeqt.

May 19 2025, 4:34 PM · gpgme, Bug Report
werner updated the task description for T7524: Release GPGME 1.24.2.
May 19 2025, 4:26 PM · gpgme, Release Info
werner triaged T7659: Release GPGME 1.24.3 as Low priority.
May 19 2025, 4:25 PM · Release Info, gpgme
ebo moved T6907: gpgme: Explicitly tell gpg that we want to verify signed data from Restricted Project Column to Restricted Project Column on the Restricted Project board.
May 19 2025, 11:48 AM · gpgme, Restricted Project
ebo moved T6688: Kleopatra GPGME: Reported assert on exit from Restricted Project Column to Restricted Project Column on the Restricted Project board.
May 19 2025, 11:47 AM · gpgme, kleopatra, Restricted Project

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

May 7 2025

ametzler1 added a comment to T7627: gpgme(qt) testsuite error on 32bit archs with 64bit time_t.

works for me, thanks

May 7 2025, 6:48 PM · gpgme, Bug Report

May 6 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).

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

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