From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ciao.gmane.io (ciao.gmane.io [159.69.161.202]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mail.server123.net (Postfix) with ESMTPS for ; Mon, 30 Mar 2020 02:44:19 +0200 (CEST) Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1jIiXK-0008ei-R0 for dm-crypt@saout.de; Mon, 30 Mar 2020 02:44:18 +0200 From: Robert Nichols Date: Sun, 29 Mar 2020 19:44:13 -0500 Message-ID: References: <20200329102015.GA13364@tansi.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit In-Reply-To: Content-Language: en-US Subject: Re: [dm-crypt] Why is the chk_luks_keyslots tool not routinely included? List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: dm-crypt@saout.de On 3/29/20 9:09 AM, Milan Broz wrote: > On 29/03/2020 14:34, Jordan Glover wrote: >> On Sunday, March 29, 2020 10:20 AM, Arno Wagner wrote: >> >>> I think that is a decision by the distros. I am certainly >>> willing to maintain it for the foreseeable future. It is >>> not really much effort. >> >> The distros just do "make install" [1]. I think it's upstream who decides what this command does. >> >> [1] https://git.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/cryptsetup#n39 > > My plan was to include this check in repair command instead of adding additional binary. > (The code could remain basically the same.) > > With LUKS2 we can store other data in binary keyslot area (depends on type), so it need a little > bit more work but it should not be a big problem. > > Please report an issue for it, that helps to not forget about it. Done. https://gitlab.com/cryptsetup/cryptsetup/-/issues/545 -- Bob Nichols "NOSPAM" is really part of my email address. Do NOT delete it.