Verifying provenances of internal builds on external mirrors? #828

Activity

1. TomHennen commented on Jan 24, 2025

   

   TomHennen

   on Jan 24, 2025

   Last edited by TomHennen

   More actions

   Hey Dionna,

   I think there might be two questions embedded in there (note I'm not an slsa-verifier expert).

   1. Can slsa-verifier support verifying provenance from proprietary tools? (IMO we should make this work if it doesn't already)
   2. Would it be possible to provide a public/private mapping to be used when verifying provenance to support use of internal mirrors? (I think this is what you mean by 'variable retargetting').

   For 1, something we'd need a slsa-verifier expert to chime in on is how the buildType would be handled. SLSA allows each builder to specify their own, and I don't know what type Kokoro-on-RBE would use.

   For 2, would something like this work how you'd expect?

   Assumptions:

   https://some.internal.mirror.repo/foo/bar is an exact mirror of https://github.com/foo/bar.

   Input provenance

   {
       "_type": "https://in-toto.io/Statement/v1",
       "predicateType": "https://slsa.dev/provenance/v1",
       "predicate": {
           "buildDefinition": {
               "buildType": "kokoro-on-rbe-or-whatever",
               "externalParameters": {
                   "configSource": {
                       "ref": "refs/heads/main",
                       "repository": "git+https://some.internal.mirror.repo/foo/bar",
                       "path": "basic-config/kokoro.yaml"
                   },
               "resolvedDependencies": [
                   {
                       "uri": "git+https://some.internal.mirror.repo/foo/bar@refs/heads/main",
                       "digest": { "gitCommit": "bb0fe8075f92bb82b679afe400a47b106f0cec4b" }
                   }
               ]

   Example command line

   $ slsa-verifier verify-artifact foo.blob \
     --provenance-path foo.blob.intoto.jsonl \
     --source-uri github.com/foo/bar \
     --source-branch main
     --rewrite-mirror git+https://some.internal.mirror.repo/foo/bar,git+https://github.com/foo/bar

   Where the caller says "hey, if the provenance says git+https://some.internal.mirror.repo/foo/bar, replace that with git+https://github.com/foo/bar". Somehow you'd have to tell users to do the rewrite, and I'm not quite sure how to ensure that's safe. One way might be "check that the gitCommit listed in the provenance matches a commit on the upstream repo and that it appears on the same branch."

   But... maybe you have something else in mind. Can you perhaps provide a sample of what you'd like the command line invocation to look like?
2. ramonpetgrave64 commented on Jan 24, 2025

   

   ramonpetgrave64

   on Jan 24, 2025

   Contributor

   More actions

   Thanks @TomHennen. To help, I have some additional questions.

   Which aspects are transparency were you looking for? Publishing the build event and signing event to a public log like Rekor?

   If your build process is able to access the instance's identities, and your firmware are actually container images, then you may be able to use GCB's built-in support for producing SLSA attestations, and slsa-verifier to verify the images.

   I think you mentioned pushing your internal source code to an external mirror. Did you mean Github? If so, would you consider performing your builds on Github, if you can get a bit-for-bit reproduced builds with your docker commands? This way, you can use our slsa-github-generators to produce attestations, publicly verifiable with our slsa-verifier. (You can also use Github's similar attestation system)

   If the SLSA Build levels are not your necessarily part of your goal, you can consider producing a VSA with a static signing key. You can distribute your firmware, the VSAs and the public key to your consumers, and use slsa-verifier to verify the artifact, VSA, and public key.