In some situations, especially with older versions of clevis, we can end
up with a partially used luksmeta slot.
We can identify such slots because they will be marked as inactive, yet
they will contain the clevis UUID, "cb6e8904-81ff-40da-a84a-07ab9ab5715e".
When this situation happens, we have cryptsetup and luksmeta slots "out
of sync", and since we currently have cryptsetup choose the slot, we may
end up trying to use such a partially used slot, which in turn will fail
because luksmeta will not be able to save data to it.
We handle this case by wiping the partially used slot, if we identify
the situation will arise.
Tests also added to verify this case is handled properly.
Fixes: #70
Commits backported:
* Add tests for LUKS binding and unbinding
- f5d42cb3ba
* Rework the logic for reading the existing key
- 834eda9db6
* fix for different output from 'luksAddKey' command w/cryptsetup v2.0.2 (
- 62bd6de0b8
* pins/tang: check that key derivation key is available
- c231352729
The tpm2-tools package in Fedora 32 was updated to version 4.0, but clevis
still only has 3.0 support. Support for the latest release is in the works
and will probable make it to the next clevis release.
But until that happens, let's backport the patches that add tpm2-tools 4.0
support for clevis so it continues to work in Fedora 32.
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
- Delete remaining references to the removed http pin
- Install cryptsetup and tpm2_pcrlist in the initramfs
- Add device TCTI library to the initramfs
Resolves: rhbz#1644876
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
