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.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Aug 24 2022
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.
Aug 23 2022
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"
Aug 22 2022
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.
Aug 19 2022
Thanks for the report! Should be fixed.
Thanks for reporting and testing my fixes.
Aug 18 2022
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".
Aug 17 2022
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.
[ 274s] + pushd lang/qt/tests
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.
Aug 16 2022
Aug 15 2022
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).
Aug 14 2022
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.
Aug 13 2022
One idea would be that gpgme installs its libraries in a directory like /usr/lib64/gpgme/, but that might be too disruptive?
Yes, you are correct.
[pid 1252] rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0 [pid 1252] access("../../cpp/src/.libs/libqgpgme.so", F_OK) = -1 ENOENT (No such file or directory) [pid 1252] access("../../cpp/src/.libs/libqgpgme.a", F_OK) = -1 ENOENT (No such file or directory) [pid 1252] access("../../cpp/src/../../../src/.libs/libqgpgme.so", F_OK) = -1 ENOENT (No such file or directory) [pid 1252] access("../../cpp/src/../../../src/.libs/libqgpgme.a", F_OK) = -1 ENOENT (No such file or directory) [pid 1252] access("/usr/lib64/libqgpgme.so", F_OK) = 0 [pid 1252] openat(AT_FDCWD, "/usr/lib64/libqgpgme.so", O_RDONLY|O_CLOEXEC) = 3 [pid 1252] newfstatat(3, "", {st_mode=S_IFREG|0755, st_size=1253896, ...}, AT_EMPTY_PATH) = 0 [pid 1252] mmap(NULL, 1253896, PROT_READ, MAP_PRIVATE|MAP_NORESERVE, 3, 0) = 0x7fe6f6ffa000 [pid 1252] rt_sigprocmask(SIG_SETMASK, ~[RTMIN RT_1], [], 8) = 0 [pid 1252] close(3) = 0
As it shows it checks the linker path in the order they are passed to the compiler and then finds the old system library before the newly built library. GNU libtool also sets the /usr/lib64 path before the using libqgpgme library, but avoids this by using the .so file directly. Presumably this is only on compatible platforms and maybe even a problem on less compatible platforms? I'm not sure the ramifications of slibtool trying to reorder the library paths itself. Hopefully the slibtool dev has some time to also share their thought soon.
You probably have to call strace with -f, so that processes started by clang are also straced.
I attached the strace log of the failing clang command, but I am not seeing anywhere where it finds libqgpgme on the system, Maybe I'm doing something wrong?
Your observations seem to confirm that the linking picks up the old 1.17.1 version of libqgpgme instead of the newly built one. You could use strace to dispel last doubts. In any case this very much looks like a problem in slibtool.
In retrospect this might be better handled in slibtool itself. I'll try to contact the main dev behind the slibtool project, but they have been very busy lately so it might take some time.
Additionally, moving the -L../src/.libs -lqgpgme earlier in the command line works.
clang++ t-revokekey.o t-support.o -g -O2 -L../../cpp/src/.libs -lgpgmepp -L../../cpp/src/../../../src/.libs -lgpgme -L../src/.libs -lqgpgme -L/usr/lib64 -lassuan -lgpg-error -lassuan -L../src/../../cpp/src/.libs -lgpgmepp -L../src/../../cpp/src/../../../src/.libs -lgpgme -lassuan -lgpg-error -L../src/../../../src/.libs -lQt5Core -L../../../src/.libs -lgpgme -lassuan -lgpg-error -lQt5Test -lQt5Core -lstdc++ -o .libs/t-revokekey
After some experimenting I found how GNU libtool avoids this.
Another interesting detail is that this is reproduced when trying to update to 1.18.0 from 1.17.1 which is installed on the system, but if 1.17.1 is built without qt5 support and 1.18.0 is then this issue is not reproducible.
revokekeyjob.moc is included by job.cpp (as many other *job.moc files). The missing symbols should be available in the built libqgpgme.so
Aug 12 2022
Hmm. There is a -L/usr/lib64 before -L../src/.libs. I guess this causes problems if there is a /usr/lib64/libqgpgme.la because this will be found before the newly built libqgpgme.la in the build directory.
Aug 10 2022
Aug 9 2022
Indeed, you are right. The object created by with can be valid even after the context (when referenced by another object).
Aug 8 2022
Not sure if that is the complete fix - if you do something like:
with gpg.Context(...) as context: ... ... cause an exception after the context has been closed ...
then context will still be a valid reference to the gpg.Context instance, and may cause segfaults when something tries to access things inside it (f.e. for serialisation).
I like your previous solution with the accessor checks, because that actually fixes the issue.
Stylistically, maybe __del__ should just be renamed to cleanup or free, and then make sure to call that function from both __exit__ and __del__.
I think the fix should be something like this:
diff --git a/lang/python/src/core.py b/lang/python/src/core.py index 81f961d9..95fd0cba 100644 --- a/lang/python/src/core.py +++ b/lang/python/src/core.py @@ -1189,8 +1189,9 @@ class Context(GpgmeWrapper): def __enter__(self): return self
@jap Thank you.
Can confirm, we've been running into this as well, but never filed a bug report. Our solution is to have this in our codebase:
Aug 5 2022
The SEGV was due to access to gpgme library after self.wrapped is set to None in the __del__ function.
The commit is: rMb2f224a471fe: python: Reset passphrase callback correctly..
Thank you for the patch. You are right.
Aug 4 2022
I have kept a backup copy of a WKDRefreshJob locally. ;-) But that's stuff for a different task.
Thanks, the update button this is now more what I think is expected. Still I am not sure if removing it completely was neccessary, well we have it in the history now. Because I see the need to also update via WKD. Currently we only update from there if a key is expired but we would never see revocations. That is a problem that we will need some solution for at some point. But yeah in that case calling it "RefreshOpenPGPKeysJob" would be a misleading API Name anyhow. So its probably good that you removed it before the upcoming release.
See T5903: Kleopatra: Add refresh button in certificatedetails for the corresponding Kleopatra task. Kleopatra now uses the good old ReceiveKeysJob for doing a key refresh from the configured key server. The RefreshOpenPGPKeysJob has been removed.
Aug 3 2022
I thought "Update" would do a key server refresh by fingerprint. Maybe I looked at the wrong job? In testing we noticed this because we suddenly had additional keys after using "update". "Update" in the certificate details should only search by fingerprint. Maybe when we know that the key source is WKD we could also look by mail address?
Okay. I do a KeyListJob with key list mode GpgME::LocateExternal which does the equivalent of --locate-external-keys and that depends on the auto-key-locate mechanisms which could include keyserver and other mechanisms besides WKD.
The lookup by email address is supposed to be done via WKD. Obviously, a lookup by fingerprint wouldn't work. And yes, obviously this may import additional key via WKD.
I am reopening this as the current behavior is strange in my opinion and should be changed before a release.
Currently the refreshopenpgpkeysjob does not refresh the OpenPGP Key by fingerprint but instead imports all keys with a similar e-mail address. This does not work for keys with no email. Also in case of public keyservers it can pull in keys that not belong to the user or are expired and so on.
Jul 26 2022
Jul 22 2022
@gniibe Thanks!
In the repo, for all related software, it's done.
Note that versions since 2020-11-07 to 2021-07-03 have major problem with non-POSIX shell, which doesn't support $(..) construct.
Jul 18 2022
Thank you.
Jul 5 2022
Jul 4 2022
Please arc close-revision D558 this revision.