https://kccncossaidevchn2024.sched.com/event/ed2b39a9a0cdfc1df18de67ce0c2f6be
Link to git repo for the slides if the schedule site acts odd for you:
https://git.sr.ht/~gregkh/presentation-security
It was fun, and will be the "set up" for my Kernel Recipes talk in Paris in a few weeks (only 3 conferences to go between now and then, travel is back in full swing.)
@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?