On 01/08/2016 12:53 PM, Marco d'Itri wrote: > On Jan 08, Marc Haber <mh+debian-devel@zugschlus.de> wrote: > >> important functionality maked as "broken", "obsolete" and eventually >> removed, just as the keyscript= feature of /etc/crypttab was lost a >> year ago (noone cared). > Let's be clear here: nobody cared enough to implement it. > It was clearly explained by the upstream maintainers, multiple times, > that they would have liked to have this feature. That's not really accurate. To make a long story *really* short: - Synchronous calls to an arbitrary executable is not something the systemd developers want to have in their code (see the linked posting). See e.g. [1], [2] - Instead it was proposed to use password agents (see [1]) for this. - Problem with that is that the password agents don't support arbitrary binary data, which is needed for keys (they only support plain text). - A patch for augmenting the password agent protocol to support binary data was rejected [3], with the idea that it would probably be better to use the kernel keyring instead of userspace to transmit these types of keys. Also, there have been strong hints (see e.g. [3], but also others that I can't find) that changing this would also require some early-available dbus, in form of kdbus, once that was done. - kdbus is not going to be here anytime soon. So people actually did implement this and when the implementation was available, the goal posts were moved by upstream. As far as I can tell, this is a case where upstream's goal of creating the best technical solution for a problem gets in the way of having something that works at all. The main problem is that there isn't any good way of getting a binary key into systemd's cryptsetup implementation at all - so that it's currently not possible to use anything other than passwords or key files if one wants to use systemd-cryptsetup. This breaks a lot of other use cases, such as two-factor authentication, using the TPM, using external key hardware, etc. - and the reason why this didn't affect Jessie much worse is that initramfs-tools still support keyscript=, so unlocking the rootfs still works via this mechanism. And it'd be one thing if a proper solution had been around the corner and this feature had been missing for a couple of months, but it has been years, and there is no perspective on when a patch for this would be accepted upstream, because (from what I read on the mailing list) they appear to want to have early-boot IPC before touching the password agent code again - which means it could take another 2 or 3 years. And yes, I get why what has been proposed upstream is better in the long term, and if I had such a use case I personally wouldn't care about what technical solution is used in the background (whether keyscript or something else), and I wouldn't complain if I had to change things on upgrade because of some new solution, but if I look at the time scales involved, it seems very unreasonable to me to say "in a couple of years your use case will be supported again" - and I think that breaking very legitimate use cases without a sensible recourse would be reason enough to say "well, let's support it at least until we have a better solution available". Regards, Christian [1] http://lists.freedesktop.org/archives/systemd-devel/2012-July/005835.html [2] http://lists.freedesktop.org/archives/systemd-devel/2015-April/031173.html [3] http://lists.freedesktop.org/archives/systemd-devel/2014-July/020880.html
Attachment:
signature.asc
Description: OpenPGP digital signature