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
I don’t always bypass the script, but when I do, I check the hash.
Erm, anyway… that’s good that it’s fixed, but I’m not sure I want to reflash a 3rd time for a test right now! I may have to find a way to automate post-flash setup…
Do I understand it correctly that, to help you test the latest image, I should follow the developer doumentation on reflashing but omit the --stable flag, then report here?
).
