The first plugin that we will use as a test subject to record information into the manifest.yaml is going to be python.
In addition to the information that is specified in the source snapcraft.yaml, like
python-version, we will add some more information and details of what’s used during the build. This is the extra information that we will record:
- requirements file: The contents of the requirements file, if it was specified in the snapcraft.yaml
- constraints file: The contents of the constraints file, if it was specified in the snapcraft.yaml
- python packages: The list of all the python packages installed with pip, and their versions.
If you can think of another piece of information that will be useful during an audit of a python snap, please comment here.
@ratliff and @tyhicks from the security team will help us reviewing the proposals of what to record, for all the plugins, the annotations to the source snapcraft.yaml, and the environment where the snap is built.
We are having a discussion here about when should we record the contents of the constraints and requirements files.
If those files are tracked in a source control system, then we already have a way to find their contents without saving it in the manifest file.
However, what should we do if the requirements file comes from a tar, for example. We also have a way to find the contents, but the tar can change. The same can happen with a requirements file in git, it can be removed and the history rewritten.
Until we agree on a consistent set of rules, I’m going to make a change to record it always.
Curious note of the day is that by recording the python packages installed with pip, we can warn the authors of snaps using these fake packages: