[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190728154032.GE6088@mit.edu>
Date: Sun, 28 Jul 2019 11:40:32 -0400
From: "Theodore Y. Ts'o" <tytso@....edu>
To: Eric Biggers <ebiggers@...nel.org>
Cc: linux-fscrypt@...r.kernel.org, linux-fsdevel@...r.kernel.org,
linux-ext4@...r.kernel.org, linux-f2fs-devel@...ts.sourceforge.net,
linux-mtd@...ts.infradead.org, linux-api@...r.kernel.org,
linux-crypto@...r.kernel.org, keyrings@...r.kernel.org,
Paul Crowley <paulcrowley@...gle.com>,
Satya Tangirala <satyat@...gle.com>
Subject: Re: [PATCH v7 05/16] fscrypt: refactor v1 policy key setup into
keysetup_legacy.c
On Fri, Jul 26, 2019 at 03:41:30PM -0700, Eric Biggers wrote:
> From: Eric Biggers <ebiggers@...gle.com>
>
> 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 <tytso@....edu>
- Ted
Powered by blists - more mailing lists