4 ms·

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

by ohazi 6y ago

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. It's not a bug or an oversight -- it's part of the design of snap, and it's not going to change. Handing out the keys to the kingdom like this is supremely annoying on a desktop (e.g. Windows 10), but it's completely unacceptable on a server. This is a terrible move, and they should absolutely walk it back.

lstamour 6y ago
I agree — the auto-updating nature of Snaps are a problem without an easy solution: https://askubuntu.com/questions/930593/how-to-disable-autorefresh-in-snap https://askubuntu.com/questions/930593/how-to-disable-autore... But I would also point out that on stable Debian it’s near impossible to deploy Certbot because the versions available are too old, especially the plugins. I’ve been routinely installing the snap instead because it’s a quick and easy way to deploy the service at the latest version. The only other alternative to suggest is to request the Certbot project deploys custom deb repos or similar. But can we expect that of every project? Perhaps we need a new standard to replace snap, if so the only folks I can see large enough to promote it would be GitHub... Since that’s unlikely to happen, maybe just noting the auto-update “feature” more prominently in their is all they should need to do?
- erik_seaberg 6y ago
  Too old in what way? Is the Debian stable version relying on something that Let’s Encrypt is deprecating?
  - lstamour 6y ago
    I’m not sure, but it’s possible. The version in stable was 0.31 or so, while the version in snap and unstable/sid is 1.11. The specific incompatibility I faced was for the CloudFlare DNS plugin, which added support for API Tokens that had granular permissions somewhere between the 0.23 version in stable and the current version of the plugin at 1.11. Current Certbot docs and CloudFlare docs both encourage you to use API tokens instead of account-wide API secrets and the previous install instructions for wildcard DNS support suggested installing the CloudFlare DNS plugin by default on the Certbot site.
alyandon 6y ago
And if all that wasn't bad enough - snapd also purges package change history after something like 72 hours so you can't even tell what updates were applied and when to your system.
- gbh444g 6y ago
  We usually call this an RCE exploit.
simosx 6y ago
You can hold off the update of a snap package for up to two months by enabling the appropriate key at https://snapcraft.io/docs/keeping-snaps-up-to-date https://snapcraft.io/docs/keeping-snaps-up-to-date I suppose the rational is that updates should happen. You can take your time to hold updates for up to sixty days but they should happen anyway. The certbot snap package is published by the EFF/LetsEncrypt themselves. You could also trick snapd that you are on a metered Internet connection, therefore avoid updates.
- ohazi 6y ago
  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.
rlpb 6y ago
> 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 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.

by ohazi 6y ago

lstamour 6y ago

I agree — the auto-updating nature of Snaps are a problem without an easy solution: https://askubuntu.com/questions/930593/how-to-disable-autorefresh-in-snap https://askubuntu.com/questions/930593/how-to-disable-autore... But I would also point out that on stable Debian it’s near impossible to deploy Certbot because the versions available are too old, especially the plugins. I’ve been routinely installing the snap instead because it’s a quick and easy way to deploy the service at the latest version. The only other alternative to suggest is to request the Certbot project deploys custom deb repos or similar. But can we expect that of every project? Perhaps we need a new standard to replace snap, if so the only folks I can see large enough to promote it would be GitHub... Since that’s unlikely to happen, maybe just noting the auto-update “feature” more prominently in their is all they should need to do?

erik_seaberg 6y ago
Too old in what way? Is the Debian stable version relying on something that Let’s Encrypt is deprecating?
- lstamour 6y ago
  I’m not sure, but it’s possible. The version in stable was 0.31 or so, while the version in snap and unstable/sid is 1.11. The specific incompatibility I faced was for the CloudFlare DNS plugin, which added support for API Tokens that had granular permissions somewhere between the 0.23 version in stable and the current version of the plugin at 1.11. Current Certbot docs and CloudFlare docs both encourage you to use API tokens instead of account-wide API secrets and the previous install instructions for wildcard DNS support suggested installing the CloudFlare DNS plugin by default on the Certbot site.

alyandon 6y ago

And if all that wasn't bad enough - snapd also purges package change history after something like 72 hours so you can't even tell what updates were applied and when to your system.

gbh444g 6y ago
We usually call this an RCE exploit.

simosx 6y ago

You can hold off the update of a snap package for up to two months by enabling the appropriate key at https://snapcraft.io/docs/keeping-snaps-up-to-date https://snapcraft.io/docs/keeping-snaps-up-to-date I suppose the rational is that updates should happen. You can take your time to hold updates for up to sixty days but they should happen anyway. The certbot snap package is published by the EFF/LetsEncrypt themselves. You could also trick snapd that you are on a metered Internet connection, therefore avoid updates.

ohazi 6y ago
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.

rlpb 6y ago

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