[prev in list] [next in list] [prev in thread] [next in thread]
List: oss-security
Subject: Re: [oss-security] Security release pre-announcement messages
From: Stiepan <stie () protonmail ! ch>
Date: 2019-07-26 12:59:25
Message-ID: HP4s7z37GTsoDW43jgPPfFMSpfknopZFj995TBm7xpl2cc6CEmZGe6oZoXCXz81Ny11QA9ACQTGwluFzbMZyyFQv3hWuHd77hZ9VwApBptM= () protonmail ! ch
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
[Attachment #4 (text/plain)]
Thank you for the details.
Which color, the pony ? ;)
Regarding the a bug is a bug rationale you are referring to, I don't discuss it and think that \
much progress has been made to treat the subset of those which are also security bugs, \
including the enlightening participation of Mr. Torvalds himself to this list. I wouldn't \
advocate cherry-picking bugfixes either, the Android examples you mention in your reference are \
a real nightmare indeed. My point is that we would have at any time the most secure available \
option. This would involve a system to switch among kernel versions when needed, eg when a \
"pure" security bug with high impact is identified and cannot be published yet, nor its fix, \
yet people could switch meanwhile to a safer, known kernel version. I hope that makes it \
clearer.
Cheers,
Stiepan
Envoyé depuis ProtonMail mobile
-------- Message d'origine --------
On 26 juil. 2019 à 10:16, Greg KH a écrit :
> On Fri, Jul 26, 2019 at 10:14:08AM +0200, Greg KH wrote:
> > On Thu, Jul 25, 2019 at 09:35:45PM +0000, Stiepan wrote:
> > > I would like to congratulate the teams that do that. If public
> > > disclosure is deemed too dangerous before a patch is available, this
> > > looks like The reasonable tradeoff. Wish it was the same with Linux...
> >
> > I too want a pony :)
> >
> > > Rationale: people could switch meanwhile to a known safe kernel. That
> > > would provide peace of mind to the "rest of us" who don't have the
> > > keys to the linux-distros kingdom of the elected few, yet wish to have
> > > secure OSes, without a window of vulnerability open to whoever hacked
> > > into the elected few's machines (or are entitled another way to this
> > > secret information).
> > > It would also make Linux governance way more democratic, which seems
> > > to be a must for such a "too big to fail" core open-source software.
> >
> > The "best known safe kernel" is the latest one we release from the
> > stable kernel series. It has all of the fixes that that the kernel
> > developers possibly know about at that point in time.
> >
> > There's no need to worry about being on linux-distros or anything else,
> > just keep updating your kernel, test in in your infrastructure to ensure
> > it all works properly, and then push it out to all of your other systems
> > and all is good.
>
> And before all of the usual objections take place, please read this long
> write up:
> http://kroah.com/log/blog/2018/02/05/linux-kernel-release-model/
> specifically the "Security" section for details as to why the kernel
> does not do "pre-release" announcements.
>
> thanks,
>
> greg k-h
[Attachment #5 (text/html)]
Thank you for the details.<br><br>Which color, the pony ? ;)<br><br>Regarding the a bug is a \
bug rationale you are referring to, I don't discuss it and think that much progress has been \
made to treat the subset of those which are also security bugs, including the enlightening \
participation of Mr. Torvalds himself to this list.<br>I wouldn't advocate cherry-picking \
bugfixes either, the Android examples you mention in your reference are a real nightmare \
indeed. My point is that we would have at any time the most secure available option. This would \
involve a system to switch among kernel versions when needed, eg when a "pure" security bug \
with high impact is identified and cannot be published yet, nor its fix, yet people could \
switch meanwhile to a safer, known kernel version.<br>I hope that makes it \
clearer.<br><br>Cheers,<br>Stiepan<br><br><br>Envoyé depuis ProtonMail \
mobile<br><br><br><br>-------- Message d'origine --------<br>On 26 juil. 2019 Ã 10:16, Greg KH \
< greg@kroah.com > a écrit :<blockquote class="protonmail_quote"><br><p dir="ltr">On Fri, Jul \
26, 2019 at 10:14:08AM +0200, Greg KH wrote:<br> > On Thu, Jul 25, 2019 at 09:35:45PM +0000, \
Stiepan wrote:<br> > > I would like to congratulate the teams that do that. If public<br>
> > disclosure is deemed too dangerous before a patch is available, this<br>
> > looks like The reasonable tradeoff. Wish it was the same with Linux...<br>
><br>
> I too want a pony :)<br>
><br>
> > Rationale: people could switch meanwhile to a known safe kernel. That<br>
> > would provide peace of mind to the "rest of us" who don't have the<br>
> > keys to the linux-distros kingdom of the elected few, yet wish to have<br>
> > secure OSes, without a window of vulnerability open to whoever hacked<br>
> > into the elected few's machines (or are entitled another way to this<br>
> > secret information).<br>
> > It would also make Linux governance way more democratic, which seems<br>
> > to be a must for such a "too big to fail" core open-source software.<br>
><br>
> The "best known safe kernel" is the latest one we release from the<br>
> stable kernel series. It has all of the fixes that that the kernel<br>
> developers possibly know about at that point in time.<br>
><br>
> There's no need to worry about being on linux-distros or anything else,<br>
> just keep updating your kernel, test in in your infrastructure to ensure<br>
> it all works properly, and then push it out to all of your other systems<br>
> and all is good.</p>
<p dir="ltr">And before all of the usual objections take place, please read this long<br>
write up:<br>
	<a href="http://kroah.com/log/blog/2018/02/05/linux-kernel-release-model">http://kroah.com/log/blog/2018/02/05/linux-kernel-release-model</a>/<br>
specifically the "Security" section for details as to why the kernel<br>
does not do "pre-release" announcements.</p>
<p dir="ltr">thanks,</p>
<p dir="ltr">greg k-h<br>
</p>
</div>
["publickey - stie@protonmail.ch - 0xADF18750.asc" (application/pgp-keys)]
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic