Certbot deprecates operating system packages, “standardizes” on snaps

> This seems unnecessarily hostile. Certbot is a complex beast that generates TLS configurations, has multiple plugins that likely require specific system configuration, and is I think charitably more than "a glorified Python script".

I didn't meant it as a knock on certbot, which I use and cherish. It's just not something that I would install and entire parallel package management system over, lest of all some ugly thing like snap.

Thanks for your work on that. I imagine it will be easier moving forward as most of the issues seemed to be related to pulling in newer versions of Python packages, which broke supplied versions of other packages (boto-related tools ISTR were breaking).

> The Ubuntu Certbot packages have been horribly broken for well over a year, probably at least two.

I think you're mistaken. The Ubuntu Certbot packages are maintained and work fine. What you're referring to is the PPA, which is no longer required (since Ubuntu's distribution-shipped certbot packages have worked fine for a long time now).

Or, if not, can you point to specific issues with Ubuntu's own certbot packages please?

> Snaps require you to allow each publisher to automatically push arbitrary software updates to your machine, and snap deliberately does not allow you to disable this misfeature.

Your emphasis is completely unwarranted here, since it's easy and trivial to install a snap without it being tied to the store such that it will never update:

    snap download certbot

then use the two commands given:

    snap ack certbot_889.assert
    snap install --classic certbot_889.snap

Now certbot is installed as a snap, but software updates for the snap are disabled.

Edit: I wouldn't recommend this, of course, because telling users to never update their Internet-connected software is a really bad idea, both for their security and for everyone else. More conventionally you'd want finer grained control over update schedules for production use (https://snapcraft.io/docs/keeping-snaps-up-to-date) rather than block updates entirely. Claiming that you cannot do it, with emphasis, though, is outright false and is an invalid claim only used by the haters. I bet you're now going to come back and tell me how the control isn't good enough somehow, but that doesn't matter. The point is that you can control updates, and you're being outright misleading by claiming otherwise.

I agree with the rationale that software should be kept up to date. However, if this was their only concern, they would make it easy for updates to be applied automatically, and then would make this the default.

But the rationale for completely removing your ability to opt-out of an update is different. Snapd is not actually providing a service to users, at least not in earnest. They're providing a service to software publishers.

They're making it possible for publishers to ship software that isn't stable. This is a useful service for publishers, because stabilizing, releasing, and maintaining software is hard work, and requires resources that might otherwise be used implementing new features or writing new software. The life of a software publisher would indeed be easier if everyone was on the latest version as quickly as possible, and if multiple versions with conflicting feature sets were never allowed to exist at the same time.

In order to convince software publishers that snapd is capable of providing this service, snapd needs to convince users that running unstable software from these publishers is a reasonable approach. But for many server operators, it isn't reasonable.

I'm not here to talk about possible workarounds, or to argue about whether a delay is an adequate workaround, or about whether the delay interval is long enough. That would miss the point.

I'm here to assert that snapd's philosophy is wrong, that it's design is broken, and that this makes snapd unfit for purpose.

Here are three scenarios:

1. A security vulnerability is found in some stable piece of software. A minimal fix that mitigates only this vulnerability (without changing other behavior) is written and backported to the stable release.

In this case, it makes sense to apply the targeted patch as quickly as possible. It's time sensitive, and the risk of unintended fallout is minimal. You can do this automatically with debian-security and unattended-upgrades. Even in industries with complex software compliance processes, there's usually a fast-track exception for targeted fixes to critical security vulnerabilities.

2. A feature was improved, added, or removed. It might improve your server's performance. It might improve performance for a different system that needs to talk to your server. It might reduce the load on the software publisher's server. It might change or remove behavior that you rely on, causing your system to break in obvious or not-so-obvious ways. It might introduce a new feature that you've been desperately waiting for.

Everybody wants these updates to happen.

But it takes time and resources to figure out what's changed, to figure out whether the change breaks your system, and then to implement and deploy a fix for your system that allows you to upgrade.

3. Adobe or Autodesk want to silently "upgrade" your perpetually licensed software to their new monthly SaaS version.

lol, fuck that, and fuck them.

----

The problem with this approach (for software publishers) is that writing and backporting targeted fixes is hard, boring, thankless work. Similarly, it can be difficult and expensive for a publisher to have to deal with multiple versions of their software existing at the same time. They might interact in conflicting ways, they might require lots of ugly, bug-prone version-checking in client software so that different feature sets can be handled correctly. The publisher may desperately want to turn off a legacy feature on their servers, but can't until the last stable releases that rely on it are properly deprecated.

But this is how stable software works. If you don't want to deal with these things, and want to insist that everyone needs to be on the latest version as quickly as possible, then your software isn't stable, and has no business running on a server.