Allow injection of extra materials via files

[pieterlexis]

Some build systems could create files that contain materials used during
the build (like docker images, operating system packages etc.). These
files would contain a JSON array with Items. When set on the
command-line flag -extra_materials, slsa-provenance will read and
parse these files and add the found materials to the statement.

[marcofranssen]

Thanks for your contribution.

This looks great. Could you elaborate a bit on the usecase and where such provenance file would originate from.

Maybe add a reference to slsa or maybe we can clarify a bit in the README.md.

We are also still learning on slsa and the provenance…

E.g. how would this work with docker images? We also have an open issue to work on docker image provenance support #73

[pieterlexis]

This looks great. Could you elaborate a bit on the usecase and where such provenance file would originate from.

To build PowerDNS packages we use pdns-builder, which is used a git sub-module.

pdns-builder takes some templates and generates a Dockerfile that has all the instructions to build the RPM or Debian package, which is docker cp'd out of the container by the build script when done. The pdns-builder repo also has a few helper scripts to generate the list of installed OS packages in the in-toto materials format.

SLSA specifies that the URL of materials is a "ResourceURI" and that is RECOMMENDED to be a "package url" and has some examples on how these urls can look.

Being able to add this package information to the SLSA material provenance would allow anyone to create a replica of the build environment and reproduce the package. It also proves/tells us what versions of dependencies we linked against.

Maybe add a reference to slsa or maybe we can clarify a bit in the README.md.

SLSA has the "Dependencies complete" requirement. It is described as

Provenance records all build dependencies that were available while running the build steps. This includes the initial state of the machine, VM, or container of the build worker.
MUST include all user-specified build steps, sources, dependencies.
SHOULD include all service-provided artifacts."

For us, the initial state is the docker base-image we pulled (e.g. debian:buster) and the service-provided artifacts are the packages that installed as part of the build-process (via e.g. apt-get).

We are also still learning on slsa and the provenance…

So are we :).

E.g. how would this work with docker images? We also have an open issue to work on docker image provenance support #73

This might not work for actually generated docker images. This is about the docker images used as a base for the builds (which, combined with the exact installed packages should lead to something that would allow for a reproducible build).

P.S. I did notice I didn't update the action.yaml to allow this option to be set, I'll add a separate commit for that.

[marcofranssen]

Thanks for clarifying. Now it starts to make more sense to me. Would it be possible to add a small usage example here in the README.md.

https://github.com/philips-labs/slsa-provenance-action/blob/main/README.md?plain=1#L188

That would be very beneficial for other consumers of the action.

[pieterlexis]

Would it be possible to add a small usage example here in the README.md.

Done!

P.S. I did notice I didn't update the action.yaml to allow this option to be set, I'll add a separate commit for that.

Done!

[MarkLodato]

This change looks good to me (as one of the SLSA authors).

[marcofranssen]

Thanks a lot for your contribution @pieterlexis.