Lack of package provenance is a security concern

snapcraft
1

snapcraft.io and “snap info …” do not require any package source, authorship, integrity, ownership, or other means by which provenance can be determined.

tl;dr -> What is the intended way to view the source of a snap and connect a snap to its upstream? Can more metadata be required for uploading snaps to snapcraft.io to allow for basic authentication of package contents?

I’m new to using snap but discovered this while working on HashiCorp Nomad and seeing this after trying to run Nomad before installing it:

~$ nomad agent -dev
Command 'nomad' not found, but can be installed with:
sudo snap install nomad  # version 0.7.1, or
sudo apt  install nomad  # version 0.8.7+dfsg1-1ubuntu1

A snap! I just started happily using snaps for other apps, so I wanted to investigate. Nomad’s is very out of date with upstream, so I went looking for how this snap is built:

~$ snap info nomad
name:      nomad
summary:   Easily Deploy Applicatrions at Any Scale
publisher: Stefhen (res0nat0r)
store-url: https://snapcraft.io/nomad
license:   Proprietary
description: |
  Nomad is a single binary that schedules applications and services on Linux,
  Windows, and Mac. It is an open source scheduler that uses a declarative job
  file for scheduling virtualized, containerized, and standalone applications.
snap-id: G6Lkx7rvJ6pn2BbWhQ8ADFz3GxtePT2m
channels:
  stable:    0.7.1 2018-03-27 (1) 10MB -
  candidate: ↑
  beta:      ↑
  edge:      ↑

Hm, no upstream or source links of any kind in the info output. The license is wrong as well. I followed the only available link to the snapcraft website and it did not display any further metadata or links.

There’s an author, but no link to contact the author or gain any information about the author. As far as I know the author field is completely controlled by the end user and could be set to “HashiCorp.”

My only available option seems to be reporting the app, but that’s seems extreme. It’s ok for people to package open source software, but I don’t even know how to tell what’s in this package.

2 Likes
2

A few notes

  • The author field is the name of the account that “ownes” the snap in the snap store, so you can’t just fill in “HashiCorp”. Though nothing is stopping you from creating an account named “HashiCorpOfficial” and publishing snaps under that name.
  • Some authors are “verified”, which means they get a check mark next to their name. However, there is no way to publicly request to be verified. Moreover, users rarely notice the absence of a safety symbol. Which is why browsers are now showing HTTP websites as “insecure” instead of showing HTTPS websites as “secure”.
  • Unconfined/classic snaps require the publisher of the snap to be vetted; the snapcraft team checks if the account is really associated with the developer of that application.
  • Snaps can optionally include their build manifest in the snap as the file snap/manifest.yaml. However, this file could be doctored and the snap tools do not tell you to look in that file.
  • Publishers can include a “contact me” url so you know how to contact them. However, that field is not required.
  • For reference, similar topics have been discussed previously, though not much came from them: Snap build transparency and trust
1 Like
3

Thanks for the useful information and especially for linking that thread! It seems to be focused on preventing malicious code execution, which while a laudable goal, is actually well beyond the scope of what I’m looking for.

Merely requiring a way to contact uploaders would be immensely useful. Requiring an upstream link would be another great step. I’m a bit shocked a centralized package management solution doesn’t require this very basic metadata to be provided. Even if there’s no way to validate the package contents in an automated fashion, it would at least allow for upstream author attribution and manual validation for use in manually reporting apps (eg this package does not match its stated upstream).

Optimally snap would have been designed to support transparent and reproducible builds from the beginning, but it seems that ship has sailed.

4
  • I agree that requiring a contact URL is very useful. Maybe you can try adding this to review-tools? This is used by the snap store and by snapcraft when you upload a snap to the store. Even a warning would be helpful here, I think.
  • I also think it would be useful to have a metadata field “snap source”, which publishers of open source snaps can use to link to the source repository of the snap.

To be clear, snaps support transparent and reproducible builds, it just doesn’t require them at any stage. Creating a reproducible snap package shouldn’t be much harder than creating a reproducible deb package.

1 Like
5

To be clear, snaps support transparent and reproducible builds, it just doesn’t require them at any stage.

Oh interesting! Are transparent and reproducible builds automatically tagged in a user visible way?

6

The review-tools only look at the snap.yaml from the snap and there is nothing in the snap.yaml that is dedicated to a contact URL. In terms of provenance, the review-tools aren’t in a position to verify that the contact URL is accurate for the snap. I recall several conversations about contact URLs in the past, but only remember that they are not supported in the snap.yaml. Perhaps @advocacy has other context?

1 Like