Hi.
Why on instruction described only one way certbot installation? Via snapd. All actual debian versions have native certbot package from official debian repo with all updates. Debian -- Package Search Results -- certbot
Installing snapd to launch python-written certbot is overhead and looks like bad practice.
The certbot authors (who aren't me, and aren't Let's Encrypt) recommend snapd because it gets timely updates that way, including dependencies. Even debian bookworm, which came out less than a month ago, has a packaged version that's 6+ months and several releases old.
You can also use pip to install without snapd: Certbot Instructions | Certbot
Also I believe the Certbot team wanted to reduce the burden of trying to keep multiple distro's packaged. E.g., in the past they used to also have a Certbot PPA. But it was decided that the team should focus on just a single, generic method of installing Certbot and they chose snap.
Personally I'm still using the Gentoo repository, as that's updated very frequently ("rolling release"), i.e., often within a few days of a new release. But a rolling release like with Gentoo is very different than Debian or Ubuntu obviously.
on servers
to me.
I moved to a PIP install in a venv to ensure that I have a current version without an unwanted snapd on my server, although I generally use Apache mod_md.
The reality is that those of us who have opinions on these matters usually possess the skills to deploy our preferred implementation.
Do people still build from source? In the olden days that used to be how you got/updated packages but it seems to have fallen by the wayside. I think maybe Nix offers this approach?
Gentoo does, by default. Only some packages like LibreOffice, rust, Chrome are offered as binaries as a service due to absurd long compiling times.
vvv @linkp Unfortunately I don't compile for my work time, only in my personal time 
Hi @cppmm,
I stopped working on Certbot before this decision was implemented, but I'm somewhat familiar with it.
(1) The Certbot project doesn't try to stop anyone from maintaining official OS packages of Certbot, and some operating systems do, and some people use them. I recently used such a package myself as part of a test version of a project. If you do use an OS that has such a version, or if you can persuade your OS developer to do it, that's great and you should definitely feel free to use this installation method. I think it's possible that more OSes will do this (again?) if a lot of users choose to ask for it. (I personally have dozens of things installed from OS packages on my laptop that are also available as snaps; it's not really that impossible for software to be distributed in both ways, even where the main developers are supporting or recommending the snap method.)
(2) The Certbot developers found that the typical OS package was very out-of-date by the standards of the Certbot project, especially in distributions that greatly prioritize stability and require an explicit justification (such as an exploitable vulnerability in an old package version) to update a package version after a code freeze or after a distro release.
This was often annoying to Certbot users and developers, because at least as of a couple of years ago, Certbot was changing relatively quickly (maybe compared to more mature software whose users might be less annoyed by having an older version in their OS). In some cases, people didn't have access to features that were relatively important to them, even though the OS developers didn't consider it to be a security vulnerability. Certbot isn't the only package that's run into this controversy with distributions; I remember witnessing an especially bitter fight about Chromium in this regard (where the Chromium developers actively disagreed with the idea that they should have to explain which fixes were RCE vulnerability fixes, and considered that all releases were in some way essential security releases).
(3) I know snapd is pretty controversial, and some people have no other reason to have it installed on their servers at all. It would be nice to have a widely available, lighter-weight, portable, and perhaps more decentralized alternative. Basically, it's a single target that the Certbot developers can aim at and that's typically available to most users and that guarantees that those users will have access to up-to-date Certbot releases.
On most OSes you can also relatively easily install Certbot in a Python virtual environment. (I've also done this myself for some projects, and it's worked reasonably well.) The Certbot project has documented how to do this as an option aimed at developers, but not suggested it to users in general, perhaps because most Certbot users aren't really very familiar with pip and virtualenv (or their consequences in terms of how to update things or how to invoke commands inside the environment). Indeed, if you do install this way, I think you'll typically need to create your own scheduled task (like a cronjob or systemd timer task) to run certbot renew, as no Certbot-provided version would be able to guess how to invoke Certbot in your particular Python virtualenv.
For people who are relatively familiar with Python and the Python ecosystem, I think this can be a reasonable and appropriate choice. It doesn't take particularly long, and it's not particularly complicated if you know what a virtualenv is and how to run software inside of one.
I think I've seen one case recently where Certbot did encounter a dependency problem when installing this way, but I think the Certbot and/or pip developers would consider this a bug and would be willing to try to get it fixed.
Edit: We just had this thread right now where the official OS package version was Certbot 0.40. That's a release from November 2019, which for some software wouldn't be a big deal, but which for Certbot feels pretty old and likely missing a lot of new functionality. (But it doesn't have an RCE or privilege escalation bug, so I guess the distribution doesn't consider it, as a matter of policy, worth making changes that conceivably might not be 100% backwards-compatible.)
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.