Hacker News Reader

Comment by ran290 | Hacker News Reader

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

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.

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/

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

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".

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...

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#...

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.

Yeah, serious +1 to this. I'm amazed by the usage of ioutil.ReadAll in popular Go libraries and tools.

Doesn't have to be written in Go to produce a single statically-linked binary.

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.

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.

“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!)

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?

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.

Go is not memory safe. It admits null pointers and a whole host of incompleteness bugs.

Rust and Haskell are both examples of safe languages. These languages admit very few bug classes. Both also compile to binaries; I'm not sure why you're touting that as a feature of Go.

That's not even a useful feature in this case. Running a python program is just as easy as running a binary from the user's perspective.

The inofficial clients work well enough nowadays.

Reply on news.ycombinator.com