From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-x434.google.com (mail-wr1-x434.google.com [IPv6:2a00:1450:4864:20::434]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.server123.net (Postfix) with ESMTPS for ; Fri, 23 Nov 2018 10:21:43 +0100 (CET) Received: by mail-wr1-x434.google.com with SMTP id x10so11606957wrs.8 for ; Fri, 23 Nov 2018 01:21:43 -0800 (PST) Received: from [10.43.17.64] (nat-pool-brq-t.redhat.com. [213.175.37.10]) by smtp.gmail.com with ESMTPSA id t5sm9856343wmd.15.2018.11.23.01.21.41 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 23 Nov 2018 01:21:41 -0800 (PST) References: <20180727081626.GA29834@localhost.localdomain> <20180730204718.GA16752@localhost.localdomain> <20180731060030.GA15852@h-174-65.A328.priv.bahnhof.se> <20180731075342.GA25101@localhost.localdomain> From: Milan Broz Message-ID: Date: Fri, 23 Nov 2018 10:21:40 +0100 MIME-Version: 1.0 In-Reply-To: <20180731075342.GA25101@localhost.localdomain> Content-Type: text/plain; charset="windows-1252" Content-Language: en-US Content-Transfer-Encoding: quoted-printable Subject: Re: [dm-crypt] Debian installer formatting LUKS2 devices by default? List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: dm-crypt@saout.de On 31/07/2018 09:53, Guilhem Moulin wrote: > On Tue, 31 Jul 2018 at 06:00:30 +0000, Michael Kj=F6rling wrote: >> Obviously, there's nothing stopping whoever is installing the system >> from dropping to a shell and setting up a container themselves, _even >> if_ the installer _only_ does one version of on-disk format for LUKS. >> So even if the installer _only_ does LUKS1, and the tools are built >> with LUKS1 as default, it's not like that will _prevent_ people from >> using the LUKS2 format if they really want to. >=20 > Sure, but now we can tell people wanting the installer to default to > LUKS2 that it'll be the new upstream default in the future, and also > give a rough ETA. It's more efficient at appeasing them than replying > they need to drop to a shell and manually format & unlock the volume :-) Hi, just an update to LUKS2 as a default: I had to postpone a plan to release 2.1 with LUKS2 as default format (to January/February 2019), and we will release very soon 2.0.6 with some f= ixes of LUKS2 format validation that need to be in place before we switch the de= fault. And the reason (long story): The LUKS2 format supports variable sizes of metadata and keyslot areas, and documentation clearly defines the supported sizes. Cryptsetup uses validation functions that should stop reading/writing inval= id header from disk (to hit not only coding mistakes but also intentional header corr= uptions). Unfortunately, we kept too strict validation in code by mistake so only def= ault LUKS2 header size is recognized as a valid header now. Currently only these default headers are present (both conversion and format create only the default size), but in 2.1 we will provide an interface to use different LUKS2 header sizes. And these headers will be not usable with cryptsetup older than 2.0.6. (Larger metadata areas are requested by some other projects that plan to use LUKS2 header for storing own metadata used for unlocking LUKS2 devices.) IOW the format is ok. We just messed up tests and validation code. Sorry ab= out that. Milan