regression: 0.081 fails to parse PEMs that 0.080 parsed fine

[dakkar]

version 0.080 happily passed the attached test, 0.081 fails most of it and hangs on the last subtest.

pem-parsing.t

Right now I've added code like this to deal with the problem, I hope you have a better solution:

sub _massage_one_key {
    my ($input_pem) = @_;

    my $was_ref = !!ref($input_pem);

    return $input_pem if $was_ref && ref($input_pem) ne 'SCALAR';

    my $pem = $was_ref ? $$input_pem : $input_pem;

    my ($begin,$body,$end) = $pem =~ /(---+BEGIN[\s\w]+---+)(.+?)(---+END[\s\w]+---+)/;

    return $input_pem unless $begin && $end;

    $body =~ s/\s+//g;
    $body =~ s/\G(.{1,64})/\n$1/g;

    my $output_pem = "${begin}${body}\n${end}";

    return $was_ref ? \$output_pem : $output_pem;
}

[karel-m]

PEM parsing is currently done by libtomcrypt functions. It is possible that the old perl implementation was more relaxed as for the key format.

If I understand correctly you need to load PEM keys like this (without newlines)?

-----BEGIN PUBLIC KEY-----MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE3VU0nT1p5W0zKHDknAgQpsOODuM2/AoZ/6wNqC9AoUCEpQempFg0aBqxleOP0uW0HG1YwCnOF8N0D8Q2RR2mlw==-----END PUBLIC KEY-----

or

-----BEGIN EC PRIVATE KEY-----MHcCAQEEIFF9oAGC6vxNLIU8D+nuvM8ms1QQlPtpGzQTfzEBVB06oAoGCCqGSM49AwEHoUQDQgAE3VU0nT1p5W0zKHDknAgQpsOODuM2/AoZ/6wNqC9AoUCEpQempFg0aBqxleOP0uW0HG1YwCnOF8N0D8Q2RR2mlw==-----END EC PRIVATE KEY-----

or even

-----BEGIN PUBLIC KEY-----
MHcCAQEEIFF9oAGC6vxNLIU8D+nuvM8ms1QQlPtp
GzQTfzEBVB06oAoGCCqGSM49AwEHoUQDQgAE3VU0
nT1p5W0zKHDknAgQpsOODuM2/AoZ/6wNqC9AoUCE
pQempFg0aBqxleOP0uW0HG1YwCnOF8N0D8Q2RR2m
lw==-----END PUBLIC KEY-----

I think we should stick to the standard which AFAIK requires "-----BEGIN LABEL-----" and "-----END LABEL-----" on a separate lines. See https://www.rfc-editor.org/rfc/rfc7468#section-3

ping @sjaeckel

[sjaeckel]

After reading that part of RFC7468 again, I've seen the following line:

The choice of parsing strategy depends on the context of use.

Currently there's only strict parsing implemented and I didn't even think of having support for a relaxed parser when I wrote this. I'm undecided whether that'd be a good example of Postel's Law, where it wouldn't really hurt if we weren't that strict.

And now with my libtomcrypt hat on: Since neither OpenSSL nor OpenSSH accept that relaxed format, I'm pretty sure we're on the safe side with the decision to only support strict parsing.

@dakkar Still I see where you're coming from and I also did something similar in the past, but maybe it's time now to fix the producer of those malformed PEM files? :)

[dakkar]

oh, the producer has mostly been fixed. I would still investigate why a malformed PEM input can make the libtomcrypt PEM parser hang