feat: portals configuration file; use `gnome-keyring` for Secrets portal

[jokeyrhyme]

I noticed that I couldn't run apps like Fractal ( https://flathub.org/apps/org.gnome.Fractal ) in COSMIC, because there's no COSMIC implementation of the Secret portal ( https://flatpak.github.io/xdg-desktop-portal/docs/doc-org.freedesktop.portal.Secret.html ) and the built-in implementation in gnome-keyring specifically only suggests to xdg-desktop-portal that it should be used in GNOME ( https://gitlab.gnome.org/GNOME/gnome-keyring/-/blob/master/daemon/gnome-keyring.portal )

Without a recommended per-desktop portal configuration file, xdg-desktop-portal can only rely on those UseIn= fields to figure out which implementations to use for which portals

The UseIn= field in *.portal files is deprecated in favour of per-desktop portal configuration files: https://flatpak.github.io/xdg-desktop-portal/docs/backends.html (although we probably shouldn't remove the UseIn= field for now)

This PR adds such a per-desktop- portal configuration file, and specifically asks xdg-desktop-portal to rely on gnome-keyring 's implementation of the Secret portal, and my testing shows that Fractal now works as expected

I'm happy to change this to a different Secret portal implementation as necessary, but I'm not currently sure what the plan is for keyrings under COSMIC

[Quackdoc]

As a curiosity, how do applications behave if gnome-keyring is missing? Will it just be the same as before?

[jokeyrhyme]

As a curiosity, how do applications behave if gnome-keyring is missing? Will it just be the same as before?

I just tested with org.freedesktop.impl.portal.Secret=foo; and I observe the previous behaviour (applications almost instantly receive errors rather than expected results from the Secret portal)

My understanding is that the flow is something like this:

1. the cosmic-portals.conf file in this PR tells xdg-desktop-portal to use the "gnome-portal" backend for the Secret portal
2. xdg-desktop-portal looks for /usr/share/xdg-desktop-portal/portals/gnome-keyring.portal (the *.portal file with "gnome-portal" as the base name)
3. that file ( https://gitlab.gnome.org/GNOME/gnome-keyring/-/blob/master/daemon/gnome-keyring.portal ) tells xdg-desktop-portal to send the Secret request to the D-Bus service with ID "org.freedesktop.secrets"
4. if there's a service already running that is connected to the D-Bus session and asking to receive messages addressed to "org.freedesktop.secrets", then D-Bus forwards those messages as desired, otherwise...
5. D-Bus looks for /usr/share/dbus-1/services/org.freedesktop.secrets.service (the *.service file with "org.freedesktop.secrets" as the base name)
6. that file ( https://gitlab.gnome.org/GNOME/gnome-keyring/-/blob/master/daemon/org.freedesktop.secrets.service.in ) tells D-Bus to execute gnome-keyring-daemon
7. gnome-keyring-daemon connects to the D-Bus session and asks to receive messages addressed to "org.freedesktop.secrets"

So, really, all I've manually tested so far is that a missing file at step 2 causes the Secret portal request to fail, and that getting all the way to step 4 or 7 causes the Secret portal request to succeed

In theory, other failures could happen at steps 3, 5, and 6 depending on missing registrations/files and/or bad values in files, but I've not tested those cases

[jokeyrhyme]

Interestingly, KDE's Secret implementation (not yet merged) follows the GNOME pattern here, with the portal implementation hosted within the keychain service and not mediated through xdg-desktop-portal-kde: https://invent.kde.org/frameworks/kwallet/-/merge_requests/67

Perhaps once that is merged, we could raise a future PR to set org.freedesktop.impl.portal.Secret=gnome-keyring;kwalletd;, if it was expected that COSMIC users would prefer to rely on KDE's implementation and not have GNOME's lying around

Although, I'm guessing eventually COSMIC might have it's own implementation that doesn't rely on GNOME or KDE

[Drakulix]

Nice to see that PR, we are currently lacking a bunch of protocols, so I wanted to add this file anyway.