Hi,
On 01/12/2014 01:12, Lennart Poettering wrote :
On Mon, 24.11.14 19:25, Quentin Lefebvre ([email protected]) 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
_______________________________________________
systemd-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
