Just a small addendum to what Andre wrote: Obviously, no tab should be shown if nothing was imported (i.e. numConsidered is 0).

Well, i can live with it. It would be an improvement.
I would prefer if no import tab was created if a key has not been updated and therefore nothing was actually imported. But I see that this would be more complicated to implement and I have no strong opinion on this anyway.

So Tobias fixed the technical reason why there was no import tab shown after the certify questions because I was too lazy (no I had no more time ;-) ) when I implemented this to carry the keylistcontroller around.

Thank you for the patch.

Using/setting a value of 2 would work for Kleopatra.

That is probably right for gpgme as used by kleopatra. However in gnupg we need to switch utf8 on and off.

Tested with version 3.2.2.2405000+git~ (Gpg4win-4.3.2-beta25)

Thank you for your report, good catch.
It's introduced by the commit: rC909daa700e4b: blake2: add AVX512 accelerated implementations
And the bug is there since then.

Fixed in rG01fa318be0f8: scd: Fix how scdaemon pipe server finishes.

Yes, the SO number changed. Before that you had run the test with an old version of the library or maybe the current one depending on your system. However, a changed SO number means that you have can have two versions of the library installed and they don't alias them with symlinks. We rarely update SO numbers but int he libassuan case we did it because technically we had a minor ABI change but GnuPG and Cie. are not affected; we did it anyway to be correct.

Strange - running sudo ldconfig prior to make check did indeed allow the tests to pass and the gnupg executable to build. I don't recall needing to do that until now; has something changed?

What you should is to to run

Asking a change of gpgme would need more time... So, I decided to change gpg-agent side.
gpg-agent part was done in: rGb3f1f2cd192b: agent: Handle SCD DEVINFO --watch command in a special way.

I don't know what the "speedo build method" is, so no. I've built this software many times before with the usual routine:

Did you used the speedo build method? Did you install libassuan first?

scdaemon part was done in: rG36d8cffc6cd2: scd: Finish DEVINFO --watch command on input close.

The use of putc_unlocked has long been removed. So we should also remove the declaration. Normally this does not harm but in your case you may want to pass CFLAGS="-DHAVE_PUTC_UNLOCKED" to make or remove the above declaration.

The point here is to escape control characters so that we do not run into problems when reading the stuff. Escaping non-ascii (c >127) is not required and would put a lower limit on the number of (utf-8) characters we can print via the status lines.
Note also that we use almost everywhere ascii versions of the character checks. Thus I would not consider this a bug.

Verified the fix.

Maybe we can support this directly in gpgme's assuan API.

Did some experiment and I concluded (for now) that new command for gpg-agent would not be needed.
Instead, it might be better doing following in GPGME.

Pushed the change to master. Please test.
rCbb0895bbb7c6: m4: Fix acinclude.m4 for underscore detection in the symbol.

Thank you for the report.

Thanks for the detailed analysis; we will check to tomorrow why this was changed.

In T7175#187690, @jukivili wrote:

Hm, CFI directives should not be used on WIN32 target. This patch should solve the issue for now:

0001-src-hwf-x86-disable-inline-assembly-CFI-directivies-.patch984 BDownload

Here is a fix for the issue which preserves the removal of cut:

Using clang for Windows is not tested or suggested. Thus low priority.

I tried to reproduce issue with clang/w32 toolchain from https://github.com/mstorsjo/llvm-mingw but there build worked even with CFI directives.

Hm, CFI directives should not be used on WIN32 target. This patch should solve the issue for now:

Thanks for testing. I pushed this fix to libgcrypt master.

seems to be related to https://git.gnupg.org/cgi-bin/gitweb.cgi?p=libgcrypt.git;a=commit;h=a5f88f30ce612b0239b946c4424d81cf0d552e96

See: MacPorts Ticket 70267 and MacPorts PR #24601

Oh, I did not notice the change as I clicked to the patch from mail notification. Trying now with the updated one:

Just to make sure, did you use the updated version of the patch? I edited the message with fix candidate and changed the attachment.

Running scratch build on s390x: https://koji.fedoraproject.org/koji/taskinfo?taskID=119376728 with the proposed change. The failure is now:

Done in 1.11.0.

While the above patch worked for MacOS 10.8 and above, MacPorts CI shows a second error for older MacOS versions:

Here's fix candidate (edit, new try):

It looks like various flavors of BSD (including macOS just declare environ when needed): environ -- user environment Note: this is a very old MacOS X man page, however the current version is from 2003, and has the same Synopsis.

This diff for 1.11.0 fixes the problem for me:

The following logic from 1.11.0 acinclude.m4 cannot possibly work to detect _ at the beginning of symbol names:

The toolchain is clang / llvm and the apple ld, native build, not cross compiling.

Didn't you had this problem with 1.10.x ? I can't remember that we changed anything at theat code for years. The only recent change was rC656ca459e which should not have changed anything. Maybe the problem is elsewhere.

Frankly, having environ declared in unistd.h is a glibc convenience and other systems likey don't have it. easy to fix, though.

Thank you for having a look into that. If I see right, Fedora has a real s390 hardware for builders so I can verify the fix when available.

Algo 329 and 330 are the new CSHAKE128 and CSHAKE256 digest algos. Looks that s390x only support accelerating SHA3 and SHAKE, as only SHA3 and SHAKE suffix are supported (see keccak_final_s390x()). So s390x acceleration needs to be disabled for CSHAKE algos.

I encountered this also on macOS. Apparently, Apple does not provide an declaration for environ, in contradiction to the manual page for execv.

I backported this trivial fix for VSD 3.3. Support for drag&drop of certificates from Kleopatra to other applications or the desktop was added for VSD 3.3 (T6893) and it shouldn't confuse the users.