indicating the service is available but I’ve got no wallets defined yet.
If it returns an error like:
Error org.freedesktop.DBus.Error.ServiceUnknown: The name is not activatable
that means the kwallet6 service is not available and you probably need to install the necessary kwallet6 rpm on to your system. A system without KDE desktop installed may not have this service.
But like I said, I get an error from Signal even on a system where I have confirmed the kwallet6 service is operational.
In fact, variations of the command above serves as a pattern for flathub dbus service permission problems. You should be able to reproduce the dbus method call that fails on your own in a terminal any time this happens in the future. You have the method information in the debug output you posted. So you should be able to use a variation of dbus-send to confirm the services works outside of flatpak’s sandbox.
Flatpaks ideally are suppose to use the portals system.
And there is a portal for secrets. The fact that signal is reaching out to a specifically to kwallet dbus service is very odd. it should be using the Secrets portal.
Every desktop specific dus service that a flatpak reaches for is an exception that noone can adequately plan or test for. Collectively we are not in a place yet where we can enforce strict use of portals by application developers.
Wait no, that’s wrong. flatpak remotes could actually enforce this as part of distribution policy. And users can also choose to enforce strict sandboxing as well. It’s a tradeoff between the level of sandbox security and application usability given the present state of application development. All of that is to say.. portals are intended to be the preferred desktop agnostic way to deal with access to information across the sandbox boundary.
It’s very hard for us to plan and test for permission exceptions outside of the defined portal system. What might be possible to do is ensure that the portals are working as expected. And because different desktops may implement the portals using their own components. Doing this becomes a desktop by desktop process. The portals are the closest thing to an API contract that we have between the host OS providing the desktop and flathub (or any flatpak remote) as an app store.
If all the portals are working, then its likely the host OS desktop is providing what it’s agreed to provide when choosing to include flatpak support tooling.
Now unfortunately I’m not currently aware of a self-verification tool that Fedora provides that users can use in their desktop of choice. There is a flatpak at flathub for a tool, which is itself listed as potentially unsafe, because it doesn’t use the portals. But pointing users to that feels… a little wrong. I mean I shouldn’t have to step outside of the portal system to test that that portal system is working right?
I feel like there is a gap here maybe. I’d like to get to the point where a Fedora user who cares can enable strict sandboxing and rely entirely on the portal system and live within the narrow application space that creates. And I want them to be able to self-verify that the portals are working.. regardless of the desktop they are using, with the understanding that different desktops will use different components to service the portals.
I’d actually like to be that user on occasion and report back on what the fully sandboxed landscape looks like and the progress being made towards a day-to-day usable fully sandboxed environment as adoption of portals increases.
