PureBoot issueshttps://source.puri.sm/firmware/pureboot/-/issues2024-02-26T14:12:17Zhttps://source.puri.sm/firmware/pureboot/-/issues/27Pureboot basic doesn't support touch input2024-02-26T14:12:17ZGuido GüntherPureboot basic doesn't support touch inputThis means that on tablet's (e.g. the Librem 11) the menu can't be operated without the keyboard sleeve (which one usually doesn't want to carry around if not needed).This means that on tablet's (e.g. the Librem 11) the menu can't be operated without the keyboard sleeve (which one usually doesn't want to carry around if not needed).https://source.puri.sm/firmware/pureboot/-/issues/26feature request: option to enable USB keyboard2023-09-01T19:41:44Zprimalmotionfeature request: option to enable USB keyboardUSB keyboard support has been removed from PB a while back. But when using the laptop in clamshell mode, it's a bit painful. It would be great to build the needed driver as a kernel module and add an option to load it or not.USB keyboard support has been removed from PB a while back. But when using the laptop in clamshell mode, it's a bit painful. It would be great to build the needed driver as a kernel module and add an option to load it or not.https://source.puri.sm/firmware/pureboot/-/issues/25feature request: add config to set the wait time at boot2023-09-01T19:31:36Zprimalmotionfeature request: add config to set the wait time at bootPB waits 5s for the user to input a key to enter the menu. It's a bit slow when you just boot normally. I set it to 1s. It would be great to have this configurable from PB menus directlyPB waits 5s for the user to input a key to enter the menu. It's a bit slow when you just boot normally. I set it to 1s. It would be great to have this configurable from PB menus directlyhttps://source.puri.sm/firmware/pureboot/-/issues/24adjust work flow after tampering detected2023-05-08T17:34:13ZChris Vogeladjust work flow after tampering detectedtampering detected **oh my!!**
* user needs to work and with some probability didn't expect this situation (time pressure)
* user didn't practice going through a safe procedure on command line to restore control over their system in a l...tampering detected **oh my!!**
* user needs to work and with some probability didn't expect this situation (time pressure)
* user didn't practice going through a safe procedure on command line to restore control over their system in a long time
This leads to a situation where the user is presented with options that are not optimal:
* just sign the stuff off to boot and get it done **obviously bad option**
* looking at the files (I hope all of them are presented in the according message on the screen) the user might find that there's still a initramfs/kernel combination that checks o.k. - if they could
* if the user knows that the tainted file can be circumvented by booting a non-default kernel/initramfs they cannot do this:
* trying to get into the system boot menu gets them back to the warning message about tampering
* the alternative "ingore and force" (sic, cited from memory) doesn't tell that there might be a later option to _choose_ which kernel/initramfs to boot
In this situation I ended up painfully using the cli to kexec the kernel/initramfs that hadn't been tainted.
Improvements I could think of:
* have some menu with the most important information pages about what might be going on and how to handle the situation. Those would only be text files that do not need much space and could help immensely to guide in this situation (especially if there isn't a second device nearby to look stuff up).
* extend the tampering warning: write out that **all files** are shown that have been tampered with and reference the help menu (see above)
* re-design menus:
* "show boot menu" should show a warning that **it'll be possible to force boot a tainted system** through the menu and then show a boot menu
* "force boot" should be renamed to something "force boot default kernel even though it might have been tampered with"https://source.puri.sm/firmware/pureboot/-/issues/23hwclock reset to 1970 - dropped to recovery shell2022-10-18T06:49:26ZChris Vogelhwclock reset to 1970 - dropped to recovery shellBecause of this [issue](https://source.puri.sm/firmware/librem-ec/-/issues/17) I already had been dropped twice to recovery shell when starting the notebook. Generally this applies in every situation in which the Notebook lost the actual...Because of this [issue](https://source.puri.sm/firmware/librem-ec/-/issues/17) I already had been dropped twice to recovery shell when starting the notebook. Generally this applies in every situation in which the Notebook lost the actual date and time.
With the LibremKey connected the totp fails and the user ends up in a recovery shell without any information about possible reasons.
I'd expect that there would be at least some information in recovery shell what to check or where to look for a checklist on how to get a first impression about the situation.
In this case ('just' clock being set wrong) it would spare any user ending up in that situation a lot of time and probably the Purism Support also.https://source.puri.sm/firmware/pureboot/-/issues/22GPG digest algo and ECC keys2021-11-17T22:00:37ZVictor BessonovGPG digest algo and ECC keysRunning PureBoot r19 with Nitrokey containing ECC keys (signing and encryption are brainpoolP384r1 and auth is nistp521) I've stumbled upon some bug preventing me from using it further.
It looks like it's impossible to sign everything in...Running PureBoot r19 with Nitrokey containing ECC keys (signing and encryption are brainpoolP384r1 and auth is nistp521) I've stumbled upon some bug preventing me from using it further.
It looks like it's impossible to sign everything in /boot - Pureboot just stops here with an error "Failed to update checksums/sign default config".
I think the problem is in the hardcoded value of digest algorithm in kexec-sign-config script.
Maybe the verification part should use sha2-384 or even longer algo for gpg to verify signatures with such keys.
Something like:
`
for tries in 1 2 3; do
if sha256sum $param_files | gpg \
--digest-algo SHA384 \
--detach-sign \
-a \
> $paramsdir/kexec.sig \
; then
`https://source.puri.sm/firmware/pureboot/-/issues/21Hitting Esc interrupts the Librem Key verification process2021-07-26T06:37:30ZDean LeggoHitting Esc interrupts the Librem Key verification processWhen I want to enter the BIOS I hit Esc to interrupt the boot and to bring up the PureBoot Boot Menu. The menu appears and then suddenly disappears for the system to check the Librem Key.
If I continue to hit Esc, I can keep interrupting...When I want to enter the BIOS I hit Esc to interrupt the boot and to bring up the PureBoot Boot Menu. The menu appears and then suddenly disappears for the system to check the Librem Key.
If I continue to hit Esc, I can keep interrupting the boot and key verification to bring up the menu. It then suddenly restarts the Librem Key verification process.
If I keep on hitting Esc, this will continue in a loop.
**What should happen**
I hit Esc once or a million times. It does not interrupt the Librem Key verification. Once it has finished it brings up the boot menu.
For me, I think if the verification failed because of 'Key not found' or 'Keys don't match', it should prompt the user for that issue before. Then bring up the boot menu.
Once in the boot menu, hitting Esc should only bring the user back to the top menu, currently it goes back to key verification.
I have a Librem 14 with the PureBoot Bundle.
I have updated to version 18 of the firmware.https://source.puri.sm/firmware/pureboot/-/issues/20Support multiple PureBoot devices with a single Librem Key2020-12-30T20:17:31ZTravis WrightsmanSupport multiple PureBoot devices with a single Librem KeyWith Librem product diversity growing to laptops, mini desktops, and now phones, it would be useful in the near future to be able to use one Librem Key to verify boots across up to 3 devices, one for each HOTP slot available in the Libre...With Librem product diversity growing to laptops, mini desktops, and now phones, it would be useful in the near future to be able to use one Librem Key to verify boots across up to 3 devices, one for each HOTP slot available in the Librem Key.https://source.puri.sm/firmware/pureboot/-/issues/19Why is it so hard to find current information for issue tracking?2020-12-20T18:37:41ZJT MoreeWhy is it so hard to find current information for issue tracking?I just posted to https://github/osreasearch/heads because that is the site that comes up for searching the heads project in google.
I suspect that the upstream heads is not using the same graphical interface as pureboot so that forum i...I just posted to https://github/osreasearch/heads because that is the site that comes up for searching the heads project in google.
I suspect that the upstream heads is not using the same graphical interface as pureboot so that forum is probably the wrong place to post ... oh yeah, there's an issue on that exact topic posted by me: https://forums.puri.sm/t/report-issues-for-heads/9090/3
Please update the pureboot documentation with links and the criteria to know when to post to one project or the other for support issues
https://docs.puri.sm/PureBoot/Heads.htmlhttps://source.puri.sm/firmware/pureboot/-/issues/18Updating checksums drops to recovery shell if you press any button besides Y/...2022-07-27T11:55:55ZJoao AzevedoUpdating checksums drops to recovery shell if you press any button besides Y/n in smartcard verification questionOn updating the checksums of the `/boot` partition files when asked to verify that the smartcard is present, you are asked to select either `Y` or `n`. If you press another key like say `u` and press enter you are dropped to a recovery s...On updating the checksums of the `/boot` partition files when asked to verify that the smartcard is present, you are asked to select either `Y` or `n`. If you press another key like say `u` and press enter you are dropped to a recovery shell.
And have to reboot the machine and select the update checksums option again from the Pureboot menu.
**What I think should happen**
If a user selects another letter besides `Y` or `n` prompt an error message indicating he selected a non valid choice and ask him to repeat the selection.
**Steps to reproduce**
- Update the checksums in pureboot
- When asked to verify if the smartcard is present press `u` and then enterMatt DevillierMatt Devillierhttps://source.puri.sm/firmware/pureboot/-/issues/16Include coreboot_util.sh inside heads environment2020-08-09T13:48:15ZJT MoreeInclude coreboot_util.sh inside heads environmentI saw the announcement of coreboot release recently and am preparing to update. The first thing I notice is that the update process is obtuse and time consuming if running heads. The docs (https://puri.sm/coreboot/ , https://source.pur...I saw the announcement of coreboot release recently and am preparing to update. The first thing I notice is that the update process is obtuse and time consuming if running heads. The docs (https://puri.sm/coreboot/ , https://source.puri.sm/coreboot/utility) say I should run the utility again but that if I'm using Heads I should update from within the Heads environment.
There is no download feature inside of heads (that I can see). I'm already running inside a coreboot+heads booted OS when I run `coreboot_util.sh`. Why do I need to restart and run from within heads?
If 'update inside heads' is the only supported workflow then HEADS should include `coreboot_util.sh` inside the environment and allow the whole process to be done at one time.
Given that heads is only supported on librem hardware it should be pretty easy to get networking going. It may require more storage somewhere to hold all of the drivers and subsystems but that is preferable to manual (confusing, error prone) steps in a process which could brick a system.
Hoping next time is easier by posting this suggestion now.https://source.puri.sm/firmware/pureboot/-/issues/13Librem Key Setup UX2019-12-09T17:44:00ZSam HewittLibrem Key Setup UX## Initial Boot
The set up process for a Librem Key should occur at initial boot for customers of the Librem Key + Librem Laptop, and that should have steps something like the following:
### New Key Setup
Customers with a new laptop an...## Initial Boot
The set up process for a Librem Key should occur at initial boot for customers of the Librem Key + Librem Laptop, and that should have steps something like the following:
### New Key Setup
Customers with a new laptop and Librem Key would see this screen on first boot:
- they can only continue if they have their Librem Key inserted otherwise they see an error
- clicking later would postpone setup to the next boot and the computer will just boot to the OS, skipping Key setup
- this screen will **always** be shown on boot until the key is set up
![key-setup](/uploads/4935d6afc7c3e42a7c8a774b52aa128e/key-setup.png)
### Processing
The Key setup process should be done largely in the background, I've an ASCII spinner here in this concept to visualize this.
![key-setup-processing](/uploads/66b09803fd79136dc1b26f9375f1837f/key-setup-processing.png)
### Error
Fairly self-explanatory, if there is an issue with the key setup display an error message and a brief explanation.
![key-setup-error](/uploads/f800a90b1e1772fdae2b2d51022e1116/key-setup-error.png)
### Success :tada:
When Key setup is successful display a congratulatory message and prompt for reboot, after which the laptop will go through the normal Key procedure at boot.
![key-setup-success](/uploads/51ece0397c1147e76ff9744c77ed0990/key-setup-success.png)
## Style
Unlike the boot screen, which is meant to not draw as much attention with a dark background, this setup should be bright and legible:
- the background colour is `#f6f5f4` and the text colour is `#2e3436`
- the suggested action (blue) button has a background colour of `#3584e4` with white `#fff` text
- other buttons have a background colour of `#ddd`
- error messages are `#c00` with white text.https://source.puri.sm/firmware/pureboot/-/issues/12Librem Key Boot Flow2019-12-09T17:24:13ZSam HewittLibrem Key Boot FlowThere's a few scenarios that need some refinement of the user experience with the Librem Key, plus there's some general issues to address:
1. The list of boot options isn't always relevant to the Librem Key procedure, hiding it would st...There's a few scenarios that need some refinement of the user experience with the Librem Key, plus there's some general issues to address:
1. The list of boot options isn't always relevant to the Librem Key procedure, hiding it would streamline the experience
2. The UI doesn't defer to the minimum needed information to take actions with the Key
### Scenario 1: "All is well"
If the key is inserted, and there is no tamper detection and the system isn't set up for TOTP, then just boot. It would only be relevant to drop to the menu or show a message when something has gone wrong. The key will blink green when all is well.
### Scenario 2: "Insert Key"
All that needs to be shown is the "insert key" message, with the menu options behind a "Boot Options" button processing what's needed to be done is straightforward. "Ok" is now Continue.
![01-pureboot-insert-key](/uploads/affd8cbf20d7a2ec7ec859b54bb85fae/01-pureboot-insert-key.png)
### Scenario 3: "Tampering Detected"
Much like the above scenario, except with the warning message about tampering. If the user chooses to take relevant actions the boot options menu is there, otherwise they can continue to boot.
![pureboot-error](/uploads/d9df0d670c8dda7115b277c10980b22d/pureboot-error.png)
### Scenario 4: The TOTP case
If someone is a TOTP user the most relevant information is the OTP code, so that should be most prominent at boot (the following concept is an ideal), and as in the other scenarios the UI should defer to that function. A warning message explains the relevance of a mismatch.
![pureboot-totp](/uploads/acb3f816bd1795b976cc573d06cb174c/pureboot-totp.png)
### Boot Menu
In all of the above cases, this would be the Boot Menu that clicking that button would take you to:
![02-pureboot-main-menu](/uploads/45c076bf776faa86ebd4d865798287ed/02-pureboot-main-menu.png)https://source.puri.sm/firmware/pureboot/-/issues/11Improved visuals for PureBoot menu2019-12-09T17:03:33ZSam HewittImproved visuals for PureBoot menuSimplifying the visuals of the PureBoot menu system will improve legibility and readability, this would entail:
- dropping all gradients in favour of solid colours
- using a solid colour background for all elements, including buttons, ...Simplifying the visuals of the PureBoot menu system will improve legibility and readability, this would entail:
- dropping all gradients in favour of solid colours
- using a solid colour background for all elements, including buttons, background, etc.
![Screen_Shot_2019-12-09_at_11.49.52](/uploads/514ca31329bb5dbd76842a5bf5ea1d84/Screen_Shot_2019-12-09_at_11.49.52.png)
The overall background colour (in hex) would be `#222`, the focused/preselected menu item background colour is `#666` and all unfocused menuitems' background colour is `#333`. All text is white `#fff`.
I've updated the warning colour orange: `#f57900` and the error colour: red `#c00` for error and warning messageshttps://source.puri.sm/firmware/pureboot/-/issues/10Use "and" instead of "+" in GPG Management Menu2019-11-21T18:31:49ZSam HewittUse "and" instead of "+" in GPG Management MenuMinor thing, but using words would be more explicit and clear here rather than symbols.Minor thing, but using words would be more explicit and clear here rather than symbols.https://source.puri.sm/firmware/pureboot/-/issues/9Sub-menu navigation has inconsistent flow2019-11-21T18:28:22ZSam HewittSub-menu navigation has inconsistent flowThere's a couple issues with sub-menu navigation:
1. Submenus either say "Exit" or "Return to main menu" and both actions do the same thing, so the language should be made consistent there.
2. There's a lot of places where it would mak...There's a couple issues with sub-menu navigation:
1. Submenus either say "Exit" or "Return to main menu" and both actions do the same thing, so the language should be made consistent there.
2. There's a lot of places where it would make more sense to return to the previous menu instead of returning all the way to the main menu; for submenus of the "Options" menu, rather than go back to the main menu, it would be more useful to just return to the previous menuhttps://source.puri.sm/firmware/pureboot/-/issues/8"Refresh TOTP/HOTP" is too technical for the top-level menu2019-11-21T18:21:32ZSam Hewitt"Refresh TOTP/HOTP" is too technical for the top-level menuThe option to refresh TOTP should only be shown if it is being used, having it here crowds the simplicity of the main menu.
That aside, it's unclear from the menu item which is being refreshed from the outset: is both HOTP and TOTP bein...The option to refresh TOTP should only be shown if it is being used, having it here crowds the simplicity of the main menu.
That aside, it's unclear from the menu item which is being refreshed from the outset: is both HOTP and TOTP being refreshed when this action is taken or is it one or the other?https://source.puri.sm/firmware/pureboot/-/issues/7Display HOTP status in menu only if there is an error2019-11-21T18:16:57ZSam HewittDisplay HOTP status in menu only if there is an errorIf all is well with the hardware token, there's no need to display the text status of HOTP in the boot menu. If there is an error, which tend to be technically phrased, human-readable error messages could be shown instead, examples from ...If all is well with the hardware token, there's no need to display the text status of HOTP in the boot menu. If there is an error, which tend to be technically phrased, human-readable error messages could be shown instead, examples from the design concepts:
![Screenshot_from_2019-11-21_13-14-42](/uploads/57fb1bfcfd29523c75b2da271673c420/Screenshot_from_2019-11-21_13-14-42.png)
![Screenshot_from_2019-11-21_13-14-57](/uploads/5564e7aa467c184b9a84e52bbdbdf6f0/Screenshot_from_2019-11-21_13-14-57.png)https://source.puri.sm/firmware/pureboot/-/issues/4Not able to enter PIN for LibremKey "on red background"2021-11-30T16:37:31ZChris VogelNot able to enter PIN for LibremKey "on red background"Not sure whether this belongs to heads or to initramfs. Anyway.
Librem13v4 german keyboard (external usb-keyboard connected) running PureOS amber with kernel 4.19.37-5+deb10u2, heads and encrypted nvme disk using LibremKey to verify (he...Not sure whether this belongs to heads or to initramfs. Anyway.
Librem13v4 german keyboard (external usb-keyboard connected) running PureOS amber with kernel 4.19.37-5+deb10u2, heads and encrypted nvme disk using LibremKey to verify (heads) and decrypt (luks).
- change any file on /boot to trap tamper detection
- reboot - don't sign
- use heads menu to select 'Ignore tampering and force a boot (Unsafe)'
- confirm to proceed (yellow background)
- choose to boot "PureOS_GNU/Linux_[/vmlinuz-4.19.0-5-amd64"
- there'll be a red background with white ascii menu asking to unlock the LibremKey "PIN: "
At this point in a normal boot I can enter my PIN using any keys I want (e.g. internal keyboard, usb keyboard, num keys on both keyboards, num pad on usb keyboard after enabling num lock) and I can confirm the PIN using any of my three enter keys (internal keyboard, usb keyboard and usb keyboard num pad).
But while in this warning mode of heads I can't press enter to confirm my pin and using the external usb keyboards num lock / num pad eventually seems to lock any change by using backspace. I didn't find a way to confirm my pin once entered. Only way out I found is rebooting <CTRL>-<ALT>-<DELETE>.https://source.puri.sm/firmware/pureboot/-/issues/2Please support running from unattended-upgrades2022-04-15T16:01:08ZGuido GuntherPlease support running from unattended-upgradesWith unattended-upgrades there's no tty at all. The result should likely be stored somehwhere and displayed on next login. With unattended-upgrades there's no tty at all. The result should likely be stored somehwhere and displayed on next login.