lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Message-ID: <20170623172856.aixyqcd4o4te6neb@thunk.org> Date: Fri, 23 Jun 2017 13:28:56 -0400 From: Theodore Ts'o <tytso@....edu> To: Richard Weinberger <richard@....at> Cc: Eric Biggers <ebiggers3@...il.com>, linux-fscrypt@...r.kernel.org, Eric Biggers <ebiggers@...gle.com>, linux-f2fs-devel@...ts.sourceforge.net, "linux-mtd@...ts.infradead.org" <linux-mtd@...ts.infradead.org>, Jaegeuk Kim <jaegeuk@...nel.org>, linux-ext4@...r.kernel.org Subject: Re: [PATCH 3/4] ubifs: don't bother checking for encryption key in ->mmap() On Fri, Jun 23, 2017 at 07:20:51PM +0200, Richard Weinberger wrote: > > The plan is that the fscrypt tree will just contain fscrypt "core" patches and > global changes/cleanups go thought the individual filesystem trees, right? Yes, it minimizes potential conflicts against other individual file system trees if we keep patches that are file system specific in their own tree. There will be times when we can't do that --- for example, if we need to make a change in the fscrypt directory that requires matching changes in all of the users of fscrypt at the same time. But when we do that there is always the chance that there will be merge conflicts that have to be manually reconciled by both Stephen Rothwell for linux-next and Linus during the merge window. But if we can avoid needing to do that, it's generally easier for all concerned. Cheers, - Ted
Powered by blists - more mailing lists