4 ms·

The client will be renamed and moved to the EFF soon: https://letsencrypt.org/2016/03/09/le-client-new-home.html https://letsencrypt.org/2016/03/09/le-client-ne

• atonse 10y ago
  Any plans to make the official client based on Go? I wasn't too happy about having to download a bunch of Python stuff on my server just to get an SSL cert. Reminded me of the days of yore when you had to fiddle with Perl modules just to run basic scripts.
  • greggman 10y ago
    I don't know about an "official" client but but caddy has support built in so you could probably extract the portions you need from that? https://caddyserver.com/ https://caddyserver.com/
  • pfg 10y ago
    I'm not sure if, conceptually, the term "official client" is still appropriate after the project is moved to the EFF and the rename is done. It's basically a move to ensure a vibrant client ecosystem which encourages users to pick the client that best fits their needs. If you're looking for a Go client, lego[1] is awesome. [1]: https://github.com/xenolf/lego https://github.com/xenolf/lego
    • notatoad 10y ago
      It seems like it'd be more accurate to call it a "reference implementation" than an official client. at the very least, it'd be nice if people stopped referring to other implementations of the LE spec as "unofficial clients".
  • Titanous 10y ago
    There are a bunch of great unofficial clients, several written in Go (I like acmetool): https://www.metachris.com/2015/12/comparison-of-10-acme-lets-encrypt-clients/ https://www.metachris.com/2015/12/comparison-of-10-acme-lets...
    • tyho 10y ago
      Unfortunately lots of Go code on GitHub has significant oversights, this included. I remember reporting a DoS bug in a different Go acme library identical to this one I found in acmetool in less than 60s: https://github.com/hlandau/acme/blob/master/acmeapi/ocsp.go#L52 https://github.com/hlandau/acme/blob/master/acmeapi/ocsp.go#... In case it is not obvious, anyone in a privileged point on the network can fill resb with enough data that the program panics due to OOM and crashes. ioutil.ReadAll really needs a big warning in the docs because I have seen this pattern far too often.
      • zachlatta 10y ago
        Yeah, serious +1 to this. I'm amazed by the usage of ioutil.ReadAll in popular Go libraries and tools.
  • mintplant 10y ago
    Doesn't have to be written in Go to produce a single statically-linked binary.
  • wyager 10y ago
    Why go? I can't think of any reason to prefer Go over any other language for this project. I'd prefer a security-oriented program to be written in a safer language, actually.
    • nindalf 10y ago
      Could you explain what you mean by "safer"? If you mean memory safe or free from undefined behavior, Go is exactly that. If you mean a language that has excellent native crypto libraries rather than wrappers over openSSL, Go provides that too. To answer your specific query, Go makes more sense for a LE client compared to Python because you'd simply need to run a binary instead of fiddling around with the source on your server.
      • minitech 10y ago
        “simply running a binary”: - download letsencrypt-auto - ./letsencrypt-auto ”fiddling around with the source”: - download letsencrypt.tar.gz - extract letsencrypt.tar.gz - ./letsencrypt-auto (and there might even be a package available!)
        • nindalf 10y ago
          This is assuming you have the correct version of python installed, right? What if you were on CentOS and the python version is 2.6? Or on Alpine and you simply didn't have python at all?
          • minitech 10y ago
            What if you download a binary and a dynamic library is missing? (This is what happens with GHC on Alpine. Binaries will expect glibc. Packages fix this problem, but they also fix the Python problems.) Another example: I recently wanted to run IDA on Arch Linux, but there are no 32-bit Qt5 packages. Compiling Qt5 is more painful than installing Python.
      • wyager 10y ago
  • creshal 10y ago
    The inofficial clients work well enough nowadays.