Obviously. But the user shouldn’t have to run “–dangerous” just to install an app. Besides any snap installed that way will not get any automatic upgrades. So this is emphatically NOT what we are talking about.
1 Like
Why would that be a problem?
snap install store1:foo
snap install store2:bar
Autoconnects would obviously happen only between plugs/slots from the same store.
Note that this is exactly why --dangerous is called like that. Installing random software from random places is, dangerous. As is installing from random repositories. Users won’t be usually able to differentiate well-looking software from well-looking malware.
And where do refreshes come from? Does that block refresh if you already have it? If I upload a new revision of a popular bitcoin wallet snap to my flashlight repository will everyone also using my flashlight snap also get the bitcoin wallet snap as a refresh? Will it have access to the data of the real wallet snap? Will it be able to make a transaction to my account from its automatically-fired configure script.
There are many reasons why this hard to get right.
Each snap would always be refreshed from the store it is installed from, unless changed manually:
snap install bitcoin (default Canonical store)
...
snap refresh flashlight:bitcoinThe point is, Snap is designed in a way that adding external Stores will be hard. However, adding external Stores is (in my and jzimm’s opinion) the most important thing snap is lacking for long-term success right now.
I had this idea last night: What if…?
A. Instead of having Canonical controlling all servers that Snap uses, what if every distribution (that was interested) ran their own servers, which then synced to each other to a ‘main’ map of packages. Any distribution in the operation can accept an app to be added to the ‘main’ map. So in other words, Snap would be joint-operated by Canonical, Red Hat, and other big distributions.
B. When an app is purchased on a distribution other than Ubuntu, the company that developed that distribution gets a cut of the purchase, equal to what Ubuntu would take. In other words, whoever runs the server for the paying distribution gets the 30% cut. Users could also use to pay up to a different distribution (whoever runs the payments server the user wants to use.) If there is no payment server for the distro, they can choose who they want to give the 30% to for the payments.
C. Every distribution has a separate ‘channel’ which isn’t included in the ‘main’ packages. This is where distribution-specific snaps get shared. So, Ubuntu would ship with the ‘main’ snap repository that everyone jointly shares and a ‘ubuntu’ repository for Ubuntu-specific snaps. Red Hat would ship with ‘main’ and ‘redhat’ repositories.
D. Every distribution has their own version of build.snapcraft.io, except they all contribute (by default) to the ‘main’ pool of apps which all of the distributions mirror.
You can very easily just host your additional snaps on a webserver and simply have a wrapper script caring for the “–dangerous” bits as well as upgradeability …
Since that topic got me curious i took some time in my lunchbreak today to hack up http://paste.ubuntu.com/25362069/
copy the script to ~/bin, make it executable and you can call snap-get upgrade from a crontab entry for snaps you installed with it…
Thats a simple way have additional snaps even with upgrades (without any signature or assertion checking though and the upgradeability is based on the verion field) and might help for in-house CI or whatnot, in any case it shows that there is nothing blocking to even just use a remote webserver as your snap provider if you want …
Apart from the core snap (which you could as well just mirror to that webserver via snap download) there is no need at all to use the Canonical snap store if you dont want to …
(NOTE: make sure to have htm2text and wget installed if you actually want to use it)
3 Likes
Interesting, thank you.
" there is no need at all to use the Canonical snap store if you dont want to …"
Well, then, why doesn’t Snap support adding repositories (again)?
did you read the script ? it will install everything in --dangerous mode, snaps are more than just the app content, the store gives a guarantee that they follow a certain standard (security checks on upload), the store signs them with an archive key so they can be verified (assertions) etc etc … my script can be used for a trusted entity (as i said for in-house CI where you trust the publisher) but not as an actual replacement for a fully fledged store …
if you want an actual store you need to implement the surroundings …
all i wanted was to show that you can use snaps also differently and nothing blocks you from that different thing to be just a standard webserver …
Oh that, that is OK. I just meant Snap out of the box. Thank you very much for the script though! However, I will still continue pushing for Snap supporting external stores out-of-the-box, as that is still important. However, this isn’t a bad workaround. I actually had been trying to write something like this myself on GitHub.
What about the joint-operation proposal I showed a few levels up?
While both sides have strong points, in the end to be a completely open packaging system there needs to be a way to set up at least a generic, simple store, for whoever wants to, imho.
As such I would advocate to at least be able to provide the following in a maintained open-source way:
- API Provider
- Base Snap-Upload management (ie, keeping whatever metadata is required around)
- Base Signing Infrastructure
‘Advanced’ Features can then be something everybody can implement as they would like as long as the adhere to the API specification:
- Threat-detection at upload time
- build services like build.snapcraft.io
- User Management
This would make it possible to provide for a simple in-house development server that can still provide the base-security out of the box.
I believe that alone would make it a lot more attractive and future-proof.
‘Getting it right’ on conflicts is a nice wish, but planning for every contingency is also not necessarily part of what we want. We should allow a user to disable the main store and only deal with the packages from store xyz. This would be the case for classic mostly.
I love snaps, I love the way they function and update. But while advocating for snaps, this is a major stumbling block. And at times like that “but this is a workaround you can use” does not sound very appealing.
2 Likes
Your A and B will require a lot of manpower on the side of the distributors to implement, but the APIs are all public, the client side source is completely public as well, so implementing another store is a matter of another distro investing into that …
For C look up the discussion about base snaps in this forum, that wil in the future allow you to have fedora snaps, solus snaps or OpenSuSE snaps (not related to stores at all though)…
D is a matter of money i guess … implementing your own build.snapcraft.io simply means to automatically call “snap cleanbuild” for repos … there is no magic in it (just a little website and a db storing the repo urls)
Absolutely. Snaps will struggle with the centralized method. But, decentralized? Flatpak is near death if that happens.
“I love snaps, I love the way they function and update. But while advocating for snaps, this is a major stumbling block. And at times like that “but this is a workaround you can use” does not sound very appealing.”
Completely true.
2 Likes
But if another distro makes another store how would someone add said store to their repositories, as it were? Presumably they’d have to distribute a patched version of snapd?
there are environment variables to override the default store … a distro could just point that to their own store …
Yeah, but then they can’t use the Ubuntu Store or any packages in that!
Agreed, the environment variable is a little too coarse, and it is hard to use on Ubuntu Core. Would something simple like ‘snap install --dangerous --store https://example.com example-snap’ be acceptable? It shouldn’t be too much trouble for snapd to remember that extra piece of information and for the refreshing code to check the right store for updates. The explicit use of the --dangerous flag here means the user accepts the risk.
@ogra These suggestions:
- Provide a really bad user experience
- Are completely broken in some cases
- Are not recommended by our team
So please qualify more clearly when you are just making things up. 
The real background and what you can expect from us going forward was described above in detail.
I work with embedded devices and don’t really care about the “user experience”. My Ideal handling would be a totally private store with only snaps validated by my company.
For that I want not multiple stores and any such hassle but simply a repository were we can host our snaps and have snapd being able to auto update them with verification of signed snaps.
Also we don’t want our snaps being available for other devices than those in our device network so ideally even hosting it on a private network.
So for that reason an open source version of the store would be what we need in combination with the possibility to point snap to that store.
“The future is not users but devices that act autonomously”
3 Likes
I believe there’s a commercial offering that you could use to do this today.