** Description changed:

- [Impact] 
+ [Impact]
  clevis can be used to automatically unlock LUKS-encrypted devices during boot 
by asking a remote server for the key (sort of). It does so by monitoring for 
the processes that send up the interactive prompts "Please unlock disk xxx:" 
and then sends a key to that process through a fifo that the process has opened.
  The bug that existed in clevis versions prior to version 17 forgot to clear a 
saved PID-variable (used to store the PID of the process that creates the 
prompt for the user), so when the PID of the first process has been found it 
won't look for more processes of this type. This means it can only unlock one 
device. If you have for example some sort of RAID root filesystem with multiple 
disks (or a ZFS mirror as me) then clevis does not work at all.
  
  [Test Plan]
  - Setup a tang server on a different host:
  # sudo apt install tang
  # sudo systemctl enable tangd.socket --now
  # reboot
  
  - Setup two LUKS-disks that shall be decrypted during early boot (append
  option initramfs to them in /etc/crypttab)
  
  - Setup clevis:
  # sudo apt install clevis
  # sudo apt install clevis-luks
  # sudo apt install clevis-initramfs
  
  - Bind the encrypted disks to the tang server:
  # sudo clevis luks bind -d /dev/<disk1> tang '{"url": "http://<tang-server>"}'
  # sudo clevis luks bind -d /dev/<disk2> tang '{"url": "http://<tang-server>"}'
  
  - Regenerate initramfs
  # sudo update-initramfs -u -k 'all'
  
  - Reboot
  # reboot
  
  After the reboot you will be stuck at "Please unlock disk xxx:" until
  you enter the passphrase manually.
  
  If you perform all the steps using only one disk it will work.
  
  [Where problems could occur]
  If something is wrong with the patch it will show up when clevis is unlocking 
a LUKS-encrypted disk during initramfs.
  
  [Other Info]
- This has been fixed in upstream (latchset/clevis, version 17, commit 
0abdfbc7812c8ef588ee22fd35941b5e831fdce7)
+ This has been fixed in upstream (latchset/clevis, version 17, commit 
0abdfbc7812c8ef588ee22fd35941b5e831fdce7 on Feb 24, 2021)

** Description changed:

  [Impact]
  clevis can be used to automatically unlock LUKS-encrypted devices during boot 
by asking a remote server for the key (sort of). It does so by monitoring for 
the processes that send up the interactive prompts "Please unlock disk xxx:" 
and then sends a key to that process through a fifo that the process has opened.
  The bug that existed in clevis versions prior to version 17 forgot to clear a 
saved PID-variable (used to store the PID of the process that creates the 
prompt for the user), so when the PID of the first process has been found it 
won't look for more processes of this type. This means it can only unlock one 
device. If you have for example some sort of RAID root filesystem with multiple 
disks (or a ZFS mirror as me) then clevis does not work at all.
  
  [Test Plan]
  - Setup a tang server on a different host:
  # sudo apt install tang
  # sudo systemctl enable tangd.socket --now
  # reboot
  
  - Setup two LUKS-disks that shall be decrypted during early boot (append
  option initramfs to them in /etc/crypttab)
  
  - Setup clevis:
  # sudo apt install clevis
  # sudo apt install clevis-luks
  # sudo apt install clevis-initramfs
  
  - Bind the encrypted disks to the tang server:
  # sudo clevis luks bind -d /dev/<disk1> tang '{"url": "http://<tang-server>"}'
  # sudo clevis luks bind -d /dev/<disk2> tang '{"url": "http://<tang-server>"}'
  
  - Regenerate initramfs
  # sudo update-initramfs -u -k 'all'
  
  - Reboot
  # reboot
  
  After the reboot you will be stuck at "Please unlock disk xxx:" until
  you enter the passphrase manually.
  
  If you perform all the steps using only one disk it will work.
  
  [Where problems could occur]
  If something is wrong with the patch it will show up when clevis is unlocking 
a LUKS-encrypted disk during initramfs.
  
  [Other Info]
- This has been fixed in upstream (latchset/clevis, version 17, commit 
0abdfbc7812c8ef588ee22fd35941b5e831fdce7 on Feb 24, 2021)
+ This has been fixed in upstream (https://github.com/latchset/clevis, version 
17, commit 0abdfbc7812c8ef588ee22fd35941b5e831fdce7 on Feb 24, 2021)

** Description changed:

  [Impact]
- clevis can be used to automatically unlock LUKS-encrypted devices during boot 
by asking a remote server for the key (sort of). It does so by monitoring for 
the processes that send up the interactive prompts "Please unlock disk xxx:" 
and then sends a key to that process through a fifo that the process has opened.
+ clevis can be used to automatically unlock LUKS-encrypted devices during boot 
by asking a remote server for the key (sort of). It does so by finding the PID 
of the process that send up the interactive prompt "Please unlock disk xxx:" 
and then sends a key to that process through a fifo that the process has opened.
  The bug that existed in clevis versions prior to version 17 forgot to clear a 
saved PID-variable (used to store the PID of the process that creates the 
prompt for the user), so when the PID of the first process has been found it 
won't look for more processes of this type. This means it can only unlock one 
device. If you have for example some sort of RAID root filesystem with multiple 
disks (or a ZFS mirror as me) then clevis does not work at all.
  
  [Test Plan]
  - Setup a tang server on a different host:
  # sudo apt install tang
  # sudo systemctl enable tangd.socket --now
  # reboot
  
  - Setup two LUKS-disks that shall be decrypted during early boot (append
  option initramfs to them in /etc/crypttab)
  
  - Setup clevis:
  # sudo apt install clevis
  # sudo apt install clevis-luks
  # sudo apt install clevis-initramfs
  
  - Bind the encrypted disks to the tang server:
  # sudo clevis luks bind -d /dev/<disk1> tang '{"url": "http://<tang-server>"}'
  # sudo clevis luks bind -d /dev/<disk2> tang '{"url": "http://<tang-server>"}'
  
  - Regenerate initramfs
  # sudo update-initramfs -u -k 'all'
  
  - Reboot
  # reboot
  
  After the reboot you will be stuck at "Please unlock disk xxx:" until
  you enter the passphrase manually.
  
  If you perform all the steps using only one disk it will work.
  
  [Where problems could occur]
  If something is wrong with the patch it will show up when clevis is unlocking 
a LUKS-encrypted disk during initramfs.
  
  [Other Info]
  This has been fixed in upstream (https://github.com/latchset/clevis, version 
17, commit 0abdfbc7812c8ef588ee22fd35941b5e831fdce7 on Feb 24, 2021)

** Description changed:

  [Impact]
  clevis can be used to automatically unlock LUKS-encrypted devices during boot 
by asking a remote server for the key (sort of). It does so by finding the PID 
of the process that send up the interactive prompt "Please unlock disk xxx:" 
and then sends a key to that process through a fifo that the process has opened.
- The bug that existed in clevis versions prior to version 17 forgot to clear a 
saved PID-variable (used to store the PID of the process that creates the 
prompt for the user), so when the PID of the first process has been found it 
won't look for more processes of this type. This means it can only unlock one 
device. If you have for example some sort of RAID root filesystem with multiple 
disks (or a ZFS mirror as me) then clevis does not work at all.
+ The bug that existed in clevis versions prior to version 17 forgot to clear 
the saved PID-variable (used to store the PID of the process that creates the 
prompt for the user), so when the PID of the first process has been found it 
won't look for more processes of this type. This means it can only unlock one 
device. If you have for example some sort of RAID root filesystem with multiple 
disks (or a ZFS mirror as me) then clevis does not work at all.
  
  [Test Plan]
  - Setup a tang server on a different host:
  # sudo apt install tang
  # sudo systemctl enable tangd.socket --now
  # reboot
  
  - Setup two LUKS-disks that shall be decrypted during early boot (append
  option initramfs to them in /etc/crypttab)
  
  - Setup clevis:
  # sudo apt install clevis
  # sudo apt install clevis-luks
  # sudo apt install clevis-initramfs
  
  - Bind the encrypted disks to the tang server:
  # sudo clevis luks bind -d /dev/<disk1> tang '{"url": "http://<tang-server>"}'
  # sudo clevis luks bind -d /dev/<disk2> tang '{"url": "http://<tang-server>"}'
  
  - Regenerate initramfs
  # sudo update-initramfs -u -k 'all'
  
  - Reboot
  # reboot
  
  After the reboot you will be stuck at "Please unlock disk xxx:" until
  you enter the passphrase manually.
  
  If you perform all the steps using only one disk it will work.
  
  [Where problems could occur]
  If something is wrong with the patch it will show up when clevis is unlocking 
a LUKS-encrypted disk during initramfs.
  
  [Other Info]
  This has been fixed in upstream (https://github.com/latchset/clevis, version 
17, commit 0abdfbc7812c8ef588ee22fd35941b5e831fdce7 on Feb 24, 2021)

** Description changed:

  [Impact]
  clevis can be used to automatically unlock LUKS-encrypted devices during boot 
by asking a remote server for the key (sort of). It does so by finding the PID 
of the process that send up the interactive prompt "Please unlock disk xxx:" 
and then sends a key to that process through a fifo that the process has opened.
- The bug that existed in clevis versions prior to version 17 forgot to clear 
the saved PID-variable (used to store the PID of the process that creates the 
prompt for the user), so when the PID of the first process has been found it 
won't look for more processes of this type. This means it can only unlock one 
device. If you have for example some sort of RAID root filesystem with multiple 
disks (or a ZFS mirror as me) then clevis does not work at all.
+ The bug that existed in clevis versions prior to version 17 forgot to clear 
the saved PID-variable, so when the PID of the first process has been found it 
won't find any more processes of this type. This means it can only unlock one 
device. If you have for example some sort of RAID root filesystem with multiple 
disks (or a ZFS mirror as me) then clevis does not work at all.
  
  [Test Plan]
  - Setup a tang server on a different host:
  # sudo apt install tang
  # sudo systemctl enable tangd.socket --now
  # reboot
  
  - Setup two LUKS-disks that shall be decrypted during early boot (append
  option initramfs to them in /etc/crypttab)
  
  - Setup clevis:
  # sudo apt install clevis
  # sudo apt install clevis-luks
  # sudo apt install clevis-initramfs
  
  - Bind the encrypted disks to the tang server:
  # sudo clevis luks bind -d /dev/<disk1> tang '{"url": "http://<tang-server>"}'
  # sudo clevis luks bind -d /dev/<disk2> tang '{"url": "http://<tang-server>"}'
  
  - Regenerate initramfs
  # sudo update-initramfs -u -k 'all'
  
  - Reboot
  # reboot
  
  After the reboot you will be stuck at "Please unlock disk xxx:" until
  you enter the passphrase manually.
  
  If you perform all the steps using only one disk it will work.
  
  [Where problems could occur]
  If something is wrong with the patch it will show up when clevis is unlocking 
a LUKS-encrypted disk during initramfs.
  
  [Other Info]
  This has been fixed in upstream (https://github.com/latchset/clevis, version 
17, commit 0abdfbc7812c8ef588ee22fd35941b5e831fdce7 on Feb 24, 2021)

** Description changed:

  [Impact]
  clevis can be used to automatically unlock LUKS-encrypted devices during boot 
by asking a remote server for the key (sort of). It does so by finding the PID 
of the process that send up the interactive prompt "Please unlock disk xxx:" 
and then sends a key to that process through a fifo that the process has opened.
- The bug that existed in clevis versions prior to version 17 forgot to clear 
the saved PID-variable, so when the PID of the first process has been found it 
won't find any more processes of this type. This means it can only unlock one 
device. If you have for example some sort of RAID root filesystem with multiple 
disks (or a ZFS mirror as me) then clevis does not work at all.
+ The bug that existed in clevis versions prior to version 17 forgot to clear 
the saved PID-variable, so when the PID of the first process has been found it 
won't find any more processes of this type. This means it can only unlock the 
first device. If you have for example some sort of RAID root filesystem with 
multiple disks (or a ZFS mirror as me) then clevis does not work at all.
  
  [Test Plan]
  - Setup a tang server on a different host:
  # sudo apt install tang
  # sudo systemctl enable tangd.socket --now
  # reboot
  
  - Setup two LUKS-disks that shall be decrypted during early boot (append
  option initramfs to them in /etc/crypttab)
  
  - Setup clevis:
  # sudo apt install clevis
  # sudo apt install clevis-luks
  # sudo apt install clevis-initramfs
  
  - Bind the encrypted disks to the tang server:
  # sudo clevis luks bind -d /dev/<disk1> tang '{"url": "http://<tang-server>"}'
  # sudo clevis luks bind -d /dev/<disk2> tang '{"url": "http://<tang-server>"}'
  
  - Regenerate initramfs
  # sudo update-initramfs -u -k 'all'
  
  - Reboot
  # reboot
  
  After the reboot you will be stuck at "Please unlock disk xxx:" until
  you enter the passphrase manually.
  
  If you perform all the steps using only one disk it will work.
  
  [Where problems could occur]
  If something is wrong with the patch it will show up when clevis is unlocking 
a LUKS-encrypted disk during initramfs.
  
  [Other Info]
  This has been fixed in upstream (https://github.com/latchset/clevis, version 
17, commit 0abdfbc7812c8ef588ee22fd35941b5e831fdce7 on Feb 24, 2021)

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1948598

Title:
  Can't unlock multiple devices in initramfs

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/clevis/+bug/1948598/+subscriptions


-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Reply via email to