Mail inbox/55959

taw_moto:

I understand but I don’t think it’s a good idea to contact 10-15 publishers and ask them to modify their snap packages.

I can understand this seems a little daunting. This work would traditionally be done by distribution maintainers. The Ubuntu developers publish multiple versions of GCC, for example and make special security update releases for all software.

With Snap packages, this suddenly becomes the task of the upstream software maintainer, and many of them are not yet accustomed to how Snap works and what the best way to do releases is.

taw_moto:

Isn’t more simple to have a snap option to disable updates for a certain package?

This would be a simpler option from your perspective, yes. There are a few reasons why the Snap developers are resistant to adding this feature:

Note that I am a community member myself, so don’t use this as an official source

Decreasing the number of insecure Linux systems out there

The number of APT updates that actually get applied is shockingly low. There is a very large number of insecure Linux machines out there, and many of them are already being used in botnets to attack secure systems. Addressing this issue is a big goal of Snap.

At this point, many people ask “but it’s my system why can’t I decide if I want to be insecure?”

• Many systems hold personal information of seemingly unreladed individuals. See the Equifax breach, for example, which was caused by outdated software.
• Many insecure systems have been weaponized to fight secure systems. Most botnets are created by infecting insecure systems and most DDoS attacks originate from such botnets.

Having many insecure Linux systems hurts everyone. For this reason, the Snap developers are going through great lengths to avoid adding an option to turn off updates completely. I agree with you that this is a quite idealistic stance and I know it creates friction with people who are used to turning off automatic updates. I myself am not totally convinced that this is the right approach, but I applaud the Snap developers for trying to solve this issue once and for all.

Because APT is still a very valid alternative, Snap has some room to experiment. If users don’t like this approach, they can keep using the regular packages.

Pushing users and publishers towards better solutions

If publishers enable it, then tracks are a much better solution for your use-case because you’ll still get minor and security updates. Moreover, the publisher of the software will know people are still using previous versions.

The actual underlying issue is that publishers should support multiple versions of their software. snap disable-updates is a band-aid which only makes the issue worse: publishers won’t actually know users want to run older versions of their software because users can “hack around it”. As you said yourself; you would much rather apply a workaround than actually telling the publishers there is an issue with their snap.

This is a common issue in Linux. The libinput stack, for example, disabled configuration options for the very same reason: when a touchpad driver misbehaves it should be fixed in the upstream code so that all users of that driver get the fix. The old input stack had so many configuration options that distributions and end users just worked around issues instead of asking the developers to fix them.

So I would definitely recommend contacting the publishers because you’ll solve this issue for everyone else too. Moreover, the solution you get is a lot better than what you’d get with snap disable-updates. This is, in my opinion, a good way to give back to the community.

I can totally understand it, however, if you’d rather keep using other packaging methods like APT.

@galgalesh I understand but I don’t think it’s a good idea to contact 10-15 publishers and ask them to modify their snap packages. Isn’t more simple to have a snap option to disable updates for a certain package? Smth like “snap disable-updates valgrind” which will pin the current version of valgr…