I sketched a bit on this like a year ago, especially trust-related things with git-ssb since its access control model is interesting (anyone can push). I think there are two ways there, either 1) to base trust on the ssb identity, such that "run pipeline if the git-ssb message is from a set of trusted ssb identities" or 2) use regular git commit/tag signing with PGP, and only run pipelines for commits with valid signatures.

I think 2) is easier, and also more generic since you can then either git-ssb, gitea, gitlab, or any other way to host git. It is also easier to share PGP keys between devices.

I played around a bit with it with Concourse since it's quite neat and extensible, but got stuck when I wanted to run git-ssb inside a Docker container inside my CI/CD VM, needed for concourse to pull the source. Haven't looked at it since.

@Powersource (phone) I agree your multi-stage pipeline is a nice way to solve that. Also fairly easy to do in something like Concourse where you can trigger a build pipeline for any kind of changed resource (new git commit, new docker image, new version of file on S3-compatible storage, etc.). So you could probably trigger a pipeline as soon as one of your trusted peers has an updated artifact, and then sign it.

Also another thought, if reproducible builds are possible for that particular project, having multiple people build the same source and then publish the resulting binaries/hashes would be a nice way to not actually having to trust the builders. If multiple independent builders produce the same binary I would feel confident that the build is ok :).

Still really tricky to actually make reproducible builds for most projects though :/

@zozs yeah reproducible builds were also my first reaction.

Reagarding the multi-stage pipelines: doesn't it kinda hollow-out the idea of a signature system altogether if the person/machine signing the binary didn't builld or at least verify it themselves? And the only real ways I can think to verify that the binary is indeed what it's supposed to be are...

1. Checking a signature (not possible; we're trying to verify for the signature)
2. Building the binary yourself (would make the exercise pointless)
3. Use reproducible builds and check that there are no conflicting hashes in a sufficiently-large pool of peers.

Or am I misunderstanding something here?

@Daan MVD i agree it does hollow out the idea of signed binaries a bit. On the other hand, if the alternative is that the signing keys are distributed to several hosts, I think a multi-stage pipeline could be the lesser evil of the two options.