Snap and modern software (was: Remove /snap directory)

[Ralf Mardorf]

On Thu, 2022-12-15 at 17:18 -0600, Keith wrote:
> Here's a few links to articles that I hope will begin to disabuse you of 
> the notion that just because software that is open-source, widely-used, 
> and is produced by experienced developers is automatically trustworthy 
> and safe:

You are missing the point. Again and again you spread the same FUD. We
know that no software or hardware [1] is 100% secure, this is the reason
for the continuous work on security. Issues get uncovered, because the
source code is available, even the source of apt packages (and probably
snaps) etc. is available and because people are working on finding and
fixing issues. This is true for apt packages as well as snaps, for BSD
ports etc..

The problem with the snap containerized approach is, that the amount of
(not shared) libraries that requires a check does increase rapidly.
While a container is a security measure, it comes with undesirable side
effects, due to restrictions.

For FLOSS software that grants customisation by the user it's a step in
the wrong direction. For (often not that) "smart" proprietary solutions
it's ok, but requires much expensive effort to stay secure and to
workaround side effects of restrictions.

As already pointed out, Apple's way of doing it is quite alright, but
still a PITA, while the Google/Android approach fails completely for
countless domains, such as real-time capabilities.

For longterm support snap doesn't make sense, because it's wanted to
stay with a version of software (with backported security fixes). A
company will not re-train staffers to become used to new GUIs each weak.
A workstation should not suffer from regressions introduced by updates
and so on and so forth. Tainting longterm by snaps is counterproductive.

To make a rolling releases that stable, that it can be used for a
workstation, a very special, elaborate strategy is required. A part of
this strategy is the user-centric policy. Tainting a user-centric
approach by snaps is counter productive.

For some proprietary solutions a containerized snap alike approach does
make sense, but it is very expensive to maintain it. Android does work
for consumer apps, but it can't be used as a production environment.
Apple operating systems such as iPadOS can be used as a production
environment, but it makes Apple products that expensive. Keep in mind
that one reason (if not the only reason) for the containerized approach
is defense against pirated copies, something that isn't needed for a
Linux or BSD install.

 

[1] Hardware, e.g.

$ grep . /sys/devices/system/cpu/vulnerabilities/* | cut -d/ -f7
itlb_multihit:KVM: Mitigation: Split huge pages
l1tf:Mitigation: PTE Inversion; VMX: conditional cache flushes, SMT disabled
mds:Mitigation: Clear CPU buffers; SMT disabled
meltdown:Mitigation: PTI
mmio_stale_data:Unknown: No mitigations
spec_store_bypass:Mitigation: Speculative Store Bypass disabled via prctl and seccomp
spectre_v1:Mitigation: usercopy
spectre_v2:Mitigation: Retpolines, IBPB: conditional, IBRS_FW, STIBP: disabled, RSB filling, PBRSB-eIBRS: Not affected
srbds:Mitigation: Microcode
tsx_async_abort:Not affected