release
release copied to clipboard
kubernetes
Document the process for updating Debian base image
We started discussing if our subscription to the debian-security mailing list is effective and giving us results at the SIG Release meeting held on 2023-05-16. The mailing list has a lot of traffic, but most of emails are not relevant to us. However, with that traffic, it might be easy to miss something that is important to us.
We discussed if there's a better way to stay informed and alerted about CVEs/vulnerabilities affecting us and the idea that came from @justaugustus is to start updating the Debian base image regularly.
That way we're going to use the latest image at the time, so number of CVEs that affect us is minimal. This is also inline with the community feedback which is that compliance teams often don't care if some CVE is exploitable but they're striving for zero CVEs.
The idea is that we update Debian base image after cutting patch releases for that month. It was intentionally proposed to do that after cutting patch releases so we have close to a full month to detect any potential regressions caused by updating the base image.
There are two major parts of this issue:
- Update the Debian base image and document all the steps needed to do so
- Based on that experience, create a document describing how can other Release Managers do the same. Ideally, that document should be an issue template similar to one that we have for Go updates
/sig release /area release-eng /priority important-longterm /assign @xmudrii @jimangel
The Kubernetes project currently lacks enough contributors to adequately respond to all issues.
This bot triages un-triaged issues according to the following rules:
- After 90d of inactivity,
lifecycle/staleis applied - After 30d of inactivity since
lifecycle/stalewas applied,lifecycle/rottenis applied - After 30d of inactivity since
lifecycle/rottenwas applied, the issue is closed
You can:
- Mark this issue as fresh with
/remove-lifecycle stale - Close this issue with
/close - Offer to help out with Issue Triage
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale
The Kubernetes project currently lacks enough contributors to adequately respond to all issues.
This bot triages un-triaged issues according to the following rules:
- After 90d of inactivity,
lifecycle/staleis applied - After 30d of inactivity since
lifecycle/stalewas applied,lifecycle/rottenis applied - After 30d of inactivity since
lifecycle/rottenwas applied, the issue is closed
You can:
- Mark this issue as fresh with
/remove-lifecycle stale - Close this issue with
/close - Offer to help out with Issue Triage
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale
Hey @xmudrii are you working on this or did you just drop the label? Happy to pick this back up when I return from paternity leave (mid June). I'm currently working on clearing out all my GitHub backlog so I can start my return at "0."
If you're working on it, please unassign me. Thanks!
@jimangel I'm not working on it at the moment, feel free to pick it up! /unassign
The Kubernetes project currently lacks enough contributors to adequately respond to all issues.
This bot triages un-triaged issues according to the following rules:
- After 90d of inactivity,
lifecycle/staleis applied - After 30d of inactivity since
lifecycle/stalewas applied,lifecycle/rottenis applied - After 30d of inactivity since
lifecycle/rottenwas applied, the issue is closed
You can:
- Mark this issue as fresh with
/remove-lifecycle stale - Close this issue with
/close - Offer to help out with Issue Triage
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale