The int-truncation change breaks other things. I noticed this by chance in the interactive mode due to warning noticed. Before we ever do such things again we need to have regression tests for setting preferences. Or manually check everything. Need to do a 2.5.16 tomorrow :-(

We need to explain and debunk this attack after its publication,

t-stringhelp change was pushed by rG8a95e963d53a: common: Fix the test of t-stringhelp.
For int-truncation, I pushed the change rGbcd87ea2b2da: misc: Validate the value on the use of strtol.

The problem is that a user may unintentionally use the suggested filename without checking that it does not harm to write to this file. It is better not to present a default name at all.

There are a lot of other ways to confuse the user. We can't fix them all because the whole purpose of a cleartext signature is to make it easy to use in legacy environments like an BBS. Modern systems use MIME to handle this in a more stringent specified way. For any use it is stongly suggested to check the actual signed data which is avaialable with the --output options. At least a sanitizing viewer should be used which filters out all escape characters (something like cat -v |less).

We have seen wrong encodings quite often in the past and thus we won't apply the patch. After all the armor header is a different layer and could also be applied or removed by other software or tools. The integrity of an OpenPGP message does not depend on its concrete outer encoding.

For someone who considers the rejection is the requirement of the spec., here is a change:

Here is a revised patch (hopefully the last one):

Here is a patch (revised since the email of mine):

For t-stringhelp.c, here is a fix.

For

openpgp_oid_from_str has a wrong memory-safety assumption

For Integer Overflow in literals_seen, I think that the claim is wrong.
When literals_seen becomes two, GnuPG stops processing to return an error.
It's not possible for GnuPG to keep processing.

For Integer Truncation of Arguments report, since the int value is limited to one-octet value, we could add check for the length of input when we use strtol.

We have fixed it but the commit also states:

I agree because the original purpose from the 90ies to enable the use of signed patch files in the Linux kernel community was never actually used and GnuPG stopped the distribution of patches from version to version many years ago. Thus I agree we should hide this option behind a compatibility flag.

Added a compatibility flag in: rGad0c6c33c3d6: gpg: Do not use a default when asking for another output filename.

Fixed in rG115d138ba599: gpg: Fix possible memory corruption in the armor parser.

Fixed in rGdb9705ef594d: gpg: Avoid potential downgrade to SHA1 in 3rd party key signatures.

Fixed in rG8abc320f2a75: gpg: Error out on unverified output for non-detached signatures.

This feature should be only enabled with a compatibility flag.

Mitigation would be: adding context validation in add_onepass_sig function, which checks WHAT of armored input.

This has a serious usability issue. If you cancel the password entry when exporting it reports success and creates an apparently valid secret key file but without the subkey you intended to export. So worst case the user thinks he has a backup but instead has no backup :/

works

works as described by Ingo

What is a partial CRL; I have never seen that and IIRC the specification for that was not complete.

For what it is worth, I think that my patch is more standard compliant then yours because it checks if there is a partial CRL.

I think 289fbc550d18a7f9b26c794a2409ba820811f6b3 implemented this wish from 2016 :) @werner please read the full report and then close it as fixed if you agree. I find it a bit funny that we both came independently to the same conclusion, that it should be handled differently even if the standard says otherwise. Because the behavior from the standard does not make sense and is in contradiction to other parts where it says that each CRL must contain all revocations.

As part of this the "Change Reset Code" button should be hidden in the general user interface.

This is about showing the corresponding about dialog text for the disable support option.