Trailing whitespace in ASCII armor causes key import to fail

[dmnks]

A trailing whitespace on the END PGP PUBLIC KEY or BEGIN PGP line shouldn't make us barf on the otherwise well-formed public key.

Details & reproducer in the original bug report:
https://bugzilla.redhat.com/show_bug.cgi?id=2124457

[nwalfield]

FWIW, this appears to be a non-issue for the Sequoia backend:

$ LD_LIBRARY_PATH=/tmp/rpm-sequoia/release ./rpmkeys   --import /tmp/bug2124457.asc 
$ echo $?
0

[nwalfield]

I also can't reproduce this for the internal backend:

$ git describe
rpm-4.18.0-rc1-11-gcef75b3ed
$ ./rpmkeys   --import /tmp/bug2124457.asc 
$ echo $?
0

[pmatilai]

That's because the reproducer was buggy, ie missing the problematic whitespace 🤦
But indeed, this only affects the internal OpenPGP parser.

[pmatilai]

...and so it begs the question whether it's worth bothering to fix at all: it's not a common thing, it's not a hard to work around and the internal PGP code is supposedly frozed for anything but critical fixes. This isn't one.

[nwalfield]

Indeed, I think there are worse bugs in the internal parser (e.g., not being able to deal with some subpackets). Nevertheless, if we want RPM to deal with such malformed certificates, perhaps it makes sense to add a unit test, which I'd be happy to contribute.

[yangchenguang94]

Hi, I debugged the code of gunpg2 found that it seemed to have special treatment on \n \r \t and whitespace