Skip to content

Entries tagged as fail

Related tags

Polkitd (Policy Kit Daemon) in Trixie ... getting rid of "Authentication is required to create a color profile"

Posted by Daniel Lange on
Debian

On the way to Trixie, polkitd (Policy Kit Daemon) has lost the functionality to evaluate its .pkla (Polkit Local Authority) files.

$ zcat /usr/share/doc/polkitd/NEWS.Debian.gz 
policykit-1 (121+compat0.1-2) experimental; urgency=medium

  This version of polkit changes the syntax used for local policy rules:
  it is now the same JavaScript-based format used by the upstream polkit
  project and by other Linux distributions.

  System administrators can override the default security policy by
  installing local policy overrides into /etc/polkit-1/rules.d/*.rules,
  which can either make the policy more restrictive or more
  permissive. Some sample policy rules can be found in the
  /usr/share/doc/polkitd/examples directory. Please see polkit(8) for
  more details.

  Some Debian packages include security policy overrides, typically to
  allow members of the sudo group to carry out limited administrative
  actions without re-authenticating. These packages should install their
  rules as /usr/share/polkit-1/rules.d/*.rules. Typical examples can be
  found in packages like flatpak, network-manager and systemd.

  Older Debian releases used the "local authority" rules format from
  upstream version 0.105 (.pkla files with an .desktop-like syntax,
  installed into subdirectories of /etc/polkit-1/localauthority
  or /var/lib/polkit-1/localauthority). The polkitd-pkla package
  provides compatibility with these files: if it is installed, they
  will be processed at a higher priority than most .rules files. If the
  polkitd-pkla package is removed, .pkla files will no longer be used.

 -- Simon McVittie   Wed, 14 Sep 2022 21:33:22 +0100

This applies now to the polkitd version 126-2 destined for Trixie.

The most prominent issue is that you will get an error message: "Authentication is required to create a color profile" asking for the root(!) password every time you remotely log into a Debian Trixie system via RDP, x2go or the like.

This used to be mendable with a .pkla file dropped into /etc/polkit-1/localauthority/50-local.d/ ... but these .pkla files are void now and need to be replace with a Javascript "rules" file.

The background to his is quite a fascinating read ... 13 years later:
https://davidz25.blogspot.com/2012/06/authorization-rules-in-polkit.html

The solution has been listed in DevAnswers as other distros (Fedora, ArchLinux, OpenSuse) have been faster to depreciate the .pkla files and require .rules files.

So, create a 50-color-manager.rules file in /etc/polkit-1/rules.d/:

polkit.addRule(function(action, subject) {
    if (action.id.startsWith("org.freedesktop.color-manager.") && subject.isInGroup("users")) {
        return polkit.Result.YES;
    }
});

and run systemctl restart polkit.

You should be good until polkit is rewritten in Rust.

Thunderbird gpg key import

Posted by Daniel Lange on
Open Source

Thunderbird, srsly?

5MB (or 4.8MiB) import limit. Sure. My modest pubring (111 keys) is 18MB. The Debian keyring is 28MB.

May be, just may be, add another 0 to that if statement?

So, until that happens, workarounds ...

Option 1:

Export each pubkey into a separate file. The import dialog allows to select them all in one go. But - of course - it will ask confirmation for each. So prepare some valerian tea.

gpg --with-colons --list-public-keys | grep ^pub | cut -d : -f 5 | xargs -I {} -n 1 gpg -ao {}.pub --export {};

Option 2:

Strip all the signatures, so Thunderbird gets a smaller file to chew on. This uses pgp-clean from signing-party.

gpg --with-colons --list-public-keys | grep ^pub | cut -d : -f 5 | xargs pgp-clean -s >> there_you_go_thunderbird.pub

Option 1 will retain the signatures on individual keys, Option 2 will not.

Your software stores are a bad idea

Posted by Daniel Lange on
InternetIT

There is significant effort involved to get your apt or dnf commands always have a consistent set of servers to talk to.

That's why running separate "software stores" is a bad idea:

Snap software store down

That way more admins need to learn how to run high availability services for dubious business opportunities to "later" monetize services. Services that nobody cares to pay for and thus opportunities that never materialize. But every company wants to find that out again. Because if Apple could do it, why shouldn't Canonical be able to do it? $$$!1!!

So, can't update Firefox on Ubuntu 22.04 right now.

At least there is https://status.snapcraft.io/:

Snap incodent / monitoring status page

So I can check back tomorrow if I can update my web browser ...

Update

09.11.2022 12:15 CET

The Snapcraft distribution system seems quite flaky, this is the downtime log:

Log of (frequent) Snapcraft outages

Bonus points for the bad client side implementation:


dl@laptop:~$ sudo snap refresh
All snaps up to date.

# ^this is a lie, just close Firefox and ...

dl@laptop:~$ sudo snap refresh
firefox 106.0.5-1 from Mozilla** refreshed
 

Postscriptum

GNOME and KDE join forces to sink another 100 .. 200k USD into the void:

https://github.com/PlaintextGroup/oss-virtual-incubator/[..]/proposals/flathub-linux-app-store.md

This is an application for funding from Schmidt Futures, which is one of the investment (as in philanthropic) funds from Eric Schmidt, former Google CEO.

The application text is worth reading. Very entertaining.

Robert McQueen (GNOME, Flathub) wrote on 07.03.2023 that the PlaintextGroup/Schmidt Futures application was denied for 2023.