Re: Cryptomount enhancements - revised

[John Lane]

On 29/07/15 18:21, Andrei Borzenkov wrote:
> В Wed, 29 Jul 2015 07:48:41 +0100
> John Lane <address@hidden> пишет:
>
>> On 28/07/15 22:38, Vladimir 'phcoder' Serbinenko wrote:
>>> Other than 3 and 5 they require difficult configuration. Mapping
>>> devices in GRUB isn't trivial. Those features are difficult to
>>> autoconfigure. Consider "plain" mode: how will you find which disk is
>>> yours when you have 5 disks all looking as random data?
>>>
>>>
>> I don't see what's difficult about providing a LUKs header and key but I
>> am aware of the issue re device identification in plain mode. However,
>> if one has a use-case for these crypto routines then I think that would
>> be a valid use-case for manually configuring grub.cfg if it's beyond
>> what autoconfiguration supports. If an end user wants to make the choice
>> then why deny him, just because it may be difficult to autoconfigure ?
>>
> Yes, it appears people ask for it. At the end, the worst that can
> happen is reading garbage.
>
>> There does seem to be interest in this functionality. Surely
>> auto-configuration would't be a bar to supporting this? I don't think I
>> am the only one who thinks these features are useful...
>>
>> Regarding device identification, I had some thoughts on that and was
>> willing to try implementing something. However I wanted to put this
>> patch-set to bed before starting on something else.
>>
> One think I'd like is to separate self-identified containers managed by
> cryptomount and dmsetup-like stuff to avoid impression that it is fully
> supported.
>
I'm unclear on what the next step is, having responded to feedback and
made changes to address the issues previously raised. Is anything
outstanding that absolutely has to happen before these patches can be
accepted?

Ideally I'd prefer to wrap up this set of changes up before thinking
about other features.