[systemd-devel] [systemd-commits] src/cryptsetup

[Quentin Lefebvre]

Hi,

On 01/12/2014 01:12, Lennart Poettering wrote :
> On Mon, 24.11.14 19:25, Quentin Lefebvre (qlefebvre_pro at yahoo.com) wrote:
>
>> Le 24/11/2014 19:17, Zbigniew Jędrzejewski-Szmek a écrit :
>>> On Mon, Nov 24, 2014 at 07:03:27PM +0100, Quentin Lefebvre wrote:
>>>> Le 24/11/2014 19:01, Zbigniew Jędrzejewski-Szmek a écrit :
>>>>> On Mon, Nov 24, 2014 at 06:44:25PM +0100, Quentin Lefebvre wrote:
>>>>>> Hi,
>>>>>>
>>>>>> I tested your patch and actually it doesn't solve the bug.
>>>>>> For example, if "hash=sha512" is provided in /etc/crypttab, the
>>>>>> first >                           if (!streq(arg_hash, "plain"))
>>>>>> is true, and the
>>>>>>> +                } else if (!key_file)
>>>>>> is not reached.
>>>>> This is be design. My patch is quite different from your patch,
>>>>> which I tried to make clear in the description.
>>>>>
>>>>> If you specify hash=sha512, then you get hash=sha512.
>>>>
>>>> Yes, and this is the problem.
>>>> cryptsetup ignores the hash, so that we should obtain hash=NULL for
>>>> it to work.
>>> Systemd is not going to work around a bug in a different package.
>>> Specifying a hash in the configuration if you don't want a hash
>>> is an error, please just fix it there.
>>
>> I understand your point.
>> Still you have a cryptsetup tool in systemd, so I would expect it behaves as
>> the "true" cryptsetup program.
>>
>> The problem here is compatibility, you do something with cryptsetup and then
>> your system fails to boot because of a different behaviour of
>> systemd.
>
> Note that compatibiltiy is really a problem with crypttab anyway, as
> there were multiple implementations of the code that reads it around:
> at least the one from DEbian and the one from Fedora, both of which
> had very different feature sets and even different syntaxes.
>
> With systemd's crypttab support we try to provide a decent amount of
> compatibility with both, to the level that it makes sense. Since we
> cannot reach 100% compat anyway, this explicitly means no bug-for-bug
> compatibility however. Hence I really think we should do the correct
> thing, rather than the traditional thing here, given that this is not
> the most common usecase anyway,
>
> Hope that makes sense,

OK. I also read Zbigniew's answer on the bug report.
I understand your point, which makes sense.

I guess we'll have to document these different behaviors in Debian, so 
that users don't get too confused...

But anyway, plain dm-crypt devices, even if they're not the most common 
usecase, should be handled in the long-term, as it is still a useful, 
and quite different setup compared to LUKS devices.

Thanks for your replies and great work!

Best regards,
Quentin