Hi Pieter,
On Mon, Mar 05, 2018 at 07:55:17PM +0100, PiBa-NL wrote:
> I would think the ocsp updates already does something similar with base64.
Yes, I thought about OCSP as well since I think it was the first one to
require large blocks. However OCSP contains a single binary record that
it totally makes sense to encode using base64. Regarding PEM, it's an
envelope containing multiple records which are already encoded. Thus the
format already contains delimiters.
> That would be usable for other binary files as well.?. Though i guess .pem
> is kinda readable already and not a binary file..
Exactly, it looks clean and the format specification mandates that readers
must ignore what is located between labels, and be tolerant regarding spacing,
which also implies that empty lines have no meaning for the encoding, thus
that we will not need to be able to send them as part of the uploaded data.
> Unless perhaps support for
> pfx files would get added some day.?. afaik those are in binary format..
I don't know pfx, so I can't say.
> root@server:/etc/haproxy# echo "set ssl ocsp-response $(/usr/bin/base64 -w
> 10000 /etc/haproxy/star_mydomain_com.crt.ocsp)" | socat stdio
> unix-connect:/run/haproxy/admin.sock
> OCSP Response updated!
>
> Not that i have a strong preference, but imho it would be nice to keep the
> way to call similar commands the the same.
I agree on this, which is also why I'm trying to think about other stuff that
we may have to upload. Using an end tag like "EOF" or any such thing would be
problematic for ACLs or maps as it would imply we would not be able to upload
this one as a pattern. Quotes could be part of some future statements and we'd
possibly regret having used them if already used for this. For example we could
imagine one day uploading some JSON parts for certain things.
In the end, PEM and base64 are not much different. We could possibly consider
that :
- anything purely binary must absolutely be uploaded as base64 and that the
end is determined by the base64 stream
- text-based multi-line blocks (like PEM) could be uploaded as-is as long
as they don't collide with our delimiters, and in this case we could use
an empty line to mark the end. At least this would work for maps, acls,
PEM and JSON, and even HTTP headers (if one day we want to implement a
debug mode allowing us to build a request from the CLI and send it to a
server, or if we want to modify some health check strings).
I'm not saying it's anything great nor awesome, but at the moment I can't
think about counter-examples that could painfully break it, nor be hard to
handle (even in Lua it shouldn't be hard, since Lua can register CLI keywords).
Probably that we could in fact extend the CLI syntax in a backwards compatible
way :
<word>[ <word>]* <arguments>*
[optional body]
Most commands don't use a body. Those using a body have to terminate it using
either its own representation known by the command, or an empty line.
"set ssl ocsp-response" takes a series of words in arguments, or a body.
Some commands might even simply support the concatenation of both, ie they
start immediately on the argument, detect the block is not completed, and
read the rest on the following lines till the end is found (either defined
by the data format or by the empty line). This simplifies the syntax of
long commands, to support both the first line as the first series of
arguments, or as the first line of the body.
E.g. we could write (just using maps as a simple example) :
add map foo.txt foo1 bar1
or:
add map foo.txt
foo1 bar1
foo2 bar2
LF
For OCSP, we could have :
set ssl ocsp-response line1
line2
line3
line4===
or :
set ssl ocsp-response line1 line2 line3 line4===
or :
set ssl ocsp-response
line1
line2
line3
line4===
For PEM certs we'd probably never read from the arguments since we don't
yet support this (no need for backwards compatiblity).
Just my two cents.
Cheers,
Willy
