From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Theodore Y. Ts'o" Date: Sun, 28 Jul 2019 15:40:32 +0000 Subject: Re: [PATCH v7 05/16] fscrypt: refactor v1 policy key setup into keysetup_legacy.c Message-Id: <20190728154032.GE6088@mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit List-Id: References: <20190726224141.14044-1-ebiggers@kernel.org> <20190726224141.14044-6-ebiggers@kernel.org> In-Reply-To: <20190726224141.14044-6-ebiggers@kernel.org> To: Eric Biggers Cc: Satya Tangirala , linux-api@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net, linux-fscrypt@vger.kernel.org, keyrings@vger.kernel.org, linux-mtd@lists.infradead.org, linux-crypto@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-ext4@vger.kernel.org, Paul Crowley On Fri, Jul 26, 2019 at 03:41:30PM -0700, Eric Biggers wrote: > From: Eric Biggers > > In preparation for introducing v2 encryption policies which will find > and derive encryption keys differently from the current v1 encryption > policies, refactor the v1 policy-specific key setup code from keyinfo.c > into keysetup_legacy.c. Then rename keyinfo.c to keysetup.c. I'd use keysetup_v1.c, myself. We can hope that we've gotten it right with v2 and we'll never need to do another version, but *something* is going to come up eventually which will require a v3 keysetup , whether it's post-quantuum cryptography or something else we can't anticipate right now. For an example of the confusion that can result, one good example is in the fs/quota subsystem, where QFMT_VFS_OLD, QFMT_VFS_V0, and QFMT_VFS_V1 maps to quota_v1 and quota_v2 in an amusing and non-obvious way. (Go ahead, try to guess before you go look at the code. :-) Other than that, looks good. We can always move code around or rename files in the future, so I'm not going to insist on doing it now (but it would be my preference). Reviewed-by: Theodore Ts'o - Ted From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Theodore Y. Ts'o" Subject: Re: [PATCH v7 05/16] fscrypt: refactor v1 policy key setup into keysetup_legacy.c Date: Sun, 28 Jul 2019 11:40:32 -0400 Message-ID: <20190728154032.GE6088@mit.edu> References: <20190726224141.14044-1-ebiggers@kernel.org> <20190726224141.14044-6-ebiggers@kernel.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <20190726224141.14044-6-ebiggers@kernel.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-mtd" Errors-To: linux-mtd-bounces+gldm-linux-mtd-36=gmane.org@lists.infradead.org To: Eric Biggers Cc: Satya Tangirala , linux-api@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net, linux-fscrypt@vger.kernel.org, keyrings@vger.kernel.org, linux-mtd@lists.infradead.org, linux-crypto@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-ext4@vger.kernel.org, Paul Crowley List-Id: linux-api@vger.kernel.org On Fri, Jul 26, 2019 at 03:41:30PM -0700, Eric Biggers wrote: > From: Eric Biggers > > In preparation for introducing v2 encryption policies which will find > and derive encryption keys differently from the current v1 encryption > policies, refactor the v1 policy-specific key setup code from keyinfo.c > into keysetup_legacy.c. Then rename keyinfo.c to keysetup.c. I'd use keysetup_v1.c, myself. We can hope that we've gotten it right with v2 and we'll never need to do another version, but *something* is going to come up eventually which will require a v3 keysetup , whether it's post-quantuum cryptography or something else we can't anticipate right now. For an example of the confusion that can result, one good example is in the fs/quota subsystem, where QFMT_VFS_OLD, QFMT_VFS_V0, and QFMT_VFS_V1 maps to quota_v1 and quota_v2 in an amusing and non-obvious way. (Go ahead, try to guess before you go look at the code. :-) Other than that, looks good. We can always move code around or rename files in the future, so I'm not going to insist on doing it now (but it would be my preference). Reviewed-by: Theodore Ts'o - Ted ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/ 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 X-Spam-Level: X-Spam-Status: No, score=-2.3 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 94A8AC7618B for ; Sun, 28 Jul 2019 15:40:54 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 6EFAB2075E for ; Sun, 28 Jul 2019 15:40:54 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726103AbfG1Pkx (ORCPT ); Sun, 28 Jul 2019 11:40:53 -0400 Received: from outgoing-auth-1.mit.edu ([18.9.28.11]:33128 "EHLO outgoing.mit.edu" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726080AbfG1Pkx (ORCPT ); Sun, 28 Jul 2019 11:40:53 -0400 Received: from callcc.thunk.org (96-72-102-169-static.hfc.comcastbusiness.net [96.72.102.169] (may be forged)) (authenticated bits=0) (User authenticated as tytso@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x6SFeXgD004159 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 28 Jul 2019 11:40:34 -0400 Received: by callcc.thunk.org (Postfix, from userid 15806) id 6A6464202F5; Sun, 28 Jul 2019 11:40:32 -0400 (EDT) Date: Sun, 28 Jul 2019 11:40:32 -0400 From: "Theodore Y. Ts'o" To: Eric Biggers Cc: linux-fscrypt@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-ext4@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net, linux-mtd@lists.infradead.org, linux-api@vger.kernel.org, linux-crypto@vger.kernel.org, keyrings@vger.kernel.org, Paul Crowley , Satya Tangirala Subject: Re: [PATCH v7 05/16] fscrypt: refactor v1 policy key setup into keysetup_legacy.c Message-ID: <20190728154032.GE6088@mit.edu> References: <20190726224141.14044-1-ebiggers@kernel.org> <20190726224141.14044-6-ebiggers@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190726224141.14044-6-ebiggers@kernel.org> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-crypto-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-crypto@vger.kernel.org On Fri, Jul 26, 2019 at 03:41:30PM -0700, Eric Biggers wrote: > From: Eric Biggers > > In preparation for introducing v2 encryption policies which will find > and derive encryption keys differently from the current v1 encryption > policies, refactor the v1 policy-specific key setup code from keyinfo.c > into keysetup_legacy.c. Then rename keyinfo.c to keysetup.c. I'd use keysetup_v1.c, myself. We can hope that we've gotten it right with v2 and we'll never need to do another version, but *something* is going to come up eventually which will require a v3 keysetup , whether it's post-quantuum cryptography or something else we can't anticipate right now. For an example of the confusion that can result, one good example is in the fs/quota subsystem, where QFMT_VFS_OLD, QFMT_VFS_V0, and QFMT_VFS_V1 maps to quota_v1 and quota_v2 in an amusing and non-obvious way. (Go ahead, try to guess before you go look at the code. :-) Other than that, looks good. We can always move code around or rename files in the future, so I'm not going to insist on doing it now (but it would be my preference). Reviewed-by: Theodore Ts'o - Ted 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 X-Spam-Level: X-Spam-Status: No, score=-2.1 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 4ABBEC7618B for ; Sun, 28 Jul 2019 15:40:52 +0000 (UTC) Received: from lists.sourceforge.net (lists.sourceforge.net [216.105.38.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 0ECCD2075E; Sun, 28 Jul 2019 15:40:51 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=sourceforge.net header.i=@sourceforge.net header.b="E2M7FS5T"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=sf.net header.i=@sf.net header.b="DXo9xQ16" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 0ECCD2075E Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=mit.edu Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=linux-f2fs-devel-bounces@lists.sourceforge.net Received: from [127.0.0.1] (helo=sfs-ml-4.v29.lw.sourceforge.com) by sfs-ml-4.v29.lw.sourceforge.com with esmtp (Exim 4.90_1) (envelope-from ) id 1hrlI3-0002E7-JE; Sun, 28 Jul 2019 15:40:51 +0000 Received: from [172.30.20.202] (helo=mx.sourceforge.net) by sfs-ml-4.v29.lw.sourceforge.com with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1hrlI2-0002Dv-Ax for linux-f2fs-devel@lists.sourceforge.net; Sun, 28 Jul 2019 15:40:50 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sourceforge.net; s=x; h=In-Reply-To:Content-Type:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=OaxkpDzUJbsX+5v0wbTx3RARXQZpYtCB+4BNL6JwSYs=; b=E2M7FS5TRlA3b/rx2ZDouIe1k7 HupLcFfm4kYaayqg5sEm7nT4IJSFVi8UWn2AHthTVKEe4g7kmxSldo1iLNu4sQ37A0PMOjlSrvMew oBiJHspnekJmIxT+ZJVVHMei2NijEtNSad9Fe53wRraDp5d09Foh5oBVRmrluWzJtI3A=; DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sf.net; s=x ; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To :From:Date:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=OaxkpDzUJbsX+5v0wbTx3RARXQZpYtCB+4BNL6JwSYs=; b=DXo9xQ16eiPf2jWbTuLqZVqZnU t91ahfZ2RmOduMGOFsqWZWogjqTopvO5AzqPTUvNrRY2ddbIdJiWC5djNUHtgJk3fmM6bFzWFzhVz R7JdMbDQvChneCKMK0sIWso1FoD1ozOS5JXTmqBw9+fVGZeGrBP22l01MTGVK6chvYmk=; Received: from outgoing-auth-1.mit.edu ([18.9.28.11] helo=outgoing.mit.edu) by sfi-mx-3.v28.lw.sourceforge.com with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) id 1hrlHz-002Qsl-TO for linux-f2fs-devel@lists.sourceforge.net; Sun, 28 Jul 2019 15:40:50 +0000 Received: from callcc.thunk.org (96-72-102-169-static.hfc.comcastbusiness.net [96.72.102.169] (may be forged)) (authenticated bits=0) (User authenticated as tytso@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x6SFeXgD004159 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 28 Jul 2019 11:40:34 -0400 Received: by callcc.thunk.org (Postfix, from userid 15806) id 6A6464202F5; Sun, 28 Jul 2019 11:40:32 -0400 (EDT) Date: Sun, 28 Jul 2019 11:40:32 -0400 From: "Theodore Y. Ts'o" To: Eric Biggers Message-ID: <20190728154032.GE6088@mit.edu> References: <20190726224141.14044-1-ebiggers@kernel.org> <20190726224141.14044-6-ebiggers@kernel.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20190726224141.14044-6-ebiggers@kernel.org> User-Agent: Mutt/1.10.1 (2018-07-13) X-Headers-End: 1hrlHz-002Qsl-TO Subject: Re: [f2fs-dev] [PATCH v7 05/16] fscrypt: refactor v1 policy key setup into keysetup_legacy.c X-BeenThere: linux-f2fs-devel@lists.sourceforge.net X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Satya Tangirala , linux-api@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net, linux-fscrypt@vger.kernel.org, keyrings@vger.kernel.org, linux-mtd@lists.infradead.org, linux-crypto@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-ext4@vger.kernel.org, Paul Crowley Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: linux-f2fs-devel-bounces@lists.sourceforge.net On Fri, Jul 26, 2019 at 03:41:30PM -0700, Eric Biggers wrote: > From: Eric Biggers > > In preparation for introducing v2 encryption policies which will find > and derive encryption keys differently from the current v1 encryption > policies, refactor the v1 policy-specific key setup code from keyinfo.c > into keysetup_legacy.c. Then rename keyinfo.c to keysetup.c. I'd use keysetup_v1.c, myself. We can hope that we've gotten it right with v2 and we'll never need to do another version, but *something* is going to come up eventually which will require a v3 keysetup , whether it's post-quantuum cryptography or something else we can't anticipate right now. For an example of the confusion that can result, one good example is in the fs/quota subsystem, where QFMT_VFS_OLD, QFMT_VFS_V0, and QFMT_VFS_V1 maps to quota_v1 and quota_v2 in an amusing and non-obvious way. (Go ahead, try to guess before you go look at the code. :-) Other than that, looks good. We can always move code around or rename files in the future, so I'm not going to insist on doing it now (but it would be my preference). Reviewed-by: Theodore Ts'o - Ted _______________________________________________ Linux-f2fs-devel mailing list Linux-f2fs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel