On Wed, 2016-09-21 at 13:52 +0200, Daniel Stenberg wrote:
> On Wed, 21 Sep 2016, Gilles Vollant wrote:
>
> >
> > I tried the "binary" option you suggested, and this not perform well. Only
> > the base64 option does the job.
>
> That's crazy talk! Of course you'd need to change some code to make libcurl
> handle such a binary input as I suggested could be a cool way to do it. You
> can't add support for files provided from memory base64 encoded either without
> changing code.
>
> When changing code and providing new features, I think we should go for the
> best and most useful approach given the circumstances.
>
> My experience with people asking for support for in-memory objects instead of
> external files, is that they usually ask for that because either they A) don't
> have a file system at all or B) they don't want to have any external files to
> their application or C) they already have that data in their program's memory
> anyway.
>
> In exactly none of those cases does it make sense for the program to base64
> encode the binary data (which can be huge in some cases) and pass that to
> libcurl, only to have libcurl strdup() that data and then decode it to binary
> again.

I don't think you were claiming otherwise, but just to be clear: there
are use cases for PEM too. If my application has an XML configuration
file I can easily include PEM data in that, but it would be distinctly
non-trivial to include binary data.

We *need* to support both PEM and DER format when it comes from files;
let's not make applications jump through additional hoops to support
both from memory too.

> My suggested approach would be a generic
> how-to-send-binary-data-to-options-that-accept-file-names, and this option
> would then be the first one to use it.

This makes sense to me, as long as it accepts PEM too.

I suppose this is as good a time as any to crawl out of my hole and 
refer to http://david.woodhou.se/draft-woodhouse-cert-best-practice.html

I'm drafting a set of guidelines for "best practice" for applications
which use X.509 client certificates, and would be very interested in
receiving feedback— either in email or as issues/pull requests to the
repository at https://github.com/dwmw2/ietf-cert-best-practice

For the sake of users' sanity, what I say in the current draft is that
applications MUST transparently accept both PEM and DER files without
forcing the user to indicate which it is¹. And furthermore, MUST
happily handle the full set of PKCS#1, PKCS#8, PKCS#12 and various
other formats.

The current state of the world, with each application on my system
supporting a *different* subset of the plethora of file formats, is
insane. And that's even before I start looking at PKCS#11 (qv).

For the case of inline blobs, I had currently written that applications
MAY support only (all types of) PEM files, if their configuration
format is such that that's all they can manage. And that binary DER
support is optional for inline blobs.

I have indicated that it *is* acceptable to require an explicit
indication of whether a given datum is a filename or other reference
(such as PKCS#11 URI), vs whether it's direct inline data. You're just
*not* allowed to make the user disambiguate between the various types
of references (filenames and PKCS#11 URIs, especially).

Daniel, that gracious "permission" does cover the header you're
proposing... although I'm wondering if it might be nicer just to add
new options for 'CURLOPT_SSL_CERT_INLINE' and the like. It might be
easier for applications to check for support that way.

-- 
dwmw2
¹ Bye bye CURLOPT_SSL_CERTTYPE and CURLOPT_SSL_KEYTYPE. You won't be missed.

-------------------------------------------------------------------
List admin: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.haxx.se/mail/etiquette.html