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:

There is a reason that we switched to ISO Date strings in large parts of GnuPG ;-)

@ikloecker Thank you. You're right. Please go ahead.

It seems that the case $libdir = '${exec_prefix}/lib64' is not handled correctly, i.e. I get

prefix=/usr
exec_prefix=${prefix}
includedir=${prefix}/include
libdir=${exec_prefix}/lib64
[...]
Libs: -L${libdir} -lgpg-error

in gpg-error.pc.

Note that gpgrt-config supports the PKG_CONFIG_PATH and PKG_CONFIG_LIBDIR environment variables.

It's in 1.18.0.

It's in 1.18.0.

Please note that with newer libgpg-error releases, you can safely not install or can safely remove installed gpg-error-config. For GnuPG and its friends (including gpgme), gpgrt-config with gpg-error.pc are used instead (when no gpg-error-config).

gpg-error-config (which is old shell script to offer functionality of pkg-config) gives -L/usr/lib64 when it is configured at the build time.
gpg-error-config hasn't got improved, but kept its behavior (for backward compatibility and lesser surprise), while we are moving to the support of gpg-error.pc (by pkg-config and/or gpgrt-config).

Maybe the solution would be to stop using gpg-error-config and start using pkgconfig instead?

$ pkgconf --libs gpg-error
-lgpg-error

Another problem seems to be that libtool/automake does not differentiate between library dependencies needed for building the library itself and library dependencies that should be exported to users of the library. There's just mylib_la_LIBADD for specifying the internal/private library dependencies and those also end up as dependencies in the .la file. Or maybe the dependencies in the .la file are used by the original libtool only for building static libraries and it's slibtool's fault to also copy the dependencies verbatim when building a shared library.

I have checked where -L/usr/lib64 comes from. Ultimately, it seems to come from gpg-error-config --libs which outputs -L/usr/lib64 -lgpg-error. I have no idea why gpg-error-config --libs adds the -L/usr/lib64, but this seems very dangerous to me and was bound to cause trouble because a -L applies to everything that follows and not just to the following -l.

One idea would be that gpgme installs its libraries in a directory like /usr/lib64/gpgme/, but that might be too disruptive?