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

[rugk]

The problem

Any software can introduce vulnerabilities into a supply chain. As a system gets more complex, it’s critical to already have checks and best practices in place to guarantee artifact integrity, that the source code you’re relying on is the code you’re actually using. Without solid foundations and a plan for the system as it grows, it’s difficult to focus your efforts against tomorrow’s next hack, breach or compromise.

from https://slsa.dev/

The solution

SLSA is in essence a framework/specification/ for software supply chain security.

Now, our supply-chain is IMHO not thaat huge, as the basics are PHP, jQuery, bootstrap and that is it. Anyway, it is also about the projects using and building upon PrivateBin. Again, as we are not a library, these are not a lot, but basically Docker images bundling it could be considered one.

SLSA seems to be a big industry effort on getting to deal with supply-chain security, which has never been done before in that essence AFAIK: https://openssf.org/press-release/2023/04/19/openssf-announces-slsa-version-1-0-release/

There is a big theory block to unpack, and I also have not yet gotten it all and also think this is quite… huge…, but in general it makes sense: There are many risks associated and we of course target the OSS use case here though in general.

• in general everything is about publishing attestations about how the software was built, in the end to a public source like this
• there are different security levels
• you may have seen projects like Docker etc. currently implementing support for it

So more practical…

https://slsa.dev/get-started actually recommends SLSA 3 if you built releases with GitHub Actions.

If you are building on GitHub Actions, adopt the Language-agnostic GitHub provenance generator / builder to make your build qualify for SLSA 3. Consumers can use the Generic SLSA Verifier for provenance verification.

https://slsa.dev/get-started#github-actions

The thing you see when you dig deeper is that it is still quite frech. The GitHub builders actually have no PHP builder, but Docker (which is WIP). Though there is also stuff for static tarballs

Alternatives

IMHO as a security-focused project, we should at least consider introducing it.

That said, our current build process for releases does not use GitHub Actions, does it?
Also, it does AFAIK go contrary to the assumptions of the project, because:

• Trust code, not individuals -> AFAIK @elrido (in 99%) you build the source and sign it. I know I have the PGP key laying somewhere, so I could too, but I trust you to do it
• Trust platforms, verify artifacts -> In the past we and me personally, did not want to trust the build processes of GitHub Actions etc. not to be malicious

Now, I see advantages in changing that, i.e. e.g. anyone can trigger the release build (more easily, too) and due to the way we build (i.e. basically the static tar file approach is all we may need – you know it depends on e.g. if you bundle GCS or so) , we could combine the aim with another one:

• Reproducible builds are a more older solution to the same problem, basically. Famously done at Debian e.g..

The SLSA site says that SLSA stage 3 can be achieved with that i.e. “verified reproducible”, which is again more strict.
Given how that is done, one could actually do it similar to how F-Droid handles reproducible builds, i.e. you can build the release locally, too (and then in the end upload your .sig/.asc anyway) and the release built by GitHub Actions should be bit-by-bit the same. So the signature should actually match.
Thus, we would have combined both approaches and do not even need to trust the platform that much (for that single run at least), but also not the individual developer, who "just" does a verification at the end confirming the build artifact matches. And we would be backwards-compatible, because of course I really would not expose the private key to a build system like GitHub Actions – IMHO, but this can also be discussed.
It's all about threat models after all. (And the SLSA people really seem to have invested a lot into thinking about software delivery.)

Given our build process (if we keep the simplest example) is so simple, that may be possible actually.

Additional context

I just wanted to write that down to spark discussion. Maybe it is not something to implement right now, but in the future when more tool support may be there.
Though, maybe baby steps can be done here.
Also, this focused on publishing provenance i.e. documenting the build process, not about verifying it from dependencies. IMHO that is the next step

[elrido]

At our company we are ATM looking at shipping our software with an SBOM (requested by some enterprise customers) and are comparing implementations of either the CycloneDX or SPDX formats to document provenance of each release and it's components. The two formats compared, in a nutshell: https://blog.sonatype.com/comparing-sbom-standards-spdx-vs.-cyclonedx-vs.-swid - it seems to me that SPDX is better supported in the industry ATM, while CycloneDX is a bit more forward thinking but also more complex. I had not heard of SLSA before, so it is certainly welcome to get to know this one as well.

Our projects builds are easily reproducible by anyone, as when we tag a commit (which any maintainer can do) github will automatically generate a git archive on the fly and these must be identical as when you locally create them using the "git archive" commands. So we already allow all maintainers to cut a release.

The signing key is currently kept by us two and you provided me with the script in #219 which is now part of the git tag signing process:

PrivateBin/Makefile

Lines 40 to 43 in b998820

	sign: ## Sign a release.
	git tag --sign --message "Release v$(VERSION)" $(VERSION)
	git push origin $(VERSION)
	signrelease.sh

Yes that part is manual, but it could be automated if we trusted github with the signing keys. We do use these signatures to validate that the release archives downloaded from github are not tampered with when building the container images, though all of that now happens on github infrastructure - but again it is reproducible by anyone using the "docker build" command (or podman or buildah...).

Not sure how public those are, but at least maintainers should be able to see the above lines output in the container build logs (occurs several times in the log, once per supported CPU architecture as multi-arch images consist of several related container images that have to get built independently):
Example log from our 1.6.0 image release

From what I read on the SLSA site, they offer some kind of independent mechanism to sign and verify artefacts and as you noted they offer a simple mechanism to integrate into a github pipeline, i.e. one that we could trigger upon a tag being pushed (which in our case means a release) and then it either downloads that tags archives (both the tar.gz and zip) to generate the shasums on or does an independent git checkout and git archive for each format.

I was curious how that signing works, if we don't have to create & publish our own key or store some token in github for the action to use and this part of their spec seems to expand on that "keyless signing".

Aside: If we try such a pipeline, we could also add this action to it, which can read the CHANGELOG.md and extract the matching version and add it's text to the (drafted) release, allowing a human maintainer to attach the gpg signatures to it in addition. That would further simplify the release process for me.

I don't mind if we give a release pipeline a try, as there is currently seems not much more impact to it than just getting some additional jsonl doc attached to our releases, which will allow users down the line an additional way of verifying our build artefacts. I would currently not yet consider extending it with the git signing process - we can extend this later on, if you would feel more comfortable with this being automated and triggered by anyone allowed to tag in our repo, than just two dedicated key holders. As long as we do keep that key at hand, should we ever need to release urgently, manually (github actions down again or rate limited or whatever).

[rugk]

Yeah I am fine with a release pipeline, but not find with providing the signing key to GitHub for now IMHO.

But manually attaching it to a (draft) release would be fine for me.

[elrido]

Sorry, have to re-open this. The release part of the pipeline seemed to work fine and I only needed to update the title of the draft and attach the signatures, but the SLSA failed in the last step:
https://github.com/PrivateBin/PrivateBin/actions/runs/7091984640/job/19302337952

I suspect the error(s) start here:
https://github.com/PrivateBin/PrivateBin/actions/runs/7091984640/job/19302310759#step:3:5

Probably need to change this to:

        run: echo "hashes=$(sha256sum ${GITHUB_REF_NAME}.* | base64 -w0)" >> "$GITHUB_OUTPUT"

[rugk]

ref
https://github.com/PrivateBin/PrivateBin/actions/runs/7091984640/workflow#L37

Yeah, though that also misses newlines, does it? Or ah, it should be one big hash, not two one per file, should not it?

$ ls    
file.tar.gz  file.zip
$ export GITHUB_REF_NAME="file" 
$ echo "hashes=$(sha256sum ${GITHUB_REF_NAME} | base64 -w0)"
sha256sum: file: Datei oder Verzeichnis nicht gefunden
hashes=
$ echo "hashes=$(sha256sum ${GITHUB_REF_NAME}.* | base64 -w0)"
hashes=ZTNiMGM0NDI5OGZjMWMxNDlhZmJmNGM4OTk2ZmI5MjQyN2FlNDFlNDY0OWI5MzRjYTQ5NTk5MWI3ODUyYjg1NSAgZmlsZS50YXIuZ3oKZTNiMGM0NDI5OGZjMWMxNDlhZmJmNGM4OTk2ZmI5MjQyN2FlNDFlNDY0OWI5MzRjYTQ5NTk5MWI3ODUyYjg1NSAgZmlsZS56aXAK

(It's fake/empty files just for shell testing)

Then it works fine, yeah.

[elrido]

Short update, this time around it seems to have worked and an intoto manifest got produced, see: https://github.com/PrivateBin/PrivateBin/releases/download/1.6.2/multiple.intoto.jsonl for the 1.6.2 release.

Feel free to verify it - from the docs I understand we can use this tool to do so: https://github.com/slsa-framework/slsa-verifier#verification-for-github-builders

[rugk]

For reference: Here is the first successful GitHub release process with an SLSA run: https://github.com/PrivateBin/PrivateBin/actions/runs/7218726337
You can e.g. see the release proof has been uploaded to https://search.sigstore.dev/?uuid=24296fb24b8ad77a42448d0044a1a78b43f1cd95cfe66ad16dab7d0100c218e0debc276cb0bb3e58 (The multiple.intoto.jsonl is there, so I am not even sure, whether we need to upload it by ourselves, but I guess it won't hurt.)

And given the manual PHP .sig in the release we have achieved reproducible builds too (or at least we can prove it now haha). (Given everything verifies, of course)

[rugk]

Some things I have done:

• Let's plan how to apply that to the official Docker image too and make use of the verification there. See/created Getting SLSA ("Supply-chain Levels for Software Artifacts") compliance docker-nginx-fpm-alpine#181 for it.
• Also I noticed some "how to verify and how to do release" documentation was missing. Created Created doc for “how to verify and how to do release” (release doc) #1217
• Created a PR for adding this to the list of projects using the GitHub provenance builder, see docs: Add PrivateBin as project using this to generate SLSA provenance slsa-framework/slsa-github-generator#3036