I pushed the change to master.

I think this might be the same as T4820.

I've just pushed ad55de70930543c1681b11e4bd624be074122b23 onto branch dkg/fix-4855 as a proposed fix, to permit --trusted-key to accept a full 20-byte fingerprint.

Latest one (gnupg 2.2.19)

(I stripped the report down to its core)

Sorry but that really strange.
I need to regenerate those files.
Could you please describe what needs to be done to have proper version?

Do not use arbitary libtool versions or use autoreconf - this is maintainer-only and any problems are not considered a bug.

With the fix of T4623, this bug is now fixed.

Fixed in master, using Libs.private support.

Fixed in master.

Yeah, this can be done.

I already tried reinstalling gpg4win without first uninstalling it (I thought it might repair corrupt files) but now I uninstalled first and it is working again.

I searched through C: and D: and found it in D:\Programme\GnuPG\bin and in D:\Programme\Gpg4win\bin - both seem to be created by gpg4win. I'll try reinstalling, hopefully without deleting my private keys...

The DLL libassuan-0.dll was not found or the system somehow found.
Do you have other versions of GnuPG or Gpg4win installed? Please search the system for copies of the above mentioned DLL?

Fixed in master and 2.2

Really interesting: The code didn't changed since since 2003 and the bug must have been there all the time. It does happen only for 25% of the certificates with CR and LF; the others have padding characters at the end '=' which is also an indication of the end of the base64 block. I wonder why this has not been reported more often; maybe because most people import binary certificates.

Wald certificate will be fixed very soon. But as it is not fixed yet, I provided an http link, not https for you.

Thomas, please provide a sample certificate. I can't access the intevation site to see whether one of the links has the cert. And pretty please fix the wald certificates!

No, this depends on the version of Libgcrypt. Sorry, won't be documented or changed. Thanks for the report, though.

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.

Building with -fno-common now works for me on 2.2 and master. Thanks for the patch.

I took your patch but modified it to define EXTERN_UNLESS_MAIN_MODULE only at one place.

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.

Install the zlib development package, its name is often "zlib1g-dev". The source requires the header because we plan to eventually support compression.

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.

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.

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)