Split the package: polkitd <-> pkexec, JavaScript <-> PKLA

This combines two major changes that are both going to require a trip through NEW for new binary package names, to minimize NEW delays.

@biebl @mpitt @laney @bigon: does anyone want to take a look at this before I upload to NEW?

pkexec vs. polkitd

This is security hardening against vulnerabilities like CVE-2021-4034. If we can transition packages like NetworkManager and udisks to depend on polkitd instead of policykit-1, then not all systems will need to have pkexec installed, mitigating any setuid-related vulnerabilities that it might have.

After this change has passed through NEW, I intend to do the same split in unstable. We can get a head start by giving policykit-1 a Provides: pkexec and Provides: polkitd, if desired, so that dependent packages can start depending on those names.

JavaScript vs. .pkla

We have effectively been maintaining a fork of polkit 0.105 in unstable since 2013, and it's getting unsustainable.

The reason why we are stuck on 0.105 is that maintainers (primarily @mpitt and @biebl, I think) didn't want to move from .pkla to JavaScript as a format for authorization rules, for these reasons (if I understand correctly):

• philosophical: .pkla is declarative, the JavaScript rules are imperative and Turing-complete
• practical: mozjs is not an easy project to have as a dependency
• practical: the migration path from .pkla to JavaScript for sysadmins' local configuration is not obvious

It looks like at least the practical objection to mozjs is going to go away soon, because polkit upstream has added a code path for using duktape instead of mozjs. duktape is a much smaller JavaScript implementation (if mozjs is like Python, then duktape is more like Lua or TCL) and hopefully a lot more API-stable.

What I've done in this MR is to resurrect the .pkla backend as a compile-time option. Instead of taking 0.105 and backporting everything except JavaScript into it, I've taken the latest upstream release and forward-ported the .pkla backend: this is a much smaller patch series!

For experimental, I'm pretty sure the backend we want, at least in the short term, is "both", so that we can evaluate them both without needing additional trips through NEW. In particular, some sysadmins and package maintainers want the extra flexibility of the JavaScript backend, which can base authorization decisions on domain-specific facts about an action: for instance, you can set up policies so that members of group foobar can issue systemctl restart foobar.service, without being able to restart other services.

For testing/unstable, there are several possible routes forward to escape from our fork of 0.105. I would like to do something about this for bookworm: I don't think 0.105 has a future, and I don't want to continue to manage an increasingly ludicrous patch series to backport upstream's bug fixes into it.

Given the timeline of the Ubuntu 22.04 and Debian 12 release cycles, I think the best timeline for this is:

• Upload to NEW soon (within the next few days) and wait for the ftp team to perform the necessary rituals
• Also wait for Ubuntu 22.04 to freeze and stop syncing from unstable
• While we're waiting, discuss which of these plans we want to go with
• After the experimental version has escaped from NEW and the Ubuntu import freeze has happened, upload to unstable with whichever plan we decided on
• No longer have 0.105 in the Debian 12 and Ubuntu 22.10 releases
• Profit?

option: Only support .pkla in testing/unstable

We could disable polkitd-javascript in unstable, and only provide polkitd-pkla. All testing/unstable users will be using .pkla authorization policies, the same as in bullseye.

We'd still be responsible for maintaining the forward-ported .pkla backend, but that's less bad than being responsible for polkit 0.105 forever.

Packagers of anything that installs rules.d JavaScript rules (for example GNOME and Flatpak) will still be responsible for translating those rules into .pkla format (to the extent possible), and installing the Debian-specific .pkla version.

option: Move to JavaScript only

We could merge polkitd-javascript back into polkitd, making JavaScript rules support mandatory.

If we want a migration path from .pkla, we could repurpose polkitd-pkla into an add-on package that installs a JavaScript-based compatibility shim that will read .pkla policies and return an appropriate result from its JavaScript function. Fedora used to have a package that did this (perhaps it still does).

Or, we could just delete the polkitd-pkla package, write a NEWS.Debian entry announcing that .pkla rules are no longer supported and sysadmins should convert them into JavaScript. I believe a script exists that can read .pkla rules and output equivalent JavaScript, which we could install as an example.

Packagers of anything that installs rules.d JavaScript rules (for example GNOME and Flatpak) would no longer need to translate those rules into .pkla format, reducing Debian-specific work.

option: Let sysadmins choose

Or, we could do the traditional Debian thing, decline to make a choice, and provide both, as I have done in this proposed experimental upload. Sysadmins who want declarative rules and are OK with having less flexibility can install polkitd-pkla; sysadmins who want Turing-complete rules and extra flexibility can install polkitd-javascript. We can tweak the order of Depends in polkitd to select which one testing/unstable users get given during upgrades - in experimental I've gone for polkitd-javascript first, for feature parity with older experimental packages, but that doesn't necessarily need to be the case in testing/unstable.

We would still have to maintain the forward-ported .pkla backend.

Packagers of anything that installs rules.d JavaScript rules (for example GNOME and Flatpak) would still be responsible for translating those rules into .pkla format (to the extent possible), and installing the Debian-specific .pkla version.

If we take this option, and then decide at some point in the future that it is too much work, then we would still be able to transition to either of the others. (Realistically, I don't think we will want to maintain our forward-port of `.pkla indefinitely.)