To be released with 1.7.0

For the two first cases (n->len) this is not a problem because len is an int. For the other cases it is better to use a reasonable upper limit to avoid excessive memory allocation.

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.

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

Applied the change in: rK86c6e972421a: Fix a memory leak in _ksba_ber_decoder_decode.

Looks like this spot was missed when T5037: dn.cpp:181: suspicious loop was fixed. In libkleo's copy of the DN parser I applied the fix in 2023. Too many copies!

I found a possible leak and a possible access of freed memory.

See the gnupg-devel mailing list for more discussions. Subject: libgcrypt P256 signature malleability via weak DER enforcement"

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

Please review the patch and feedback.

A workaround exists with the new option --ignore-crl-extensions.