We have two different Librem Key models at this point. The original which was made by Nitrokey and the "Made in USA" one. Each one has a different product ID and probably HID_NAME as well.

Yes, this is by design for extra security, as well as adding the convenience of not having to enter in unlock passphrases two different times at boot (once for /, once for swap). The downside is that it removes the ability to resume from hibernate.

That's because of the 'su $user' command that's in there. Root doesn't have to type the user's password but a regular user (even the same user) does.

Yes, ENV{ID_VENDOR} is what we'd want, as ID_VENDOR is being set in an environment variable that gets passed along to these udev rules. I was just flagging that in your udevadm output it had set ID_VENDOR (via ATTRS{ID_VENDOR}) to Nitrokey.

Based on this:

So to get this straight, the udev rule works with your particular Librem Key on one laptop but not another? I wonder if for some reason the ID_VENDOR value changed from "Nitrokey" to something else in newer revisions of the Librem Key.

To me this ticket should be closed, as we have achieved the initial goal (packaging the equivalent of gpg-encrypted-root into PureOS).

The cryptsetup-initramfs package has a README on configuring gnupg-sc, but I've found it's not entirely accurate and is too focused on configuring a *new* and non-root disk.

Just confirming that we can close this ticket.

This particular ticket is about the German keyboard layout issue where the pipe key does work, but sends an incorrect signal, not about the unrelated UK keyboard issue where the key does not send a signal at all.

It's not a firmware problem exactly. The keyboard is a *different* layout than the default US/UK/DE layout, it's a variant. In the US case it's a US alternate international layout. If you dig down into the keyboard options and set it to that, the pipe key works, however during an install everyone naturally picks the default US keyboard layout (or UK or DE, depending on the device) and almost every key works as expected except the pipe key.

My apologies, I have no idea where I got that number. I reviewed my own hand-edited file and it says "backslash"

This is the value I used and tested, and it's the value that we used for the other entries that were already in the file. If we were to change it for this case, we should also change it for the other, previous Librem 13 entries.

Yes, this should go upstream like with the parent issue. I have tested this fix against my Librem 13 v4.

If it's better to open a new ticket than comment on this one that's fine, but having all the context of this ticket is useful. We now have a Librem 13v4 and so need to modify the same systemd files to add:

It probably makes sense to keep this open until the package shows up in PureOS (having it in Debian is nice, but not sufficient). Once it makes its way into PureOS then sure, close the ticket.

In the mean time could you add a task that erases/truncates /var/log/auth.log after that script runs?

Thanks for the update. Let's leave this ticket open to track the work in bringing the updated cryptsetup package into PureOS. Once that package exists in PureOS we can close this ticket.

I want TB to be packaged by PureOS and installed by default on PureOS unless there is some Free Software licensing issue that would prevent this (I don't believe there is).

We do not need or want it. Specifically the problem with systems like vboot (and why we went with Heads instead) is that we do not want to require that the BIOS pass a signature check against a key that we control. We want the user to be able to flash with a custom BIOS if they so choose, even if we haven't blessed it with our signature.

Sweet! So, what's the timeline look like for me to be able to test this on something?

@mladen.pejakovic so far we don't have anyone in-house who is able to re-create this specific problem but clearly you are getting some kind of support request that motivated you to file this ticket.

@jonas.smedegaard are you able to recreate the problem listed in this ticket with your Librem 13 UK?

This is why I'm trying to narrow everything down to specifically which models are having the specific issue referenced in this ticket. Today I've gotten two different explanations:

@chris.lamb Since you have a UK model, could you please apply the patch @mladen.pejakovic is referencing above and see if you can recreate this regression?

@mladen.pejakovic and @chris.lamb (cc @todd )

Hi @chris.lamb I just wanted to check in on the progress with this. Looking at the official bug it looks like things have stalled a bit but maybe there are other things happening behind the scenes with people working on packaging that I'm not aware of.

Sorry, by "upstreaming" I meant "get packaged into Debian." At the time I wrote this in February I was hoping we could get this into PureOS relatively quickly and had assumed that getting this packaged into PureOS would be faster than into Debian so I wanted to do the fast thing first if it was indeed faster.

The point about it just being a shell script is valid. I would be perfectly fine with including this script (or a similar forked script) directly into cryptsetup-initramfs, especially if that helps speed the process along.

Just checking in on the status of this ticket. We are not yet at a place where this is blocking other activity but will be within another week or two.

This problem seems to specifically point to the installer not changing its own active locale during the install process, but merely setting the default locale for the install on disk.

This issue has been resolved.

Hmmm it worked the second time around... on the VM. Going to test on bare metal now.

Sorry, I mean the "Install PureOS" application that runs within the Gnome desktop crashed. By crash I mean the installer application disappeared. I will see how repeatable it all is.

I've had this application crash for me both when testing in a VM (at that point at the disk encryption password section) and also when trying directly on bare metal Librem 13v2, when trying to connect to wifi.

It would be possible after the fact to even go as far as to reformat the swap partition to be a non-LUKS volume and treat it as regular unencrypted swap, if you wanted, but as @mak mentioned, it would be better to keep it as encrypted, but as a different kind of persistent encryption.

Or if the attacker happens to read the contents of swap while the system is running. Since it isn't overwritten at each boot, it's possible imaging swap while the system is running would reveal old secrets that weren't securely wiped.

You make a good point. In this case it's a security tradeoff because suspend-to-disk creates a security vulnerability since secrets that were in RAM only (disk decryption keys, passwords) could be written to disk and potentially be recoverable.

The swap partition should be encrypted with a random LUKS key like in a standard Debian install instead of via a key file. It's a feature that encrypted swap is blown away each reboot.

@netnut404 If you are willing to use X instead of Wayland, you can switch to that and follow my steps above to generate modelines for the resolutions you want.

I tried the setcap command but still got the same error on PureOS.

More debug info:

I added more logging and tried again. here are the (sanitized) results:

I've uploaded virsh capabilities output as well

When you attempt to start a pureos live cd image in Boxes, you will get the following error in the terminal:

After discussion, removing the PureOS tags as we don't want to risk tainting PureOS with the remaining proprietary software in our coreboot firmware. This project will remain on the coreboot side.

Given most of the work for this is not coreboot work, but PureOS work integrating an existing firmware image (which we'd treat as a binary blob) with fwupd, I don't know that this is really a coreboot project as much as a PureOS project.

I prefer and would advocate for option 2 because it instructs sites that (mistakenly or not) use browser versions to determine how to behave that PureBrowser is most compatible with a particular version of Firefox (which it is, having been almost entirely derived from that browser, with some modifications), while also informing the site that the browser is not in fact Firefox, but something else.

Before the ticket is closed for good, could you provide a User Agent string workaround (if that would work, otherwise some other workaround) so we have steps to present to another user who runs into this or similar problems?

From what I've read on https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/EDID/HOWTO.txt the kernel only includes EDIDs up to 1920x1080:

I was able to get a Librem 13v2 to output at 2560x1440 by switching to GNOME on Xorg at the GDM login prompt for my user and using the steps from here to generate a custom modeline.

The Ubuntu 14.04 Live disk was able to see the full suite of resolutions from my external monitor up to 3840x2160 @ 30hz and 2560x1440 @ 60hz. It uses the 3.19.0-25-generic kernel so perhaps we are seeing some regression with Skylake on more recent 4.x kernels.

I've tested this so far with a few other Live disks including Tails (4.14.12-2 kernel), Fedora 27 (4.13.9-300.fc27.x86_64), Ubuntu 17.10 (4.13.0-21) and Ubuntu 16.04 (4.10.0-28-generic). All of those live disks had the same 1080p limitation.