Sure it might contain code making me vulnerable to a state actor but that’s not a threat profile I care about.
I don't check all the software I use myself. But I use open-source software with the peace of mind of someone who knows that the incentives to abuse me are simply not there and the fact that right now that are hundreds of people/bots checking it.
> Sure it might contain code making me vulnerable to a state actor but that’s not a threat profile I care about.
State actors are not the only threat. Think about arbitrarily disabled features, DRM, programmed obsolescence or simply not allowing anybody to improve/fix it after the device is abandoned by the manufacturer.
As has been shown plenty of times, “more eyes looking at the code” is a fallacy as those eyes are very much not looking to find security vulnerabilities. Also, the lack of security in userspace GNU/linux codebases is something really worrying, much much more so than hypothetical hardware attack when you can just append to the end of .bashrc from a goddamn npm install and basically do anything you want, including streaming every single keypress?
There are also automated scans of a long list of FLOSS. Google runs OSS-Fuzz, you can check LibreOffice to see lots of commits to fix defects detected by OSS-Fuzz, coverity and other static analyzers. Access to the code, at the least allows determined users to more easily find where or why the bug happens. And yes, people do it.
> hypothetical hardware attack when you can just append to the end of .bashrc from a goddamn npm install and basically do anything you want, including streaming every single keypress?
Yes, this is more serious. But would need a compromise on packagers side and an uninformed (or automated) update on my side. Considering an update with such a vulnerability would affect initially a small fraction of users before being discovered, it is very unlikely that this hypothetical would have a big impact.
Also, your automatic checker examples are related to the project’s size and importance, not to FOSS alone. It is very welcome but your average one-person C project that is installed on everyone’s system doesn’t benefit from such tools.
This is debatable: https://en.wikipedia.org/wiki/Comparison_of_open-source_and_.... Any links to your argument?
The fact remains, every type of software is ripe for bugs and security measures must be taken so those bugs won’t become exploitable.
https://www.crowdsupply.com/sutajio-kosagi/precursor
Of course, then you get a RISC-V running at 100MHz. If you want something faster, you need to trust your CPU provider. There's no way around that; silicon is not end-user introspectable.
Yeah ok now we are in the religion side of things, since you cannot check the silicon...well i stop here, not worth my time.
BTW: The power microcode is opensource.
READ.
The microcode is opensource..
Open source microcode does not change the fact that you need to trust the CPU manufacturer not to backdoor your CPU. There is literally no way around that that does not involve using FPGAs and restricting yourself to 100MHz CPUs.
By the way, I googled POWER9 microcode and was not able to find any source or reference to it. The source code for the firmware running on various auxiliary cores is open source. However, the CPU cores do contain microcode for executing more complex instructions, and I am not finding any reference to this being open source.
>>>since you cannot check the silicon...
And since you have problems using google too:
https://www.sbir.gov/node/1620879
>>A small business has already shown that a completely open source solution (to include CPU firmware, CPU Microcode, Baseboard Management Controller (BMC), BIOS boot code, power management, etc.) based on a high performance CPU is possible.
Imagine who that "small business" is?
FYI, IBM loves to use the term "microcode" to include side CPU firmware and such. This is different from Intel "microcode" which strictly refers to the instruction dispatch part. Is the instruction dispatch microcode in POWER9 open source or not?
None of these are it: https://wiki.raptorcs.com/wiki/OpenPOWER_Firmware
Maybe it's time for you to have the realization that POWER9 has proprietary microcode just like Intel. At least it seems they probably have less of it, and they do vaguely document it in the CPU manual (they have micro-op classes and counts) but it's there, and I don't see any real source code anywhere. They also have patch registers, so you can't even say it's not updatable. The POWER9 manual mentions six Instruction Mask Registers per core, but these registers are documented nowhere (I just spent a good 30 minutes digging through the giant register documentation PDFs and HCODE source, but I couldn't find anything).
Is this better than Intel? Yes. Is it "fully free"? No. Nothing's fully free. Which is why we need nuanced analysis, not the nonsense arbitrary lines the FSF draws in the sand.
if i dont have options for alternatives, i think its completely rational to use something without trusting it. i would say that this should be a default attitude
However the distinction between blob on chip flash and blob on system storage is nonsensical to me. I would much rather have a sandboxed untrusted part I can update rather than a sandboxed untrusted part that I can not update.
Unfortunately I have not seen anyone actually give a reason why the line should be drawn there instead of closed source blobs are not ok period. Doesn't matter where they live. None of us are arguing in favour of blobs.
this makes it sound like FSF supports these blobs. how i understood the situation is that they tolerate them until an alternative presents itself. this is a valid position to take and does not make them hypocrites/cult/religion etc
actually since you work with macs, do you think Apple respects your freedom or do you think they are more ethical than FSF?
But they also never claimed to be ethical. They never claimed to guard a moral ideal. They have claimed many things (protect privacy of users, guarantee security of users) which they did not act upon, and they have received flack for that. But they didn't claim to be ethical. Not even in a aspirational way like Googles "Don't be evil" moto.
The FSF, however, claims that ethics is it's prime driver. And by endorsing hardware with proprietary blobs (placed on chip flash instead of system storage) they display hypocrisy. They choose the very pragmatism they criticise others for choosing.
And that is something religions do aswell.
I have asked you why is the line there and you have not answered.
Whether Apple is ethical or not is a different question. There is plenty of criticism to be fired at them for various issues. That's a personal call for people to make. I'm not saying you should go buy Apple hardware. I'm saying it's significantly more trustworthy from a security and privacy standpoint than x86 machines. Do they respect my software freedom? About as much as the RYF machines. They both let me run my own OS and they both rely on proprietary firmware for various things. The FSF's certification criteria do nothing for my software freedom (which has nothing to do with whether blobs are in ROM or RAM), they just hurt security, which is something else I care about.
We all have to make our own decisions about what to purchase based on the information available to us. That is why having such information is so important. If you value repairability more than anything, you should probably get a Framework. If you value security above all, you should get a Precursor device. If you want a trustable machine that's still high performance, you should get a Mac. If you want to run Windows games, you should get a gaming PC. If you value your freedom... there isn't anything truly free out there. RYF machines certainly aren't it, nor more free than many others by practical measures, nor transparent about their design.
Hence why I criticize the program. It's not achieving anything positive. It's just a feel good thing; the FSF says it respects my freedom so I can feel good about being Free™ while running more proprietary firmware than many other off the shelf machines.
Just to put things into perspective, I believe Google have done more for computing device freedom than the FSF, because the Chromebook team is notoriously pretty much the only large team which actually pushes for open source everything pretty hard, and they're important enough that some vendors listen, and they have the money to develop things themselves. For example, if you look for an open boot/OS stack for the Tegra X1, the closest you're going to get is the Chromebook Pixel's. Only the RAM training blob is closed source (and there is a reverse engineered replacement these days). Everything from the low level bootloader to the GPU drivers are open. This is no thanks to Nvidia - for pretty much all other customers they offer proprietary bootloaders. Also, I'm pretty sure some Chromebooks even have open source EC firmware, which those ThinkPads the FSF loves so much don't.
Look, don't take my word for it - take the word (and more importantly, the reasoning) of the guys behind the Novena open laptop: https://www.bunniestudios.com/blog/?p=5706
also i am confused why this issue isnt being taken with the hardware manufacturers? if i purchased their product, and if their user license did not forbid me from using linux-libre, and if this update is absolutely vital for my safety, then it makes much more sense to take issue with the manufactures. they should open source the update in this case
You can't even argue that it is a difference of being stored in ROM vs. RAM because the existence of patches means that microcode is upgradeable.
You're not sacrificing security, you're making a tradeoff.
If I update my CPU microcode to something I can't check myself, I'm explicitly choosing to trust my CPU provider, under the assumption that the risk of a microcode-based attack from my CPU provider is smaller than the risk of a cpu bug-based attack by an unknown attacker.
If you don't trust your CPU provider then you have zero security from them already. Even if the entire design of the CPU is open-source. https://www.bunniestudios.com/blog/?p=5706
You are already running CPU microcode that can't be checked when you are running Guix on x86. That ship sailed when you decided to use x86.
If you update your CPU microcode to something that can't be checked, you're already sacrificing security.
EDIT:
But yes, I understand people complaining that FSF rejects proprietary software but is OK with some forms of ROM which in turn may be very similar to "proprietary software you can't change".
Well, I never asked their reasons to someone from inside the FSF, so I my knowledge about it can improve. Nevertheless, I can see some points:
I don't think FSF would consider IME acceptable if it was ROM.But indeed, it would be very good if someone from FSF could better explain it.