Checking musl internal, it seems that we can detect a single threaded application by:
https://git.musl-libc.org/cgit/musl/tree/src/internal/libc.h#n22

Thanks for your help @gniibe and apologies for wasting your time. It looks like this is an issue with ncurses on musl systems and I'll pursue it there. I have a patch to their configure which works & fixes building pinentry.

I've reported it on bug-ncurses@ to get some insight: https://marc.info/?l=ncurses-bug&m=166268018624805&w=2.

Mysteriously, I get nothing:

$ pkg-config --cflags nurses

To debug this you can enable logging of the dirmngr (which does actually talk to the keyservers). To do so open GnuPG System/Network in Kleopatra's configuration dialog and set the debugging level to 4 - All and enter a filename for the log file.

Ah OK I'm following now, I had took that as maybe another lookup at that time was failing. The keyserver that we have configured is hkps://keys.openpgp.org. Is there any misconfiguration here with that setting?

In T6014#163001, @ebeiersdorfer wrote:

OK, so this warning should just be ignored then?

OK, so this warning should just be ignored then?

Could you please check what pkg-config --cflags ncurses returns?
In my environment (of Debian), it returns:

It looks like there was a problem similar to this a while ago: https://dev.gnupg.org/T2320 where it turned out for unicode ncurses builds, a specific header had to be included, but that workaround seems to have been removed from pinentry since.

bernhard added a comment.Mon, Sep 5, 6:05 PM

If it is was broken for you and works now, let us know here.
if "lists." still is there in email addresses somewhere, please also list.

Kleopatra does searches in parallel. What you see in the second dialog might be a response from a Web Key Directory (i.e. search by mail address with lookup at the mail domain).

Here is a list of possible issues:

Or better:

• If it is was broken for you and works now, let us know here.
• if "lists." still is there in email addresses somewhere, please also list.

Thanks!

https://lists.gnupg.org/mailman/listinfo/gnupg-devel has `To post a message to all the list members, send email to gnupg-devel@gnupg.org." now, which seems fine, it was wrong before.

Fixed for 3 lists. I can't remember the details but quite some time ago someone requested some changes and while applying them the host_name must have changed / I changed it. The problem with Mailman is that it does not use plain config files to keep under etckeeper. At least not with some effort.

@werner also I suggest to check the default setting for this, see https://www.list.org/mailman-install/customizing.html and you can use the scripts mentioned there to check the configuration of several mailinglists at once and change it, if you know, which one is to blame, e.g. the host_name value.

@werner
Can you take a look at the host_name setting at the [General Options] configuration page for the lists in question,
e.g. https://lists.gnupg.org/mailman/admin/gnupg-devel

The more relavant error is that there is no status output on failure which is what gpgme uses (due to double forking).

Yeah, we known. Fix is rGf34b9147eb3070b see T6070

Thanks for testing. I guess I will do a new release.

Applies cleanly and fixes the crash. 👍

For master (2.3) the fix is not needed due to another way the code works, but having a more robust function is always good.

You may try the above commit - if should apply cleanly to 2.2.37.

You are right. This due to your old binary private key (stubs). Otherwise you would at least have one item ("Key:"). I need to see what do do about the release. Maybe a tool to update the key files would we a good workaround.

Oh well, why do I receive such bug reports right after the next release :-(

Sorry for the confusion ...
There was no single gpgol-File for deletion.
There were 100.000 other files from other programs.
No idea, why this has interferred with gpgol, but it obviously has.

Ok. So I never assumed that you had actually 100 gpgol_enc_number.dat files lying around.

Thanks, I really appreciate having this fixed in gpgrt-config! I backported the commit to gentoo and can confirm that fixes the build issue with slibtool.

Thank you for reporting, and sorry for late handling of this report.

I had a look into my \AppData\Local\Temp and found some 10,000 Files/Folders (nearly 100,000 files in total) with over 10 GB.
After deleting most of them, GPG4WIN 4.0.3 is working!

It's strange that the problem only occurs locally on one machine. I set up a test bench and did not experience the same errors as before.

Thanks a lot. Due to your log I have tried with a long username and umlauts and a dot in my username. My test name was Längül!ödiföäada.dad which is the longest that Windows allows. But It still works for me. Even if I create one or two gpgol_enc.dat files in %TEMP% It still works:

... Logging active, standard, with email content and meta information

I have produced a log using 4.0.3.
See attached.

GnuPG requires threads but not gpgme.
We already had the same discussion about threads and libgpg-error more than one year ago: https://dev.gnupg.org/T5296

Thank you for your report. Next time, please include information of your target and configuration in the report.

This issue happens even if a user enters the correct password for the private certificate.

I think this is a duplicate of T4779 I am merging them because if it is not a duplicate T4779 is still the right issue because we need better error messages for PKCS #12 import

strange, I have not received one. Did it bounce somewhere maybe because of size? Encryption should compress this though.

To identify/locate the issue, you can try command line:

In the situation of a certificate about to be expired in the cache:

Thanks, @gniibe -- i agree that this change to put_cert should be helpful, when encountering a certificate that is already invalid.

Applied to master and 1.10 branch.

Ok, email sent

I believe that this error is caused by a software bug of Gpg4win. Please get back to me if you need additional details about this issue, thanks

Please, Last chance to add a log with Included file names (Include data checkbox) before the next release. Me and a colleague reviewed the function and don't find an issue with it. Otherwise I will only add a MessageBox error in that case for the next release.

Yes, that was sadly the case with the last release. It was fixed in: https://dev.gnupg.org/T6070 but not yet released. So the next version will work again. Until then you have to stick with the older version.

@SPYazdani But your log is also without the Data information. The issue is that I see the Problem that it tries to aquire a temporary file name and fails to get one. Then it runs into an unexpected state. But gpgol_string_107 is the pseudonomized debug output of the filename. Because the filename would include your username. And I need to see what GpgOL tries there and why this would fail.

@aheinecke I posted a link to the logs in T6158

This was reported again in T6158. The problem is still that I have not seen a log with Data debugging enabled. @SPYazdani could you maybe create one? Please enable logging and check the box below the logging filename where it says "Include Mail contents (decrypted!) and meta information." and then you might afterward look into the log file and post here the lines above "Could not get a name out of 100 tries" I am interested in the candidate names and also please then check if those files really exist and if so try to remove them.

Ah right, forgot about this issue. I merge it with the other one and answer there. I need a log with data debugging enabled of this issue.

rejecting an intermediate certificate too.

Pushed the change of mine to master, since I can confirm that it results validate_cert_chain working better, because of put_cert's rejecting an intermediate certificate too.

I pushed the changes. It also cares about the case for --cflags.

@dkg: Thanks for the detailed description of the problem.

@orbea Thank you for your suggestions.

Thank you @dkg for the analysis. Unfortunately, the certificate cache is hashed by SHA-1 FPR, so, I think that it is a bit difficult to implement moving certs "front" / "back".

I think that for GnuPG 2.3.7 or later, you can add "Prompt: no" in your private key, which helps your interactions.
https://dev.gnupg.org/source/gnupg/browse/master/agent/keyformat.txt$138?as=source&blame=off

Fixed in 1.2.1.