So in short you want:

1. Allow to specify a keyserver by IP without any DNS lookups.
2. When connecting via IP use the IP address for Host:.

With the downstream report: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=925952 I resolve this here.

Thanks for the report. This was fixed with: https://cgit.kde.org/libkleo.git/commit/?id=8a94ac0835f0cff8908943d2a630a003a3429220 which I backported to Applications 18.12 which is the current stable release. But debian needs to add this patch. I'll report a debian bug and link it here.

Good that it works again for you.

I don't anymore think that it makes sense to fix it. Further there is no cache for PINs; that is entirely up to the card.

This was most likely a (chipcard) hardware issue. It went away after polishing the contact pads for a bit. Possibly my laptop reader applies more force...

No more reports about this in a while.

False positives happen from time to time with various Anti Virus Software. We have it as a FAQ in the wiki:
https://wiki.gnupg.org/Gpg4win/AntiVirusSoftware

Thanks so much your helps.
With new version 3.1.6, I can generate key on Kleopatra tool and use key stored in smartcard.

The same chipcard works still fine in a different (type of) reader / machine.

Thanks people, thanks aheinecke, for your support.

3.1.6 is released. Please test again and reopen this issue if you still have problems.
Thanks!

3.1.6 is released.

3.1.6 is released.

3.1.6 is released.

gpg4win 3.1.6 is released which contains this fix.

3.1.6 is released please use that one.

3.1.6 is released

Sorry, this did not make it into 3.1.6. But I'll definitely see about it for the next release. If it is an institutional / corporate issue you could also contract us through www.gnupg.com

Strangely, if I look at my upgrade history, it cannot be caused by gnupg or libusb update. Everything was working fine in February 2019.

I think I found it. The problem was that for mails without headers the S/MIME detection would fail and the mails would still be handled by GpgOL. I think this together with the fixes for T4403 / T4267 should finally solve this with Gpg4win-3.1.6

BTW in 2.2.15 you can also do

I forgot: Instead of importing the missing internal CA, this works:

I agree, the question is which CRL is checked when how. Maybe there is some mistake on my side. Here is a recipe for Debian:

I don't think this is a bug. Failure to encrypt when CRL check fails is expected.

In T4427#123774, @werner wrote:

Can you please run

gpg --debug ipc -vK

which will also start gpg-agent and print some diagnostics. You may want to redact the output. You can also run

Actually you should never use --debug-all; we have more specific log levels. Use --debug help to see them.

From: aheinecke (Andre Heinecke)
Sent: Montag, 28. Januar 2019 19:25

fwiw. Your patch is beautiful in which it follows our coding style and
debug output. I'm confident that we will accept it but currently I have
to read up on Job's a bit.

Is there a way I could help you with this? This issue is hampering adoption
of GnuPG 2 here.

--

Jan Echternach

Many thanks for the fast fix! Decryption works now. I'll report another bug for encryption.

Trying to install the update manually (according to windows update my windows is fully updated) it says "This update is not meant for your computer" and aborts.

I've started some documentation how to repair a broken archive under: https://wiki.gnupg.org/TroubleShooting#Restoring_corrupted_Archives_created_by_Kleopatra

A quick note: The second workaround above does not work.
The presence or absence of the expired certificate in my keyring does not matter. The check by dirmngr fails regardless.

The reason for the problem is that we check all configured keys to print a note about expired and otherwise unusable keys. This should be warnings but due to the way we use shared code the error counter is bumped and operations stops. With the fix these will just be warnings and decryption continues.

@nbriggs No this is not related if you get "no pinentry" it means pinentry is not started at all. This issue is about pinentry starting but not properly coming to the foreground. I've opened T4430 for your issue.

Hi,
I'm pretty sure that I finally understood it and fixed it. There was a data mismatch between the IMAPISecureMessage and IMAPIMessage which somehow only happened for sent mails. This case is now handled.

There was indeed a problem. With a test card I could reproduce the issue and fix it.

in I think a related scenario we are having the pinentry window not spawn at all, leading to "no pinentry" errors
Win 10 latest patches Mar 2019
Version 3.1.4-gpg4win-3.1.5
We've tried a few hacks including adding the .conf file to C:\Program Files (x86)\GnuPG\bin with
pinentry-program "C:\Program Files (x86)\Gpg4win\bin\pinentry-qt.exe"

Can you please run

gpg --debug ipc -vK

which will also start gpg-agent and print some diagnostics. You may want to redact the output. You can also run

gpg-agent -v --daemon

which should also print some more info.

Thank you, it worked.

Because the rules for downcasing are way to complicate to yield any stable result, the I-D requires that only ASCII acharacters are downcases, that is A-Z to a-z. Here is an example:

I applied https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=patch;h=8d1b5982138c104f3c50663738892fa110193059 on top of 2.2.14.

We fixed that in master and 2.2. Can you please test this with the next release and report or close this bug?

Thanks.

It may be our McAfee, that’s the usual culprit when something is being blocked that we need. Thank you for your help, I’ll let you know if this works for us!

[Randall_Meredith_ESig_7.14.17]

From: aheinecke (Andre Heinecke) [mailto:noreply@dev.gnupg.org]
Sent: Monday, March 25, 2019 2:36 AM
To: Randall, Meredith <MRandall@hoosierlottery.in.gov>
Subject: [Task] [Triaged] T4419: GPG4win not installing on Windows 10 Laptops

• This is an EXTERNAL email. Exercise caution. DO NOT open attachments or click links from unknown senders or unexpected email. ****

aheinecke triaged this task as "Normal" priority.
aheinecke added a comment.

The step where it is hanging at is to register the GpgOL Addin with Windows.

Can you try the hanging command on an elevated command line maybe without the /s switch which is for "silent"

c:\windows\system32\regsvr32.exe "c:\program files (x86)\Gpg4win\bin_64\gpgol.dll

Maybe it gives an error or shows some more information. Alternatively maybe a security software jumps in there and blocks access to loading this dll. Any unusual security software installed?

TASK DETAIL
https://dev.gnupg.org/T4419

EMAIL PREFERENCES
https://dev.gnupg.org/settings/panel/emailpreferences/

To: aheinecke

Cc: aheinecke, mrandall, Rafixmod, ccharabaruk, gp_ast

This is an automated email from the GnuPG development hub. If you have registered in the past at https://bugs.gnupg.org/ your account was migrated automatically. You can visit https://dev.gnupg.org/ to set a new password and update your email preferences.

I'm changing this to testing as the original problem is now fixed with a good solution that properly detects the contents of ms-tnef wrapped messages.

Can you open the command line (cmd.exe) and execute there: "gpg --passwd 6B05B09F" ?

The step where it is hanging at is to register the GpgOL Addin with Windows.

I've recently moved from the Windows 7 system where I saw the problem to a Windows 10 system where Kleopatra works. As Windows 7 will no longer be supported by Microsoft, there seems little point in working on this issue, so I'd be happy if it was closed as Won't Fix.

This looks duplicate of https://dev.gnupg.org/T4317

Thanks for the report. underscore followed by an uppercase letter is actually reserved for the system; thus we should not have used that.

i don't think we need another column without the domain, i agree that it's easy enough to strip.

That keeps the interface the same just in case we ever change the format. It has also the advantage that you can use the tool to extract the mail address from the user id and thus see whether it is valid.

That seems plausible to me. I'm not sure why you'd include the @domain part in the output, since it's all strictly about the localpart. what happens if you provide some upper-case inputs?