I guess you are the only person who does it. But yeah. I agree that it should be fixed.

I patched version 1.13.0 with that commit and installed the patched version on Monday. It appears to have fixed the problem.

This should resolve it.

Well there is nothing specially pythonic about it, it just includes the dirs and not the files:

Argh, that Python specific stuff Ben used is weird and does not fit into the autotools model. Someone(tm) need to have a closer look at it.

Merged. Thanks again for your work on this.

Thanks for the explanation. That addresses my concerns.

I agree that this is a minor API shift, but i *don't* think it's a security problem, because i was particularly careful to maintain the invariant that decrypt(verify=True) will only ever return valid signatures.

Thanks for the prompt action here. Some build environments (e.g. distro builds) might ask for additional compiler warnings in the user-supplied CFLAGS, but i suppose those build environments that enable the warnings deserve what they get.

That makes sense to me. So I've now moved the -Wno flags out of the maintainer mode conditional but left the parts adding warnings in the maintainer mode conditional.

The thing is that that I accidentally added the -Wno-* flags only in maintainer-mode as they were -Wmore-strict-warning-flags. One reason for using more strict warnings in maintainer mode is to allow building with older gcc versions without having to test for the availability of the warning flags.

Thanks for the report. This is annoying me, too when doing release builds.

I'm for merging this as I understand the rationale. In Kleo / GpgOL I also only need one valid signature.

I've just published a branch dkg/fix-T4276 (with commit 4100794e305ba22241ea5a4f7b42bb5189fbd948) which i think resolves this issue.

@werner This issue also applies to GPA. Looking at the edit key interface I can't see how we can handle this. Am I overlooking something or do we just loose the error information / is it not emited by gnupg?

I think I identified the bug. A fix is pushed.

Before the SEGV, calling a handler in _gpgme_io_close is strange:

GPGME 2019-04-11 12:24:58 <0x660e>        _gpgme_io_close: check: fd=0x22 invoking close handler 0x7f341d8b8960/0x7f33f0003930

Because the file descriptor 0x21 and 0x22 is allocated by _gpgme_io_pipe, and there should be no handler(s) for those fds.
Either, the notify_table is screwed up, or there is a leak of fds.
I'd like to see the logs of all calls of _gpgme_io_set_close_notify and _gpgme_io_close.

Sorry, I overlooked. I think it is inside _gpgme_io_close calling the handler, and the handler segfaults.

Apparently, it SEGV-ted itself by assert at line 468 in gpgme/src/engine.c.
For GpgSM, info->file_name is not assigned (while it is done by gpg and gpgconf).
The code hasn't been changed for a while, I don't know the exact reason why it becomes occur.

Can you see the problem and fix it with the given information?

We will do a new release in two or three weeks.

Dear Andre, LO team is not able to integrate your fix unless a new release of GPGme is ready. Usually you do that every half year or so, but sometimes the delay is much less (e.g. 1.11.0 and 1.11.1). Perhaps, you would find it possible to roll out a minor version of 1.13.0 to ease the suffering of international users a bit earlier?

I did that. It felt like it took longer for the error to appear with debug output enabled, but that is probably subjective/random noise.

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.