Hacker News Reader

Comment by throw0101a | Hacker News Reader

> I'm using the acme.sh client but the process will be similar no matter which client you choose to use.

Always nice to see some variety in clients along side the official Let's Encrypt one.

While we do use the official Python-based client at works at times, whenever I install it via apt, and it pulls in a whole bunch of dependencies, it's a bit disconcerting to me.

I'm a bit partial to dehydrated, which is a shell script (works under Bash and Zsh): I find it a lot easier to understand. It's handy to put on Linux/POSIX-based appliances like F5s, where the only prerequisites are Bash, cURL, and OpenSSL (and standard Unix tools like sed, grep, etc):

* https://devcentral.f5.com/s/articles/lets-encrypt-on-a-big-i...

* https://github.com/EquateTechnologies/dehydrated-bigip-ansib...

View on HN

> whenever I install it via apt

You have the option to create a virtualenv and install it with pip, or snap, or use a docker image. See [1]. This has a couple of advantages:

* you'll get the latest version from the maintainers - for instance right now only debian unstable has the latest 1.18.0 version - debian testing bundles 1.12.0-2 * you won't be adding system packages that might affect other parts of the system

[1] https://certbot.eff.org/docs/install.html#alternate-installa...

> You have the option to create a virtualenv and install it with pip, or snap, or use a docker image.

You could jump through all those silly hoops (most of which will be completely alien to people who are not Python devs) in order to use the "official" dependency-heavy Python client.

Or you could just use a single pre-compiled Go binary, LEGO [1].

I have been increasingly favouring Go recently because the functions delivered to the end-user are dependency free, you can just ship simple single binaries instead of having to say "oh you need Python X with this that and whatever other Python library under the kitchen sink installed on your system".

And that's before we start talking about conflicts that can occur between Python libraries....which, let's face it will happen in an "average Joe" environment where Joe is just randomly using apt to install any Python dependencies.

[1]https://github.com/go-acme/lego

Very good point. This is a great selling point for Go. It takes so much deployment pain away.

Indeed, for example this snippet from the Saltstack docs:

>For historical reasons, Salt requires PyCrypto as a "lowest common denominator". However, PyCrypto is unmaintained and best practice is to manually upgrade to use a more maintained library such as PyCryptodome. See Issue #52674 and Issue #54115 for more info

We wouldn't even be having that conversation with Go.

There would be no weird "lowest common denominator" dependency. There would be no concerns about potential conflicts between other crypto libraries, and no choice to make about which "better" library you want to install. Plus of course the 10 other non-crypto dependencies that Salt needs.

All you'd need is a binary, config file(s) and an init script and you'd be good to go.

Sure, static linking and the like make the initial deployment much easier. On the other hand, it also means that any bugs in the dependencies are baked into each application, and fixing those bugs (which may be critical security issues) requires rebuilding all the downstream code. Provided, that is, you can rebuild the downstream code. Users of closed-source binaries are simply out of luck.

Mixing multiple versions of the same (or closely related) libraries in the same program remains an issue even with self-contained applications. It might work out if the users of each version are isolated from each other, at the cost of program size and attack surface, but say you're using PyCrypto in one module and PyCryptodome in another, and you want to pass configuration or key information between them—the types won't match up. You'll also have two different API styles to deal with for the same tasks, which is bad for maintainability, which is ultimately bad for the user because it create more opportunities for bugs and makes it harder to implement new features and enhancements.

> On the other hand, it also means that any bugs in the dependencies are baked into each application, and fixing those bugs (which may be critical security issues) requires rebuilding all the downstream code.

I'm afraid I don't buy that argument at all.

Because Python is either the same or worse.

You've got the potential bugs in the Python code itself, and then the potential bugs in the random Python dependencies. You've got a whole stack of potential bugs there.

P.S. What's that nonsense about "closed-source" Go binaries ? If its an open-source project then its open-source until its compiled ! If the code's on Github then you can clone it and do as you please if you're not happy with the author's Go code.

> Because Python is either the same or worse.

No, you update a python library and it works for everything importing it. The point is that you can fix vulnerabilities in unmaintained apps with a simple update if the vulnerabilities are just in dependencies.

> P.S. What's that nonsense about "closed-source" Go binaries ?

The discussion is about passing around binaries and nothing else.

In practice the apps that don’t publish updated dependency lists are also the ones that end up breaking by when you do update their dependencies. It only works in the simplest of patch versions.

> And that's before we start talking about conflicts that can occur between Python libraries....which, let's face it will happen in an "average Joe" environment where Joe is just randomly using apt to install any Python dependencies.

What kind of conflicts are you talking about? In both Debian and Ubuntu repos, all Python packages and their dependencies are nicely versioned and separated so there can't be any conflicts between Python versions. As for the handful of Python packages that are mutually exclusive (Pillow and PIL), either only one implementation is in the repos or you can install any one of them and have it work since they're drop-on replacements.

Now, if you start installing system-wide packages with sudo pip, you'll of course break things, but if you're installing things from the apt repos, there is no reason to ever do this (and pip will yell at you that you shouldn't do it).

> You could jump through all those silly hoops (most of which will be completely alien to people who are not Python devs) in order to use the "official" dependency-heavy Python client.

Why would snaps or docker be completely alien to people who aren't python devs?

Why would you deploy a snap or an entire docker container for a job a single shell script or binary can do? It's like using a bulldozer to move a pebble.

I didn't say anything about its utility. I was just curious what docker containers and snaps have to do specifically with python developers.

This might be a good scenario for pipx. It’s a Python package manager optimized for deploying applications instead of libraries.

https://pypa.github.io/pipx/

Use pipx-in-pipx to make it even more robust: https://pypi.org/project/pipx-in-pipx/

I hope this is a joke, right?

Sadly, No. Thanks to the way Python works when installed via homebrew on Mac this is actually very necessary if you want to install system-wide python utilities that do not depend on the system python. Without it you can have these utilities broken by a system update or by a homebrew update that bumps the Python version.

Which is another reason why I lean towards dehydrated when I can: a lot fewer "system packages" to deal with.

Link: https://dehydrated.io/

Which is unsupported and may explode randomly in the future. Like they did with `certbot-auto`.

They only support snap. Which is fucking nuts.

I can't bear to use certbot because snaps on a headless server (along with using aide) are a complete nightmare and no-go for me.

I'll second the suggestion for dehydrated.

Prefer to avoid snaps too. First time I'm hearing of dehydrated. I've dabbled a bit with acme.sh too and it's good (can do ECC certs and it's a single shell script).

I've stopped using Ubuntu in favour of good old Debian due to Canonical foisting snaps. I know you can remove snapd but the whole Ubuntu ecosystem is pivoting towards them.

What does certbot have to do with snaps..? You have all the options of container, build from source, download a binary release, get it from apt (or what have you) repos.

certbot does not officially support binary packages on Linux, so you have three choices for supported releases: snap, docker, or pip (best effort). If I’m not already using docker for the site (spoiler: I’m not) then why the fuck would I install docker if I’m not willing to install snap?

I guess the installation via pip is only best effort in the sense that they can't support every platform that pip is able to run on. For example their dependency on the "cryptography" library might cause problems on platforms which can't get a pre-compiled version from PyPi and have to built it from source.

If you are on x86 and use a distribution with glibc I wouldn't expect any problems.

I've had no issues installing it from debian apt repos on arm64 and amd64... I mean, if you don't want to use certbot and prefer something else, fine, but I can't see how docker/pip/snaps are the only options.

They're even listed as alternative methods here: https://certbot.eff.org/docs/install.html

I wish at least one of the other people downvoting my comment would pipe in to what their issue is, or what I could be missing.

And yes, I've encountered the cryptography-switched-to-rust-thing in various other scenarios.

It’s python so scratch “binary” above and replace with “pip” obviously.

https://packages.debian.org/buster/certbot

You seem confused.

Genuine question : Whya re snaps a nightmare on headless servers? Their auto-updating nature does add some stability issues but any other reasons?

Because it's not conjusive to a minimal attack surface - by way of example: https://www.helpnetsecurity.com/2019/02/13/cve-2019-7304/

Not to completely minimize it, but that says local attacker, not remote attacker. So someone would still have to gain access to the system in question in the first place.

Just because a server is headless does not mean that it isn't interactive in some way or running some user-submitted scripts or code.

Also, compromising a service running as a user (not root) would be sufficient to then escalate.

OpenBSD's 'acme-client' may be a good fit in these kinds of cases - not sure if anyone has ported to other systems but it's probably a pretty direct recompile with maybe a couple of adjustments

https://man.openbsd.org/acme-client.conf.5 http://cvsweb.openbsd.org/src/usr.sbin/acme-client/

I maintain portable fork of the project: https://git.sr.ht/~graywolf/acme-client-portable

It’s the most sane client and should’ve been a standard one.

The OpenBSD acme-client is OpenBSD specific and lacks a whole bunch of features, it is I suppose exactly what you'd expect the default acme-client to be in OpenBSD and so it fits its role perfectly but it doesn't make any sense as the "standard" ACME client with no support for lots of desirable ACME features.

+1 for dehydrated [1]. Aside from being able to run basically anywhere, it is very easy to script: Create a file with the list of domains you want, and run `dehydrated --cron`. dehydrated will obtain certs and/or modify existing and/or renew, or just do nothing.

Certbot is designed for interactive use: obtaining, changing and renewing certificates are all distinct commands, and if you tell it to obtain a cert you already have, it'll just obtain it anyway. Handling this from a script is a huge pain.

[1] https://github.com/dehydrated-io/dehydrated

I use lego everywhere. You download it from github or build it with go, drop it in a bin folder, run it first time and set up a cronjob. That's it. No on site deps, no interpreters, no venv.

I recommend acme-tiny:

https://github.com/Tronde/acme-tiny

It's an acme client in a single, small, stand-alone Python file.

I reverse-engineered it and ported it to Common Lisp. I haven't published the result, but I'd be happy to do so if anyone is interested.

Recommendation from me as well. Have been using this script for multiple years now without a single issue. The minimal code is awesome for avoiding unnecessary external dependencies and complexity.

Be sure to use the latest version from https://github.com/diafygi/acme-tiny though :-)

From the gh page doc it requires too much stuff to set up. Imagine if you need certs for >10 domains I prefer lego + cronjob or caddy. Most web apps speak http now and it's just a matter of proxying to a local port, unless you are using php, uwsgi, psgi. Php-fpm is also well supported.

Reply on news.ycombinator.com