On 8/24/21 11:17 AM, Ludwig Nussel wrote:
Ancor Gonzalez Sosa wrote:
On 8/24/21 5:16 AM, Michael Chang wrote:
On Mon, Aug 23, 2021 at 04:20:29PM +0200, Ludwig Nussel wrote:
Michael Chang wrote:
On Mon, Aug 23, 2021 at 03:13:04PM +0200, Ludwig Nussel wrote:
[...]
cryptsetup --type luks1 luksFormat /foo/bar
That's done on purpose due to all the LUKS2 concerns I already linked before.
Oh well that explains why the tests work then. So far I assumed that the responsibility to use defaults that work with the distro were with libcryptsetup and other tools just follow (hence PBKDF2 despite LUKS2).
In that regard, when we asked the SUSE Security Team they didn't sound exactly excited about PBKDF2. See [1].
How come yast even bothers? cryptsetup in openSUSE never used LUKS2 as default so potential problems with it should have never appeared on your radar, right?
DISCLAIMER: starting here my reply may sound defensive (apart from being looong), but that was not the intention. I'm all for adopting LUKS2, but don't forget YaST should keep users away from problems. And now, the long reply: YaST bothers because LUKS1 and LUKS2 have differences that are relevant for libstorage-ng. They support different features (like labels), they have a different layout on disk, they use different mechanisms for resizing... All that may affect several calculations done by libstorage-ng and YaST. The level of support for both in Grub2 is VERY different. That affect how the automatic partitioning proposal should look like and also the warnings the Partitioner should show in some situations. And all that may be architecure-specific. In short, LUKS1 and LUKS2 are different enough to simply be treated as the same thing in YaST. We need to be in closer control since we cannot use LUKS2 as default until all the mentioned details are ironed up. It's reasonable (and even wanted) to add general support for LUKS2 in YaST. Right now we only use it in some controlled scenarios, see [2]. But that implies limiting where and when LUKS2 can be used (based on Grub support, memory availability and other criteria), offering the possibility of using alternative algorithms (and explaining the users the advantages/problems of each one), etc. Basically all that was already described in [3]. Afterwards, we can make LUKS2 the YaST default for all situations in which is safe. Otherwise, if YaST would have just started to create LUKS2 devices due to [4], ignoring all the mentioned considerations above, it would have been YaST's fault. YaST would have been blamed for changing an important security feature in an unnoticed way, for making it easy to create non-bootable setups in so many situations, for not taking the memory usage implications into account, for using a not-so-great encryption algorithm... So YaST has plenty of reasons to control which LUKS version it proposes and all of them boil down to a common one... providing a robust and surprises-free (open)SUSE system by default. All that said, it's maybe time for a first implementation of general LUKS2 support in YaST, but only on an already running system. Not supporting it during installation and/or for any mount point that is needed for booting. We can build from there, as long as Grub also evolves to support more setups. Cheers. [1] https://bugzilla.suse.com/show_bug.cgi?id=1142801 (maybe it's an private bug currently, although it contains no sensible information and I guess it could be made public) [2] https://yast.opensuse.org/blog/2019/10/09/advanced-encryption-options-land-i... [3] https://bugzilla.suse.com/show_bug.cgi?id=1185291#c1 [4] https://build.opensuse.org/request/show/913630 -- Ancor González Sosa YaST Team at SUSE Software Solutions