If a certain snap is set up to be built and published by one of the Canonical controlled build services (i.e. build.snapcraft.io and Launchpad) it might be beneficial if the corresponding public source repository (and even the build logs) can be exposed on the store page so that the user can know where it is come from(increases the transparency).
Implementation Details
If the snap’s automatic publishing is set up we should also disable the ability for the publisher to publish the snap via the snap push command so that we can ensure all snap builds are from specific public source repository rather than pushed directly from the publisher(or someone else ;P).
If the environment variable SNAPCRAFT_BUILD_INFO is set to 1 then you’ll get a snap/manifest.yaml inside the snap on build. This is part of the system which sends out security updates.
Snaps built in launchpad have this switched on by default. Many of the snaps I have installed have this.
$ ls -l /snap/*/current/snap/manifest.yaml | wc -l
79
I believe there have been discussions in the past about having some kind of snap source equivalent to apt-get source. Not sure where those discussions got to, perhaps @chipaca knows.
Sure, I understood that. I was just pointing out that some of the pieces necessary for this to happen now exist. Whether that’s exposed via snapd-glib to gnome-software and via the snapcraft website, is a matter for a bunch of other people. There’s an upcoming set of meetings in a couple of weeks, perhaps this will be considered for the next cycle.
How do we know that the manifest.yaml is not something that the developer put in manually and was actually not created by snapcraft on build? I.e., how do we know that this hasn’t been tampered with and does reflect the actual contents of the snap?
I believe the content of prime/meta and prime/snap directories are reserved and will be overwritten by snapcraft, as long as the build environment isn’t (fully) controlled by the publisher it should be fine.
it’s conceivable that the build service could perform an attestation step whereby it signs the build files it bundles e.g. via GPG. That would allow reliable guarantee that the build was performed on the build service provided that the key cannot be accessed, and exfiltrated, during a build by a snap author’s code.
Do we really need to be so certain that a build was performed on the build service, and unmodified by the builder, though?
There’s no guarantee that the developer hasn’t doctored the manifest.yaml. However, you could try building the software yourself using the details in that file and compare the results. At the end of the day, you’re going to have to put trust in the developer and snapd’s confinement system.
Some potential users are more security-conscious than I and want more guarantees as to why they should trust Canonical and the snap developer, I think knowing what the source is, if the developer wants to provide it, would help.
Unless you build your running system completely from scratch you have no guarantee that any of its components was build from specific source. It doesn’t matter how much security-conscious you are, in the end Trust is all there is.
It’s not just my thought, apparently, there’s a site arguing that builds should be reproducible with many projects (including Arch, Bitcoin, Debian, Fedora, openSUSE, and Tor) working on making their software reproducible to build: https://reproducible-builds.org/
I can see that Flatpak is not listed, however, so perhaps this is somewhere that snappy could gain an edge, if it so wished (though I imagine that Flatpaks being reproducibly built would come under Fedora’s goal).
I think you are presupposing that snaps must only be for open source projects. I’m not so sure that Microsoft would like their Skype build information public for example.
