So came across this post today via OSNews, someone who bought both phones and has a few words to say about both. Thought the community might be interested, pretty sure Syonyk might be vaguely interested.
https://thatgeoguy.ca/blog/2020/12/06/Librem-5-Evergreen-vs-Pinephone/
I purchased a Purism laptop in April, and ended up returning it for a System 76 laptop.
When volunteering at LibrePlanet a few years a go I was able to meet one of the engineers at Purism who, at the time, was show-casing a tablet they were working on (this was pre-phone). The guy was super nice and really knowledge, explaining everything they do ti enable kill-switches and the challenges of working with proprietary firmware and chips.
That is all to say I think Purism is a good mission driven company, but their dogmatic commitment to absolute security comes at a great cost for usability and performance. I think companies like System76 and Pine Phone strike a better balance for most FOSS enthusiasts like myself. I do hope Purism success and hope usability can catch up (which I think they eventually will).
I liked the writeup. Thanks for mentioning it!
I’m not much of a phone power user. I don’t need the latest greatest features or performance, but even then that kind of money for a bulky, 3-year-old hardware doesn’t seem like a value to me. Given everything still (sadly) tied to firmware blobs on proprietary chipsets doesn’t sound like it’s really possible to give any absolute guarantees about be-all-end-all security except that we’re totally sure things are disabled via kill-switches.
Maybe it’s a bit better off than even some custom Android Roms (like LineageOS or Graphene), but with that kind of cost, bulk, and software quirks I’m not going to buy-in on maybes. I guess at least the Librem didn’t turn out to be totally vaporware. I don’t know much about Purism, but if their critics are to be believed it sounds like they’re in over their heads in hardware/software development for a mostly from-scratch phone.
PinePhone seems intriguing though. As a test bed it’s at a price point that one can be toyed with, experimented on, and it’s no great loss if you don’t really like it, or it doesn’t perform as hoped. Low cost-barrier to entry hopefully builds a wider community that wants to work on it, whether on usability, security, or future hardware design.
How many freelance devs are lining up to build new apps for the Librem right now? I’m thinking not many.
I’m far more interested in their work neutering the management engine and other such firmware “value adds” - though I admit I’ve not looked at their phones much. I’ve debated one of their laptops as an x86 utility beater, but I just don’t need another laptop.
As for the phones… I’m not terribly surprised. Pine does the whole “cheapest viable widget” thing quite well, though the community tends to be a bit of a mess - I still don’t quite understand the mechanics of the maintainer of the PineBook Pro kernel, but it’s all out there, if you want to go hunting. And maybe a bit of kernel hacking.
I have enough projects laying around, though, that I don’t need phone projects too. 
I looked into it. “Development ergonomics” so to speak need some improvement. I also didn’t like PureOS as much as Debian. I like the idea of https://librem.one/ but I’m not ready to jump from Gmail yet. In a lot of ways it feels like they’re trying to create a “not-so-walled” garden covering a lot of the day-to-day functions apple products cover (chat, email, phone, basic computing) but in a more libre / secure way. I hope they continue to iterate and improve, they have a lot of potential to be a great alternative to Apple or Google ecosystems.
Heh I don’t see much value in it. I mean it’s not like the baseband is open source so you’re doing nothing more than an AOSP build on a supported android device. With much, much slower hardware than the state of the art.
I’ve been looking into it a bit more with the announcement of the PinePhone Pro (https://www.pine64.org/pinephonepro/), and I don’t think the blobs in the baseband really matter. It only shifts the “point of trust” by one level, because of how they’re connected.
On a lot of modern smartphones, the wifi chipset and baseband (cell comms) have DMA access to the main memory for performance reasons, such that a compromise of the baseband gives you the permissions and access to compromise the main OS. IOMMUs can help here a bit, but… pretty much, you can write main memory on a lot of devices from one of the peripheral chips.
The PinePhone doesn’t have this - they use lower bandwidth and theoretically safer links to the other chips: Setting the Record Straight: PinePhone Misconceptions - PINE64
The WiFi module communicates with the CPU over SDIO and BT is over UART – neither of these connections provide direct access to CPU memory.
The LTE modem on the PinePhone is a ‘black box’, and runs its own Linux system internally. This includes all the proprietary modules (blobs) needed to run the actual cellular radios. However, this system is almost entirely isolated from the main system running on the A64 SoC. The only data contacts between A64 and modem are USB connection for data and I2S connection for audio. All data going in or out of the modem must go over these connections.
So, effectively, the trust boundary for that stuff has been moved from “where the baseband/wifi/bt hits the air” to “the connection between the host CPU and the baseband/wifi/bt chip.” I don’t think that’s a major fundamental difference, and as long as one paranoidly parses the data coming over those links as “probably malicious,” that those bits run internal firmware that’s not accessible doesn’t change the threat modeling.
You lose performance, yes, but it is a reasonably more secure way to handle stuff. Now, those interface drivers should be fuzzed to hell and back, but as long as the baseband sending malicious data over a simple link can’t compromise anything, those can be fully compromised with no risk to the core OS integrity. I think.