Found it: I did not initialize gpgme_op_interact's last parameter out with gpgme_data_new. The error is now gone.

Since you are using C++, I suggest that you have a look at GpgSetOwnerTrustEditInteractor in the C++ bindings of gpgme. Have a look at QGpgMEChangeOwnerTrustJob in the Qt bindings of gpgme to see how it's used even if you do not want to use Qt.

Yes, kleo always maps '+' -> ' '

This looks like a missing escaping issue in the sender (scdaemon?) or an unwanted unescaping issue in the receiver of the string (which uses Kleo::hexdecode()).

Thanks

gpgme_key_t is a different kind of object than a gpgme_foo_result_t and thus has different properties.

Thanks!
I will study it soon.

Use the source! GnuPG is free software.

I tested the change of last_update after importing a same key with different content, but found that there is still no change.

On import. Please use gnupg-devel mailing list for further API questions. This is a bug tracker and not a help forum.

Nice. The way with KS_GET and assuan is much better then I thought about using a temporary home and a --locate-key

Also applied to gpgme.

For libgcrypt, it was fixed in: T5637: Use poll for libgcrypt (support more than 1024 fds)

The below change makes the function report a general error if gpgconf didn't write any output on stdout:

diff --git a/src/engine-gpgconf.c b/src/engine-gpgconf.c
index 28f91158..21211366 100644
--- a/src/engine-gpgconf.c
+++ b/src/engine-gpgconf.c
@@ -1245,6 +1245,13 @@ gpgconf_query_swdb (void *engine,
         }
     }

Hi, was there any update on this? I found the following bug [0] in libgcrypt, which we solved [1] with using poll ages ago.

Please see T5587

Please talk to the KDE folks who develop Craft. We do not support building anything with Craft. Check out gpg4win (https://dev.gnupg.org/source/gpg4win/) to see how we build our products on Windows.

Nevermind, I found the appropriate link above, thanks again.

Thanks for noticing me but I can't access your git repository at https://dev.gnupg.org/source/gnupg.git and the github mirror at https://github.com/gpg/gpgme is not up to date. Do you have an other mirror?

Thanks. This has already been fixed in July with rM4b64774b6d13ffa4f59dddf947a97d61bcfa2f2e

I filed a bug report to GCC, with modified test case.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102151

For GCC 11, modified version of struct arg_and_data_s has an issue for x86_64.

For the use case of struct arg_and_data_s in gpgme, which may allocate zero-sized ARG[], it seems that GCC 11 interprets it as an invalid use.

dlopen'ing of gpgme is NOT SUPPORTED. It is in general not a good idea to do this on standard Unix systems.

To extend on this: dlopen'ing of gpgme is NOT SUPPORTED. It is in general not a good idea to do this on standard Unix systems. On Windows we could make it work because DLLs on that platform are well designed and not a hack like the Unix shared objects.

We really want thunderbird users that interact with GPGME to have a great and stable user experience, but the problem with dynamic loading and self compiled versions is that we cannot really know the build settings and enviornment and it is very time consuming to reproduce that. GPGME does some very low level things for optimized IPC that can depend on build options etc. This is why I am mostly in favor that thunderbird ships a defined version that we can debug and see the settings.

Reading the mozilla entry more carefully, there still seems to be an issue.

https://blog.gerv.net/2012/01/mozilla-projects-and-gpled-code/

@kaie, thanks for the pointer!

In T5250#148131, @bernhard wrote:

BTW @kaie

Thunderbird cannot use anything requiring GPL in its default configuration, because Thunderbird wants to distribute a single MPL licensed package that includes all components that are required for OpenPGP.

Any pointer why, they have made that choice, though? A bundle of MPL and GNU GPL components is fully allowed by the licenses as far as I know.

Using GPGME is probably the best way, even if gpgme-json might also work for some operations.

This is a duplicate of T5522: gpgme: qt: t-various.cpp TestVarious::testSignKeyWithExpiration fails on 32 bit.

rM6a79e90dedc19877ae1c520fed875b57089a5425 looks good

Thanks for the reply, this source code file and suggestions are very useful. Let gpg execute commands is a solution, but it is not optimal compared to providing a functional interface.
In addition, it is reversible to revoke the subkey by expiring it. But I will use the solutions you provide at this stage, knowing that you have time to provide better solutions. thank you!

What do you mean by "exporting revocation certificates"? Once such a certificate is imported you simply export the public key including the revocation signature. Otherwise, simply takes the revocation certificates from ${GNUPGHOME}/openpgp-revocs.d where they are written to, if you generate a key. Kleopatra uses gpg directly to generate a revocation certificate mimicking what gpgme would do: See https://dev.gnupg.org/source/kleo/browse/master/src/commands/genrevokecommand.cpp.

Thanks for the report. Fixed.

Thanks for the report.