In a current version I see this at least if I do not quit Kleopatra completely and restart to another screen setting. Further testing at the moment is not warranted, as there will be changes to the columns handling with the switch to Qt6. (T6924)

Btw compare the Kleopatra versions in Gpg4win and your VSD Version. They should mostly be identical with VSD maybe lagging a bit behind, Or your emplayer has not updated VSD. Many don't

We're waiting for a RNP v0.17.1 release which intends to tolerate this mode.
https://github.com/rnpgp/rnp/issues/2198
https://github.com/rnpgp/rnp/pull/2190

This is fixed on RNPs side: https://github.com/rnpgp/rnp/issues/2198

After much investigation and debugging it turned out the problem really was that KOrganizer was hiding declined and unanswered invitations. Fixed already in master and 24.02.

Btw we should probably add TB in our QA environment to check for such things. Esp. with future changes in GnuPG we should try to use TB and maybe a bounycastle MUA (Greernshield?) to avoid creating accidental incompatibilities.

I cannot think of any of our products where you cannot chose the signing key.

From your description it is not clear what you did exactly.

To reproduce:

• Send a mail to yourself
• add an attachment
• select encrypt

I assume you mean the information shown in the subkeys window int the column "Strength"?

Given the situation where GnuPG works well with existing OpenPGP card implementations, what we should do here is, perhaps:

There are multiple problems described in your report. Let us handle one by one.

Thank you for your quick testing.

Works for me using the latest vsd beta (3.1.92.39)

I've reported the success to MacPorts. My test was performed on only one platform, Mac OS X 10.4.11 or "Tiger". Since there exists a problem with building recent version of GPGME testing on Mac OS X 10.5.8 or "Leopard" will have to wait a few days…

With the unified patch all works fine (again), even the test target succeeds!

I think last time we talked about some generic solution for this. And ended up trying to research if we could add this in the end after linking is done to avoid having to patch/add an RC file for every library like GnuPG. Kleopatra and GpgOL already has one as you can see in windows with right click / properties and then details. Maybe we need to change the values there.

Performing the patch manually the "port" (package) built and installed. Starting then gpg-agent worked too, killing it (with gpgconf) worked as well.

The patches looks too large to merge (than actually needed), and not enough/clean like not having detection of the system.

I am still not sure why I noticed the double signing but with the new stamp feature we have an effective way to avoid long delays due to authenticode signing. Some gmake macro guru might want to look at gpg4win.mk.in to get rid of the duplicate rule ignore messages.

strcasecmp is pretty standard on Unix. However, in GnuPG we test for it and mostly use our own ascii_strcasecmp to avoid fun with locales. Ralph Seichter is providing macOS builds for GnuPG (https://sourceforge.net/p/gpgosx/docu/Download/) . Maybe it is worth to contact him via the gnugp-devel mailing list and ask him whether he has experience with your toochain.

By adding "-Wl,-t" to the arguments g++ reported:

Libtool invocation has "--tag=CXX --mode=link /opt/local/bin/g++-mp-7 -std=c++11 -pipe -Os -std=c++17 -D_GLIBCXX_USE_CXX11_ABI=0", but g++ then has no -lstdc++ – in C -lc is automatically used because there all C library functions can be taken from… (same for mathematical functions and -lm)

I agree with the column save /restore but i disagree with adjust to contents since this can create a "jumpy" layout e.g. with long comments and the user might be annoyed if she changed thr layout and it is then automatically changed again

It seems libtool fails to add the standard C and C++ libraries to the link command line. On Linux I have "[...] -lstdc++ -lm -lc [...]" in the libtool link command line. Looks like a bug in the tooling (macports or libtool).

On March 11 and 18, the private key file DE1AB1D22899CEC7DBB1A7863F34E6E92BFB7756.key was wrong.
I updated on March 25. Now, the endian is GnuPG (d is big endian).

Thank you for the reminder. I will update the version in configure.ac for AM_GNU_GETTEXT_VERSION, when I will confirm other developers' emvironment.