Matthew GarrettI want a spec for providing metadata defining which artifacts should go into a build and how to build it, and multiple implementations of that spec, and the ability to deploy different implementations to different cloud vendors using SEV to attest to the boot state, and then verify that all these different implementations in different environments generate identical outputs so we can avoid having to place arbitrary trust in our build systems
Could some startup just take a bag of money from someone and do this for me
Rob Landley@mjg59 unfortunately when you combine that with package management systems you get https://xkcd.com/927/
Arvid E. Picciani
Jyrgen N
Nicholas Weaver@mjg59
Or a bag of money from DARPA, perhaps?
Or a bag of money from DARPA, perhaps?
Robin@mjg59 So I’ve just got to trust your spec? Asking for all my xml security spec friends :)
Morten Linderud@mjg59
You could build this under https://in-toto.io/ i think?
Cc @sangy
Sangy@Foxboron @mjg59 Yup! there's actually some work to e.g., attest the state of the builder and more using a link type called SCAI: https://github.com/in-toto/attestation/blob/main/spec/predicates/scai.md
there's already stuff to e.g., cross compare various attestations for agreement by using threshold mechanisms!
penguin42@mjg59 So, if, you were using any standard package manager and build system, and hypothetically, you managed to get a cloud VM to boot into a SEV VM that was trustworthy, and you had got around to some external attestation service, that attestation service could deliver a key to the VM, so that the standard package system could then sign it's built package with a key traceable pack to your attestation system. Who does the comparison to see if 2 produce the same result is even harder.
@penguin42 @mjg59 why would you care if the outputs are the same if you know the environment was safe? (Assuming no attacks on SNP exist, oops oh well)
@penguin42 @mjg59 yeah but it's a lot of work 😄