Can you please run claws like this:

Anglocentrism smells like a relic discrimination in our age of Unicode, let users name folders as they natively see the world. For example, a Greek/Russian/Turkish carpenter with calloused hands, who stores his chisel and hammer in a toolbox, might want to store computer tools like GPG or LibreOffice in a folder Εργαλεία/Инструменты/Araçlar (=Tools), but particular tool unexpectedly says “Error!”, which might be perceived as passive-aggressive “No, I was made to serve the needs of English-speaking celestials only”. Thanks to Andre Heinecke and Egor Pugin for sympathetic attitude and prompt steps to solve this issue.

Looks good, thanks!
I think they (LO) will catch up with the next gpg4win or gpgme release or smth like that.

I've rewritten your patch a bit so that it falls more in line with our general style of helper functions and is more generic.

Well in general we don't support installation into UTF-16 paths for Gpg4win, our installer prevents that. This is probably why this issue never came up.

Thank you.

Thanks for the report and the patch. As this results in multiple message boxes (which we create and not Libreoffice) I'll assign it high priority.

Also see related libre office issue https://bugs.documentfoundation.org/show_bug.cgi?id=124609

News for 1.13.0:

• Support GPGME_AUDITLOG_DIAG for gpgsm. [T4426]

@dkg If you propose a patch here I'm pretty sure that we will accept it. As one of our Python binding users you know better then us how the API should behave.

Reading through this issue and the related documentation: Thanks for writing this all down and adding links!

It's better to have a new Task for this as I explain in T4402

I'm new here, therefore I'm unsure whether this posting is correct at this position.
Within my organisation we have ongoing troubles with the error described here, with windows version 3.1.3 there is no such button "force decryption" as documented here.

Ouch indeed. Looks like you run into a "hanging" gpg-agent situation in that case our main background process is blocked and all other processes wait for it to respond and nothing works anymore.
This should never happen and we need to fix it. But so far we have not found a way to reproduce it.

Looking at other threads I found the problem in some .lock file in my gnupg directory. One of them was locked by a running process and I was not able to delete. So I opened up task manager and I had dozens of gnupg related processes running. I killed all of them and removed any .lock file.
This way Kleopatra started again but the certificate above (aruba) was not present in the imported ones. And, of course, I'm not going to import it anymore, will use my sixt sense to trust certificates...

The exact file that created the lock is attached

The only action I can do is quit the program telling it to stop the background actvity, but I cannot use it anymore...

Ouch, worse problem here. After closing kleopatra telling it to stop doing whatever it was, I restarted the application and now it's stuck in "Loading certificate cache"

The certificate was defintely missing the tag lines, thanks. I also tried opening the certificate from that page (Windows has no problems without the tag lines) and exporting it explicitly as base64, and the output file is fine.
The problem is that the import now seems to go well, but no certificate is imported at all. I tried several times and the import box just closes after selecting the file.
I tried to close Kleopatra and it says there are ongoing background operations. At least 15 mins passed between the import and the closing tentative.
Actually, it is stuck doing something.

Thanks for the report.

I could reproduce the issue and fixed it similar to the code suggested.

Will be released with 1.12.1

Thank you!

@werner This one? https://www.gnupg.org/documentation/manuals/gpgme/Selecting-Signers.html

Please see the section 'Selecting Signers'.

@werner Looks like recpstring is only supported for encrypt and encrypt+sign, but not just for signing. Is there a way to specify the subkey to use when signing?

yikes. Sorry for that one,..

Fixed. Needs to go into the next gpg4win release.

Ah okay, that was Windows were we have a couple of warnings anyway. Must have missed that one.

Aiiih, what happend to the sentinel attribute? I need to check.

Thanks.

Thanks.

Thanks.

Thanks

Thanks, I don't think that it is a problem for our usecase but the fix is trivial and we should apply it.

Thanks!

Thanks, will be fixed before the next release.

Applied.

Done for libgcrypt.

I give this normal priority to move it out of the "Needs Triage" queue.

Done for libgpg-error.

Topic branch of libgpg-error is not good to show changes (for other libraries).
So, I made D473: Introducing LDADD_FOR_TESTS_KLUDGE to enable 'make check' with LD_LIBRARY_PATH.
Appliying to libgpg-error.

3.1.6 will have two ways to install the browser integration non-interactively

I sent a message to gnupg-devel about this issue as it will probably hit more people now that the keys used are expired :-(

Oh,.. it is even worse. The conflict keys expired 2019-01-06 so they are actually expired right now.

I don't know why @BenM closed this bug given that he mentioned that the qt part is yet not solved.

We've run into the testTofuConflict failure on NixOS. gpgme v1.12, gnupg v2.2.12.

For other distros, it seems it's quite old issue: https://sourceware.org/ml/binutils/2012-05/msg00037.html

My patches on the topic branch: https://dev.gnupg.org/source/libgpg-error/history/gniibe%252Fdisable-new-dtags/

Thanks for the report. Indeed I've overlooked this.

My tentative conclusion: When (GNU) ld supports --disable-new-dtags, add it to LDADD in tests/Makefile.am.

Reading this discussion: http://lists.gnu.org/archive/html/bug-libtool/2018-01/msg00014.html
It seems that it could be fixed if we care about the order of libraries.
And it's not the issue for libgpg-error, which doesn't require external libraries.

For binutils, in Stretch, Debian specific patch was introduced.
Then, upstream introduced --enable-new-dtags option for configure to build binutils.
Now, Debian uses --enable-new-dtags option (at build time).

Even with the logging changes this still happens. I just retested it. Can't run Kleopatra on Linux with GPGME_DEBUG=9.

Though not directly related to our issues, this bug report on the MSYS2 site reported by their users encountering trouble with GPGME provides additional weight to irreconcilable differences between MSYS2 and GnuPG:

Though apparently resolved back in May, this is what ultimately led to T4191 and was thus only properly resolved quite recently.