Why not snap?

There are multiple applications (e.g. Skype, Bitwarden) which aren’t officially available via arch repositories, but do have official snap packages. For me that sounds like the best way to get them (I like the fact it’s official packages, that I’ll be getting updates, etc). And I don’t think slightly longer load times are a big price to pay for it.

But I think there’s a lot of hate in the community for snaps (could be wrong, just my impression). Am I missing something? Is it all just a “yuck Canonical” philosophy, or is there a particular problem I should be aware of before enabling and using snaps?

Would appreciate your opinions :slight_smile:
Thanks!

Read this (under the heading snap);
https://blog.linuxmint.com/?p=3906

1 Like

@ahershko, since this is not a help request, I hope you don’t mint it being moved to #lounge.

1 Like

@Kresimir please, do what you do best… :frog:

7 Likes

The problem with Skype for example is that these packages are provided only as rpm or deb. Someone packages for arch on AUR, but you could also download,convert and install Skype locally using pacman. I don’t know if that is advisable though and if you would get any updates or need to install new versions ever now and then.

Just fyi https://ostechnix.com/convert-deb-packages-arch-linux-packages/

But I would rather use AUR just for a couple of these proprietary software if really necessary to install. You can also use flatpak.

Write proprietary in gothic? Or bash snap :rofl:

1 Like

Here you go:

8 Likes

No problem. Thanks for moving it :slight_smile:

2 Likes

Skype and Bitwarden (to use two examples) have official snap packages, advertised on their websites.

Sure - I can also install via AUR or Flatpak, but these channels aren’t maintained by the companies themselves (unless I’m missing something here), but rather by members of the community. So to use those means adding more people “to trust”.

In other words from a security perspective, isn’t it better to use official channels? What’s so terrible about snap?

Did you bother to read what @Kresimir posted above?

That lays out the argument against using snaps (technically snapd). Whether you consider it acceptable or terrible is up to you to decide.

3 Likes

Thanks, I read it (after posting, oops).

So if I understand it correctly the key objection is that Canonical collects data on how people use snaps. For me (and speaking just for myself here, of course) that’s not a strong enough reason to switch to (unofficial) AUR or flatpaks, as them being unofficial introduces a potential security issue (I need to trust the private individuals maintaining these unofficial options).

I fully respect that for many people in this community the privacy concerns weight more heavily. Wanted to understand if there’s something else I’m missing (“there is a terrible bug in snap that will cause your computer to go up in flames after 30 days”), and it sounds like there isn’t.

That’s why you can convert and install the Deb package yourself if you follow my link above, then no need to add additional packages like snapd or other community member to package for you. (If you don’t want to use AUR)

The downside (to converting the Deb myself, vs snap) is that I wouldn’t get automatic updates. But totally understand if for some that’s a price worth paying so they avoid sharing usage data with Canonical. A personal choice, I guess.

If you are that worried about security then you should probably not use proprietary, far worse than using a package packaged in AUR, since the packaging code is available to inspect and tell you exactly what it does. I am not talking about the type of software packaged, that is then the users choice to install or not

I think you may misunderstand the AUR. @dalto had some nice posts about how to inspect and package packages on arch.

6 Likes

If you don’t care about the fact that Canonical is tracking your usage of snaps and don’t mind the extra disk space and bandwidth consumed, there is probably no reason not to use snaps.

6 Likes

You can always inspect the PKGBUILD of any package in the AUR if you do not trust the maintainer. And for the most part you will see that the literally just download the package from the official website and wrote a quick install/ conversion script while making sure that the necessary dependencies are installed.

I.e. see https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=skypeforlinux-stable-bin ; it literally downloads Skype from the official repo (which I assume that snap also does). If anything malicious would be going on, you would see it in the PKGBUILD of the package…

EDIT: seems @Zircon34 types faster than me… :upside_down_face:

3 Likes

Probably not because you install locally. I don’t know. But for sure it’s not my first choice if it’s packaged already in AUR.

AUR is transparent.

How a package is constructed and built is front and center in the PKGBUILD file. Nothing is hidden or obfuscated. You can view a detailed revision history.

Only difference between a repo and AUR package is that a user maintains it, not a member of the Arch team. You also have to build the non -bin packages into binaries yourself, which AUR helpers make easy.

The AUR is also a community. The AUR package web page comments section contains discussion / issues / fixes for each package. Any issues tend to get raised and resolved fairly quickly, unless a major fix upstream is required.

The AUR is big, convenient and pragmatic. It contains tens of thousands of packages. In one place, fronted by a great website, and packages are accessed using a single AUR helper tool.

Trust factor in the AUR is miles ahead of snaps and Canonical IMHO. You still need to be cautious and careful when using the AUR, but once you get used to it distro hopping to a non Arch distro will be painful.

7 Likes

In addition to what everyone has already mentioned, I find that it is also far more convenient to use aur packages. Updates are pulled when you’re updating your system, whereas Snap or Flatpak require a separate command, and Pacman may not be as fast as xbps, but unless you’re building a browser from scratch odds are it’s still a lot quicker than installing a flatpak/snap.

I don’t like Snaps, and would never use them unless I had to. I hate the idea of Canonical forcing tracking upon the user, and have had bad experiences with removing snaps in the past (leaving traces, like systemd services enabled for example).

I do like Flatpak, I think the concept is wonderful and I’m all for better isolation. Having said that, sometimes it comes at a cost of requiring some additional manual work, like allowing access to parts of your system which wasn’t enabled when you installed it (like accessing a file in a home dir) and sometimes it doesn’t interact as well with other software as an aur pkg would. The size thing is a non issue to me, I’d have to install hundreds of Flatpaks for it to be a problem.

I trust most AUR maintainers, and it’s convenient so for most software it’s what I use. If I had to install privacy-invading software, like Zoom or Discord, I would pick Flatpak because the less access these applications have, the better.

Last but not least, if you’re dealing with Flatpaks having Flatseal installed makes it a breeze to control their access.

1 Like

For bitwarden I would argue the opposite way.

The AUR package for bitwarden is a source code package which builds the bitwarden binary during installation. And it pulls the source code from https://github.com/bitwarden/desktop. This is THE source code which was audited by security experts around the globe and it is THE source code which is considered to be save.

The bitwarden snap package on the other hand is a binary. And you do not know which source code they used to build it. You trust them that they used the source code from https://github.com/bitwarden/desktop and that the snap does not contain extra stuff. But do you know that? My trust is with the bitwarden AUR package.

I guess the same argument applies for all the other AUR source code packages compared to binary packages. E.g. aur/firefox-esr-bin vs. aur/firefox-esr; aur/joplin-desktop-bin vs. aur/joplin-desktop, and so forth

3 Likes