Fixed with gpg4win 3.1.9.

I wrote the script and the intention is supporting old systems using POSIX shell. Our goal here is: Not introducing (additional) dependency to Bash.

Thanks for your feedback Werner.

This is all valid Bourne shell syntax. In detail:

Thank you very much for your quick action!

Hi Andre,

Hi,
as usual, thanks for your help.

@gouttegd good catch!

The reason for this is the change to Kleopatra that the columns are configurable ( 4847fcc27afc8101752de82b0dd1f5fee027695d ). In the process we added additional columns like origin and to hide the "summary" column that the line edit for the recipients use we gave it an index number that was higher then our internal column count.

Thank you very much for the report. I can see this problem myself. It is strange because the code for that has not changed since 3.1.7 so it must be some sideeffect.

Thanks a lot @gniibe for this change.
I do understand and share your concerns, nevertheless are there, in my opinion valid reasons to be able to have a backup or duplicate, especially on the same or similar media type.
Consider for example giving multiple devices a chance of common interaction, using the keys for backup encryption etc. - I think there are several possible use-cases which can benefit from this.

I just assumed that is an ntbtls problem.

If I understand correctly, this is exactly the same problem that the one we encountered some time ago in the code dealing with fetching keys from HTTP (--fetch-keys), and that we fixed with this patch.

fwiw, the bug looks like it's in send_request in ks-engine-hkp.c, which re-uses the http_session object without re-initializing its tls_session member.

thanks for the triage, @werner!

We need --keyserver in gpg for just one reason: backward compatibility.

thanks for fixing that error message, @werner. As @Valodim points out in discusson about hagrid, a gpg.conf keyserver option (deprecated according to the documentation) overrides the dirmngr.conf keyserver option (not deprecated according to the documentation.

I'm having a very similar problem in 3.1.5! Randomly, when I try to view a PGP-signed e-mail, nothing shows, both on preview panel and when I open the message.

This is a high prio error, I guess, because it breaks a very useable part of gnupg, that is really hard to maintain. If it is not stable to sign keys with the gpg-agent, it is very hard to use that. Many might switch back to the ssh-agent.

Please check if this patch works for you and please check where this flag actually comes from and what it does say!

Fixed in master.

any feedback on this proposed patch?

I did forget to mention that the key I'm using is 4096 bit long

I was creating a tar archive with 7-Zip on my Windows 10 machine. After the creating was completed I was encrypting the archive like so:

Just to clarify, you were able to decrypt and extract it without error? Which tool did you use to extract the tar archive?

The solution conflicts the the fix suggested and implemented for T4330.

Fixed similar to the suggestion but NaN and INF are detected earlier.

I did encrypt the file myself with the version mentioned above.

I see the regression of gpgconf. I wonder if it's better to fix gpgconf side, too.

I see a regression with your fix. This option is even controllable with gpgconf at the basic level. It would be better to make it a dummy option.

Fixed in master. Closing.

Fixed in master (to be 2.3).

I tried to apply&push, since we changed the file a bit, I needed to apply it manually.
Anyway, it's done.
Closing.

I meant, 'card-timeout' was not intended for controlling caching PIN on card. It was for "DISCONNECT" command support.
I'm going to remove questionable documentation.
Closing.

No worries -- you led me in the direction of a solution when you mentioned loopback mode. I appreciate your time and your help!

Thank you for your fix suggestion. I think your change is good. I applied and pushed.

Sorry, I responded in a mode of "tracking a bug to fix soonish". I should have changed my mode into showing HOWTO.
Thanks for sharing useful link.

I found these instructions for pinentry loopback in Emacs, and they worked!

When you can configure it properly, there is a way to workaround it.

A newline is required by the PEM standard.

Maybe the file was encrypted with a version of gpg4win-3.1.5? We had a serious bug there that sometimes files were corrupted. See: T4332

This is problem of your setup of your build environment. Closing.

I added the section in tools.texi. Closing.

For (1): it is broken out-of-the-box, that would be true. When you can configure it properly, there is a way to workaround it. Well, I admit, it's not yet perfect.

Thank you for that analysis. I don't understand some of the parts (because I don't know anything about pinentry), but I do have some questions.

Thanks for your report. The symptom you have could be only solved by using pinentry loopback mode, or using some special pinentry for CLI, I suppose. pinentry-tty is not sufficient for this usage.

Please let me know if I can run any other tests to help debug this issue. I'm happy to help.

FYI, pEp annoyance was addressed and handled here: https://bugs.debian.org/891882
By this patch: https://sources.debian.org/src/enigmail/2:2.0.11+ds1-1/debian/patches/0002-Avoid-auto-download-of-pEpEngine-Closes-891882.patch/

Thank you for your response.

For GnuPG, the error is: you don't have run-able libntbtls.so in your environment (because of your wrong configuration, perhaps) but you have it to link.
For GPGME, the error is: your linked libgpg-error.so.0 and the one which runs are different (because of your wrong configuration, perhaps).

I've pushed fa0a5ffd4997c2ca38a1dd2d89459b6b1f18ad99 to the branch dkg/fix-T3464, which i think solves the problem i was seeing without reintroducing any new problems.

I can confirm that this is actually a problem now :( gpgme_op_decrypt_verify returns a status with GPG_ERR_MISSING_KEY set when a session-key is used.

we've never shipped a binary gpgscm in any debian package. I was just reviewing the differences between what we ship and what upstream ships, and i noticed this discrepancy.