As discussed on the mailing list, I very much agree that we have a problem and the tooling we currently have is user-unfriendly and not helpful at all. The issue has been known for a long time and has slowly been becoming more of a problem as people use a user account + privilege escalation to do administrative tasks instead of logging in as root. Nevertheless, the proposed solution is just taking the easiest way out instead of figuring out how to resolve the problem without creating a regression.

-1

This issue will be discussed during today's meeting.

This was discussed during today's FESCo meeting:
ACTION: zbyszek to set up a meeting with Change owners to discuss alternative approaches

@zbyszek has there been any movement here?

We starting discussing this internally, but we want Lennart's input. He's on leave currently, but should be back in February.

Given where we are in the F36 schedule (specifically, ~3.5 weeks from the Beta freeze, which is the contingency deadline for this proposal), should this be re-targeted to F37?

Yeah, as the person who initially brought this up, let's retarget this for F37

Yeah, as the person who initially brought this up, let's retarget this for F37

Done!

@salimma do we have an update on this?

@salimma @ngompa @davdunc Do we have an update on this?

@salimma @ngompa @davdunc Do we have an update on this?

It's been several months without an update on this, and at least three requests. I propose FESCo reject this proposal and let the owners re-submit when they're ready.

I surfaced this to @zbyszek a few weeks ago and he mentioned there's still interest in sorting this problem out in systemd, but a solution still needs to be designed and implemented.

I meant to reply here…

We have a rough plan how to handle this:
- systemd is growing a generic mechanism to pass "credentials" to the initramfs system by attaching additional initramfs images which are then unpacked and placed in the appropriate directory in tmpfs. (Somewhat like the early cpu microcode which is handled by the kernel, but this is consumed in userspace.)
- on systems where TPM2 is available, those credentials are bound to the local machine and kernel version (most likely, the exact update lifecycle is TBD)
- on systems without a TPM2, there's no encryption of the credentials, but this still should be OK, because modern hash methods like yescrypt and argon should be sufficient to thwart offline attacks on passwords.
- when building/installing an initrd, we'd attach passwords for users in %wheel as "credentials".
- users can authenticate using their password. The mechanism for this needs to be implemented, most likely as a PAM module.

Overall, I think this gives a fairly nice story: authentication is convenient, but the system is secure against offline attacks. Most of the pieces are in place, in particular the hard ones, but the PAM module and integration with kernel-install remains TBD. We plan to work on this, but I can't give a timeline yet.

We plan to work on this, but I can't give a timeline yet.

For the purposes of the Changes process, should we consider this proposal withdrawn and you'll re-submit when the plan is more firm? Or should we hold this in limbo? (The answer, I think, should depend on how much the proposal as it currently exists will remain unchanged)

@salimma @ngompa @davdunc @zbyszek should I consider this proposal withdrawn until the timeline is available?

Processing the change as withdrawn as agreed in today's FESCo meeting

Closing without the "pending announcement" tag, since it's a withdrawal not a decision.