Whether this becomes two articles or one is really your call and depends on how closely the topics are related (can they be easily broken into two standalone articles) and perhaps how long a single article will be.

We can add a second article if you decide mid-writing that it is best.

Understood. As mentioned in #177 the fido2/u2f way to decrypt the disk could fit nicely in the security keys series as a standalone article but as you said we can wait on how long this will be before we decide

I started to work on this

I'm done writing, awaiting review :)

@w4tsn: I've done an editing pass on this article. Go ahead and make any further revisions you like between now and Wednesday, 04:00 UTC. Then, unless you request additional time to further revise the article, I'll schedule it to go out at 08:00 UTC Wednesday morning.

Thanks!

FIDO U2F keys do not suffer from [invalidation of secure boot measurements due to kernel/intramfs updates] as they are not tied to the hardware platform.

Maybe I'm misreading what you are trying to say, but shouldn't that be "... as they are not tied to the software environment"?

FIDO U2F keys do not suffer from [invalidation of secure boot measurements due to kernel/intramfs updates] as they are not tied to the hardware platform.

Maybe I'm misreading what you are trying to say, but shouldn't that be "... as they are not tied to the software environment"?

What I tried to convey in few words is this: the TPM2 based approach is hardware- and software dependant and invalidated every time something changes like a uefi driver blob, the initramfs, the graphics card, etc. The FIDO2 token however does not suffer from this as its binding is independent from the hardware and software platform - the binding is not dependent on Secure Boot measurements. Instead in FIDO2 (more specifically FIDO U2F) some form of challenge-response is done between the workstation and the key to determine if the disk may be unlocked so it does not get invalidated on kernel updates etc.

@w4tsn: I've done an editing pass on this article. Go ahead and make any further revisions you like between now and Wednesday, 04:00 UTC. Then, unless you request additional time to further revise the article, I'll schedule it to go out at 08:00 UTC Wednesday morning.

Thanks!

Thank you! I made some more minor changes

@w4tsn: Someone just pointed out that the format of the crypttab file require a plus separated list of PCRs. But your article says it should be comma separated. Which is correct? Does the article need to be revised?

@w4tsn: Someone just pointed out that the format of the crypttab file require a plus separated list of PCRs. But your article says it should be comma separated. Which is correct? Does the article need to be revised?

Oh my, they are right. A revision is in order. In my notes it says I had to use two different formats in CLI compared to crypttab but following the man-page it is indeed plus-separated in both cases.

I kinda missed the opportunity to also include steps for getting this to work on Silverblue - it might be nice to publish one more article in this series covering that

Oh my, they are right. A revision is in order. In my notes it says I had to use two different formats in CLI compared to crypttab but following the man-page it is indeed plus-separated in both cases.

I've made the revision. Let me know if any further changes are required.

I kinda missed the opportunity to also include steps for getting this to work on Silverblue - it might be nice to publish one more article in this series covering that.

It's up to you. Richard might want you to go through the formal approval process. But such an article would have my +1.

One comment clarifies that one has to point to the correct partition. The following section could be added:

Find your encrypted LUKS disks

For the following sections you need the filesystem path(s) to your LUKS encrypted partition(s). Use lsblk to find them.

$> lsblk
NAME                                          MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINTS
sda                                             8:0    1     0B  0 disk  
sdb                                             8:16   1     0B  0 disk  
zram0                                         252:0    0     8G  0 disk  [SWAP]
nvme0n1                                       259:0    0 476.9G  0 disk  
├─nvme0n1p1                                   259:1    0   600M  0 part  /boot/efi
├─nvme0n1p2                                   259:2    0     1G  0 part  /boot
└─nvme0n1p3                                   259:3    0 475.4G  0 part  
  └─luks-fdb98c38-dd84-4b18-b2d0-c508bc0f7b8f 253:0    0 475.3G  0 crypt /home
                                                                         /

Find the partition number(s) hosting the luks- partition of type crypt. In this case that'd be /dev/nvme0n1p3. Use this path as target for the following sections.

I kinda missed the opportunity to also include steps for getting this to work on Silverblue - it might be nice to publish one more article in this series covering that.

It's up to you. Richard might want you to go through the formal approval process. But such an article would have my +1.

I'll open up a discussion for this

One comment clarifies that one has to point to the correct partition. The following section could be added: ...

I've added the requested section.

I kinda missed the opportunity to also include steps for getting this to work on Silverblue - it might be nice to publish one more article in this series covering that.

It's up to you. Richard might want you to go through the formal approval process. But such an article would have my +1.

I'll open up a discussion for this

I'm good with another article aimed at Silverblue. I only think we need to have the Pagure ticket. Opening the discussion is only needed to establish the title and general topic/outline so we can track it. But I give it a +1

Someone mentioned that systemd-cryptenroll does not work with LUKS1 only LUKS2. I think a short notice about this would be nice in the article with maybe a link on how to upgrade from LUKS1 to LUKS2? Found this discussion on it: https://discussion.fedoraproject.org/t/upgrade-from-luks-luks2-on-main-disk/81099

On a side note: I'm surprised that there is no FedoraMagazine article on how to upgrade your LUKS1 to LUKS2. Even the fedora docs do not have a section on this. Both are things that I'd like to change now that at least one user reported an issue with this. Especially since long time fedora users will have this problem sooner or later and this conversion is not done on upgrades but does involve manual action from users.

Archwiki: https://wiki.archlinux.org/title/Dm-crypt/Device_encryption#Conversion_from_LUKS1_to_LUKS2_and_back

I've added the note about needing to upgrade to LUKS2 if you are using a LUKS volume created pre Fedora Linux 30 and I included the links you provided.

How to upgrade from LUKS1 to LUKS2 sounds like a great addition for the Fedora Quick Docs. It doesn't seem like there would be enough to it for a Fedora Magazine article. Unless there is more to it than what is described in the Arch wiki?