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.

Fixed in 1.2.1.

Thanks for the followup about R3, @mpilgrem! Looking at your logs in more details, and the source code for find_cert_bysubject in dirmngr/certcache.c, i think i see what the issue is. It's slightly more subtle than not terminating early if a known trusted root can validate a truncated chain.

@mpilgrem, i'm glad that removing the DST Root CA X3 from your windows control panel worked for you, but it still doesn't seem to be a reasonable fix from a GnuPG user perspective

Thanks for the information.
As a follow-up: Is it possible to tell gpg-agent to

• not ask to insert a missing smartcard (and behave as if cancel had been clicked; after which the next private key is used)
• but to ask for the pin, if the smartcard happens to be inserted?

pinentry 1.2.1 has been released today

I added this option on 2005-07-19 and iirc this was planned for the FSFE's rig to produce their membership cards. I kept that option in 2.0 for backward compatibility but it does not make any sense because its gpg-agent's duty to ask for cards - gpg does not known about it.

We have a cancel button and an cancel-all button (Window close button). The former skips the current key the latter should cancel the entire decryption process.

Looks like this option has been merged 16 years ago from gpg 1.4.3. My guess is that it was never used in gpg 2.x.

For the original issue I'd prefer to silence the error/warning with -Wno-narrowing because I think it's a non-issue. Or does changing the enum declarations to enum : unsigned int make clang happy?

For gpgme (as for the other GnuPG libraries) we use the good old mailing list based process for contributing patches. See doc/HACKING for details. In particular, we'll need a signed DCO from you.

Doing the same thing on my second PC, I can be more precise:

Yes, this is with Clang. I am working on getting it to compile on Windows with clang-cl, using vcpkg, with success. I have several patches to fix the issues that clang detected, and so I wonder if I should create a Task to discuss them all?

I'll reopen this ticket here, since the underlying issue is not quite resolved yet as @dkg helpfully outlined above.

g++: error: unrecognized command-line option '-Wc++11-narrowing'; did you mean '-Wno-narrowing'?

How did you get this error? I don't even see a warning for this when building gpgme with g++ (SUSE Linux) 12.1.1 20220812.

Thank you dkg. I am new to 'certificates' generally - and a little knowledge is a dangerous thing - but this is what I did:

@mpilgrem: in the meantime, for connecting to keys.openpgp.org, which *has* cleaned up its certificate chain, you might also want to try killing your dirmngr process, and/or cleaning up the data in .gnupg/dirmngr-cache.d/.

Basically, the website in question (e.g. https://openpgpkey.gnupg.org/, which exhibits this problem) serves up three certificates:

In T6136#161943, @ikloecker wrote:

This looks like a good approach, but I think stripping the standard paths needs to be deferred until later, because, if PKG_CONFIG_SYSROOT_DIR is set, then the library search paths are prefixed with $PKG_CONFIG_SYSROOT_DIR, and then the prefixed standard paths probably shouldn't be stripped.