4 ms·

If you want to be super minimal, I prefer acme.sh[1] instead. It even comes preconfigured for various DNS providers[2], and you can even create your own hook if

• thayne 4y ago
  If you have over a thousand lines of bash (or any other kind of shell code really), that is a pretty big red flag that you probably shouldn't be using bash IMO.
  • delusional 4y ago
    If you want to issue a certificate in an environment where you only have a shell, it's the only language you can use. Sometimes you write in shell because it's the lowest common denominator.
    • encryptluks2 4y ago
      • delusional 4y ago
        Not everything I do is a job.
      • throw0101a 4y ago
        > If you only have shell on your servers then it is time to start looking for a new job. Perhaps you wish to have "real" certs on appliances like F5s and Isilons (FreeBSD-based) where you can't install extra stuff, but where curl and openssl (and bash/zsh) are present. Or perhaps you want to run simple software that you can actually audit. While "over a thousand lines of bash" may take a little while to examine, good luck auditing Zope, which is what certbot pulls in as a dependency: * https://packages.debian.org/bullseye/python3-certbot https://packages.debian.org/bullseye/python3-certbot * https://packages.ubuntu.com/jammy/python3-certbot https://packages.ubuntu.com/jammy/python3-certbot
        • encryptluks2 4y ago
          Here we are talking about a lightweight C executable though that doesn't have those dependencies. You are also not limited to provisioning certificates on appliances as well, and in those cases I don't think have a thousand line bash script offers anymore security (probably less) than a full-featured C program.
          • throw0101a 4y ago
            Except you have to be able to compile the C code into an executable, which may not be possible on an appliance.
            • ClumsyPilot 4y ago
              appliance as in a router or a washing machine? who, ever, would not pre-compile and distribute binaries in a situation like that?
              • throw0101a 4y ago
                At my last job I ran an Isilon: I could upload a cert for the HTTP server via the web UI, but there was no ACME client. I could SSH in, drop dehydrated and have it work because all I needed was a shell, curl, and openssl. Similarly with F5: there is (was?) no native ACME client (at least a few years ago when I first looked at it). So I download dehydrated and used various CLI interfaces to schedule automated runs and importation of the certificates. There was no pre-compiled binary, and no compilers, on either system, and so talking about a "lightweight C executable" is non-sensical. Further, even if we (managed to) compiled things off-host, when we did an OS upgrade on either system, a whole bunch of libraries would change and we'd have to (remember to) re-compile. There is no such worry with a shell script. If you want to have ACME-fetched certs on a general computer system, then compiling a C program (large or small) is an option. But there are scenarios where compiled/compiling C programs is not an option, and you telling me otherwise when I have personal experience of these situations takes some chutzpah.
      • mr_toad 4y ago
        If you’re provisioning an immutable VM or a container you don’t want to add unnecessary cruft. The official LetsEncrypt client and its > 100 dependencies is a non-starter.
    • thayne 4y ago
      Well, if you have to use shell that's one thing, but I would be hesitant to use such a large shell script for something as important as certificate issuance in an environment where I didn't have to.
      • linsomniac 4y ago
        Just as a counter point, I've been using acme.sh for ~3 years now and it's been rock solid. I get your point, and was pretty shocked to find acme.sh, but after the certbot PPA made a giant mess of my system I gave it a try. On the other hand, why should I balk at running thousands of lines of bash, but be fine with thousands (or many more) lines of C, Python, PERL...? You can write crappy or beautiful code in any language...
    • Snelius 4y ago
  • superkuh 4y ago
    On the otherhand, if you're a user and not a developer, you know something written in bash will be written to run on any machine out there. Doesn't matter if it's old or new. Whereas if it's written in C++xx or Rust or the like it'll only compile/run on rolling release distros (or for the 3 months after a normal distro is released that it's up to date).
    • nicoburns 4y ago
      It might only compile on a machine with a recent compiler if it’s aggressive with using new language features, but why would need to compile a Rust/C++ version from source? A compiler binary will run jut fine on old distro versions.
      • netheril96 4y ago
        On old distros you need to install the latest libc and libstdc++/libc++ to run them. I’ve tried many times in the past and never succeeded.
        • nicoburns 4y ago
          Typically projects will compile the binaries on systems with a much older version of libc (but the latest compiler) specifically to avoid this problem. If they’re not doing this then I believe they won’t work on older systems even if compiled with old compiler versions.
    • steveklabnik 4y ago
      Bash isn’t on non-UNIX machines by default. I could run a C or Rust produced binary just fine, but I couldn’t run that shell script.
  • majou 4y ago
    Stop bashing on bash. It has limitations, and quoting takes a hot minute to grok, but those don't come into play for a surprising amount of medium-large projects when used properly. I use POSIX sh only and get by with maintainability and handling failure modes just fine.
    • whateveracct 4y ago
      ShellCheck and unofficial strict mode make bash a pretty nice language.
    • thayne 4y ago
      Bash is great for cases where you are gluing together a bunch of other commands. But it also has a lot of pitfalls, that something as large and complex as this will absolutely run into (to be fair, so does c). As a specific example, the ACME protocol requires working with json. Doing this in bash is very difficult and error prone, especially if you want to avoid a dependency on something like jq, as this does.
• zdw 4y ago
  I use this and it's pretty great. Also it can be highly locked down - run as it's own unprivileged user, with access only to directories served by another webserver for the ACME handshake, storing certs, and a tightly restricted sudoer to restart the webserver on cert cycle.
• throw0101a 4y ago
  > It even comes preconfigured for various DNS providers[2] Also, CLI utility that supports a bunch of APIs: * https://github.com/AnalogJ/lexicon https://github.com/AnalogJ/lexicon
• klysm 4y ago
  Minimalism is much different than portability. I don’t consider heavy bash scripts to be minimal.