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
Replying to
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
Replying to
Does the phone or its the internal flash memory store any cached data and ? or if it does what will prevent a forensic company extracting my cached encrypted data?
1
Replying to
All data on persistent storage is encrypted. Data in user profiles is encrypted with a key derived from the unlock method for that profile. There's also hardware support for encryption reinforcing this. Of course, when you unlock and make data accessible, keys are in-memory.
1
2
Show replies
Replying to
Is it possible to lock out totaly the usb odb from ever accessing again if i choose to just have Graphene, ub only to charge phone but nevr to acess any data, also to lock out the recovery mode, be just able to update from phone it self! ?
1
Replying to
Charge only is the default. You need to authorize access from a computer. Recovery only allows installing signed updates and uses the same multi-layer signature verification, downgrade protection, etc. as the over-the-air update client. Recovery doesn't trust the attached PC.
1
2
Show replies