No info received; either really malware downloaded from a fraudster site without proper checking on bare coincidence with other updates.

From where did you downloaded it? Did it show a valid issuer for the software (Intevation GmbH)?

There are likely some bugs in the new code and I also want to do some improvements; see rGb4f1159a5bd7. But things should basically work as before and thus I set this again to testing

"log" and "lock" are easy typo/confusions to make, @aheinecke was just trying to understand your report better, since there wasn't much information in it.

At no point did I mention log files ? So not sure where that is coming from.

apologies but I do not understand this issue. Please clarify. Were you having issues with "log" files or "lock" files?
What was your issue?

I'm using enigmail 1.9.9 because I'm on a mail client that doesn't use WebExtensions, so it's using gnupg for keyserver stuff. In this case that means I've been able to verify it's a gnupg issue (both Kleopatra and enigmail displaying the same issue as CLI).

@Moonchild wrote:

using enigmail with the new version

Just registered to report pretty much the same.
I've been using gpg 2 for a long while and it's been doing just fine, up to the point where people started using keys it didn't recognise that require a later version.

i'd be unlikely to ship anything as /etc/gnupg/gpg.conf or /etc/gnupg/dirmngr.conf just because of the mess that admins have to deal with when shipped config files change.

Arggh, gpgconf uses its own option parser so adding the global config file there will require some extra work.

@dkg You might find this interesting. Debian could do stuff in /etc/gnupg/gpg.conf or /etc/gnupg/dirmngr.conf without patching GnuPG to change some defaults.

All done in master with the latest libgpg-error (see T4859). There is always a global configure file in /etc/gnupg (or whatever "gpgconf --list-dirs sysconfdir" prints). The name of the configure file is the same as the user config file (gpg.conf, gpgsm.conf, gpg-agent.conf, ...) but for gpg.conf no versioned config names are used.

Okay, we now have global conf files in master. The extra flags to ignore or force certain options will be added to libgpg-error.

Seems that the public key needed to be exported from the Linux side and imported on the Windows side. Once this was done, the rest of the key information is displayed under Windows for the gpg --card-status.

Older version of GnuPG had a rare bug in the keyring update code.

I'd like to re-report this bug for version 3.1.11-Gpg4win-3.1.11
in Windows 10 version 1809 build 17763.1039 and version 1909 build 18363.657.

OK. The reason I'd posted on here was because KMyMoney was working properly until I tried to use the encryption.

Hi,
Thanks for the report but, but we are not developers of KMymoney, I can only offer to help the developers if they have questions but please rather report a bug at bugs.kde.org regarding that so that they can figure out what might be wrong.

Am I right as to this being due date?

I renamed the ticket so that others don't think we generally don't support Office2019 because I use it myself and it works for me.

Hi, I am not sure what you mean by "The Icon does not recognize the created certificate".
Does it show you that the mail is unsigned when you view a signed mail?
What does the tooltip of the icon say?

I remember that I tested inline content-disposition handling in Outlook without GpgOL and try to do the same handling as Outlook would handle them. But then at the very least It should be shown as an attachment and not hidden.

I've just tested this with GpgOL 2.4.6~beta3 as well, and while the i see the same issue :( (though the legacy display part is not shown, thanks to your fix of T4796).

Thanks! taking screenshots is definitely tedious. I just redid the screenshots for all the sample pgp/mime messages with GpgOL 2.4.6-beta3, and i can confirm that it looks like you've resolved the matter.

Hi Andre, did you already get anywhere with this task? Thanks a lot in advance, Joachim

I am also having this issue, but it is with Decrypt & Verify. It basically renders the app unusable. What happens is that when you click the button another window opens but it seems to be in the background, because it just looks white and it won't appear when you click on it. This happens for all files it seems.

Hi Andre,

1. I am the sender, and can guarantee both correct keys were used. The same two keys do work in the Kleopatra clipboard tool (with recipient tool's email parser) , just not with standalone files (at least not with his file decryption be tool).

1. It could be a user error on my part, but the Kleopatra GUI is showing both keys with check marks, so I have trouble imagining what I could do different.

1. Recipient is not using Kleopatra, as noted in the original ticket. It is possible (and I suspect, likely) that the problem is an incompatibility between these two tools. If this is the case, then we need to find which tool is not following the standard, or perhaps the standard is ambiguous.

1. Since filing the ticket I have discovered that if I (sender) use command line GPG (ugh!), the recipient can decrypt the file with his tool. This seems to point the finger towards Kleopatra as the more likely cause of the problem.

1. There was a screenshot included in the original ticket showing very clearly the recipients tool doesn't recognize the presence of a second (i.e. recipient's) key.

I am attaching the screen shot from the recipient’s tool again, for your convenience.
I am also adding a screen shot of the my (i.e., sender’s) set-up in Kleopatra.
Rich

G. Richard Newell
Assoc. Technical Fellow, FPGA Business Unit, Microchip Technology
(408) 643-6146 (office), (408) 882-4785 (mobile), +1 (925) 478-7258 (Skype)
PGP: (2009 DSA-1024, ELG-4096) B751 FC13 8B4E 49DA 2270 35A2 20E4 E66A D0D0 2E34

     (2016 SSA-4096, RSA-4096) 65F5 CCD6 23B3 BD3D CEDE AB58 171F F4DE E7D0 3ECA

From: aheinecke (Andre Heinecke) [mailto:noreply@dev.gnupg.org]
Sent: Monday, January 27, 2020 12:37 AM
To: richard.newell@microsemi.com
Subject: [Task] [Closed] T4824: Encrypted file appears to not be encrypted by recipients public key

EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
aheinecke closed this task as "Invalid".
aheinecke added a comment.

Hi,

I have difficutlty to accept that as an issue in our tracker. Somehow the GUI for Kleopatra appears to be confusing for your "Sender" which apparently is not you, correct? This results in the wrong keys selected for encryption.
With this amount of information I cannot see any path of change for our software.
Could you maybe provide a screenshot how the recipient selection looks for your user in Kleopatra, so that we can discover why it might be confusing or why the recipients key is not selected correctly?

I'm setting this issue as "Invalid" in the meantime. Not out of disrespect or so, only because I don't see how the information from this issue can currently lead to a change in our software. I can change the status later again.

Thanks,
Andre

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

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

To: aheinecke

Cc: aheinecke, grichardnewell, Neurone, 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 have difficutlty to accept that as an issue in our tracker. Somehow the GUI for Kleopatra appears to be confusing for your "Sender" which apparently is not you, correct? This results in the wrong keys selected for encryption.
With this amount of information I cannot see any path of change for our software.
Could you maybe provide a screenshot how the recipient selection looks for your user in Kleopatra, so that we can discover why it might be confusing or why the recipients key is not selected correctly?

I believe "geometry" field value from [SignEncryptFilesWizard] can help in debug.
But I'm not sure about posting it here: does it contain any sensitive info?

Result of renaming:
It helped, but only for 1st run. Then problem occurs again.
I've tried to restart the app, but it doesn't help.

Thanks for the report. I have observed that the Window is sometimes opened in the background so I accept that this is an issue for Kleopatra somehow and we need to look into it. I know that your problem is a bit different but that is related.

I've downgraded to gpg4win-3.1.10 - still be reproducible...

An updated build is available here: https://files.gpg4win.org/Beta/gpgol/2.4.6-beta3/

thanks for the fix, @aheinecke ! can you post screenshots of the changes? or do you have a nightly build i could test?

I have checked the eMail header of the eMail from Sender X in the Exchange mailbox of User A and I see Sender X is using Mozilla Thunderbird and I tested it with Thunderbird also, but it works for me.
I cannot provide all details of the eMail from Sender X because it's a customer of another customer, but I have replaced the IP addresses and other private information in the eMail header and this is the result:

thanks for the report. This is definitely a sore spot and we need to look at it again. I did some experiments a while a go trying to fix this issue but so far I was unable to get to stable results so for now this is a known issue.
I'm a bit suprised that the workaround with not having the mail open does not work for you.

This again,...
That error always occurs when the Exchange Server is unhappy with the structure of our PGP/MIME Mails. It has nothing to do with S/MIME, that is only because Exchange only knows about S/MIME, so our PGP/MIME Mails also claim to be S/MIME mails.

Display now looks good to me in all cases. We still keep the subject when a reply / forward is done, but that is the same as before. To do this properly I would have to actually do the protected headers sending,.. as then I could automatically flag such a message to be sent with protected headers. But that would be a new feature and I rather work on properly doing BCC sending as the next privacy enhancing feature.

At least one configuration error I could identify by myself: Kleopartra -> GnuPG-System -> Smartcard -> Connecting Reader with port N. If it is written: Yubico YubiKey OTP+FIDO+CCID 0 then Yubikey is recognized. I forgot to write "Yubico Yubikey" at the beginning and the "0" at the end. Now smart cards and Yubikeys are working for gpg. What is still a problem is SSH. A SSH key is on smart card or the Yubikey.

Werner, no silly questions exist, only silly answers are existing. However, Yubikey is enabled for usb. I using Yubikey Manager a GUI, for the USB interface it is enabled: OTP, FIDO, FIDO U2F, OpenPGP, PIV and OATH. Thanks also for the suggested command line test. Indeed an error code shows up:

Maybe a silly question, but let's be sure: Is the Openpgp app enabled on that Yubikey and is it enabled for usb? I can't remember the Yubikey commands on how to check this but tehre should even be a GUI. These days I use the new gpg-card tool to manage my Yubikeys (from GnuPG master).

Please, note the following uncommon behavior:

I'll keep this on needs triage because I don't know what the issue could be. I have a yubikey 5 at hand and just tested it with Gpg4win 3.1.11. It works without problems.

note that it *does* sometimes hide the legacy display part, for some messages, including unfortunately-complex -- that's good! -- but maybe this points to some internal inconsistency:

there is no way to handle this correctly with such messages. The PGP Standard says that PGP Messages may have every encoding. This is a reason why we always talk about "you should use PGP/MIME" as this is basically PGP with added handling for content meta information like the text encoding.

This is fixed now.

This is fixed in Gpg4win-3.1.11

We currently do not have the resources to work on it as our focus is more on GpgOL.

Any news about adopting GPGrelay to GnuPG > 2.1?

Thank you for the good report.

Thanks for the report.

Will be released with 3.1.11

This is done in 3.1.11

Will be greatly improved with 3.1.11