Hi, > TL;DR...
Yes, I knew about that risk. But shorter messages have failed to draw attention to a supposedly "important" bug. I expected that the original patch was good to go, but I somehow forgot that a 720+ day old patch is subject to bitrot. Please correct me if I'm wrong, but wouldn't we now need (at least) three patches now to fix this problem? * We have to patch src/sulogin-shell/rescue.service.in and src/sulogin-shell/emergency.service.in in version 232 (the version in stretch). * We have to patch src/sulogin-shell/systemd-sulogin-shell.in in version 234 (the version currently in stretch-backports and buster). * We have to patch src/sulogin-shell/sulogin-shell.c in version 235 (the version currently in sid). I can probably find some more time in the coming week to contribute to a solution. I do have a few comments in advance: 1) I want to stress that I believe that the only correct solution is an unconditional --force. Patches that do just that do not reduce the boot security of any plausible installation in any way, and are also much easier to implement correctly. The points below can be mostly ignored if we do this. 2) The "You are in rescue/emergency mode" message has to change depending on the setting: the mentioned login prompt won't be there when using --force. 3) I think it's much simpler to build two separate binaries (one that forces, one that doesn't) instead of dynamically adjusting a command line and a message based on the value of an environment variable. 4) If you think it's likely (not merely possible) that supplying other options to sulogin will become necessary, then I think it makes more sense to pass sulogin-shell's arguments to sulogin and use getenv() to decide the label of the mode (rescue/emergency/potato), rather than the other way around. Regards, Stijn van Drongelen _______________________________________________ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
