Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[bug] verify base image pre-submit fails #1401

Closed
laurentsimon opened this issue Dec 21, 2022 · 11 comments · Fixed by #1322 or #1988
Closed

[bug] verify base image pre-submit fails #1401

laurentsimon opened this issue Dec 21, 2022 · 11 comments · Fixed by #1322 or #1988
Labels
type:bug Something isn't working

Comments

@laurentsimon
Copy link
Collaborator

laurentsimon commented Dec 21, 2022

See https://github.com/slsa-framework/slsa-github-generator/actions/runs/3751444140/jobs/6372431280

I have temporarily disabled this check in the branch protection setting

@laurentsimon laurentsimon added type:bug Something isn't working status:triage Issue that has not been triaged labels Dec 21, 2022
@laurentsimon laurentsimon removed the status:triage Issue that has not been triaged label Dec 21, 2022
@ianlewis
Copy link
Member

ianlewis commented Dec 21, 2022

It seems like they re-build and push all the old image tags when they add a new image tag. It's really annoying because it makes it hard to know if an image has been modified out from under us, but I think updating the sha should fix it.

@ianlewis
Copy link
Member

Maybe we don't really need to verify the sha if we can verify the image at the tag?

@laurentsimon
Copy link
Collaborator Author

laurentsimon commented Dec 22, 2022

It seems like they re-build and push all the old image tags when they add a new image tag. It's really annoying because it makes it hard to know if an image has been modified out from under us, but I think updating the sha should fix it.

So you're saying they re-build (non-deterministically) and the hash changes?

@loosebazooka any insights?

@ianlewis
Copy link
Member

Yeah, I'm pretty sure most docker builds aren't hermetic/deterministic.

I filed a bug in the repo for the official golang image so we can see what they say as well.
docker-library/golang#448

@ianlewis
Copy link
Member

I updated the sha in #1322 and re-added verify base images as required check so that should fix the issue in the short term.

@loosebazooka
Copy link
Contributor

loosebazooka commented Dec 22, 2022

There are ways to do reproducible builds. For example with ko and a distroless base image.

Oh the golang image?

@ianlewis
Copy link
Member

ianlewis commented Dec 22, 2022

There are ways to do reproducible builds. For example with ko and a distroless base image.

Oh the golang image?

Yeah, this is the official golang image. They literally push new images for every tag all the time. I literally just fixed it and they pushed the image again and updated the tags 40 min ago (v annoying). I guess they just assume that folks won't reference images by sha and update their tags constantly.

@ianlewis ianlewis reopened this Dec 22, 2022
@ianlewis
Copy link
Member

We pin the base image by sha and verify Docker content trust on the image, but since they update the tags all the time the sha that we expect changes and our image verification script fails.

I guess we could just stop pinning the base image by sha because they clearly don't expect us to and it's pretty useless to do so if they keep updating it.

@loosebazooka
Copy link
Contributor

Oh, those are built by docker, not the golang team. Perhaps @Sajmani knows where the official golang team images are?

@jonjohnsonjr
Copy link

They rebuild the tags to pick up security fixes. This is expected. Tags in container registries are more like git branches than git tags.

@ianlewis
Copy link
Member

They rebuild the tags to pick up security fixes. This is expected. Tags in container registries are more like git branches than git tags.

I kind of understand that better now and I can understand some of the benefits like security updates etc. Thanks. It does make it tricky to work with DCT though.

Right now we are using a Docker container action which builds the image on ever GHA run. It would pick up the changes in the base image tag immediately and AFAIK has no way of verifying the images before using it.

So we have a couple options:

  1. Don't pin by sha. This means that any changes to the base image tag would get picked up immediately and we wouldn't have a way to verify that the base images we are using are verified images. So I think this is out.
  2. Switch to using a pre-built Docker image and verify DCT of base images when we build the image. We can then pin by sha to make sure it hasn't changed since we verified it. This might be the most practical answer, short term, but does require a decent amount of work to set up building, and managing the image.
  3. Rewrite our action to use TS or something else and don't use Docker container actions. Long term, I think we want to do this anyway.

Not sure whether #2 or #3 is going to be more work in the end.

laurentsimon added a commit that referenced this issue Apr 13, 2023
Fixes #1401 

Removes the detect-workflow Docker container action in favor of the
detect-workflow-js action. Also removes the base image verification
pre-submit as it's not needed anymore.

/cc @asraa

---------

Signed-off-by: Ian Lewis <[email protected]>
Co-authored-by: laurentsimon <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type:bug Something isn't working
Projects
None yet
4 participants