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