Re: Security policies for Kubernetes

Greg KH <gregkh@...>

On Thu, Nov 10, 2016 at 12:41:46PM -0700, Nicko van Someren wrote:
It's also worth noting that precisely because the Linux kernel team put out a
release every single week the scheduling of IT resources for deployment is not
a problem. People know in advance when your releases are going to drop. It is
more valuable to have the advanced notice if you don't have a highly regular
delivery schedule.
Ah, but I don't, I'm a horrible release maker. I did 3 releases 2 weeks
ago, none last week, and then one this week. Or was it one last week, I
can't remember... And all were on different days of the week, with no
apparent reasoning behind when each is made[1] (some came later than
announced, some earlier, and one with no announcement at all, and this
was just the past 3 weeks.)

So no, no one knows when our stable kernel releases are going to happen,
heck, I don't even know that :)


greg k-h

[1] - It's my travel schedule that drives most of it, combined with when
security bugs are found and fixed in Linus's tree, which happen
unexpectedly as expected, or when embargos leak early, as happened
with DirtyC0w[2].

[2] - DirtyC0w is proof that even when everything goes right on the
project's security team side (kernel team was properly notified of
problem in the wild, fix was found, backports to all relevant
kernels were made and tested, embargo was planned, distros were
notified ahead of time), it's really up to the other groups you
notify to not mess up in order to keep it all together, which
failed horribly here (embargo was leaked to the public from a
distro, random companies knew there was a pending problem weeks
early due to a different leak, competing OS team decides to make
fun of the situatation and make a web site, etc.). So I'm really
all for not telling _anyone_ outside of the project's team about
security issues, as it always seems to go wrong.

Join to automatically receive all group messages.