Bug#971515: Request for security team input on kubernetes TC bug
On Sun, Nov 08, 2020 at 10:49:31PM +0100, Florian Weimer wrote: > * Moritz Mühlenhoff: > > > * Follow a scheme similar to Firefox ESR where in case of a security > > the update either happens to the latest minor release of > > the current branch or if that has stopped, happens to the next > > major release. To map this to specific k8s releases: Let's assume bullseye > > were already stable and would ship 19.3. In three months a security issue > > arises which is severe enough to warrant an update and we ship 19.5 > > in a DSA. Fast forward 6 months and 19.x is EOLed, but some severe > > security issue needs to be fixed; then the bullseye update would move > > to 20.1 or so. That sounds unusual for a Debian release, but it's > > the status quo for _any_ Kubernetes user after all (whether deployed > > on premises or at some "cloud vendor"). > > Another thing to consider: Kubernetes rebases will likely require Go > rebases, if I read this table correctly: > > <https://github.com/kubernetes/community/blob/master/contributors/devel/development.md#go> I can't tell how strict these requirements are in practice. It's similar to Firefox requiring more recent versions of rustc and golang packages are co-installable, so when it comes to that, shipping a new golang-x.y package might also be an option. > Since Go has a bit of spotty history in terms of kernel backwards > compatibility, this could cause further challenges. Do you have a concrete example of such a change? I see that 1.14 is available in backports, so this seems to work out so far. Cheers, Moritz
Bug#971515: Request for security team input on kubernetes TC bug
Catching up on this... > > This leaves Debian with two options: > > * Keep it out of a stable release and accept that it's good enough > > if people just install whatever deb they currently find in testing/sid > > (works out well enough for most given that blob nature of Go!) > > IMHO this is the most reasonable option and perhaps the only viable one. Ultimately that's for the release team and/or CTTE to make a call on. And this while discussion also needs the input of Janos as the current kubernetes maintainer. > > * Follow a scheme similar to Firefox ESR where in case of a security > > the update either happens to the latest minor release of > > the current branch or if that has stopped, happens to the next > > major release. > > I think Kubernetes have many more vendored 3rd party libraries than Firefox. > IMHO we can not expect the same level of confidence for Kubernetes... But each of their releases constitutes a bundle of third party libraries they've vetted to work together, so this seems to work in practice? (as can be seen by the 1.19 upload from today). Or maybe I'm missing the specific concern of yours, is this about them missing fixes in their bundled libs? Cheers, Moritz
Bug#971515: Request for security team input on kubernetes TC bug
On Wed, Oct 21, 2020 at 08:22:11AM -0700, Sean Whitton wrote: > Hello security team, > > The TC are being asked about src:kubernetes, and it would be good to > hear from you about whether and how security support is a relevant > consideration in determining whether the level of vendoring in that > package is acceptable. Could you take a look at #971515 and perhaps > give us some input, please? I don't currently have the time to read through all the discussion backlog, but let me try to "zoom out a bit": The bigger issue here (independent of the whole vendoring aspect) is how kubernetes can be supported in a stable release to begin with. This was raised by Shengjing Zhu in #959685 before. Upstream support only lasts for up to a year and it would be presumptuous to pretend that we can seriously commit to fix security issues in k8s for longer than upstream. This leaves Debian with two options: * Keep it out of a stable release and accept that it's good enough if people just install whatever deb they currently find in testing/sid (works out well enough for most given that blob nature of Go!) * Follow a scheme similar to Firefox ESR where in case of a security the update either happens to the latest minor release of the current branch or if that has stopped, happens to the next major release. To map this to specific k8s releases: Let's assume bullseye were already stable and would ship 19.3. In three months a security issue arises which is severe enough to warrant an update and we ship 19.5 in a DSA. Fast forward 6 months and 19.x is EOLed, but some severe security issue needs to be fixed; then the bullseye update would move to 20.1 or so. That sounds unusual for a Debian release, but it's the status quo for _any_ Kubernetes user after all (whether deployed on premises or at some "cloud vendor"). If we follow the latter approach, then the current way k8s is packaged is the only viable option (as otherwise the run time deps shipped for 19.x would be incompatible with 20.x etc.) Cheers, Moritz
Bug#947847: please install systemd-sysusers using update-alternatives
Simon McVittie wrote: > I think we have a fairly good picture of the costs that would be > incurred from using alternatives: Plus in the case of opentmpfiles; a pile of security issues: systemd-tmpfiles addresses a number of complex races using low level primitives like openat() et al. or O_PATH, while opentmpfiles is implemented in shell. Cheers, Moritz
Bug#727708: systemd (security) bugs (was: init system question)
On Thu, Nov 28, 2013 at 08:07:16PM -0600, Steve Langasek wrote: All distributions care about not having security issues in their code, but that's not the same thing as actually doing the work to audit the code. In practice this only happens when dedicated resources are turned on the code in question, and having more companies using the code does not magically make that happen. [I took care of the systemd DSA people are referring to] The issue people are talking about were discovered during a review of the Red Hat Product Security Team (most likely triggered by the inclusion of systemd into RHEL7). So in fact having more companies use the code exactly made that magically happen. For every complex code base a thorough review will unveil security-related implementation bugs and the ones found for systemd are not exactly earth- shattering. More review and more usage will lead to more bugs being found, we should rather applaud Red Hat for investing resources and be diligent. After all Red Hat is the only distro staffing a proactive product security team (from which everyone is profiting outside of RH as well). I don't consider the lack of reported security issues for the contenders as a credible indication of them being more secure. FWIW, the main reason I'm personally in favour of adopting systemd is precisely security (in terms of sandboxing and restricting services). See http://0pointer.de/blog/projects/security.html for some pointers. [EOD from me due to a lack of time, but that needed to be said] Cheers, Moritz -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131130150714.GA4204@pisco.westfalen.local
