The latest stable ‘plain’ variant image doesn’t match the checksum it’s supposed to match.
Is @JCS with Purism maintaining the builds? If so I’m glad his profile says “Passionate about open-source philosophy, sustainability, and doing things the right way even when it’s inconvenient.” … that’s good, because I’m about to get a little bit annoying (sorry).
This security stuff is the poster child for “inconvenient, but the right way to do the thing”. I think it’s not a great practice to store the checksum on the same server as the binary download, yes? If the server gets compromised it just means the malicious actor needs to upload two files instead of only one.
I think doing this is a more secure way is going to take some work. And I’m hoping that this mismatch is just some process gone wrong and not something else.
Ironically, the fact that they don’t match makes me reasonably confident there isn’t funny business going on, because they should’ve updated the checksum file too if they had a brain. The fact that they don’t match seems to indicate something simpler going on. Still, need to get that fixed.
If people are interested in discussing a better practice than keeping the checksum in a folder on the same server, I’m up for a discussion about it.
I don’t think having the checksum on a different server is required. However if you don’t, one should sign the checksum. Given that Purism used to advertise their PGP signatures on the “Core” page, I’ve never figured out why they were opposed to signing their checksums. Kyle R wrote something about that, but I thought it was BS and he never answered my questions.
That would also be an option, and an even better one if they can do it. As long as the signatures can’t be changed in the same way (so then those should be stored in a different location so it can’t be tampered with).
But if it’s not signed, as it is now, as a basic risk mitigation the method of changing the checksum file should be completely different and require different credentials. As it is now it doesn’t appear to be adding any real value.
It’s especially strange if we really don’t care about this, given how ‘paranoid’ Purism has been about the hardware/firmware. I would think it’s much easier for a bad actor to screw with this software vector and do bad things, than tampering with firmware.
Is it possible that the stable build was updated but the checksum was not updated? Did you check the date on each file?
Up to a point that is correct.
It depends on what attacks you are attempting to defend against.
For example, most Librem 5 users will be using the reflash script to do the whole process. If the reflash script knows to download the binary from one server but the checksum from another server … but the reflash script is itself compromised then it really doesn’t matter which servers are involved in the real unhacked reflash script.
I view the checksum mainly as a defence against a stuff-up (mine, Purism’s, my internet connection) more so than against a hacker.
I looked at that yesterday. If I’m not mistaken the dates were the same and the timestamps were a few minutes off. With an automated process maybe that’s normal. But I don’t think timestamps can be relied on too much anyway (for security purposes).
You’re right to point out the script is another attack vector. I still think separate storage would benefit even the automated script method. If the script isn’t compromised but the binary is, we definitely want the checksum to catch that. For the script’s security itself, hopefully the GitLab instance (or whatever they’re using) is well secured to protect that with 2FA and so on.
Also I wasn’t able to find a checksum, or anything, to verify the uboot imx file. Unless I’m mistaken that seems to be an area for improvement?
Whatever the reason for the mismatch, it still seems like a good opportunity to review and possibly update security practices.
Hell, no. I only meant: check the timestamp for troubleshooting purposes in order to understand how this happened (under the assumption that it’s a stuff-up, not a hack - a good hacker would touch any files that the hacker had corrupted in order to conceal the update).
It looks as if Purism has two separate servers for downloading. So, in the case of the stable download, it would readily be possible to have the checksum on the other server. (However with the number of different versions of the reflash script floating around, that could be troublesome i.e. would probably end up having to have the checksum in both places.)
And hopefully someone at Purism reviews this whole topic as part of fixing the checksum.
Based on the related post, I would assume that the user just ran the reflash script ‘as is’ (and that script does normally work).
Maybe someone has fixed the error already. The user would have to exhibit the two hash values from the exception message as they were at the time the message was produced.
Yeah I definitely decompressed it, and I ran it against the compressed version too just to be sure.
Also since I did it both manually and the normal reflash script complained about the checksum, I was fairly certain I hadn’t botched this one up (it wouldn’t be the first time ).
Edit - I guess the ‘older’ image is just due to the --stable parameter. I didn’t check any nightly/experimental files.
Yes, but also choosing the unencrypted image plays a role i.e. the two stable disk images can succeed or fail independently.
My guess is that most people are using the encrypted image - so the unencrypted image could have been broken for a while. Hopefully, Purism will soon confirm fixed, and perhaps give us a root cause.
Yeah it might’ve been that as well. I bet you’re right that the encrypted is more used. Actually I was able to flash the encrypted version a few days before that just fine.
I did not check the md5sum when I imaged some Librem5s a few weeks ago. (I was lazy.) In the event that PureOS is compromised, I am likely affected and I hope someone posts here about it.
The reflash script does it automatically. So you only have the option of not checking the hash if you bypass the script and do some of the steps manually.
For the record, I’ve fixed the CI image generation, so you should be able to flash your phones with recent plain image by omitting --stable parameter (until it breaks again at least).
In order to promote the new images to stable and in turn fix the sum mismatch that’s currently present there, someone would have to test them. I’m not going to promote them blindly
).