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

gpg-error-config and its relatives (libassuan-config, included) were written before pkg-config. The support of cross build, multiarch, and multilib by those are quite limited (and sometimes wrong). Basically, those scripts are deprecated, but it has been kept for backward compatibility.

It seems the issue is also in libassuan-config.

$ libassuan-config --libs
-L/usr/lib64 -lassuan -lgpg-error

The shell logic here does not seem quite right to me.

Thanks for the report! Should be fixed.

Thanks for reporting and testing my fixes.

Our tests are fine as of rM2e7a61b898fc.

It will be a lot of work to change this in gpg. Thus ISO dates were only introduced with gpgsm after the former glibc maintainer refused to switch to a 64 bit time_t - which would have been easy enough at that time (about the year 2001).

Yes, it's a problem in gpg. gpg asks for the expiration date of the subkey

[  277s] EditInteractor: 4 -> nextState( GET_LINE, keygen.valid ) -> 5

gpgme replies with an ISO date

[  277s] EditInteractor: action result "21000101T120000"

Then gpg asks again for the expiration date

[  277s] EditInteractor: 5 -> nextState( GET_LINE, keygen.valid ) -> 4294967295

which gpgme doesn't expect, so that gpgme return a "general error".

Thanks! It seems that we pass the correct expiration date to gpg:

EditInteractor: action result "21000101T120000"

So, it's maybe a problem in gpg now.

Hmm. Please run the test with

GPGMEPP_INTERACTOR_DEBUG=stderr GPGME_DEBUG=8 TESTS="initial.test t-addexistingsubkey final.test" make -e check-TESTS

in lang/qt/tests under the build folder to get (a lot of) debug output.

WIP with those three patches: