If the stub has been created or updated we will now ask for the card
with the Display-SN. If in addition a Label has been set to the key
that label is also shown. Note that the Display-S/N is associated wit
a card but the Label is associated with a key. For example if the
same key has been stored on two cards, the prompt will ask for one of
those cards but shows the same same Label. It is sufficient to insert
any of the cards with the key because that is what we actually need.

In master we already have Token lines which are created but not yet used. I am going to extend this with the display S/N and drop the idea of a separate Display-SN entry.

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).

Push the change.

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?

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.

As mentioned in T6134. The overlayer encoding is still broken and only as a workaround uses verschlusseln instead of verschlüsseln in german. Should be fixed once and for all.

Right, I think I never fixed this but someone changed the ü to u in translation to workaround it. That was what https://dev.gnupg.org/T4637 is about. I think I'll reopen this one.

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

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.

revokekeyjob.moc is included by job.cpp (as many other *job.moc files). The missing symbols should be available in the built libqgpgme.so. The command line

rdlibtool: link: clang++ t-revokekey.o t-support.o -g -O2 -L../../cpp/src/.libs -lgpgmepp -L../../cpp/src/../../../src/.libs -lgpgme -L/usr/lib64 -lassuan -lgpg-error -lassuan -L../src/.libs -lqgpgme -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

includes -L../src/.libs -lqgpgme. So it should link against the newly built library and not against an installed library.

Dear ikloecker,

I have no idea why OpenKeyChain cannot decrypt TestFileB.pdf.gpg. Here is the packet list (with automatic decryption).

$ gpg --list-packets TestFileB.pdf.gpg
gpg: encrypted with rsa3072 key, ID B29C3E00B6EF27FA, created 2022-08-12
      "TestKey4 <TestKey4@Email>"
# off=0 ctb=85 tag=1 hlen=3 plen=396
:pubkey enc packet: version 3, algo 1, keyid B29C3E00B6EF27FA
        data: [3071 bits]
# off=399 ctb=d2 tag=18 hlen=2 plen=0 partial new-ctb
:encrypted data packet:
        length: unknown
        mdc_method: 2
# off=420 ctb=a3 tag=8 hlen=1 plen=0 indeterminate
:compressed packet: algo=1
# off=422 ctb=90 tag=4 hlen=2 plen=13
:onepass_sig packet: keyid BBF1585AFE6385A9
        version 3, sigclass 0x00, digest 10, pubkey 1, last=1
# off=437 ctb=cb tag=11 hlen=2 plen=0 partial new-ctb
:literal data packet:
        mode b (62), created 1660319025, name="",
        raw data: unknown length

$ gpg --list-packets TestFileA.pdf.gpg 
gpg: encrypted with ECDH key, ID 8594A0FBC4AFAF88
gpg: public key decryption failed: No secret key
gpg: decryption failed: No secret key
# off=0 ctb=84 tag=1 hlen=2 plen=94
:pubkey enc packet: version 3, algo 18, keyid 8594A0FBC4AFAF88
        data: [263 bits]
        data: [392 bits]
# off=96 ctb=d4 tag=20 hlen=2 plen=0 partial new-ctb
:aead encrypted packet: cipher=9 aead=2 cb=16
        length: unknown

-> This still uses AEAD. It seems Werner's method to remove the AEAD feature doesn't work. At least not with gpg 2.3.7.

$ gpg --edit-key 8594A0FBC4AFAF88
Secret key is available.

Hello All,

I am going to introduce a new DisplaySN: value for 2.2 which might also be useful for master.

Does the progress bar really say "Verschlusseln" (with u instead of ü) or this is a bug in the screen capture tool? In the pinentry dialog there are also two ü that are displayed as u.

@werner @ikloecker I tend to agree with the original reporter that this is an issue. Not a Bug, but an issue that causes problems for our Users. At least we should have some way in Kleopatra to disable "Advanced Features". Then users could be pointed to some screenshots how to disable AEAD.

This works now with the fix in pinentry that uses the same code to bring the smartcard insertion dialog to the front as we use in the password entry dialog.
Before I was able to reproduce the issue, now it works as expected:

We have changes for this in master; I need to see whether it is possible to backport them.

Here is an example on how to remove the AEAD preference from a key using GnuPG 2.3:

As an alternative you may change the preferences on the key to adjust them to your changed/downgraded version.

Observations:

• TestKey1 (gpg 2.3) is an ECC-key (ed25519/cv25519) while TestKey3 (OpenKeyChain) is an RSA-key (rsa3072). I assume that OpenKeyChain supports ed25519/cv25519.
• TestKey1 (gpg 2.3) states that it supports some advanced OpenPGP features: features: 07 (= 0x04 + 0x02 + 0x01).
• TestKey3 (OpenKeyChain) states that it only supports one advanced OpenPGP feature: features: 01

Some details about TestKey3:

$ gpg --show-keys backup_2022-08-11.sec
pub   rsa3072/BBF1585AFE6385A9 2022-08-12 [SC]
      4AFA1B0808A82E3EF941B067BBF1585AFE6385A9
uid                            TestKey3 <TestKey3@Email>
sub   rsa3072/F3E9DFE37D777AEF 2022-08-12 [E]

Some details about TestKey1_0x31B038AA:

$ gpg --show-keys --verbose TestKey1_0x31B038AA_public.asc 
pub   ed25519/CD1E530031B038AA 2022-08-12 [SC] [expires: 2024-08-11]
      A438C95B6CAA724BC9F3DEB9CD1E530031B038AA
uid                            TestKey1 <TestKey1@Email>
sub   cv25519/B390B84B58866C6A 2022-08-12 [E] [expires: 2024-08-11]

Here are two keys that I created on OpenKeyChain. They are in an encrypted backup file:

Here are two test keys I created with gpg4win 4.0.3 after reinstalling.

Please don't yell at us!

All issues were "fixed" by getting rid of the dialog for T6115: Kleopatra: On "revoke certification" do not offer keys which did not certify that certificate.

Depending on what the user selected (key, one or more user IDs, a single certification) all certifications that the user can revoke are determined and, after confirmation, are revoked one after the other.

Apologies for the delay here, but the particular user claimed it was no longer an issue and it fell off my radar. However I now have a new individual with the same problem.

While playing with your scripts I figured that it would be useful to enhance the KEYINFO command. With
rG989eae648c8f3d2196517e8fc9cce247b21f9629 we could now

FWIW, the man pages do not carry all the info we have. However, I plan to chnage this and put everyting into man pages. It turned out that even me uses the man pages more than info(1) or gnupg/doc/*.

In T6129#161497, @werner wrote:

We are currently investigating another problem with a new feature. Thus things are delayed. Hopefully we get a new release this month (or at least a new gnupg 2.3 version to install on top of gpg4win).