Some historic integer encoding glitches from Peter Gutmann's style guide:

Some Microsoft software will generate negative values about 50% of the time
whenever it encodes anything as an INTEGER because it ignores the fact that
the top bit of an integer is the sign bit (this is still occurring in
programs released as recently as early 1998).

Telesec:
The certificates encode INTEGER values incorrectly by setting the high bit,
which makes them negative values.  This is particularly problematic with RSA
keys since they use a hardwired exponent of 3,221,225,473 (!!!) which always
has the high bit set (0xC0000001), so all the RSA certificates have invalid
encodings.  This was corrected in late 1999.

The encoding of the Certificate may follow the BER rather than the DER. At
least one implementation uses the indefinite-length encoding form for the
SEQUENCE.

And I don't expect that that everything is correct now. As long as we don't have a clear security issue here, we should not add extra constraints on DER or even BER parsing.

For the record (to show we don't hide a problem), I add some information.

The reporter published: https://github.com/JakeGinesin/gcrypt-p256-malleability-poc

It seemed that the reporter (also) claimed that a git repo could be weak/vulnerable when X.509 signature (with a relevant curve key) is used to validate the commit.

Speaking about git and its use of cryptographic signature, I address some technical information here.
(Because I don't understand the reporter's claim)

• When a representation of signature (which validates a commit with its public key) changes, commit id is changed, because the signature itself is a part of commit data to be hashed.
• I don't think this causes a severe problem for a git repo. If this is somehow problematic, we should note that there are other possibilities for third person to change the representation of a signature inside a last commit (to publish at his own site), keeping the validation valid.
  • For PEM, the CR-LF ambiguity allows multiple representations in ASCII (which is used for git commit) when the signature is represented by multiple lines. See RFC7468.
  • (For OpenPGP, ASCII armor is more lax which allows multiple representation in ASCII other than CR-LF ambiguity.)