Qu Wenruo <quwenruo <at> cn.fujitsu.com> writes: <snip> > > - As of now uses "user" keytype, I am still considering/ > > evaluating other key type such as logon. > > UI things can always be reconsidered later. > Never a big problem. This is not only a UI concern, but an API/ABI concern. To use eCryptFS as an example, on mount(2) you pass the information for it to look up the key in the kernel keyring, and it looks for a key of type "user" - I have personally written code that uses trusted and encrypted keys, and the raw mount(2) call (sans any of the eCryptFS userspace libraries) to mount eCryptFS filesystems sealed to the TPM. If eCryptFS switched to using another key type, my code would cease to work unless the filesystem jumped through hoops to do so in a backwards-compatible way. Similarly, while eCryptFS uses a "user" key, it requires that key have a specific structure - as a result, the encrypted keys support added a key type of "ecryptfs" to create random keys with the appropriate structure, meaning the key type for unencrypted keys and the encrypted key key type field differ. This is surprising and non-obvious, and took some time to figure out in my implementation. The way btrfs encryption interacts with the keyring APIs is important, and "reconsidering later" will potentially represent an API/ABI break. Please keep it in mind. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
