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.
Conversation
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.
2
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
And I don't really see what stops inspecting / reviewing in with the same care / depth. It's not even obfuscated in any way.
If you took the alternate approach of getting official access to the sources, you give up your right to publish them, obviously not to review them.
1
But regardless, you're not really reviewing / auditing code, and there is not a community of people doing it. If there was, they wouldn't be blocked by only having compiled, unobfuscated libraries in some cases. As you're well aware there aren't even people interested in building
2
the substantial portions that are open source from source, let alone reviewing / auditing the code. If you wanted, you could use the open source device support code with a mainline kernel, for all the good that does you. Will have comparable functionality to what you talk about.
You won't get the same kind of security support, and you'll be much more on your own, but you won't have the same kind of pressure to migrate quickly and cope with the changes in the official device support code. Either way, hardware / firmware is still closed on ANY device.
1
Some less than others. On a pixel I need hundreds of Meg's of binary blobs or spend hundreds of hours of work to pare them down.
At least with Pinephone type devices the baseline is lean and the number of blobs is very small and easier to audit and reason about.
1
Show replies