Before running code downloaded from the internet, one should to read and understand the shell script or run some cryptographic check to offload that responsability to a trusted party. This is even more important for code that is run with sudo.
Suggestion: include a sha256sum check for the downloaded shell script on the coreboot website that decides wether the sudo command may run or not.
To say the least, I am surprised about the lack of such an integrity check - especially because exactly this kind of integrity check is done inside the script itself.
I would appreciate an explanation from Purism why they chose not to include such an integrity check if that was a conscious decision and if not that one is added.
A different, but related question is how can I find out which version of coreboot my machine currently runs? I think the it would be useful if the coreboot update website contained a description of how to discover the currently installed coreboot version.
simply because it can’t easily be done automatically, and would be a PITA to keep in sync. If one has concerns about downloading the script and running it, then cloning the git repo instead would provide additional assurance.
running the script tells you, as does sudo dmidecode -s bios-version
Thank you for the command, it is exactly what I was hoping for.
I disagree with the following statement, though:
I am sure the sha256sum update could be automated in the repo. For example with a shell script and a pre-commit hook invoking it. Upon commit, the shell script is automatically invoked, that then checks if the sha256sum of the coreboot_util.sh script is contained in the README.md and if not updates the README.md with the new sha256sum of the script. Easy, automated. (There might be flaws or trade-offs in this approach that I am not aware of.)
Having voiced my opinion about the easy and automated concern and a proposed solution, I am not sure that easy and automated is actually desirable, because there might be versions of the script committed to the repo that are working drafts and are not supposed to be used. In this case stopping before the script is executed might be desirable. So whether the proposed automatism is useful or not also depends on your workflow in the repo, which I do not know.
Cloning the repo might indeed add security, but I doubt that you proposed that as general solution that you want to put into the readme instead of wget? It boggles my mind that purism generally agrees that cryptographic hashes are necessary to safeguard against the internet and uses them in the coreboot_util.sh script but then decides that it is not necessary when customers run code in the command line. I would love to see the same vigilance and security by default that is custom to the purism approach.
To this date in 2021 the script has been modified on about 10 days - 10 time calculating a sha256sum and updating the README.md with it amounts to about 20 minutes of work. Not that much from my point of view. I think that’s about the amount you @MrChromebox already spent on this forum post - I know I did.
While that is approximately ‘best practice’, and doesn’t hurt, I am not clear on precisely what problem you are trying to solve and how a hash would solve it.
Corrupted during download - very unlikely if https: is used to download (and 100% for sure you should not download via http:) - but, yes, a hash serves a theoretical purpose in this scenario
Corrupted on the web site - a hash doesn’t really serve a purpose if the corruption is intentional (malicious i.e. hacked) and the hash is on the same web site. What you actually need is a digital signature. (If you use a hash or signature in this scenario, unless the processes are robust and automatic, there is a risk of false positives on detected corruption.)
The main scenario in which I use a hash for a download is where the download occurs via a mirror or via an alternative download mechanism. So I can download whatever dubious content I like from wherever I like but I don’t use the content until I have gone back to the primary (non-mirror) web site and checked the hash.
Undoubtedly you are right that you should not run a shell script that you download from the internet unless you either trust the web site or read the shell script first.
I am trying to nudge the coreboot towards a more secure sourcing of the the update code. I know adding the checksum check doesn’t solve all problems, but at least it solves some.
e.g. the web browser and wget might not rely on the same set of trusted root certificates. So if a malicious actor can get away with changing traffic for one tool that change is still detected. I am not an expert in that field, but I am sure there are plenty more reasons, probably even better ones than the before mentioned, that make it a good idea to use the checksum. For some people the internet basically doesn’t work without installing root certificates issued by the state who might want to compute things a user doesn’t.
That’s just plain wrong. HTTPS is no guarantee that the file isn’t corrupted, only that the corruption is detected by the receiver. But detected doesn’t mean there’s no download. The sudo command on the website, however, is not conditional on the success of the download. So this is a legitimate concern. (Think about slow/unreliable internet connections. To see that premise of intact downloads via HTTPS break one can simulate a slow connection with something like wget https://source.puri.sm/coreboot/utility/raw/master/coreboot_util.sh --limit-rate 64 --timeout 5 -O coreboot_util.sh let it go for a couple of seconds and then turn of WiFi and/or unplug the ethernet cable. This will yield a corrupt coreboot_util.sh file containing only the first couple of lines.)
+100 for signed version of the update script.
Some of the commits in the coreboot repo are signed (indicated with the green “Verified” badge) while others are not. Can I suggest configuring the repo so it only accepts signed commits?
In my thinking the update is supposed to fail if something with the signature or checksum is wrong. Always. I am willing to accept waiting weeks or months because of a false positive before an update if I can be reasonably sure to avoid one false negative. Stopping the update because something smells fishy is a feature, not a bug. I don’t care if it is because the checksum has not been updated yet - the release is not ready and the developers should fix the issue, because they can and know what they are doing - unlike an unexperienced user who might start her Linux journey with a Librem device. What I want to say is that false positives are inconvenient but false negatives are dangerous.
Also if the checksum/signature update is forgotten, that issue will immediately surface once the release is tested. As per this forum post, the installation procedure undergoes thorough testing anyway. And even if such a missed update slips through, the users will let the forum know in no time.
Fair point. I was sloppy in my text there. That’s what I meant … not that corruption can’t occur during download, only that it is very unlikely to go undetected.
Seems a reasonable suggestion. You don’t have to convince me though. It’s not within my control. @MrChromebox ?