We have discussed this and what we think would be the best solution would be to have an extension in the engine-gpg of GpgME either through a flag or through a new API to use gpgtar directly with --encrypt and decrypt. This should behave exactly like the gpg encrypt / decrypt / verify functions but would avoid the need of Piping in Kleopatra. It is a fairly recent development that gpgtar can do the crypto operations by itself so this is why this was not done initially.

@justus: Please talk to @kuwv on how to transfer the package to him.

I do not consider the whole PyPi thing a secure solution and thus we do not want to engage us there. However, if you need small patches to GPGME, please go ahead post them to the ML or upload them here.

For testing I have created a Gpg4win installer and only selected minimal installation and gpgme-json was there. Both in /bin and /bin_64.

works: the process is canceled without any notification.

The problem with expired keys may still happen for GpgSignKeyEditInteractor, but Kleopatra doesn't allow certifying expired keys or user IDs. Therefore, I don't look into this.

OK I can confirm that with ae9258fb and f1802682 commits I was ble to update my rpm packages to 1.18.0.

In T6305#165907, @ebo wrote:

With GnuPG VSD 3.1.25 the Certify action is not disabled for me. Neither on Windows nor on Linux system.

With GnuPG VSD 3.1.25 the Certify action is not disabled for me. Neither on Windows nor on Linux system.

How did you manage to certify an expired key? For me the Certify action is always disabled for an expired key or user ID.

Ok. So after further discussion. It is good that you kept a WKDRefreshJob copy :)

In T6285#165459, @gniibe wrote:

Now, the use of AM_PATH_GPGME_PTHREAD shows warning. Also I update the documentation.

Now, the use of AM_PATH_GPGME_PTHREAD shows warning. Also I update the documentation.

Thank you for the bug report and your suggestion.

Actually we have two gpgme versions in gpg4win because gnupg is a "sub"-installer inside of gpg4win and it comes with its own gpgme. That gpgme is the release version but the one used by gpg4win's kleopatra is often a newer snapshot.

thank you, works for me.

Thank you, looks good to me.

Please use gpgme.pc to configure your build. Your options are:
(1) With Autoconf:
(1-1) Use pkg.m4 and PKG_CHECK_MODULES (which uses pkg-config to access gpgme.pc)
(1-2) Use gpgme.m4 and AM_PATH_GPGME (which uses gpgrt-config to access gpgme.pc)
(2) Or... use pkg-config to access gpgme.pc.

I updated gpgme.m4 to include configuration of GPGRT_CONFIG.
Using this new gpgme.m4, it should work.
Using this new gpgme.m4 plus old gpg-error.m4, checking GPGRT_CONFIG is duplicated.
Using this new gpgme.m4 plus new gpg-error.me, no problem.

I overlooked the use case of gpgme programming not using libgpg-error. This use case should be supported.

ready for testing

Note the relationship to T4195, T4826, and T4766

In QGPGME which is used by GpgOL and Kleopatra we have solved this by loading the configuration only once and then reusing it. I see no need to change something in gpgconf here.

@gniibe - Thanks for the quick response. It now works for me.
cu Andreas

@ametzler1 Thank you. That was because of my bad fix.
Fixed in rMf1802682c3c8: python: Fix configure generating setup.py.

the pushed fix breaks when libgpg-error does not require special CFLAGS, i.e. when @GPG_ERROR_CFLAGS@ expands to an empty string:

FWIW: I am not anymore very convinced of our tofu code. it leaks too many information because it tracks and stored all signature verification. The model is further way too complicated and the SQL used will eventually lead to a resource problem. Maybe doing Tofu stuff in the frontend is a better idea and get rid of all the history processing which works only for fresh mails and not for data verification.

Yes it is set to tofu+pgp. Is it now possible to change the trust-model on context based?

Thanks for the report, since you are using it on the command line and it works I assume that trust-model is set to tofu+pgp? Because in the Test code there is no context flag for tofu+pgp trust model.

Thanks for the report, since you are using it on the command line and it works I assume that trust-model is set to tofu+pgp? Because in the Test code there is no context flag for tofu+pgp trust model.

Let's don't forget that we need to have a sig_class replacement.

This is not easy to fix because it would break the GPGME API. Here
are the values we can expect:

I assume this is gpgme master. Please write proper bug reports.

Pushed the fix.
Note that non-in-tree build never been reliable (using the result of the configure, in tree).
So, I basically don't consider the use case of non-in-tree build.

Reviewing the build process, it's just better to use @...VAR...@ by configure (instead of invoke pkg-config again in setup.py).

The export/backup of the secret part of S/MIME certificates has been fixed with T6189: Secret key backup of S/MIME certificate creates bad result. An exported certificate should now be imported without problems.

Now "BER error" is reported, if the user tries to import a .p8 certificate. (The certificate exported by Kleopatra wasn't stored as PKCS#12, but presumably as PKCS#8 which gpgsm cannot import. See T6189: Secret key backup of S/MIME certificate creates bad result.)

BTW, gnupg/doc/DETAILS tells that the fingerprint is optional:

Pushed the fix for GPG_ERR_INV_ENGINE.

gpgsm may emit S IMPORT_PROBLEM 1 (with no fingerprint information) when it cannot find valid fingerprint.
I think that this case should be handled correctly by GPGME, not returning GPG_ERR_INV_ENGINE.

Ok. That is about the Invalid Crypto Engine. But this does not explain why a .p12 export via Kleopatra leads to this error when we export a valid certificate. The same thing I do with Kleopatra on the Command Line works:

The error is generated in parse_import in gpgme/src/import.c:

if (errno || args == tail || *tail != ' ')
  {
    /* The crypto backend does not behave.  */
    free (import);
    return trace_gpg_error (GPG_ERR_INV_ENGINE);
  }

Thanks, I really appreciate having this fixed in gpgrt-config! I backported the commit to gentoo and can confirm that fixes the build issue with slibtool.

GnuPG requires threads but not gpgme.
We already had the same discussion about threads and libgpg-error more than one year ago: https://dev.gnupg.org/T5296

Thank you for your report. Next time, please include information of your target and configuration in the report.

I pushed the changes. It also cares about the case for --cflags.

@orbea Thank you for your suggestions.

For the original issue I'd prefer to silence the error/warning with -Wno-narrowing because I think it's a non-issue. Or does changing the enum declarations to enum : unsigned int make clang happy?

For gpgme (as for the other GnuPG libraries) we use the good old mailing list based process for contributing patches. See doc/HACKING for details. In particular, we'll need a signed DCO from you.

Yes, this is with Clang. I am working on getting it to compile on Windows with clang-cl, using vcpkg, with success. I have several patches to fix the issues that clang detected, and so I wonder if I should create a Task to discuss them all?

g++: error: unrecognized command-line option '-Wc++11-narrowing'; did you mean '-Wno-narrowing'?

How did you get this error? I don't even see a warning for this when building gpgme with g++ (SUSE Linux) 12.1.1 20220812.

In T6136#161943, @ikloecker wrote:

This looks like a good approach, but I think stripping the standard paths needs to be deferred until later, because, if PKG_CONFIG_SYSROOT_DIR is set, then the library search paths are prefixed with $PKG_CONFIG_SYSROOT_DIR, and then the prefixed standard paths probably shouldn't be stripped.

Original pkg-config supports PKG_CONFIG_SYSTEM_LIBRARY_PATH (default is determined by build time, and overridden by environment var), PKG_CONFIG_SYSTEM_INCLUDE_PATH as well.

In T6136#161915, @orbea wrote:

Or maybe it would be better to only check the standard libdir paths as in the libgpg-error configure.ac?

--- gpgrt-config.orig	2022-08-21 23:14:40.017298485 -0700
+++ gpgrt-config	2022-08-22 08:28:16.339977281 -0700
@@ -210,6 +210,7 @@
     # the resulted list is in reverse order
     for __arg; do
 	case "$__arg" in
+	    -L/usr/lib|-L/usr/lib64|-L/lib|-L/lib64) ;;
 	    -l*)
 		# As-is
 		__rev_list="$__arg${__rev_list:+ }$__rev_list"

Hmm. Good point. Always adding -L${libdir} makes the .pc files easier to relocate.

Actually, there's plenty more locations where unistd.h is included unconditionally, all of which should likely embrace in guards like this.

The -L${libdir} is standard in nearly all applicable .pc files on my system. In the case of pkgconf the -L linker path is removed from the output if its the standard linker path. Of course however you think its best to fix this would be fine though.

Why should gpgrt-config change the information read from the *.pc files?

Or maybe it would be better to only check the standard libdir paths as in the libgpg-error configure.ac?

--- gpgrt-config.orig	2022-08-21 23:14:40.017298485 -0700
+++ gpgrt-config	2022-08-22 08:28:16.339977281 -0700
@@ -210,6 +210,7 @@
     # the resulted list is in reverse order
     for __arg; do
 	case "$__arg" in
+	    -L/usr/lib|-L/usr/lib64|-L/lib|-L/lib64) ;;
 	    -l*)
 		# As-is
 		__rev_list="$__arg${__rev_list:+ }$__rev_list"

Thanks. QGpgME should now also compile with strict C++11. And C++14'isms shouldn't happen again unnoticed.

This was apparently discussed before:
https://www.mail-archive.com/ports@openbsd.org/msg105601.html

Also in:

I suggest simply removing any -L linker path from the output if it matches the $libdir in gpgrt-config.

Even without libassuan-config installed in libassuan-2.5.5.

$ gpgrt-config --libdir=/usr/lib64 libassuan --libs
-L/usr/lib64 -lassuan

gpg-error is not affected at least.

 gpgrt-config --libdir=/usr/lib64 gpg-error --libs
-lgpg-error

In lang/qt/tests/Makefile:

LIBASSUAN_CONFIG = /usr/bin/gpgrt-config --libdir=/usr/lib64 libassuan
LIBASSUAN_LIBS = -L/usr/lib64 -lassuan