Support for Flatpak secrets portal on Linux

[mak448a]

When I tried to package an app for Flatpak on Linux, it failed to access the system keyring because Flatpak packages are sandboxed. If it's not too much hassle, would it be possible to add libportal support?

Relevant links
https://flatpak.github.io/xdg-desktop-portal/docs/doc-org.freedesktop.portal.Secret.html
https://flatpak.github.io/xdg-desktop-portal/docs/convenience-libraries.html

[ntninja]

Flatpak runtimes have libsecret available which handles the absence of org.freedesktop.SecretService by using said portal. Does the application work if you run it with --env=PYTHON_KEYRING_BACKEND=keyring.backends.libsecret.Keyring?

In any case, the mentioned portal only makes a crypt key available, so you won’t see any keys added to the system keyring unless you pass --talk-name=org.freedesktop.SecretService sandbox option, but it should still persist and load keyring items.

EDIT: Fix env value

[mak448a]

Flatpak runtimes have libsecret available which handles the absence of org.freedesktop.SecretService by using said portal. Does the application work if you run it with --env=PYTHON_KEYRING_BACKEND=keyring.backends.libsecret.Keyring?

Unfortunately it didn't run. If it helps, I'm using the KDE runtime for flatpak

File "/app/lib/python3.13/site-packages/keyring/backends/libsecret.py", line 52, in priority
  raise RuntimeError("libsecret required")
RuntimeError: libsecret required

Is there an extra dependency I need to include?

In any case, the mentioned portal only makes a crypt key available, so you won’t see any keys added to the system keyring unless you pass --talk-name=org.freedesktop.SecretService sandbox option, but it should still persist and load keyring items.

Thank you! I did not know that.

[ntninja]

Ok strange, I just checked and the 25.08 FreeDesktop platform environment contains:

1. The libsecret C library
2. The Secret GI typelib
3. The CPython 3.13 interpreter
4. But not the Python GObject bindings?

This seems like a platform bug.

It’s the import gi line of https://github.com/jaraco/keyring/blob/main/keyring/backends/libsecret.py that fails, all the other lines would work everything is there except the binding loader… Quite strange.

[ntninja]

And the 24.08 FreeDesktop platform contains CPython and the Python GObject bindings but not the libsecret C library or GI typelib…

Did some digging: Apparently PyGObject was dropped from the FreeDesktop Platform (and moved to GNOME Platform) because it is “too GNOME-y”, arguing that it’s not inline with FreeDesktop minimaliness goals:
https://gitlab.com/freedesktop-sdk/freedesktop-sdk/-/work_items/1844

I’ve added a comment asking to reconsider, but I doubt it will do anything.

[ntninja]

In any case, if you want to use libsecret to store the secrets locally in the app’s data directory, rather than the system keyring (or at least allow the option) then make sure your app is built with the pygobject Python library present. Supporting the Flatpak secrets portal directly in python-keyring would only mean using the Portal to query the encryption key to use to encrypt the secrets locally and store them in a local file – I think relying on libsecret to do this is probably the smarter way, since it will at least be consistent then.

[mak448a]

Does that mean if I somehow include pygobject in the yaml file, keyring will connect to libsecret?

[ntninja]

Yes, if you’re using flatpak-pip-generator add pygobject to the requirements list. Otherwise, try something like this (from the linked issue):

# Generated with flatpak-pip-generator --yaml pygobject
name: python3-pygobject
buildsystem: simple
build-commands:
  - pip3 install --verbose --exists-action=i --no-index --find-links="file://${PWD}"
    --prefix=${FLATPAK_DEST} "pygobject" --no-build-isolation
sources:
  - type: file
    url: https://files.pythonhosted.org/packages/07/4a/42b26390181a7517718600fa7d98b951da20be982a50cd4afb3d46c2e603/pycairo-1.27.0.tar.gz
    sha256: 5cb21e7a00a2afcafea7f14390235be33497a2cce53a98a19389492a60628430
  - type: file
    url: https://files.pythonhosted.org/packages/2b/58/d34e67a79631177e3c08e7d02b5165147f590171f2cae6769502af5f7f7e/pygobject-3.50.0.tar.gz
    sha256: 4500ad3dbf331773d8dedf7212544c999a76fc96b63a91b3dcac1e5925a1d103

[ntninja]

As expected there was a bad take on my request to include PyGObject, perfected by immediately locking the issue (wouldn’t be surprised if I was blocked too…):

It's included because they are part of libsecret not pygobject and none of them are specific to Pygobject or Python. They can work with a bunch of supported language runtimes. It doesn't mean we have to ship the glue or compilers for every one of those languages.

For the record: It is not the same since they do not ship runtimes „for every one of those languages” to begin with. The language runtime and typelib are both already there and there to stay. Just the gluecode that’s missing…

In any case, I argued with someone from the mclasen crowd and I wasn’t disappointed. All is as it should be… 😆

[mak448a]

Sorry to bother, but I tried adding pygobject and I can't seem to get it to work. I even added meson as a dependency to try to fix this error, but it still is not working. https://github.com/flathub-infra/vorarbeiter/actions/runs/24054844046/job/70158741816

[ntninja]

Using wheels is frowned upon for Flathub. I strongly recommend you adopt flatpak-pip-generator and (since you’re using packages with Rust dependencies) flatpak-cargo-generator.

Please take a look at how I packaged recent versions of Blink:
https://github.com/flathub/com.icanblink.blink

In particular the ”Maintainers” section of the README should point you at all the moving parts. Pay particular attention to the uses of the flatpak-pip-generator (which takes a requirements.txt from your source project as input). You’ll probably wanna copy the pypi-dependencies-fixup-rust.py file and update the list of Python packages that have a Rust dependency at the top (see README on how to use after adapting).