In the past, when GrapheneOS was in a better state, the latest kernel.org LTS branches were promptly merged along with additional fixes not included in the upstream branches. The fix for the bug now assigned CVE-2019-2215 was already applied for the Pixel 1 and 2.
Conversation
Unfortunately, due to lack of resources and support, it hasn't yet been possible to start doing this for the ongoing revival of the project. In the past, I used to do it myself, but don't have the time and energy available anymore and people aren't stepping up to fill that gap.
3
4
7
It was never possible for me to get done more than a fraction of what the project aimed to do by myself. The ongoing attacks by malicious people have taken away a lot of my time / energy and I'm not able to do everything that I did before. Lots of past work needs to be restored.
1
2
5
In general, the Linux kernel does not assign a CVE when fixing a security vulnerability. That's the case for most open source projects. It's important to use the latest revision of LTS branches and apply more fixes on top of that. Other than that there aren't really good answers.
1
3
7
The newer kernel branches have lots of new vulnerabilities and attack surface. It's not clear if vulnerabilities are even being fixed at a faster rate than they're being added. Similarly, it's unclear if ongoing hardening work outweighs endless new attack surface / complexity.
1
3
10
I've talked about these issues a lot, and in a lot of depth. I recommend watching this talk to help with understanding the scale of the issues and the sorry state of software engineering not just in the Linux kernel but most other major software projects:
youtube.com/watch?v=qrBVXx
1
5
13
The Linux kernel uses a fundamentally insecure architecture, insecure tools, and has a development culture treating correctness and especially security as an afterthought. It ultimately needs to replaced, but until then, best effort approaches minimizing the harm are important.
2
9
16
This Tweet is from a suspended account. Learn more
Replying to
The Linux kernel and other fundamentally insecure software projects designed and implemented without robustness and security as core principles. The Linux kernel is likely getting less secure over time, not more secure, and there is no feasible way to fix a problem of this scale.
2
5
7
It is not realistic to turn the Linux kernel into something with decent security. Best effort approaches of applying as many security fixes as possible and attempting to address whole bug classes and exploit techniques are useful, but ultimately aren't a solution to the problems.
Every major release of the Linux kernel makes the problem worse. The complexity and attack surface keep growing at a ridiculously fast pace. The work on hardening moves at a far slower pace than other work making the Linux kernel less secure. Applies to a lot of other projects.
3
2
5
Show replies