All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ludwig Nussel <ludwig.nussel@suse.de>
To: util-linux <util-linux@vger.kernel.org>
Subject: Re: remove encryption options from mount and losetup?
Date: Fri, 15 Jun 2012 11:13:56 +0200	[thread overview]
Message-ID: <4FDAFCD4.7010205@suse.de> (raw)
In-Reply-To: <20120615084753.GA2566@x2.net.home>

Karel Zak wrote:
> On Thu, Jun 14, 2012 at 01:47:16PM +0200, Ludwig Nussel wrote:
>> Karel Zak wrote:
>>> On Wed, Jun 13, 2012 at 04:53:04PM +0200, Ludwig Nussel wrote:
>>>> 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
> 
>  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.

>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.

>  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

-- 
 (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) 

  reply	other threads:[~2012-06-15  9:13 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-06-13 14:53 remove encryption options from mount and losetup? Ludwig Nussel
2012-06-13 15:01 ` Karel Zak
2012-06-14 11:47   ` Ludwig Nussel
2012-06-14 19:43     ` Milan Broz
2012-06-15  7:03       ` Ludwig Nussel
2012-06-15  8:47     ` Karel Zak
2012-06-15  9:13       ` Ludwig Nussel [this message]
2012-06-15  9:40         ` Karel Zak

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4FDAFCD4.7010205@suse.de \
    --to=ludwig.nussel@suse.de \
    --cc=util-linux@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.