First, I’ve probably picked the wrong topic so, I’m sorry in advance. Here’s a little story. I am a daily user of a great snap, ‘zero-tier’. This software is just brilliant, for those who don’t know it, it offers a centralised customisable VPN service… hamachi style. The developer recently released a critical security update, but the snap has been published by third party and it is now outdated. Imo this snap offers a great example of the problem… So much has gone wrong here: for a start the original developer did not embrace the snap project (the original sin ), then a user that was attempting to run this software on Ubuntu Core saw no other way than fork the original project and create a snap out of it. Afaik this is the second sin, as he never attempted to contact the original developer nor tried to rejoin with the main project with a pull-request. Worse he didn’t create a yaml pointing at the original repo but compiled the snap from his outdated fork. And now we come to today… The maintainer has become inactive for over a year. What to do next? Ideally I’d like to bring the original developer onboard, but chances are this can be complicated. A much motivated friend of mine (@capruro) created yet another fork and a better yaml, made a PR on the snap repo but the maintainer is not replying. What is the way forward here? @popey made a great post some time ago suggesting that third party publishers who run out of love for their snap (or just time) should delegate to Snapcrafters (which I find very noble) but what if it is already too late and the maintainer is not taking the initiative? This seems to me an endemic problem with third party publishers. When everything goes well we all win, we get the apps we want on all the supported platforms even if the original developer is not contributing, but when it goes bad it really does… This snap (with the security flaw) is still on the store, outdated and us (the community) cannot do much about it.
Hi Turux, I was going to post something about it. I’ve been the maintainer of a third party snap over the past few months and I’m doing my very best to keep it up-to-date. It has been a learning process for me and I came to some conclusions I would like to discuss with the community.
I love the concept behind snaps that allows others to package and publish apps without the need of an approval from the original maintainer but at the same time, especially with 3rd party snap, you can’t be sure how much software comes with it without check the yaml (if you can find it) or if it contains all the security patches. As maintainer, I receive alert from the email notification system, that warns me about packages in my snap that can be upgraded. It is great although it can be improved. Considering that all I have to do is to trigger a snap rebuild, I would like to see (in the future?) a way to automate this process… I’m not suggesting this should be the default option, yet it would be nice to have the option to make it so.
This topic rises another, more philosophical, question: is there any policy regarding not-up-to-date snaps on the store? If this process requires a human intervention, will outdated packages be removed from the store (or flagged as outdated?)
There was a post a while back I think is relevant to this thread Feature request: Allow user to flag snaps as out-of-date
For ZeroTier specifically, if upstream did want to adopt the Snap they would be able to dispute the package name and take over themselves so they could push updates to it, as far as the rest of the community taking it over goes I’m not aware of any official processes, but I do think it’s important for the Snap Stores longetivity that something is done about it. (It’s all in the other thread so I won’t repeat myself here).
Thanks James, and sorry for the duplicate thread.
I wouldn’t call it a duplicate thread, I just think they hit on a lot of similar points, and every bit of feedback is helpful
I think in particular, the snap ecosystem for some people might only be as important as a few single applications, so picking out specific examples such as this one is as important as assessing the whole at once.
The snapstore like many appstore rely on names to differentiate each app. However unlike the other stores works with the open source world were it’s harder to have coordination without version control.
Other stores like dockerhub follow github, where each user can fork/PR everything and publish his customized version. This approach also have his downside cause you will have hundreds duplication for the same thing while you can trust verified authors. IMO each unverified snaps should be centrally managed by snapcrafters (comunity base snap) and only verified author should be able to publish directly (like closed-source snaps). Resulting in a more controlled store and giving the possibility to every users to check the “community snap” and propose/push updates.
Flathub essentially follows that model and it works for them rather well. I’d be up for seeing more snaps adopting that model, but I’m not sure mandating it for unverified snaps is necessarily the best choice, flathub has other policies such as demanding that the build file works completely offline and is reproducible to the build servers they use, and whilst it’s good for review and trust, it also means certain applications become a lot of work to publish and might not get published at all, whereas snap is more accepting by providing options all the way to editing the .squashfs by hand if needs be, if it works it works, but you couldn’t really make something with significant manual involvement like that work in that model so easily.
not needing verification is one of the main reasons why snaps came to existence 6 years ago (and why they are so heavily confined by design) … there is a gating mechanism at the upload level of the store when you register a name … common known project names, names of packages existing in the ubuntu archive and probably other criteria require you to actually request the name first.
after long experience we collected with our deb based third party appstore (where reviews in the end took months or even never happened) in ubuntu, one big target was to reduce verification and review requirements
I agree James, making it more complicated for publishers ain’t the way forward, but policing the store more, add a ‘report outdated snap’ button and putting in place a ‘revert to Snapcrafters’ procedure can be achieved!
who staffs snapcrafters or guarantees that they have the manpower to care for these orphaned packages then ?
That’s tough… I know that Snapcrafters can’t possibly take care of all the apps on the store. It’s not their role and, as you said, they don’t have the manpower to do that. But I can see a way forward in what @James-Carroll was talking about tho, a button to report an outdated snap… If the maintainer is not responding, the snap can be flagged as ‘not-maintained’ on the store, and (maybe?) after some time they can lose their privilege on the name, making space for newer, better maintained snap…
I’m just speculating obviously
I understand the name reservation policy, that totally make sense. The thing is, how should be managed next?
When someone publishes a snap they are supposed to keep the app updated to its latest version and keep up-to-date its dependencies packages too.
I appreciate that no one can keep track if an app on the store is up-to-date, but it should be feasible to check if a snap is running on outdated dependencies.
My concern is if my snap has outdated packages it becomes vulnerable. Sure, it is confined in a container-like and the risks are limited, but yet there are some! I’m talking about applications that can be publicly exposed betraying the users’ trust. Even if the application itself does not have updates for years, the users need to be sure that the packages inside the snap are up-to-date especially if the snap has e.g. port forwarding requirements.
Transmission-deamon is another good example: someone from the community packaged it in a snap as the upstream project seemed to not be interested, but again it has now become outdated. I forked their project and updated their snap locally compiling it myself… but for me it does not make any sense that the only option is to publish yet another snap under a slightly different name…This will only lead to duplication and confusion.
I just wanted to chime in here with a related problem. I’ve just been testing the tmux snap (Install tmux on Linux | Snap Store) and I’m 100% sure that it was all well some days ago, when the stable version was 3.1b (and ironically, it’s named tmux-non-dead because yeah there is a dead version also which is just sitting there).
Now, all of a sudden the stable version for amd64 is bumped back to a 2½ year old version 2.7, updated July 2018. The arm64 still has the correct stable release, but the others have not. How do these things happen?
There should also be a way to report things like this, because now I’m stuck in testing the snap and getting it to work for me (was struggling with some Apparmor errors).
But I also think it’s a huge problem that Canonical isn’t officially maintaining more snaps, and just letting snaps die, even snaps they used to maintain themselves (expect, for instance).
This does not send any good vibes about the snap ecosystem at all, and I actually think the problem with 3rd party snaps is broader than you describe.
May third party package systems (like chocolatney for Windows) suffers from the same disease and it’s a pain for users.
Oops, it seems I am the bad maintainer here! I think @turux correctly intuited the situation for the most part.
To add my experience, I initially created the zerotier-one snap because I had a need to run the software on some Ubuntu Core devices, and a snap version did not exist at the time. I will say this community has been less than enthusiastic about supporting private snaps or, in other words, allowing distribution channels other than the official snap store. Naturally, if I wanted to run zerotier on my Ubuntu Core devices and take advantage of the automatic update process, I had to go through the official snap store. Since then, I have been thrilled to see so many users from around the world downloading and installing the snap. It is a good sign when someone cares enough to complain.
This pressure to publish to the official snap store could contribute to a glut of low quality or poorly maintained packages. I think there were some reasonable suggestions in this thread that could help improve the user experience. Personally, I am familiar with Arch Linux which has a notion of official packages and community packages, and for the community packages, there is a mechanism for handling orphans. I am not sure if that would be applicable.
I know the development team at ZeroTier is at least vaguely aware that my snap version exists. It was my impression that they are not very enthusiastic about maintaining another package format, but I would hand it over to them without fuss if asked. I will try to release an updated version within the next few days. It seems the snap ecosystem has changed a bit since I last used it. I am having trouble building and testing the snap locally, but I will see what I can do.
The suggestion from @capruro is interesting. It looks clean but is not building on my machine. It might be trying to run make in the wrong directory, but I am not sure.
I set up Travis CI to rebuild my snap for folding-at-home weekly. Folding at home is not currently supporting the snap, so what snapcraft does is to pull the latest stable debs and extract them in the snap. I think setting up some CI like Travis or GitHub Actions is the best way to keep the software updated
Hi @lance, Thanks for your intervention, be aware that at the moment there is a compiler issue in zerotier 1.6.2 with arm64 https://github.com/zerotier/ZeroTierOne/issues/1317
I was able to compile the version I PRed to you on all other architecture using the store.
I’m trying to compile an older version manually, but I’m having issue with snapcraft on docker. When I will have some time I will try to flash a clean ubuntu image on another SD card and try to snapcraft in the classic environment.
snapcraft could encourage approaches like snapcrafters/android-studio:snap/snapcraft.yaml to automatically keep things up to date (a repo automatically downloads the latest published release). However that’s no good for opening a PR on the upstream repo.
I maintain casperdcl/cli, a fork of github’s cli/cli… they didn’t want to merge a PR adding snap (yet) so rather than taking the Android Studio approach, I just set up a daily cron job to rebase onto the latest upstream in the meantime.
I agree, encouraging some good CI/CD is the best way to reduce orphaned or outdated packages. Maybe it would be a good idea to have it in the docs, so to propose some already solutions known for working well.
Mine is based on Travis CI, as I said, and it runs weekly, rebuilding the snap and publishing to stable → https://github.com/fcole90/fah-snap/blob/master/.travis.yml
I’m quite sure a similar solution can be achieved with Github actions as well
There’s so many problems with 3rd party snaps. The recent Solar Winds attack should point to an obvious one. You can create a version of an application with malware in it and people will just use it. Heck, you could release a ‘good’ version, and then later release a malwared version and it will auto-update.
I really think there needs to be some comparable review process for SNAPs; similar Google or Apple App stores. How much review is of course going to be up to SNAP, but the way things are is pretty dangerous in my opinion. I personally avoid many snaps even though I would really like to install it because I don’t trust ‘Random Person’.
Offer a curated version of the store that has been ‘vetted’. For those who want the wild west of SNAP, more than welcome to use the Open Snap Store. For myself, heck I’d pay a reasonable fee every year to have a review Snap Store. This is especially true as SNAPs auto update
There can be different levels of review
- the SNAP is built from the source. In this case, only a YAML version of a project would be accepted. No forks.
- Some rating of trust of the creater of the SNAP. Big firm, lots of users… other metrics
- Review of permissions requested
- Automated security scan
- Manual review of source or change