@Julien: thanks, it seems I was missing this part 2 in my previous reads.
You are welcome. Iām happy that I have you useful information. Cheers 
After reading that reddit discussion I now have a thirst to know more about how /e/ intend to address the security side. The ultimate goal is to have /e/ shipped by OEMs on their devices, so these security issues need to be addressed at some point.
Is the approach going to be
- Get /e/ v1.0 stable
- Address all the security issues
Or the other way around?
My use case for /e/ is to replace Google-Android on out-of-support phones used by members of my family, for which I need stability and security.
Good: you are at the right place. The V1 is planned to be stable because it wonāt be a beta anymore + clear of Google stuff + pipes shouldnāt leak to any Google servers so itās a good beginning to have a secure OS.
Well, I just worked out that the phone I want to run /e/ v1.0 on will probably not get v1.0 as there is currently no LOS 15.1 build and itās looking unlikely that it will be built.
Still, more information on what the /e/ team are doing to address the security issues raised in that Reddit thread would be appreciated.
I found this discussion as Iām interested in verified boot (relocking bootloader after installing the OS). This is one of the points raised by the Copperhead Person on the linked comment on reddit.
I searched for it and it seems that LineageOS will not support verified boot as it would make using gapps harder. My theory (not a developer here) is thatās because any change on the system partition needs to be signed by the same key and they canāt distribute gapps for licensing reasons. Following this logic it should not be a problem for /e/ to support verified boot (like CopperheadOS did).
This would be a nice selling point for technical/paranoid users to distinguish /e/ from LOS. Please consider this.
And of course: thanks to everyone for putting your energy into this project. Itās urgently needed.
regards,
hex
2 Likes