der: implement a buffered pem reader

[baloo]

This fixes the parsing of x509 certificates from Pem format and brings a test for it.

[baloo]

I don't see how there could ever be two instances of borrow for this refcell and I think this is safe

[baloo]

oooh, fun! I triggered the fuzzer!

[tarcieri]

@baloo looking at this so far it feels like a lot of indirection. You have PemReader wrapping BufReader wrapping pem_rfc7468::Decoder (itself another wrapper around a buffered reader). And I'm not sure why you need RefCell at all?

It feels to me like PemReader should own an e.g. Buffer type, and ideally never use it unless a peek operation has been previously performed, which is the only thing which fills the buffer.

[baloo]

Yeah, it could very well be,
The refcell is because of the Decode::peek_header where I don't have mutability and because of its nature, I can't just assume I have stored enough in the buffer already.

[baloo]

I'd be easier if I was to just base64 decode the whole payload and have that in a buffer. Any opinion?

[baloo]

I'd be easier if I was to just base64 decode the whole payload and have that in a buffer. Any opinion?

pem feature pulls alloc. I think that flies. I'm not aware of any pem with unlimited size.

[tarcieri]

I'd be easier if I was to just base64 decode the whole payload and have that in a buffer. Any opinion?

That's how the existing Document types work for decoding PEM, so you'd just be reinventing the wheel.

pem feature pulls alloc. I think that flies. I'm not aware of any pem with unlimited size.

They do that because they use the Document type.

If this feature is implemented correctly, it can eliminate the alloc dependency.

The ssh-key supports heapless PEM decoding and encoding this way.

[tarcieri]

This looks great now