For the impatient, there is now an initial experimental image to test, demoing the new changes.
I don't want to receive bug reports for that just yet, because I haven't tested it a lot myself yet and there are quite a bunch of issues that I am already aware of.

Major changes done:

• The OEM install image is now booting a full PureOS live session
• Full-disk encryption support in Calamares is fixed
• Calamares can do OEM-style installations with full-disk encryption
• Partition layout on OEM installs can be defined manually
• Live session is managed by casper, which is a bit easier to maintain and has a couple of neat features and bugfixes
• The "Remove the live medium and hit enter to reboot" screen works now
• gnome-initial-setup is now added and enabled by default
• gnome-initial-setup (g-i-s) has been tweaked to honor PureOS settings
• Added workjaround for locale-gen systemd issue to g-i-s, needs to be properly addressed sonish
• Added a new LUKS encryption page to g-i-s to allow setting a disk encryption password
• Added a mechanism to reset the LUKS password on first boot, to allow OEM installs with full-disk encryption to work
• On OEM installs, g-i-s launches the installer after finishing.
• debian-installer itself is no longer used (although some of its components are)
• Various bugfixes (screen shield doesn't lock the desktop anymore, settings changes, etc.)

Known very notable issues:

• g-i-s sometimes fails to set locale (language/keyboard) sometimes, settings seem to stick though after a reboot
• Calamares sometimes tries to allocate space for an enormous swap partition, if run in automatic partitioning mode
• Before OEM setup completion, g-i-s freezes for a while with no user feedback while applying changes
• g-i-s does not allow setting a new hostname in OEM setup
• Possibly lots more bugs

If you want to test the experimental demo image to get an impression, fetch it from https://downloads.puri.sm/playground/oem/2018-03-22/
After booting into the live session, you can launch the OEM installer from the GNOME Shell dashboard, if it did not start automatically on its own. If the automatic partitioning gives you an unreasonable layout, create a manual partition layout with:

• one ext4 partition (about 1.2G) mounted as /boot
• one ext4 LUKS encrypted partition mounted as /
• swap (if needed)

The encryption password you set does not matter, but a password must be set (as part of the OEM install process, the password will get removed at a later stage and replaced with a keyfile).
Then hit install and reboot.

This code has only lived in a VM so far! Not much testing has been done, especially not on real hardware.
This is a prototype and expected to have issues - it just shows the direction of where this feature is going, and is no final product (it's pre-alpha quality)

There's a new experimental live image available now for testing.
This build is feature-complete now, which means that - at the current point in time - I don't plan to add more features and the only remaining things to work on are bugs.

Known bugs:

• Before OEM setup completion, g-i-s freezes for a while with no user feedback while applying changes
  • this is tricky to resolve, as it would require invasive changes in g-i-s
• Language switching requires re-login / locale-gen run, so g-i-s does not instantly switch languages (as it should)
  • no clear path to address this yet, this issue might persist for a while
• Autologin in GDM does not work on real hardware, but does work in a VM (use user "pureos" in case this happens to you)
  • possibly a GDM bug, needs some investigation and will definitely be fixed
• On boot with encrypted disk, the system displays a message that the swap partition could not be decrypted, but decrypts it later anyway
  • the swap partition (and all other encrypted partitions on the system) is decrypted using a keyfile on the password-encrypted root partition. That root partition is not mounted initially in the initramfs, so the first swap mount attempt fails. As soon as the root partition is unlocked, all other partitions get mounted successfully. We need to figure out a reliable way to delay the mounting to get rid of this issue.
• The Plymouth theme is wrong on the installed system
  • this issue is already fixed, but will need an image rebuild to make the fix visible

A test image can be found here: https://downloads.puri.sm/playground/oem/2018-03-31/

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.

@kyle.rankin In that case we will loose suspend-to-disk support entirely. I could make this happen, if we decide that our users should not be able to use suspend-to-disk on their systems.

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.

@kyle.rankin That could only happen if the encryption of the first disk (which holds they keyfile to decrypt the swap partition) is broken. If that happens, the impact would of course be more severe, as there are potentially a lot more passwords stored in RAM.

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.

That does make sense... You could also argue though that as soon as the attacker has the opportunity to read the swap partition or other parts of the RAM, you've already lost.

So, pro using a random password for swap at each boot:

• Improved security in scenarios where the attacker has already access to the system and is able to recover old secrets from a currently unlocked swap partition
• d-i did that in previous OEM installs
• The initial swap decryption message would be gone ;-) :P

Contra:

• Suspend-to-disk will not work with this

I see the point in both sides. Since PureOS should find a compromise between security and usability, I'll ask the other devs what they think, and apply whatever we come up with.
Tbh, I am also not sure if suspend-to-disk works reliably on the Librems, I haven't tested that in a while.

Just out of curiousity, would it be possible to disable this feature post-installation? ie switch from encrypted to unencrypted?

That way we could potentially ship with a more-secure machine and offer (somewhere, with warnings, etc.) the choice to loosen that in order to support S2D.

@chris.lamb You wouldn't switch to unencrypted but keyfile-encrypted, but yes, something like that would work. You'd need to swapoff, then reformat swap and encrypt it with the keyfile, and then rewrite crypttab and update the initramfs.

Could longer-term be a job for a small disk-encryption service that I am planning to write (at the moment, a script is called to perform all disk-encryption changes, which is not great because passwords can end up in logfiles and we are using PolicyKit wrong that way). This would need some good user interface though, and would generally be more of a longer-term perspective (one I like though).

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.

(Apologies. I misspoke when I said *un*-encrypted; what I meant was "whatever less-secure method which would re-enable S2D)

So, if there are no objections, I would make a change to always reencrypt swap on boot by default on OEM installations, mainly because that is what we have done in OEM setups so far, with the option to change that back in future.

Aside from that, I think the new image is usable now, so I will but out one more image for testing and then put a copy in the regular release channel, so we get some more testing on the new image. It is badly needed that we update our OEM images.

FTR, the new OEM image for testing can be found here: https://downloads.puri.sm/playground/oem/2018-04-06/
New known issue:

• swap partition is not mounted correctly with the new boot-reencryption mechanism, will be fixed in a future build

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.

What is "this application"? GNOME Initial Setup? What does crash mean, did it disappear? Can you send me your journal log (all of sudo journalctl > log.txt) in a private message?

The wifi thing definitely sounds like an upstream bug in GNOME (I never tried connecting to wifi, we could disable that panel), for the disk encryption password section there is really nothing happening there, so I wonder why anything would crash.

If you reboot and make a second attempt, does it work then?

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.

So, Calamares crashed? Please open a terminal, type pureos-installer-oem --debug and get it to the point where it crashes, then send me the terminal output.

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

The swap partition not-mounting issue is fixed now as well, but will a new image build (obviously) to take effect.
I will build a new image for testing next Sunday.