I don't like the UI/UX of needlessly asking for passwords, but given this comment I need more info.

For flatpaks, aren't they entirely self contained? If so, I'm not expecting they can modify the mandatory access control regime beyond a specific flatpak. True/false? I expect admin/wheel user's flatpaks to be --system installed by default, without requiring a password to add or remove. And a standard (unprivileged) user's flatpaks should be --user installed by default, and likewise not require a password to add/remove.

But if the scope of the change includes RPM, I can see how that might be a problem. I regularly see completely different package listings for add and remove, so it's already asymmetric.

For flatpaks, aren't they entirely self contained? If so, I'm not expecting they can modify the mandatory access control regime beyond a specific flatpak. True/false? I expect admin/wheel user's flatpaks to be --system installed by default, without requiring a password to add or remove. And a standard (unprivileged) user's flatpaks should be --user installed by default, and likewise not require a password to add/remove.

Yes, but PackageKit does not support flatpaks. GNOME Software uses libflatpak to handle flatpaks.

But if the scope of the change includes RPM, I can see how that might be a problem. I regularly see completely different package listings for add and remove, so it's already asymmetric.

This would only affect RPMs.

Keep in mind the scope of this change is very limited. This only matters for local admin users who leave their systems unlocked, allowing an attacker to gain physical access to the system. This is a really niche problem to defend against. If I leave my laptop unlocked at a conference, I doubt anybody would touch it, but if they do I would be more worried about them messing with my files than with them uninstalling RPMs.

(I have a broader-scoped proposal as well: eliminate the need for active admin users to type the admin password for all polkit rules distro-wide. I think we could do this using a JS rule. Prompting admin users to repeatedly type their passwords after they have already authenticated is more security theater than actually useful....)

This would only affect RPMs.

OK. If I use dnf for this, I always have to authenticate. This industry has long been in the paradigm where there is no inherent trust that the requester is really the local admin user, hence that user is always prompted for authentication (within the sudo 5 minutes timeout). All security problems are niche problems, aren't they? If all of us reverted to root only workflow, a tiny number of us are going to get pwned in a year's time. That doesn't mean it's a good idea, right?

I guess I'm equally concerned about Software being able to install RPMs, as well as remove them, if the supposed local admin hasn't "recently" been authenticated as such; in particular if they are RPMs that aren't Fedora signed.

Anyway, I am not a computer security professional. I'm disinclined to second guess FESCo or the Fedora security team without a really compelling reason other than "this ui/ux is annoying". What's the alternative? Does favoring flatpaks over RPM obviate the problem?

Approved: local active admin users should not be prompted to authenticate in order to uninstall signed RPMs.

New MR: Allow admin users to remove packages without password prompt

Well @ngompa, what do you want to do here?

Clearly Richard is still opposed, and now Matthias too. I notice they are no longer arguing that the password prompt is important for security, though, but as more of a "are you sure you want to do this?" step....

So Neal, what do? Install a gschema override downstream?

So Neal, what do? Install a gschema override downstream?

If you really want this, then yeah.

I see @rhughes has been maintaining the downstream package as well, so I'm hesitant to add the patch without his approval. At the same time, this change is approved by the WG, and the arguments against that were posted in the upstream PR seem quite weak tbh.

@rhughes, are you OK with this happening downstream? Or would you rather discuss further at a future WG meeting?

the arguments against that were posted in the upstream PR seem quite weak tbh

I already gave you my thoughts on why I think it's a bad idea. What you're basically asking for is permission to ignore my opinion and do it anyway. I won't stop you from doing it downstream, but I will make it very clear that when it blows up in the future it's not my problem to deal with.

OK, I'll add the patch downstream then, since this change has already been approved by the Working Group.

this change has already been approved by the Working Group.

BTW, the Working Group takes responsibility for its policy decisions, so it's not going to be your problem if it blows up. That said, I'm extremely confident it won't blow up.

Fixed.