Consider Switching to Chainguard's Python Image?

[dlorenc]

Hey!

I noticed a few CVEs in the image published here, as well as a few issues and PRs to address them: https://github.com/kiwigrid/k8s-sidecar/issues/238 https://github.com/kiwigrid/k8s-sidecar/issues/215 https://github.com/kiwigrid/k8s-sidecar/pull/232

I took a pass at converting this to the Chainguard Python image in a fork: https://github.com/kiwigrid/k8s-sidecar/compare/master...dlorenc:k8s-sidecar:cgr?expand=1

The image is also available at ghcr.io/dlorenc/k8s-sidecar for testing.

Would you be interested in trying this out? If so I could clean this up and send a few PRs.

[jekkel]

Hi @dlorenc

looks interesting. Do you know the versioning and update strategy of those images? I would prefer immutable image tags but unfortunately our current base images rebuild often into the same "floating" tag. This way dependabot is not really able to detect updates (adding the sha to the tag breaks multi-arch builds via buildx I believe). If they reliably publish new versions for updated dependencies then this might be worth the switch already.

[dlorenc]

We can do either floating tags or immutable ones - what would your ideal tagging strategy look like here? I'm happy to help get that supported.

[jekkel]

As said: immutable tags for which dependabot can correctly infer updates (and CVEs) would be best.

[dlorenc]

So something date-time based? Or tied to the versions of the packages underneath somehow?

[jekkel]

I'd vote for semantic versioning, but those base images tend to be a baseline of multiple versions really, some of which are important for compatibility, some not. And I'm afraid there's no common way of aggregating semantic versions, is there?

[dlorenc]

Yeah that's kind of the general issue with tagging images. Every bump is somewhat semantic depending on how you look at it.

[jekkel]

So from my POV I'd prefer the following:

• given an image advertising itself as being a python image
• compatibility based versioning (i.e. SemVer) should focus on changes to python and it's ecosystem
• almost every other change to the image shall be considered a patch increment

So considering python 3.11.x this would translate into something like chainguard-python3.11:a.b.c and every change but python major or minor bumps would be represented in the image version (semantically). Python major and minor changes would be part of the image name. It would be an alternative to move the python minor also out of the image name and translate it into image minor bumps (with an unrelated absolute number though).

Does this make any sense for you?

[github-actions[bot]]

This issue was closed because it has not had any activity in the last 120 days. Please reopen if you feel this is still valid.