I recently took a look at the Signal snap and noted in the issue tracker that it pulls in the current .deb file without any verification (either GPG or checksum). It seems to me like it’s a good idea to be verifying remote sources wherever possible.
After looking closer, I notice that the Signal team are not publishing separate signature files for the packages, which means this can’t be done with a simple gpg --verify and we probably have to invoke debsig-verify instead to verify the signatures embedded in the package.
Unfortunately, debsig-verify is somewhat convoluted and needs keys to be imported into a precise directory structure as well as a policy file to be generated before it will work properly. I started looking into how to integrate this kind of verification into the override-build: step but immediately it strikes me that this would create a lot of boilerplate in every Snapcraft.yaml that implemented it.
Since I note a lot of Snaps seem to be built by pulling in upstream .deb files, I propose that it would make sense to provide some form of integration for debsig-verify that would allow a Snap author to easily pull in an upstream .deb file and verify it by declaring only the .deb file and either a key signature or upstream .asc file.
We do have experimental (unstable) support for package-repositories configuration, which will enable repositories using snapcraft.yaml configuration. I hope that it should have the effect of reducing the number of [sideloaded] deb installs, and instead rely on the apt infrastructure already in place for validation. Signal is a good candidate for this.
For the general case of validating fetched files, I would encourage the use of source-checksum property.
This does sound like it would solve the issue at hand. (For others reading, the thread with more info is this one.
This I would agree with, though as an aside I have found a number of issues with this approach and the dump plugin. For instance, in the case of Signal’s Snapcraft.yaml, there is some automated logic going on with sed and grep etc, to obtain the version number of the latest package version so that the package can be pulled. I can’t see any way to manipulate the source-checksum field in a similarly programmatic way.
Similarly, the source-checksum property does not accept using on statements the way source does, so Snaps which use the dump plugin and are built for multiple arches are basically locked-out of using source-checksum. (Though that is probably an issue that warrants its own thread).
