@gregkh Yeah I was going to guess it has something to do with 38,640,000 lines of code. And the fact you actually fix things quickly.
@gregkh @sjvn also now you have me thinking about the metric of lines of code used. For example, there must be projects where I’m guessing very little of the code is actually used by anyone at all, eg it has a lot of unused features, or legacy support that isn’t needed but hasn’t been removed. And then I’m guessing there’s more common case of very few people use a given code path but like any feature if one percent of the internet uses it that’s a lot of users.
@gregkh “If you are not using the latest stable / longterm kernel, your system is insecure” ... I like that one. Thanks!
@gregkh Nice.... One thing I'm curious though, if security issues are handled by a small team and reviews are public, wouldn't it be possible for a threat actor to watch patches coming from this group and assume most of them are security issues? There would be a lot but after filtering for commonly used subsystems/drivers and indicators of possible remotely-accessible bugs it would be feasible to investigate and try to exploit them, no?
1/2
@gregkh Yet as I was writing this I realize the alternative is also scary, if issues are reviewed internally (perhaps a larger group but still tightly controlled), then any commit not seen in the ML's are definitively security issues - that reduces the lead time (those commits could be merged shortly before cutting a release) yet reducing the time between merge and release also limits the ability for related issues to be reported.
2/2
@gregkh So I guess it's the right approach, but how much off an issue could that be?
@gregkh I'm not sure if I fully understand the "but once it is fixed, it becomes irrelevant" in the slides. In the optimal case, yes, I agree.
But what if it is a "boomerang bug"? If people misunderstood the issue and created a wrong or only partial fix? What if the fix later turned out to create a regression somewhere else? Wouldn't it be helpful for others to know how to recreate the original issue to be able to create a proper fix then?
(And how often do "boomerang bugs" occur in Linux?)
@gregkh one example I'm thinking of is this bug in the Linux bridge which I tried to fix more than ten years ago... and then this year noticed I didn't properly fix it... having described the original issue and how to trigger it in the Git commit greatly helped me to remember the original issue and what it was all about in the 1st place...
2013: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b00589af3b04736376f24625ab0b394642e89e29
2024: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=f5c3eb4b7251baba5cd72c9e93920e710ac8194a
(would hv said the issue were not a sec. issue / not crit. but after your slides not sure anymore)