I think that the default for reflashing should match the default for shipping, which means encrypted. A default reflash should get back to what you got out of the box with the latest security updates.
Anyone who received the same box as me and wanted it without disk encryption would have to reflash for it so should know what they are doing.
I’ll try Jumpdrive, thanks for the suggestion.
Lack of POP support is a feature not a bug IMHO. Given a choice I’d remove POP from every server I run, it doesn’t do any good and allows users to choose configurations that cause me support issues.
OK, but let’s say the Librem 5 customer is using POP on a server that the customer does not control (like the customer’s ISP) - so removing POP is not an option.
Also, for a privacy-focused phone, storing email locally rather than in the cloud may be preferable. I mean sure if you control the server (control a tiny piece of the cloud), there is less difference between POP and IMAP but let’s say that you don’t control the server.
Maybe the script should just ask you if you don’t specify a variant explicitly on the command line.
Are there any servers that support POP but not IMAP? For a privacy focused device would you want to use email with a server that doesn’t support IMAP? Such a server probably wouldn’t be up to date with security patches etc.
If the reflash tool made it mandatory to specify whether disk encryption was desired or not then that would be fine by me. Anything other than having 2 things with different defaults for the same option would be OK IMHO.
Definitely yes but I looked at two of my ISPs and one hosting company that I used to use and they all offer both. However if you want to store your email on their server - putting aside the privacy and security issues with that - you have to put up with their storage limits, or pay extra. So there’s a lot to be said for downloading email and storing locally.
If you need shared access from anywhere via multiple devices then IMAP may well be the best solution.
Is that Daniel Micay from GrapheneOS back under a different name? Interesting that he says that he contacted Purism to ask about porting GrapheneOS to the Librem 5, and then decided that the hardware was too insecure. I have to wonder about that, given how many things he gets wrong in his criticisms of the Librem 5. At any rate, I responded to correct the record: https://news.ycombinator.com/item?id=30769589
That’s quite an accusation. You tend to do that to provoke responses to things you want people to correct for you – coerced offloading of work. You’ve done it with me multiple times and I truly dislike it. It’s exactly why Daniel feels you’re attacking him. I had hoped that the fact that you were banned from the purism subreddit for a month would have clued you into that behavior.
I don’t think he has said anything incorrect. If so, please prove it. If you’re referring to his statement here:
[strcat] Librem 5 has a bunch of components where they are not shipping updates.
Various pro-Purism people have interpreted that as him saying that those proprietary firmware updates are not possible. That isn’t what he said. What he said is true:
Purism isn’t shipping updates to the proprietary firmware. You and I both know they
aren’t/won’t since if they did, there is no way the device would be RYF certified.
[Personally, I think the FSF has been clear that if Purism intends for those proprietary
blobs to be updated on the Librem 5, then the Librem 5 would not be certified RYF.]
After having read what he has to say and what you have had to say, I have to agree with Daniel on most everything. There are a few statements he has made that I don’t understand, but at this point I’m assuming that I’ve missed something (instead of assuming he is wrong).
Without getting bogged down in the actual dispute here (between you, Amos and ‘Daniel’) … the above-quoted text skirts on the edge of falsehood.
You will see in this forum that various people are having problems with the WiFi/BT card in the Librem 5 and they are able to download updated firmware and create the firmware directory and drop the downloaded firmware into the firmware directory and magically the card will use the updated firmware.
[strcat] Librem 5 has a bunch of components where they are not shipping updates.
[you] … the above-quoted text skirts on the edge of falsehood …
I understand your point, but disagree. When a difference in word choice means a difference in whether the device is RYF compliant or not, it is not just a “doesn’t matter” difference. And in that context, “technically true” is not really “the edge of falsehood”.
I was making no comment at all about RYF compliance. It was only a comment on the text
“Purism isn’t shipping updates to the proprietary firmware”. In order to be true or false, you need to define precisely what you mean by “shipping updates”.
If you mean "apt upgrade will not update the firmware" then that is true.
If you mean “other user shell commands will not update the firmware” then that is false.
In either case, the files will all come from a web site controlled by Purism. In either case, it is initiated by the user.
Not true. Purism updated the RS9116 WiFi/BT firmware from version 1.2.20 to 2.0.0024. Plus, Purism has 4 commits to facilitate firmware updates for the RS9116 (1, 2, 3, 4)
If “strcat” was in talks with Purism to port GrapheneOS to the Librem 5, then he should have known Purism’s position on firmware updates and he should have known that the Librem 5 doesn’t need to use an IOMMU to isolate its components because of the way that the phone is designed.
I guess that I should explain this. I had a debate with Micay about the Librem 5’s security, and he started insulting me and claiming that he was being persecuted. In our second exchange, he accused me of being “involved in direct efforts to organize raids and harassment against GrapheneOS developers”. When I responded with this post, the r/Purism moderator deleted my link to the Techlore video which detailed Micay’s past behavior with other communities and banned me for a month. Those are the only interactions that i have had with Micay.
All of this is off-topic, so I probably shouldn’t have said anything in the first place on this forum.
Not true. Purism updated the RS9116 WiFi/BT firmware from version 1.2.20 to 2.0.0024. Plus, Purism has 4 commits to facilitate firmware updates for the RS9116.
“Facilitating” firmware updates is different than “shipping updates”. You need to understand what “shipping updates” means to an OS developer. Also the discussion was about all firmware including the cellular modem.
By the way, are you saying that Purism intends the firmware in the Librem 5 to be updated after delivery? If so, it violates the “secondary processor exemption” allowing proprietary firmware for RYF devices.
If “strcat” was in talks with Purism to port GrapheneOS to the Librem 5, then he should have known Purism’s position on firmware updates …
It depends on the timing of his discussions. But it’s also why strcat said “shipping updates”.
… he should have known that the Librem 5 doesn’t need to use an IOMMU to isolate its components because of the way that the phone is designed
This is one of those cases where you are so sure of your position that you didn’t read his position. It’s one of those cases where you are so sure of yourself, you accuse someone else of being wrong based only on your misunderstanding. Remember that I’m the one who told you that the USB2 bus (not the USB3 bus) is isolated from DMA (I told you this because I was arguing that the pinephone’s modem and wifi was as isolated as the Librem 5; you continued to obstinately refuse this argument and didn’t ever back off from the opposite position until Luke penned an article). But you didn’t read strcat’s other point in regard to his view about the need for IOMMU: Access to USB2 means that one only has to trigger a bug in the USB driver to have access to the kernel memory. USB2 is electronically isolated from DMA, but USB2 is not isolated from the kernel and a bug in the (monolithic) kernel driver exposes memory.
Did you not read his point or did you not understand his point? You have this habit of not understanding something and then calling them wrong with the apparent attempt to force them to bring it down to your level. That’s not their obligation. I usually oblige, but strcat doesn’t. In fact it’s why he thinks you are trolling/attacking him. And your response to him accusing you of harassing him was to call him paranoid and link to a video to another group that he thinks is attacking him. Did you not learn anything from your ban?
The very same thing applies to the driver for a device behind an IOMMU as well. For such scenario, having IOMMU does not change anything at all. The only difference is that a USB device can pretend to be a different thing than it really is, which would make the kernel use a different driver - significantly increasing the attack surface, as you don’t have to exploit one specific USB driver but can use bugs in different ones as well. However, you can always require manual confirmation to enable a driver for a previously unseen device, which is something we’re already working on (which will also apply to things that you connect via USB-C port).
IOMMU could actually help with limiting the impact of bugs in things like GPU or VPU, as without it they can (mostly) access the memory any way they want. That’s, however, a completely different risk profile than exposing DMA for things like baseband modem or WiFi card, which Librem 5 does not do, and which phones that do usually restrict by using an IOMMU.
The very same thing applies to the driver for a device behind an IOMMU as well. For such scenario, having IOMMU does not change anything at all.
As you will note, strcat also brought that up. He asserts that the attack surface is far smaller. My reading indicates that there is a consensus that having an IOMMU is more secure and that is all strcat was asserting. This is especially true for the future now that USB3 (which allows DMA) is becoming ubiquitous.
But I’m not here to repeat discussions that strcat has already had. I’m here to point out that Amos shouldn’t assume strcat is wrong simply because he doesn’t understand someone else’s points.
I’m not an expect on recent USB versions, so correct me if I’m wrong, but my understanding is that USB3 doesn’t do DMA either; there’s a xHCI feature in USB 3.1 that lets the controller optionally use DMA, but that’s much closer to the GPU/VPU example than anything else (and can be disabled anyway). It’s only USB 4 that does the kind of DMA that can leave you vulnerable to DMA attacks performed by the peripheral.
Also, while discussing potential attack surface, you also have to consider that using IOMMU correctly is a complex and error-prone thing by itself. If you have IOMMU-protected DMA with exploitable IOMMU, you end up with unprotected DMA.
It’s my understanding that full duplex data transfers at SuperSpeed in USB3.0 require DMA. (Edit: It’s also my understanding that it’s not like USB3.1 xHCI where the host can
negotiate on/off. Other than the host deprecating to USB 2.0, there is no way to avoid
DMA attacks with USB 3.0 ).
This further response is also an edit:
[you] Also, while discussing potential attack surface, you also have to consider that using IOMMU correctly is a complex and error-prone thing by itself. If you have IOMMU-protected DMA with exploitable IOMMU, you end up with unprotected DMA.
I believe the consensus is that having an IOMMU is far more secure. That was certainly strcat’s assertion.
OK, but let’s say the Librem 5 customer is using POP on a server that the customer does not control (like the customer’s ISP) - so removing POP is not an option.