Bug#971515: Request for security team input on kubernetes TC bug
* Moritz Mühlenhoff:
> 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.
Let's just say that some Kubernetes developers are very eager to get
their hands on the most recent Go toolchain even if there are
practical issues with choices in the run-time library, such as the
changes to certification validation. Not sure if anyone would want to
suffer these toolchain rebases if there was a clean way around them. 8-)
> 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.
I see.
>> 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.
I think that's it: <https://github.com/golang/go/issues/37436>
If I recall correctly, there was a kernel version check (!) that
managed to reject kernels which did not have the bug. And combined
with the workaround failing, this led to non-functional programs.
Reply to: