On Tue, Dec 05, 2017 at 01:33:23PM -0700, Theo de Raadt wrote:
>That was also the initial design with substantial priv seperation.
>It shouldn't be designed to tap another process potentially running
>with a different uid.
Not wanting to touch processes that run with different user ids, is that
in order to fully eliminate any influence from the other process/uid on
the servproc process? servproc is quite tighly pledged with "stdio
proc". Just curious.
"proc" -- as root, right?
Idd.
acme-client was designed to updates the certs. Only that.
Updating the certs requires communication via either http or dns.
It wasn't designed to start processes and services, kill processes,
etc.
I thought spawning httpd from base was the right direction instead of
rolling my own simple httpd.c (much comparable to the hand-rolled http.c
client that ships with acme-client). A route that I had originally taken
and still think might be viable.
It looks like you are trying to bring in all the heavyweight designs
of certbot.
Why do you have a problem with the little bit of shell script running
at the correct position and privilege level?
Why does it need to be integrated?
Because serving the challenges either via a webserver or via a
dns-server is currently a hard requirement to fulfill the core service
of updating the certs.
I understand the reason letsencrypt came into existence is the web. So
most environments where acme-client currently is used probably already
have a httpd running. But I suspect the demand for acme-client on
non-webservers will rise and it will feel more like a kludge to
configure, start and stop a webserver in those environments.
Having said that, other than "to me it doesn't feel right", the little
line of shell-script idd isn't much of a problem. I'll leave it for now
and we'll see if a desire other than only me might start to exist in the
future. ;)
