I’m experiencing bugs in the pureboot firmware now. I have the same PurismKey with the same privkeys for nearly a year now. I put the pubkeys on a usb, along with the Pureboot-15v4-13-beta, plugged it in, flashed, and then tried to add my GPG keys to the keyring. Again, and again, and again…
It doesnt matter if I add to the running or standalone bios, or replace + reflash. It never accepts them, and always sends me back to the same screen where HEADS fails to detect a keyring. I even tried a factory reset, wiping my key, generating new keys, and saving to usb. Nope. Only now at least it gave me an actual error page.
I had this problem with both flashing from PureOS, and also re-flashing from a USB stick. Pretty late rn, going to bed, wont be back till noonish.
I directly dropped my backup keyring onto tthe usb. The exact same usb I had just used to install pureboot.
My keys have no expiry, and my card is fully functional.
After multiple failures to restore my keys, I did a factory reset, which generates new keys, and even that completely failed to set a new keyring on the ROM. See photo #1.
just to make sure there are no misunderstandings you need to place the public key to the ones stored on the librem key as a public.asc file onto the USB stick as explained here https://docs.puri.sm/PureBoot/GettingStarted.html#first-boot not a whole keyring
First of all… That’s 100% irrelevant in the face of my statement that I tried selecting the factory reset option in the ROM screen, which wipes the card and drops the new pubkey to your usb.
But yes. I went back to my original gpg private key, reset the card, added the private keys to the card, used gpg --export to generate a pubkey file and dropped that on the USB.
I then fired up an instance of TAILS on another computer, and verified the USB by importing the key file from the USB. And also double checked the card.
I check the hashes of the 13-beta.ROM file, based on the hashes in the util.sh file in the latest release… Altho this is bad security practice, they really really REALLY ought to be signing EVERYTHING with a well published key.
I get the errors as show above in the photos… Every time. No matter how I try it. I even just now tried the previous version 11-beta.rom, still no success.
Im also seeing a message “SPI Configuration locked down”.
Really want to see someone from Purism stepping up here to help me. This is not ok. They guy Im talking with on email suggested that I try factory reset, despite already telling him I had tried that.
Hm this is really confusing especially the info about the serial does not make much sense at least in my option, since the interface to the Rom and the TPM is AFAIK SPI or I2C based.
Not sure how your USB drive is formatted but since I couldn’t find any advice in the Pureboot wiki regarding the format of the usb drive, I’m not sure about the right filesystem. Would try fat or ext4 if you didn’t do that already.
Regarding the “SPI Configuration locked down” if your Librem would be the 14 Inch model I’d ask you about the Hardware switch inside the case, but since they are not available jet I’m all out of ideas at the moment, except the USB drive one.
Maybe @MrChromebox could help you out.
I have it fat formatted. But I’ll try ext4, that’s a decent idea.
Im gonna go back and download the same firmware from when I bought the laptop a year ago. Maybe it’s a hardware rev number or something. Wouldn’t be surprising if dev and test are done on the newer models and the older ones aren’t checked.
don’t be silly, I test every single device/version before release. You’re running into a bug where a zero-size serial_number file is causing the propagation to fail. I’ve identified and fixed the root cause, just haven’t had a chance to spin a new release
you’ll run into the same issue with the older revision. The bug was triggered when you switched from Pureboot to coreboot and back without setting the device serial number when flashing coreboot.
I’ll build an update with the fix for the 15v4 in a few, and will have you flash manually to bypass the bug
there is no way around flashing something manually at this point because your current firmware is missing the serial number, and so the Pureboot built-in updater is going to fail.
Thank your for turning that around quickly for me. Just fyi, the mount_usb command didn’t work, and I couldn’t find it in /dev. So I selected the menu option to load GPG keys, which mounted the usb, and then I aborted to the shell.
Much appreciated your close support the past couple days. My only feedback is that .rom and iso files should be signed. It makes me pretty uneasy to run any software that I can’t fully verify with a well known public key.
I know that’s been requested before, and I believe the CSO posted his reasoning why we don’t. I’ll see if I can dig up the post. All of the firmware/script commits are GPG signed by me, so that’s something I guess
mount-usb… I should’ve figured that lol. There is literally no UNIX command that Im aware of that has an underscore.
Yeah, I suppose I should just be using Git from the command line instead of complaining about sig files. Altho I had problems with TAILS Git, even when rooted, and I’m not proficient enough on Git, or TAILS magic for preventing CL ops, to troubleshoot
I can’t find the post right now, but I think the TLDR was pretty much: “having a single signing key for ISOs / firmware images requires either one person to be a single point of failure, or multiple people having access to the same key, and neither is particularly optimal”
It’s not exactly wrong, but digital sigs, whether PKI, overt manual verification, or embedded in the backend, is the best way we found for ensuring communication trust between 2 geographically separated entities.
It’s not easy, but it’s doable. Qubes has a pretty good system in place where their master key lives offline in a physical vault, and they use subkeys for signing releases.
