I don't like your attitude and how you approach this in terms of communicating and the kind of dubious / false claims you make. I'm not going to give you long-form write ups of my knowledge / research especially on Twitter. You can do what you want but don't try to make false
Conversation
claims about it and misrepresent the compromises involved as you are repeatedly doing. My recommendation to you was to at least use the Pinephone and avoid worse problems. If you want to ignore that recommendation, that's fine, but don't expect me to spend more time on this.
1
Also, verified boot is PRIMARILY not about defending against physical tampering. The primary threat model is persistent compromise. So even when it comes to that feature, which is dwarfed by the importance of other aspects of hardware security, you present it in a warped way.
2
1
I don't really think engaging with you on these topics is productive. Doesn't seem to go anywhere and it's not going to become an in-depth discussion if you're just jumping being different things in way that's very misleading / inaccurate and unfocused on anything in particular.
1
I can't tell what you actually want to do anymore or what you're talking about / comparing. You were talking about porting AOSP to those devices, then presenting issues with making an OS for Pixels using the official vendor support as issues with AOSP, etc. Can't follow it.
1
I am weighing risk pros/cons of three short term paths.
1. Blindly trust endless vendor blobs and do constant reveng work for Pixels.
2. Try to port AOSP on more OSS friendly H/W Librem5/Pinephone
3. Build minimal feature phone Linux on Librem5/Pinephone.
2
1
1. Blindly trust endless vendor blobs
This is true regardless of which device you choose since they all have fundamentally closed source hardware, with the vast majority of the complexity in this regard, along with a lot of closed source firmware.
1
Also, you are blindly trusting the open source code including the Linux kernel code in exactly the same way. The closed source SoC vendor libraries are not black boxes, and in fact the source code is shared under NDA. If you really wanted access I'm sure you could get it.
1
Either way, I don't see you doing any code review / auditing or hardening. It's theoretical that you would be doing something like that with the source code. You blindly trust both open and closed source code. You blindly trust the hardware and firmware. This is universal.
2
I review lots of things as I have time and have a few CVEs to show for it. I can't even begin to review it all, but I only want to use things the community can review so together we might combine our respective small bits of time into deep review.
2
1
What community? Not aware of any community doing anything substantial in that regard. It's not a real thing, and if it was, they could fully review closed source libraries to the same extent and doing it with the same extreme care/depth is not substantially harder at that point.
People review the Linux kernel and a lot of the boilerplate of android.
Is it enough? No. We need 1000x but as more people depend on AOSP more eyeballs come with it.
I won't ever give up my right to review and for others to review what they can.
1
1
> People review the Linux kernel
Who reviews Linux kernel in anything but a very shallow and targeted way?
> I won't ever give up my right to review and for others to review what they can.
You have a right to inspect / review closed source software too.
2
Show replies
It's not a black box. None of it is even obfuscated. You can't say the same thing about an ARM SoC which is an immensely complex black box with unfixable issues, particularly if you're going to choose to use one that's particularly outdated and poorly secured. Same for other HW.
1
I well understand hardware vendors can't be trusted but that is not a solvalble problem today. We have to make educated guesses about the least bad SoC and then use open firmware/OS
as much as possible on top to reduce risk.
1