@Powersource (phone) my previous research group did a lot of post-quantum research. They had an internal nerdy bet about which algorithm NIST would select 😄

And yeah, crystals-kyber is public/private key encryption, but meant to be used similar to how RSA is used for encryption today, i.e. just to protect a symmetric key for something like AES or ChaCha20, not for bulk encryption of the data itself :).

@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.

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 :/

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.