Re: Security policies for Kubernetes

Nicko van Someren <nicko@...>

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.


On Thu, Nov 10, 2016 at 12:21 PM, Nicko van Someren <nicko@...> wrote:
That's interesting feedback. I was speaking to the VP of infrastructure at a major bank last week and he said that having a heads up from OpenSSL helps him hugely and he wished that more projects did it. I also had a request from one of the CII members asking for the same thing. Who in the OpenSSL team felt it didn't work? I would be interested to know what problems they find with this.


On Thu, Nov 10, 2016 at 12:17 Greg KH <gregkh@...> wrote:
On Thu, Nov 10, 2016 at 11:05:01AM -0700, Nicko van Someren wrote:
> One thing I think would be valuable to include in the security process is for
> there to be a broadcast mail to some 'announce' mailing list in advance of
> patches to high severity issues, indicating that a critical patch is imminent,
> with an expected release date but without full details of the issue. For large
> users with big IT infrastructure it may be necessary to schedule extra staff to
> install urgent patches quickly and having advanced notice of when this will be
> necessary is very helpful. Projects like OpenSSL usually send these out three
> days before security-critical releases (seeĀ for
> examples).

I think you might want to reconsider that, as over beers, the OpenSSL
team says that this type of thing really doesn't work and just causes
more problems...

But hey, remember that I'm on a project that does weekly releases
without telling anyone what the security fixes we made in them were, so
what do I know? :)


greg k-h

Nicko van Someren
CTO, Linux Foundation
+1 (978) 821-0391

Join to automatically receive all group messages.