| 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: <20150513020208.GK15721@dastard> Date: Wed, 13 May 2015 12:02:08 +1000 From: Dave Chinner <david@...morbit.com> To: Jaegeuk Kim <jaegeuk@...nel.org> Cc: linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org, linux-f2fs-devel@...ts.sourceforge.net Subject: Re: [PATCH 03/18] f2fs crypto: declare some definitions for f2fs encryption feature On Fri, May 08, 2015 at 09:20:38PM -0700, Jaegeuk Kim wrote: > This definitions will be used by inode and superblock for encyption. How much of this crypto stuff is common with or only slightly modified from the ext4 code? Is the behaviour and features the same? Is the user API and management tools the same? IMO, if there is any amount of overlap, then we should be implementing this stuff as generic code, not propagating the same code through multiple filesystems via copy-n-paste-n-modify. This will simply end up with diverging code, different bugs and feature sets, and none of the implementations will get the review and maintenance they really require... And, FWIW, this is the reason why I originally asked for the ext4 encryption code to be pulled up to the VFS: precisely so we didn't end up with a rapid proliferation of individual in-filesystem encryption implementations that are all slightly different... Cheers, Dave. -- Dave Chinner david@...morbit.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists