My idea of the simplest letsencrypt client is lego. One binary to rule them all.
My idea of the simplest letsencrypt client is lego. One binary to rule them all.
I do hear your criticism of shell scripting - I've written enough things in Bash and Bourne to be intimately familiar with the pitfalls myself. However the string handling required here is pretty basic (strings are encoded anyway as part of the ACME protocol so no escaping required there; and domain names are just ASCII characters without whitespace (even unicode domains just get compiled down to ASCII) so it's all pretty basic stuff). Plus curl and openssl are both solid tools and pretty standard on most systems (given openssl is used in the vast majority of web servers; you'd probably need that just to run your SSL certs anyway).
I don't have anything against lego either. In fact I'm quite an advocate of Go - having written a number of projects in that language myself. But I do think this is one situation that shell scripts are a technically valid option as well.
> This is a work in progress. Please do NOT run this on a production server and please report any bugs you find!
And it's been in development for at least two years per the dates on the files - with hundreds of commits made at a reasonably continuous pace judging by the code frequency graph.
Either that's a ridiculously conservative warning, or I think there is a problem with something in this approach.
Duuuude! There's an awscli out there that does all that for you, is maintained by Amazon, covers all the edge cases and is forward compatible cause Amazon takes care of that. Instead we have hundreds of lines of gnarly shell script code to compute hashes and prepare HTTP requests :(
Meanwhile, the underlying API have been fine...
The awscli, on the other hand, is the official CLI from Amazon.
But if one is using a shell to launch that binary, then IMO there are two userland binaries: the shell and the binary being launched. In that case, the second binary depends on the first.
Lets assume one really wants to use only a single binary for whatever reason. Could she use busybox? Does busybox have an openssl-like function? I am not sure.
However I can confirm that the BSD equivalent of busybox can easily be compiled, statically, to include an http client, openssl and the other utilities needed for these shell scripts. I use such a binary for daily work.
Note I am not a LetsEncrypt user and have no comment on ACME or these shell scripts or other programs. I am only commenting as an avid shell scripter and user of static, "multi-call" binaries.
Not sure if "one binary to rule them all" really applies.