From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 61BC0C4332F for ; Fri, 16 Dec 2022 21:06:56 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231873AbiLPVGz (ORCPT ); Fri, 16 Dec 2022 16:06:55 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48890 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230171AbiLPVGy (ORCPT ); Fri, 16 Dec 2022 16:06:54 -0500 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A5143DEFE; Fri, 16 Dec 2022 13:06:53 -0800 (PST) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 442316221A; Fri, 16 Dec 2022 21:06:53 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 7663AC433EF; Fri, 16 Dec 2022 21:06:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1671224812; bh=vQnEle8DIQDINZxnB4NynE9ZPfDylYmC1JKlkPCWync=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=Lw67mAqbYQewRYaBRK79ZyXVfd7uicKtXjRTP7rWqlPFcx4p8r4qJm9WleLTc/9m8 Afj57BHi1WUzfLH1Lxo5o91LOvRYNBobnEZZHw7J/c+GvYDJnjRDjMo7mUYDk7HnXS tPkiXE1SPXm7AgxVv+GWXCBAG7Zv6vbDwyoxDVymffwBbRQ/rsolhHDCiduVlPkofI a3sYKxMNkEgQKmD2ZYkz8a4CCAZPS1R2r7S87MvDJPi1tQjgQXU84dDlFFcrtqbn7h /+JMg29kiV0wbYgBTSmTnFbvcrbK/radR1MK9d8dLg0WF8h1Y9DKtrmx7etugfndQ7 gGg/dbKobgxKQ== Date: Fri, 16 Dec 2022 13:06:50 -0800 From: Eric Biggers To: Luca Boccassi Cc: linux-fscrypt@vger.kernel.org, linux-ext4@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net, linux-btrfs@vger.kernel.org, linux-integrity@vger.kernel.org, stable@vger.kernel.org Subject: Re: [PATCH] fsverity: don't check builtin signatures when require_signatures=0 Message-ID: References: <20221208033523.122642-1-ebiggers@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-ext4@vger.kernel.org On Thu, Dec 08, 2022 at 08:42:56PM +0000, Luca Boccassi wrote: > On Thu, 8 Dec 2022 at 03:35, Eric Biggers wrote: > > > > From: Eric Biggers > > > > An issue that arises when migrating from builtin signatures to userspace > > signatures is that existing files that have builtin signatures cannot be > > opened unless either CONFIG_FS_VERITY_BUILTIN_SIGNATURES is disabled or > > the signing certificate is left in the .fs-verity keyring. > > > > Since builtin signatures provide no security benefit when > > fs.verity.require_signatures=0 anyway, let's just skip the signature > > verification in this case. > > > > Fixes: 432434c9f8e1 ("fs-verity: support builtin file signatures") > > Cc: # v5.4+ > > Signed-off-by: Eric Biggers > > --- > > fs/verity/signature.c | 18 ++++++++++++++++-- > > 1 file changed, 16 insertions(+), 2 deletions(-) > > Acked-by: Luca Boccassi So if I can't apply https://lore.kernel.org/linux-fscrypt/20221208033548.122704-1-ebiggers@kernel.org ("fsverity: mark builtin signatures as deprecated") due to IPE, wouldn't I not be able to apply this patch either? Surely IPE isn't depending on fs.verity.require_signatures=1, given that it enforces the policy itself? - Eric