As we continued to update the software center we came across another problem: We couldn’t create a Snap store of our own.
What does that mean, it means that the only official way to get a Snap is through the Ubuntu Store (read: repository). Say we wanted to create our own platform to serve Snaps, well we can’t because the server-side software needed to do that is not publicly available to use by 3rd parties (like us). That doesn’t mean you can’t install a Snap that doesn’t come from the Ubuntu Store however, you can, in the same way you can install an APK in Android (read: sideload). But like in Android it isn’t a good idea to do so because of security concerns.
We understand why that is the way it is (that there’s only a single sanctioned store), but it really was a downer.
They also cite the following problem:
libsnapd-qt was mostly unusable. The library unfortunately isn’t actively maintained
They also think that a lack of plugs (to reduce package size) is a good thing (I strongly disagree with them on that, whereas I don’t disagree so much with their external repos objection). They say they had a problem with snapping KDE apps, hmm:
Unlike Snaps, AppImages don’t require to set up a (single, proprietary, sanctioned) Store to download them and they also don’t need something like a daemon to work although we do use one to manage them from our UI, they also don’t require connecting Snaps with other Snaps (plugs) an AppImage while larger in size can have all of its dependencies inside a single file, in our case this is very important because packaging Snaps of KDE apps was ultimately futile but we managed to package KDE apps with AppImage.
There is no “requirement” to plug into other snaps, excepting core which is usually automatically connected anyway so you shouldn’t care about it.
There is also no limitation preventing you from putting all your dependencies inside the snap. The whole point of snap is to do exactly that (bundle all your dependencies)!
I have reached out to the Nitrux developers to better understand how snaps didn’t fit their need. If they identify missing features/bugs then we should know about them for future developers who are evaluating snaps. Thanks to @Ads20000 for raising the issue.
To hopefully add something to this discussion and raise a use case for external stores.
Many IoT devices might be running in private Intranets, especially enterprise devices. While there is some security in them being private intranets these devices wouldn’t be able to receive security updates. While a simple solution would be whitelist the snap store, it is much harder to go to a customer and say “We need you to allow access to these third party servers.” Anything requiring an on premises solution would benefit from these and even if not on premises a customer opening up access to your servers vs your servers and a third party server is a very different question.
While I assume Canonical is running it’s own servers for the store because of the unique infrastructure mentioned above, some customers have specific partner hosting requirements for reasons of security and competition, and like to verify this infrastructure. Similarly, I doubt Canonical would be amenable to many snap developers saying “Hi, our customer needs to verify your infrastructure.”
The ability for one party to hast a private store inheriting from the main snap store would be a great work around for this.
Just the other day, I was reading comments on Snap, and someone called it “just another thinly-veiled attempt by Canonical to control everything.” Which is not really true, but when you can’t add External Repositories, it certainly comes off that way, though I have addressed my thoughts on the matter a thousand times already.
Still researching/thinking about better ways for external repositories…
I don’t want to say the Snap developers are doing a bad job though. They are working on features like crazy - base images, mounts, etc. for IoT consumers, and feel that external repositories aren’t high on their priority list. That is well and fine - but I certainly wish it was higher on that list.
This is over a year old now so I guess design has changed but when responding to a point on how snappy is tied to the ‘Ubuntu’ store, @sabdflsaid:
The snap format is a format, like a zip file. That’s what creates the distro-neutrality. That’s the equivalent to AppImage and Orbital-App and the newly-energised RH flatpak project. The format is completely neutral, has no tie to any store.
Of course, in Ubuntu, we have a store. It’s the same store we built for the phone. Yes, it uses your Ubuntu identity, but no, there is absolutely no reason snaps can’t work with any other store.
I wonder how he would respond to the same point now? I suppose it doesn’t matter too much, since whilst Canonical pays all the full-time devs, Niemeyer is the snapd lead, not Mark… Also what Mark said is still technically true, snaps are just packages that theoretically anything could interpret… Just thought this was worth noting in this topic
OMG, you are trying to copy Apple/Microsoft behaviour so much… It looks so sad from outside. You’ll never be number one while you are trying to copy number one…
I think the malware found in the snap store is actually a reason in favour of keeping the status quo. This way snappy isn’t quite as problematic as PPAs or Flatpaks because there is only one store so all apps must pass any tests required to get into the store and then can be taken down if there’s anything wrong with them, this isn’t possible with PPAs or Flatpak because if you install a PPA or a Flatpak remote then there’s no way for Ubuntu or Flatpak developers to take that PPA or remote down (well, I suppose Canonical can take down the PPA, but I don’t think Flatpak would be able to take down a remote @mhall119)?
PPAs are just apt repos provided by Launchpad, so depending on how strict your definition is yes Canonical can take those down. That doesn’t help you with 3rd party repos like Chrome and WineHQ add to your system.
Flatpaks can also have multiple repos, so yeah if you install a Flatpak from an untrusted repo you’ll have the same problem as an untrusted apt repo, yes. Using something like Flathub will give you a similar level of protection to the using the Snap store.
Even Windows 10 S supports LOB apps (Line-Of-Business). Still doesn’t change the fact that I really, really disagree with the idea of security by Store apps only, except for maybe a high-security location (e.g. business PCs set up by an administrator, old folks).
How else do you get such a high level of security though? Any sort of federation allows people to install insecure repositories - either completely malicious ones or ones with bad security practices?
Other than Ubuntu Core, which is not used as a desktop operating system as far as I’m aware, you can still use traditional packaging formats by default and, optionally, Flatpaks, AppImages, binaries, etc
I feel like this is just too far, if you know what I mean. I believe we should allow external repositories or, yes, potentially insecure ones. If we had a camera on every corner of every street and inside every house in the world, we would have excellent security. There is a balance of security/options.
The main thing I hate about Snap is I feel like Snap is trying to force this issue. Look at say, Flatpak and Flathub. Flatpak is the packaging method, Flathub is the main “app store”. You will most likely use Flathub, but you aren’t locked in. With Snap, you are locked in unless you want to do a ton of work on a custom version of Snap. FOSS is about choice, Snap gives you one choice, the Snap Store.
Remember the systemd controversy? I can’t imagine the controversy if Snap becomes common and people can’t adjust their updating schedules to any way they wish.
@zyga-snapd I meant like, the ability to disable auto-updates, etc. Yes, I know that makes things less secure, but I personally would like the choice to do with my system as I will.
The other reason I don’t like the centralized locked-in snap store is about what happens when a controversy occurs.
Take, for example, CoinHive. Widely perceived as a pest, would Canonical remove it, or would they listen to the claims that is could be a legitimate way of monetization in the future?
Or, say, something controversial like politics. What happens when the Left is angry because there is an NRA TV snap on the Store? What does one do in that situation? My point is that Snap has never dealt with anything controversial. I am sure that if Systemd was available as a Snap 5 years ago, we’d have piles of people begging for it to be banned.
I am sure GNU would beg for every mention of Linux to be replaced with GNU/Linux. Canonical might try to integrate their solutions for Livepatch, Ubuntu Advantage into Snap while making it harder for competitors. My point is, a group’s interest in running the Store can cause real problems.
I suppose it doesn’t matter too much, since whilst Canonical pays all the full-time devs, Niemeyer is the snapd lead, not Mark… Also what Mark said is still technically true, snaps are just packages that theoretically anything could interpret… Just thought this was worth noting in this topic