Getting SLSA ("Supply-chain Levels for Software Artifacts") compliance

[rugk]

Okay now that we have SLSA compliance on the PirvateBin (PHP) project itself, we can continue here.

Steps needed

From what I see:

1. SLSA-verify the PrivateBin PHP release. (That makes much sense to keep the integrity of the dependency chain intact) Also this will automatically make us aware of SLSA issues in the main project.
2. Then build the Docker image as usual via GitHub workflows and push the stuff. (Also that signature needs to be pushed somehow as a proof.)

Implementation

• (for step 2) This time we should be able/can benefit from a finished builder (I hope). That said the Docker one is marked as WIP hmm… You end up at https://github.com/slsa-framework/slsa-github-generator/issues/57, which explains work is not ready yet. https://github.com/slsa-framework/slsa-github-generator/issues/57#issuecomment-1737837131 suggests alternatives like using the image-based verifier and building inside a container but hmm?
• I am also yet unsure how to integrate that builder then with step 1. Can I somehow define what dependencies it should automatically verify? (I assume we cannot verify deps like Alpine linux or so as they likely do not use SLSA or so, yet.)

[elrido]

We do already guarantee the integrity of most software in our docker images. The privatebin release is validated using the gpg signatures: https://github.com/PrivateBin/docker-nginx-fpm-alpine/blob/65ceef01304606a989dbae98d1a4d43bb1d65d0f/Dockerfile#L56-L59

We use Alpine Linux as a base image and it's apk package manager does verify the packaged items integrity, alpine also strives for reproducible builds and all the downloaded source files hashes are part of the packages spec, so when they get built or rebuilt the sources get validated each time and the built artifacts are also verified through apk itself when you install them.

The part that I'm unsure about is the composer installed PHP libraries - I've not researched if it does any form of signature validation or such.

The PB release is downloaded within the container image, so if we wanted to switch from the gpg signatures to this new tool, we needed that tool to have gotten packaged for alpine. What I do like about the gpg approach is that we can do that verification offline, because we included the public key in the repo - we frequently had issues when the public key had to be downloaded first. The SLSA process relies on an online PKI, so it would probably re-introduce that fragility.

I don't mind having introduced SLSA signatures for third parties to consume, but I don't think it adds any value switching the attestation method in our docker images. gpg is also more prevalent than this new tool and found pre-installed on many linux distros (i.e. in all Debian derivatives, as gpg is used in the package management). slsa-verifier, in contrast, is not yet commonly available via package management - installing and/or building it from source introduces it's own attestation challenge.

[rugk]

Yeah then we can focus on first providing slsa signatures for this build for the outside to consume. Anyway I guess proper verification would be to verify the slsa signatures we can because it provides different security properties.