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

[Lennart Poettering]

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,

Lennart

-- 
Lennart Poettering, Red Hat