When we install a snap, how do we know that they are safe?
Do we have access to the build scripts, or is it just a matter of trusting the uploader?
For example, https://snapcraft.io/thunderbird is quite popular. It’s not from Mozilla or the Snapcraft team. How can we audit it to make sure it doesn’t harvest email passwords or run a bitminer, for example?
Docker, for example, will link to the source or display the dockerfile. Flathub will also show the build script on github most time.
Not saying it is malicious, just asking how the trust is established.
the trust in snap is mainly established on a binary/execution level … to harvest any data from your system a snap would have to have access to the respective places on your filesystem which snaps typically do not have by default unless you connect the respective interfaces allowing them to do so … that said, it is indeed good practice to put a link to your snapcraft source into the package description (since we are still lacking a source: field in the metadata AFAIK) … perhaps @kenvandine would be willing to add some hint to the source of thunderbird here …
Does @kenvandine have any relevance other than being the author of that snap? I only used that snap as an example.
And the snaps will get access to the data, users will agree to whatever the default permissions are. For Thunderbird it will know your email password because you enter it yourself. For something like Rambox, you enter all your social media and slack passwords.
For this community to be able to trust the snaps, we need to either trust the author of the snaps, or need to be able to easily see the build process so any diligent community member can raise concerns.
Also, simply linking to the source is not enough if there is no automatic build process, since a malicious snap author could simply upload a snap not based on that source.
I really wish someone from the snap team would weigh in on this, but I am not sure how to properly raise this to their attention. Someone like @popey perhaps?
not really, snaps are exactly designed for not needing to trust the author via the automated store reviews on upload that scan for malicious behaviour along with confinement on the users host and the use of intefaces …
indeed it is true that you give your email password to the email client app you are using … but you can also be sure that beyond this email password this application can not read your ~/.gitconfig or your steam login or whatnot …
not sure if @popey is much closer to the “snap team” than i am … but i moved this post to the snapd category so it will show up in the right queue…
snap apps can be created and published by almost anyone, and you need to have some level of trust to use any snap. The whole of the snap confinement mitigates the worst cases and tries to make it easier to decide what and when to trust things, and the “verified publisher” checks should bolster that further. However, just as with regular packages, if you don’t trust a snap’s author, don’t install that snap!
Also note: snaps created via build.snapcraft.io or indeed the launchpad build farm directly will have a snapcraft.yaml and a manifest.yaml with which you should be able to rebuild snaps to some degree. They’re not reproducible builds as there are dates and things in there, but maybe this is what you’re after?
… but note too that you can create snaps with toothpicks, duct tape and pliers too, there isnt any requirement to use build.snapcraft.io or even a snapcraft.yaml (or snapcraft itself) to build a snap
… even though the vast majority is surely built using the build service nowadays, the upload scans, confinement (a snap is not actually executed on top of your host rootfs at all, all relevant bits of the sandbox are readonly etc etc) and interfaces are the bits that minimize the attack vector … but indeed you need some level of trust when giving the app credentials that it needs to operate.
You can inspect the snap yourself. Here for example I download the snap from the store, unpack the manifest.yaml which shows what the build was made from, and links to the build in launchpad from where you can get the build log. Does this increase your confidence that the snap contains nothing nefarious?
I think there are several opportunities to display this information in the current snapcraft.io/store. Currently snapcraft only has the “Verified account” badge as a means to vouch for the snap.
Compared to https://hub.docker.com/search?q=&type=image, you can see that they have a few different levels. They use “Official Images” that are made by Docker, “Verified Publisher” that is sort of like the one snapcraft uses. There’s also “Docker Certified” which is above and beyond what I am suggesting here.
However, there are also ways to feel safe in using the ones that don’t carry the above badges, and this is what my point is. Take this one, for example: https://hub.docker.com/r/buildpkg/debian
I can directly and easily see the Dockerfile, and can tell right away that there are no shenanigans going on. I can also see the automatic build logs, so I know that the chain of trust is not broken between the source code and what was uploaded to the Docker repository.
So, my suggestion would be that snapcraft does something similar. Show the contents of the related snapcraft.yaml file directly on the store page (or link to it), and indicate that the build was performed on the build server and therefore matches the snapcraft.yaml recipe. Some sort of “Trusted build process” badge or whatever could also be used.
I think this would go a long way of increasing snap usage as people would be more inclined to trust snaps made by 3rd party developers. Realistically, why should someone trust them otherwise?
It could also help entice new developers as there would be more exposure to snapcraft.yaml files instead of having to go hunting for them. I think it has helped the Docker community by always showing the Dockerfile alongside the container description.
We had some discussions in the team recently about verification, and increasing user confidence. I expect these things might get discussed again and perhaps scheduled for the next cycle (starting in November). Everyone has a busy backlog right now, but it’s certainly something we’re aware of and can look again soon.
There are scans yes, but please note that scanning for runtime behavior is fraught. If the user enters a credit card number into a browser snap, there are no scans that would catch the browser exfiltrating the provided data to somewhere else.
It has always been my recommendation that people should consider the publisher when installing a snap in addition to things like classic vs strict, connected interfaces, what data to provide to the snap and ideally, yes, build logs for open source projects.
Trust for publisher have to come from somewhere and nothing builds trust as much as transparency where everyone can see how upstream source end up in snap package.
That’s not the point. We don’t want open source software being closed source basically because the build process if hidden, and we can’t go around to everyone asking “can we please see your build process?”.
So you’d want to force any proprietary software vendor out of the snap store? Snaps are just a delivery mechanism, while it is great that you can include build information (and we should definitely encourage any opensource developer to do this), this can’t be mandatory…
Edit: perhaps we could enforce it for certain licenses though
For any package in the ubuntu (or debian) repositories, anyone can rebuild it from source via apt source and debuild. It seems reasonable to insist at the very least that this reproducibility is retained by any package that is migrated from deb to snap format.
