Embed Notice

HTML Code

<blockquote style="position: relative; padding-left: 55px;"><section><a href="https://fosstodon.org/users/kernellogger/statuses/111928180959151440">Thorsten Leemhuis (acct. 1/4) (kernellogger@fosstodon.org)'s status on Wednesday, 14-Feb-2024 16:17:09 JST</a><a href="https://fosstodon.org/@kernellogger" title="kernellogger@fosstodon.org"><img src="https://gnusocial.jp/avatar/109466-48-20230324184559.webp" width="48" height="48" alt="Thorsten Leemhuis (acct. 1/4)" style="position: absolute; left: 0; top: 0;">Thorsten Leemhuis (acct. 1/4)</a><div><a href="https://social.kernel.org/objects/eeafd5a4-64ac-4680-a28c-ffc3c91a22f0" rel="in-reply-to">in reply to</a><ul><li></ul></div></section><article><p><a href="https://social.kernel.org/users/gregkh">@gregkh</a> </p><p>Will be interesting to see how the new process[1] plays together with "participation in stable is optional for mainline developers" and the "developers almost never declare specific changes as security fixes"[2] approach I assume still holds true for mainline.</p><p>I sounds like it could easily happen that someone fixes a  security bug in mainline w/o telling anybody, so no CVE would be issued unless someone backports the change.</p><p>[1] <a href="https://lore.kernel.org/lkml/2024021314-unwelcome-shrill-690e@gregkh/" rel="nofollow noreferrer">https://lore.kernel.org/lkml/2024021314-unwelcome-shrill-690e@gregkh/</a></p><p>[2] <a href="http://kroah.com/log/blog/2018/02/05/linux-kernel-release-model/#security" rel="nofollow noreferrer">http://kroah.com/log/blog/2018/02/05/linux-kernel-release-model/#security</a></p></article><footer><a rel="bookmark" href="https://gnusocial.jp/conversation/2712043#notice-5384582">In conversation</a><time datetime="2024-02-14T16:17:09+09:00" title="Wednesday, 14-Feb-2024 16:17:09 JST">about 9 months ago</time> <span>from <span><a href="https://fosstodon.org/@kernellogger/111928180959151440" rel="external" title="Sent from fosstodon.org via ActivityPub">fosstodon.org</a></span></span><a href="https://fosstodon.org/@kernellogger/111928180959151440">permalink</a><h4>Attachments</h4><ol><li><article><header><div>No result found on File_thumbnail lookup.</div><h5><a href="https://lore.kernel.org/lkml/2024021314-unwelcome-shrill-690e@gregkh/">[PATCH] Documentation: Document the Linux Kernel CVE process - Greg Kroah-Hartman</a></h5><div></div></header><div></div><footer></footer></article></li><li><article><header><div>Domain not in remote thumbnail source whitelist: www.kroah.com</div><h5><a href="http://kroah.com/log/blog/2018/02/05/linux-kernel-release-model/#security">Linux Kernel Release Model</a></h5><div></div></header><div>Note This post is based on a whitepaper I wrote at the beginning of 2016 to be used to help many different companies understand the Linux kernel release model and encourage them to start taking the LTS stable updates more often. I then used it as a basis of a presentation I gave at the Linux Recipes conference in September 2017 which can be seen here.
With the recent craziness of Meltdown and Spectre , I’ve seen lots of things written about how Linux is released and how we handle handles security patches that are totally incorrect, so I figured it is time to dust off the text, update it in a few places, and publish this here for everyone to benefit from.</div><footer></footer></article></li></ol></footer></blockquote>

Corresponding Notice

Embed this notice
Thorsten Leemhuis (acct. 1/4) (kernellogger@fosstodon.org)'s status on Wednesday, 14-Feb-2024 16:17:09 JSTThorsten Leemhuis (acct. 1/4)
in reply to
- Greg K-H
@gregkh
Will be interesting to see how the new process[1] plays together with "participation in stable is optional for mainline developers" and the "developers almost never declare specific changes as security fixes"[2] approach I assume still holds true for mainline.
I sounds like it could easily happen that someone fixes a security bug in mainline w/o telling anybody, so no CVE would be issued unless someone backports the change.
[1] https://lore.kernel.org/lkml/2024021314-unwelcome-shrill-690e@gregkh/
[2] http://kroah.com/log/blog/2018/02/05/linux-kernel-release-model/#security
In conversationabout 9 months ago from fosstodon.orgpermalink
Attachments
1. No result found on File_thumbnail lookup.
  [PATCH] Documentation: Document the Linux Kernel CVE process - Greg Kroah-Hartman
2. Domain not in remote thumbnail source whitelist: www.kroah.com
  Linux Kernel Release Model
  Note This post is based on a whitepaper I wrote at the beginning of 2016 to be used to help many different companies understand the Linux kernel release model and encourage them to start taking the LTS stable updates more often. I then used it as a basis of a presentation I gave at the Linux Recipes conference in September 2017 which can be seen here. With the recent craziness of Meltdown and Spectre , I’ve seen lots of things written about how Linux is released and how we handle handles security patches that are totally incorrect, so I figured it is time to dust off the text, update it in a few places, and publish this here for everyone to benefit from.

Public

Embed Notice

HTML Code

Corresponding Notice