search

slsa-framework / slsa-verifier

Verify provenance from SLSA compliant builders
Apache License 2.0
216 stars 45 forks source link

slsa-verifier SHA seems to be different #131

Open naveensrinivasan opened 2 years ago

naveensrinivasan commented 2 years ago

Looking at this https://github.com/slsa-framework/slsa-github-generator/blob/773c7d7a4381a2db9de497319c3b293c6f148421/.github/actions/generate-builder/action.yml#L54 which points to slsa-verifier v1.1.1 as the SHA f92fc4e571949c796d7709bb3f0814a733124b0155e484fad095b5ca68b4cb21

I tried to confirm the SHA and I am doing this on my darwin

  1. Checkout at the tag v1.1.1
  2. Compile using this flag GO111MODULE=on CGO_ENABLED=0 GOOS=linux GOARCH=amd64 go build -trimpath -tags=netgo -o foo .
  3. shasum -a 256 ./foo
  4. The output I am getting for the above command is e43961037f45a237e0c5be30eb05b4deeccf22790f47a3f80b8ed5a910702517 ./foo which seems to different from this f92fc4e571949c796d7709bb3f0814a733124b0155e484fad095b5ca68b4cb21
image

Am I missing something?

naveensrinivasan commented 2 years ago

@laurentsimon @asraa FYI...

laurentsimon commented 2 years ago

Thanks for trying this out, fun experiment. So here are some thoughts:

  1. We don't claim to have reproducible builds, but we'd love to have them :) Have you verified that the arguments we use during compilation are enough to achieve reproducible build? For example, we don't pass any argument to set the build ID or build time.
  2. Once we fix 1), I would start looking at the compiler version you're using. It must be the same we're using. You could try by building in a GitHub workflow and installing the Go compiler's version we used during our build. You can find the one we're using by downloading the provenance file and running cat slsa-verifier-linux-amd64.intoto.jsonl | jq -r '.payload' | base64 -d | jq: 1.18.3
  3. Repeat step 2 on your machine using the same compiler version

Hope this helps.

laurentsimon commented 1 year ago

Do you want to try something to make the build reproducible or do you want to close the issue?

naveensrinivasan commented 1 year ago

Thanks for trying this out, fun experiment. So here are some thoughts:

  1. We don't claim to have reproducible builds, but we'd love to have them :) Have you verified that the arguments we use during compilation are enough to achieve reproducible build? For example, we don't pass any argument to set the build ID or build time.
  2. Once we fix 1), I would start looking at the compiler version you're using. It must be the same we're using. You could try by building in a GitHub workflow and installing the Go compiler's version we used during our build. You can find the one we're using by downloading the provenance file and running cat slsa-verifier-linux-amd64.intoto.jsonl | jq -r '.payload' | base64 -d | jq: 1.18.3
  3. Repeat step 2 on your machine using the same compiler version

Hope this helps.

Thanks for trying this out, fun experiment. So here are some thoughts:

  1. We don't claim to have reproducible builds, but we'd love to have them :) Have you verified that the arguments we use during compilation are enough to achieve reproducible build? For example, we don't pass any argument to set the build ID or build time.
  2. Once we fix 1), I would start looking at the compiler version you're using. It must be the same we're using. You could try by building in a GitHub workflow and installing the Go compiler's version we used during our build. You can find the one we're using by downloading the provenance file and running cat slsa-verifier-linux-amd64.intoto.jsonl | jq -r '.payload' | base64 -d | jq: 1.18.3
  3. Repeat step 2 on your machine using the same compiler version

Hope this helps.

I want to make the build reproducible. I can take on this one. Can you assign it to me?