The build service is really great, and the new snap status badge (built and released, building, failure) for inclusion in github and similar site that support markdown is neat. When clicking that button the user is shown the status of the last build and the possibility to inspect the logs, example:
As an end user what would be really great is the ability to see which builds released on channels (stable, candidate edge) on the snap store were built using the build service with the possibility to inspect the snapcraft.yaml file used. This way we can minimize trust on unverified publishers because the end user can be certain that the build service is not messing with the sources by introducing any kind of malware and that by inspecting the yaml file he can be sure about what he is going to get and executing on his machine.
This would be almost as good as deterministic builds.
Hope you consider this feature, because at this time we have to trust completely the publisher. Most snaps don’t even include the original used snapcraft.yaml, with all sources in the meta directory.
3 Likes
This is only a partial answer to your request (which I think is generally reasonable and fits the direction we’d like to go in), but it’s perhaps worth noting that snaps built on the build service since December 2017 or so have had something like this in snap/manifest.yaml:
image-info:
build_url: https://launchpad.net/~snappy-dev/+snap/snapcraft/+build/477798
That’s ultimately intended as a building block for something more visible, but in the meantime you can look at it directly.
2 Likes
Thanks, that looks promising! Example url:
And it’s parent (including other architectures):
It’s all there: build log, direct snap file download and other useful meta info.
But what is still missing is the direct link to the original snapcraft.yaml used to produce the build. It is available under /snap/snapname/current/snap/snapcraft.yaml once installed though.
So nice to have it partially supported now. The goal of this feature suggestion is to expose this info to the non expert end user to recognize at a glance which snaps use the build service and trust that more expert users could inspect the build sources which makes malicious actors less likely to try to hijack snaps. Of course this is no solution to all trust issues but it helps since most trust the upstream project but less the packager.
Similarly, the Arch User Repository (AUR) allow the user to inspect the build packages to make at least sure the package is really shipping upstream code from a public git repo and not building a custom or patched binary.
