Thanks. Fix goes into 1.37.

It has been fixed in the repo for nearly a year, see T4459. A new release is urgently required and will follow in the next days. I close this as a duplicate.

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?

Thank you for the detailed report.

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

Funny. I looked into the history of that function: @dshaw removed the option --list-trust-path from gnupg 1.x in December 2002. He commented

In T4817#132207, @dkg wrote:

(if you don't want to publish the full strace output here because you're concerned it might leak some information about your machine or your network, but you're ok sharing it with me personally, you can send it to me privately by e-mail, encrypted to the OpenPGP certificate with fingerprint C4BC2DDB38CCE96485EBE9C2F20691179038E5C6, and sent to one of the e-mail addresses associated with that certificate. please make a note here if you do that)

In a private mail someone else reported a similar problems and explained that gcc-10 will change the default from -fcommon to -fno-common. I think this is again a bad move in compiler development. Replacing the de-facto standard C compiler behaviour with something _allowed_ by ISO-C. No industrial grade toolchain would ever do such a silly default change - too many customers would rightfully be angry with them.

Yes. With LTO turned on the object files must not contain the same data blocks.

maybe gpgme should be changed to parse --export-ownertrust instead?

Thanks for reporting this this. Your patch is correct.

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.

You mean that common blocks can't be used anymore? The RISC-OS had this problem but it was the only architecture I was aware of that required "extern" trickery.

That means that the GnuPG Backend does not work. I do not think that the office update is the reason, me and others use GpgOL with the most recent versions of Office Pro Plus without issue.
Have you possibly modified you gnupg config files? If there is a bad value in there it would result in such an error.

We briefly talked in the OpenPGP WG about the u32 problem and agreed that this is not an issue for 2440bis. The mismatch between creation date and expiration period is one of those minor PGP flaws. PGP-2 even used days to specify the expiration period.

Avoiding a failure for older versions means that the test suite won't catch this particular bug if it is reintroduced in future versions. That seems suboptimal for me, but given the complexity of the dependency chain, i don't know how to solve it. I prefer just raising an error with older versions of GnuPG as with rMf2aeb2563ba2 , as this is a test of the json interface, which isn't in widespread use yet.

Changing back to wontfix given the wontfix resolution of T4826

This is not a problem for 2107 (when you and i are 6 feet under). it's a problem well before then for anything that has an expiration date of 2107 or later (as demonstrated by the legitimate example certificate here today).

I would like to understand why this changed. T4061 might be relevant here. This has been fixed after the 2.2.19 release.

Well thanks for reporting it ;-)

I don't care; encryption won't work for us 6ft under. (This is a protocol problem which someone should address in a couple of decades)

That looks pretty much like another gawk regression. The easiest fix is to install another AWK version (e.g. mawk).

This is a problem for gpgv and gpg as well. gpg reports:

It looks like at least for OpenPGP, the layer below GPGME is also broken for expiration dates in this time window (see T4826)

I don't mind a workaround that avoids an ABI/API fix as long as it defers actual failures until 2038.

I'm reopening this because i think users of these 32-bit platforms are going to run into issues before 2038 happens. Certs could appear expired before they are actually expired, for example, because of the wraparound time.

I would prefer to have a procedure that do not reset PINs to their default values, but as long as all PINs are set to known and valid values when KDF is setup it will not make the token unusable after that, so it seems reasonable to me.

Or, #5 would be:

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.

thanks for looking at this, @aheinecke ! if you or @werner know of any internal side effects where this does matter, it would be great to add a test that documents them.