remove encryption options from mount and losetup?
Hi,
Is there any reason to still keep the encryption options in losetup and mount around? They look entirely useless to me. Even when using passfd and an external key generation function it's still broken as the key size is fixed at 32 byte and the last byte is always set to '\0'. So would a patch that removes encryption support completely be acceptable?
cu
Ludwig
Signature · 4 lines
(o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg)
Karel Zak
maintainerQuoted 6 lines · Ludwig Nussel
Is there any reason to still keep the encryption options in losetup and mount around? They look entirely useless to me. Even when using passfd and an external key generation function it's still broken as the key size is fixed at 32 byte and the last byte is always set to '\0'. So would a patch that removes encryption support completely be acceptable?
Our goal is to follow kernel, so it would be better to remove this feature from kernel loopdev first.
Karel
Signature · 2 lines
Karel Zak <[email protected]> http://karelzak.blogspot.com
Quoted 10 lines · Karel Zak
Quoted 6 lines · Ludwig Nussel
Is there any reason to still keep the encryption options in losetup and mount around? They look entirely useless to me. Even when using passfd and an external key generation function it's still broken as the key size is fixed at 32 byte and the last byte is always set to '\0'. So would a patch that removes encryption support completely be acceptable?
Our goal is to follow kernel, so it would be better to remove this feature from kernel loopdev first.
Well, someone could come up with another tool to support cryptoloop, or rather 'transfer functions'.
If losetup has the philosophy to provide the canonical implementation for all loop features then losetup isn't complete anyways. It needs options to set lo_encrypt_type, lo_crypt_name and lo_encrypt_key_size independent of each other then. Also, overwriting the last 8 bits of the key with zeroes certainly defeats the purpose. Those transfer functions are dynamic so it's possible to have others than cryptoloop with different semantics on the lo_encrypt_* fields.
cu
Ludwig
Signature · 4 lines
(o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg)
Quoted 4 lines · Ludwig Nussel
Karel Zak wrote:
Well, someone could come up with another tool to support cryptoloop, or rather 'transfer functions'.
cryptsetup can map all compatible mappings with cryptoloop using dmcrypt (and it can automatically alloc loop device as well) so providing something compatible is just question of simple wrapper.
IMHO cryptoloop should be removed from kernel... The only usable (and secure) solution using this interface is out-of-mainline-tree loop-aes extension.
Milan
Quoted 6 lines · Milan Broz
Quoted 4 lines · Ludwig Nussel
Karel Zak wrote:
Well, someone could come up with another tool to support cryptoloop, or rather 'transfer functions'.
Quoted 6 lines
cryptsetup can map all compatible mappings with cryptoloop using dmcrypt (and it can automatically alloc loop device as well) so providing something compatible is just question of simple wrapper.
IMHO cryptoloop should be removed from kernel... The only usable (and secure) solution using this interface is out-of-mainline-tree loop-aes extension.
Sure. Who is going to send the patch?
I don't think this needs to be the precondition to remove the incomplete encryption support from losetup. On the contrary, the current losetup support makes cryptoloop even worse as there's no support for hashing the passphrase nor a way to e.g. pipe a random key into losetup.
cu
Ludwig
Signature · 4 lines
(o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg)
Karel Zak
maintainerQuoted 9 lines · Ludwig Nussel
Quoted 8 lines · Karel Zak
Quoted 6 lines · Ludwig Nussel
Is there any reason to still keep the encryption options in losetup and mount around? They look entirely useless to me. Even when using passfd and an external key generation function it's still broken as the key size is fixed at 32 byte and the last byte is always set to '\0'. So would a patch that removes encryption support completely be acceptable?
Quoted 7 lines
Quoted 2 lines
Our goal is to follow kernel, so it would be better to remove this feature from kernel loopdev first.
Well, someone could come up with another tool to support cryptoloop, or rather 'transfer functions'.
If losetup has the philosophy to provide the canonical implementation for all loop features then losetup isn't complete anyways. It needs
I don't know what was original idea, but the current '--encryption' works somehow. Yes, it's not perfect, it's maybe almost useless, but it's still have some users and we cannot remove it without a prior warning.
Fortunately, cryptoloop is in our deprecated.txt for years, so I think it's should be enough to add a fat warning to the next v2.22 release and remove this feature in v2.23.
Anyway, I like Milan's idea with libcryptsetup, and we will try to prepare any solution. BTW, the current cryptsetup also support loop-aes ;-)
We will see...
Karel
Signature · 2 lines
Karel Zak <[email protected]> http://karelzak.blogspot.com
Quoted 23 lines · Karel Zak
Quoted 9 lines · Ludwig Nussel
Quoted 8 lines · Karel Zak
Quoted 6 lines · Ludwig Nussel
Is there any reason to still keep the encryption options in losetup and mount around? They look entirely useless to me. Even when using passfd and an external key generation function it's still broken as the key size is fixed at 32 byte and the last byte is always set to '\0'. So would a patch that removes encryption support completely be acceptable?
Quoted 7 lines
Quoted 2 lines
Our goal is to follow kernel, so it would be better to remove this feature from kernel loopdev first.
Well, someone could come up with another tool to support cryptoloop, or rather 'transfer functions'.
If losetup has the philosophy to provide the canonical implementation for all loop features then losetup isn't complete anyways. It needsI don't know what was original idea, but the current '--encryption' works somehow. Yes, it's not perfect, it's maybe almost useless, but it's still have some users and we cannot remove it without a prior warning.
Quoted 5 lines
Fortunately, cryptoloop is in our deprecated.txt for years, so I think it's should be enough to add a fat warning to the next v2.22 release and remove this feature in v2.23.
From a distribution PoV it doesn't really matter. I just need to know
the direction :-) I'm currently struggling between porting our old patch that adds password hashing to losetup once again or to remove encryption support from losetup completely. I think we cannot ship 12.2 with the current upstream state as that would add a third and even more broken way than what we had before.
Quoted 2 lines
Anyway, I like Milan's idea with libcryptsetup, and we will try to prepare any solution. BTW, the current cryptsetup also support loop-aes ;-)
Sure but setting up the block device is probably not what mount should do.
cu
Ludwig
Signature · 4 lines
(o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg)
Karel Zak
maintainerQuoted 24 lines · Ludwig Nussel
Quoted 23 lines · Karel Zak
Quoted 9 lines · Ludwig Nussel
Quoted 8 lines · Karel Zak
Quoted 6 lines · Ludwig Nussel
Is there any reason to still keep the encryption options in losetup and mount around? They look entirely useless to me. Even when using passfd and an external key generation function it's still broken as the key size is fixed at 32 byte and the last byte is always set to '\0'. So would a patch that removes encryption support completely be acceptable?
Quoted 7 lines
Quoted 2 lines
Our goal is to follow kernel, so it would be better to remove this feature from kernel loopdev first.
Well, someone could come up with another tool to support cryptoloop, or rather 'transfer functions'.
If losetup has the philosophy to provide the canonical implementation for all loop features then losetup isn't complete anyways. It needsI don't know what was original idea, but the current '--encryption' works somehow. Yes, it's not perfect, it's maybe almost useless, but it's still have some users and we cannot remove it without a prior warning.
Quoted 6 lines
Quoted 3 lines
Fortunately, cryptoloop is in our deprecated.txt for years, so I think it's should be enough to add a fat warning to the next v2.22 release and remove this feature in v2.23.
From a distribution PoV it doesn't really matter. I just need to know the direction :-)
Just remove the encryption, that's the direction ;-) I'll do that for RHEL7, Fedora 18 and v2.23 upstream.
Quoted 11 lines
I'm currently struggling between porting our old patch
that adds password hashing to losetup once again or to remove encryption support from losetup completely. I think we cannot ship 12.2 with the current upstream state as that would add a third and even more broken way than what we had before.Quoted 2 lines
Anyway, I like Milan's idea with libcryptsetup, and we will try to prepare any solution. BTW, the current cryptsetup also support loop-aes ;-)
Sure but setting up the block device is probably not what mount should do.
I have talked about it with Milan on IRC, it will be better to kill cryptoloop at all without any extra workaround. It seems that arbitrary workaround will drag out the agony of cryptoloop.
The current cryptsetup is able to work with loop devices so it should be enough (I guess).
Karel
Signature · 2 lines
Karel Zak <[email protected]> http://karelzak.blogspot.com