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.