So why are there different grades of failure? Why is "invalid packet" a less scary error message than "WARNING: message was not integrity protected" when both are equally bad things?

Right. And the MDC detects this and only if says okay you get a good decryption status back.

This warning shall only show up if a message was really modified and not in case of

a simple truncation.

(Testing for now for better visibility. Real or Semi-real bugs with fixes are already set to Resolved)

The described attack is not easy to understand and as of today the
gpg.fail website seems to have the same content as the draft we
received on 2025-10-23. There it states:

Note using the output of --decrypt directly on the tty is a Bad Idea(tm). You won't cat arbitrary files to your tty for the same reason.

https://gnupg.org/blog/20251226-cleartext-signatures.html explains why we have cleartext signatures and how you properly use them. The suggestion of the reporters to remove them entirely is a no-go because there are too many systems (open source or in-house) which rely on that format. If properly used (i.e. using --output to get the signed text) there is no problem. Anyway the suggestion has always been to use detached signatures using two files or PGP/MIME).

Sorry, I don't know Fedora packaging details. Please ask on gnupg-users for help if you want to build gpa yourself on that platform. This bug report is only read by very few people but on gnupg-users you can get the attention of several thousand users and developers.

Spent some time discovering and unfortunately it's Windows's bug in loopback interface.
I wrote a test demo (blocking mode) to exchange data and watched their packets, found that network stack would drop packets when congestion control algorithm is set to BBR2. It seems the second data exchange was broken.

To avoid further noise on this ticket, i've done as requested and posted to gnupg-devel : https://lists.gnupg.org/pipermail/gnupg-devel/2025-May/035875.html

For the records:

A bug tracker shall never be used for discussion because the audience is not as expected. Only very few people follow a certain bug but several hundreds are following discussion on gnupg-devel@. That is basic hacker knowledge.

I am surprised that you don't want to use the issue tracker for issues.
GnuPG's trust calculations are quite clearly broken, by any metric. There's nothing to discuss here.

Heiko, I told you already in T7106 that it is not a good idea to re-open a ticket. If you really want to discuss stuff, take that to a mailing list.

I see two interesting angles from which to think about this Web of Trust calculation:

> I'm not sure i understand why "the latest" should be preferred.

A bit more experimentation shows the same behavior, even if Alice's tsig of Bill is full, not marginal, and even if all signatures are made in the same second, which is the finest resolution that OpenPGP objects can report.

Interesting analysis, thanks for the sleuthing! I'm not sure i understand why "the latest" should be preferred. For example, in the graph made in this example, which part of the graph is the "latest"? Since the path from Alice to Carol is two hops long at least, it's conceivable that one path (A→Bob→C) has both "the latest" tsig *and* "the earliest" tsig, if the other path (A→Bill→C) happens to have been made between the other two tsigs.

I also spend some time with this and the problem is described by this comment in trustdb.c:

No, it is not a bug and I beg you not to change the status again. Don't start the same trouble here as some of you guys did with the IETF WG!

Err, I don't see why I would "need to test" anything further.

This is just one build of PGP and you would need to test all versions on Windows, macOS and Unix. You also need to test against all versions of GnuPG since 1998 (when we started with interop tests). We won't change this in GnuPG and risk regression. If you have a problem with that go and add a fix to your tool - name it bug compatibility or whatever. And please do not re-open this bug.

In T7106#185462, @werner wrote:

This has been implemented and tested to be compatible with PGP - a looong time ago. iirc this was discussed around 1999 but might be only by private mail between the PGP hackers and me. Thus any change now might break PGP - which is still widely used (although mostly for encryption).

We suggest the use of the keyboxd for a reason. The use of multiple keyrings has always been a problem and has been kept on demand from a couple of people. Eventually things change and for a new installation the use of the keyboxd is the suggested way to run GnuPG. Support for pubring.gpg and even pubring.kbx may eventually be removed - not now or in the next year but it may happen. You have been warned ;-)

Indeed, GnuPG's IPC uses TCP connections from 127.0.0.1 to 127.0.0.1 taking the destination port (and a cookie) from a file. We can't change that easily to the new Unix socket implementation Windows recently introduced. I hope there is a way to exclude localhost->localhost from congestion control.

This has always been the case. git blame shows for check_signatures_trust:

Here is a patch against master which normalizes line-endings when verifying text signatures over binary literal data packets

I don't see a bug here and any change in this domain disks a regression with existing data. BTW, the mode byte was not even part of the signed data before signature version 5.

My comment from a year ago still holds true; you may want to fix your testing framework and re-openig this bug iff you can show that there will be no regression with PGP 7 and later.

If you say so, i won't press this. I will just leave this ticket with an observation that even for someone who reads the source code this is not intelligible. At the top of gpgconf_list in g10/gpg.c, the comment says:

Installing language-pack-tr-base fixed the issue. Closing. Sorry for the noise.

In T7454#196228, @werner wrote:

Actually not a bug: In my tests I forgot to unset LANGUAGES and LANG before calling gpg.

LANGUAGE= LANG= LC_MESSAGES=de_DE gpg

Thus this should work. But it did only work when I used

LANGUAGE= LANG= LC_MESSAGES=de_DE.UTF8 gpg

Thus the whole thing is related to the configuration of locale.alias and on whether LANGUAGE is set in the environment (for me it is set to en_US:en

Actually not a bug: In my tests I forgot to unset LANGUAGES and LANG before calling gpg.