Open ikeycode opened 1 year ago
When you say "build machine," do you mean the machine building the package for the repo, or the individual packager's machine? Or both? I guess it doesn't really matter in the end, just asking for clarity.
Does this require the generation of additional private/public keys from contributors?
Regardless, additional verification isn't a bad idea, and the ability to untrust builders if something goes super sideways seems like a really nice feature.
So the actual (final) infra machine that built it. This is different for privately built packages obviously. But I'm more thinking of "two ticks" CD
Gotcha. This seems like a good idea to me.
Sounds like a good idea to me
Gotcha. This seems like a good idea to me.
Sounds like a good idea to me
I concur. This seems like a good idea to me.
I like this approach.
We're going to add multisig support to the .stone format, as per-package verification is inherently far more secure than index-based verification.
As part of our build infrastructure, each build machine will sign a .stone to lay ownership on it, whilst the repository will add another signature upon incorporation. This will facilitate the revocation of malicious machines and artefacts en-masse.
Note: We can also use this to single-sign our stone-format repository index files
Computation
In verification, the SignaturePayload is exempt from iteration. Compute the BLAKE3 hash for the raw data of all payloads (header+block). Then generate EdDSA (Ed25519 curve) key from this input hash. Each signature is inserted into the SignaturePayload
SignaturePayload
A SignaturePayload will consist of one or more SignatureIdentifiers. Each will tag the origin (local, remote, authority, etc), key length, algorithm, in a robust enum-based update-friendly fashion. For example: