Comment by marcan_42
5 years ago
In fact, having FSF validation doesn't prove anything but rather may be detrimental, because the FSF validation has built-in backdoors, and Purism took full advantage of them - reducing user freedom in the process.
Thread on how the Librem 5 is explicitly designed to hide proprietary blobs from the user in order to gain RYF certification (where having those blobs readily accessible would be strictly an improvement in freedom, as it would mean you are free to verify their contents, audit them, and potentially replace them with a free version if you develop one):
https://twitter.com/marcan42/status/1040626210999431168
Make no mistake, Purism has gone quite far down the freedom marketing religion path laid down by the FSF. They no longer care whether you're free or not, they care that you believe you're free.
If you have blobs, stick them in /lib/firmware. Don't go hiding them in separate flash chips that I can't audit or rewrite just so you can slap the FSF's meaningless "the main CPU didn't touch any blobs (except the bootrom but we don't talk about that) so it doesn't have the digital cooties" rubber stamp on your device.
You are wrong, from https://ryf.fsf.org/about/criteria :
"We want users to be able to upgrade and control the software at as many levels as possible. If and when free software becomes available for use on a certain secondary processor, we will expect certified products to adopt it within a reasonable period of time. This can be done in the next model of the product, if there is a new model within a reasonable period of time. If this is not done, we will eventually withdraw the certification."
Do they actually enforce that, if the device can either have a proprietary blob that is user-updateable, or a proprietary blob that is not user-updateable, it must use the design where the proprietary blob is user-updateable? Because other claims by the FSF (namely, that non-updateable blobs can be treated as part of the hardware) directly contradict that.
This thread is just wrong. You can modify the blobs if you need to: https://forums.puri.sm/t/does-respects-your-freedom-certific....
The Librem article I linked in my thread clearly states:
https://puri.sm/posts/librem5-solving-the-first-fsf-ryf-hurd...
> The SPI flash will be read only so the firmware blobs can’t be modified without the user knowing.
The post you link to is full of wishy-washy fluff, but does not answer the direct question that the user posed in the OP, about the DDR timing code flash being writable.
I don't see any "wishy-washy fluff". It states quite clearly:
we do not institute any kind of write-lock or burnt fuses that would prevent the owner of the hardware from reflashing it with whatever firmware (new or otherwise) they choose.
In other words, you can modify the firmware on the Wi-Fi card or modem.
Concerning the RAM, I do not see any problem with that, since there is no proprietary code running after the booting. As FSF says, it can simply be considered as a part of "hardware" which is necessary for the start of the system.
Edit:
> can’t be modified without the user knowing
> without the user knowing
Did you actually read what you quoted?
3 replies →