[openssl-users] get type of PEM data

[Jordan Brown]

On 3/29/2018 1:08 AM, Richard Levitte wrote:
> In message <1ce93d56-6fa4-1bae-d440-5ab843900e40 at jordan.maileater.net> on Wed, 28 Mar 2018 17:10:40 -0700, Jordan Brown <openssl at jordan.maileater.net> said:
>
> openssl> Matt: Indeed, looks very promising. Now if only we were on
> openssl> 1.1.1 :-(. I'm a little surprised that it doesn't read from a
> openssl> BIO.
>
> It's certainly possible to add such an API.  As a matter of fact, we
> do have that internally, specifically for PEM files...  have a look in
> 1.1.1's crypto/include/internal/store_int.h.  That's not the initial
> intention with the API, though...

To be clear:  it doesn't bother me one way or the other.  It just seemed
like the general design for "reading data from a stream" for OpenSSL is
to read from a BIO, rather than directly providing "read from file",
"read from memory buffer", et cetera.  I was surprised to see a new
feature that didn't follow that pattern.  I *do* need "read from memory"
for my application, but writing a temporary file would not be a problem.


> Also, I can't quite shake the feeling that a BIO API would be a bit
> shaky.  Internally, the file: scheme loader opens all files in binary
> mode, as it's designed to detect if the file is a PEM file or raw DER,
> so the question remains, if we would open up a BIO STORE API, what are
> th expectations?  Will people open such files in binary mode at all
> times?  Should that be a content type agnostic interface (i.e. should
> it detect if the file is PEM or raw DER), or should there be separate
> functions for PEM and raw DER content?

I would expect the behavior to be identical for a BIO interface and any
other - which, I guess, would mean that the BIO would need to be in
binary mode.

> Please note that for each question, we're getting further and further
> away from the idea of having an interface where the caller doesn't
> need to know much more than how to indicate where to load stuff from,
> to an API that almost becomes a 1:1 mapping of PEM and d2i functions.
> When we've come that far, what have we gained?

Agreed that for this interface the caller shouldn't need to know what's
being read.

-- 
Jordan Brown, Oracle Solaris

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20180330/395e0694/attachment.html>