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.
Is there is a standard way to retrieve the manifest used to produce the snap, or is the manifest embedded in the snap?
Does the manifest always contain all the information needed to build the snap? At least as of last year, the manifest sometimes omitted important properties of the build environment, such as which repositories were configured. For example, refer to YAMLs for snaps built using PPAs
We aren’t talking about revealing the source code but about packaging process. Build manifest doesn’t contain any sensitive data on its own. This is what flatpak does.
Yes, if you replace transparency with black-box which is only opened voluntarily when you gently ask for it then reproducibility is inherently lost.
