We have been using various tweaks to make sandboxed Qt apps well integrated into the system. For KDE Plasma integration, we have been allowing access to kdeglobals config file, where we store the most common configuration, like used icon theme, widget style, etc. A similar approach has been used by Gnome, where they need to allow access to DConf, otherwise applications will not be able to read default system configuration. These tweaks have been usually set in the runtimes and applications using these runtimes automatically inherited all the needed permissions during the build. This has some weak spots, because changing permissions in the runtime requires all applications to be rebuild to pick up the changes, or applications not using the runtimes at all had to allow all the access themself and really not everyone knows what everything needs to be enabled.
This will change with upcoming release of xdg-desktop-portal (version 1.2), which will bring new portal to solve this problem (for both Flatpak and Snap). There is new “Settings” portal, allowing apps to request various configuration from the sandbox, without need to have access outside (kdeglobals, dconf). For Gnome configuration, this has been built in directly in xdg-desktop-portal so there is no need for specific backend support. For KDE Plasma configuration, we have our specific code reading kdeglobals config file in xdg-desktop-portal-kde. This support has already been merged and will be part of Plasma 5.15 release in February. To make applications automatically ask for this configuration through the portal, instead of reading kdeglobals/dconf, I added support to both widely used Qt QPA plugins. For applications running under Plasma we have now this implemented in plasma-integration plugin. This support will be also released with Plasma 5.15 in february. For Qt apps running in Gnome, I added this support into QGnomePlatform, which has been released already some time ago and is already available in Flathub.
Hopefully with all of this released soon and more widely used, we can slowly start removing all the hardcoded permissions for both dconf and kdeglobals config file in the runtimes.
Presumably this will affect apps distributed using appimage as well?
This could be a good opportunity to introduce a standard location for finding root ssl store locations. It is not desirable to have every app either include it’s own root ca store or to have a list of some common distribution locations.
This will not affect apps distributed as appimage, because appimage doesn’t use portals.
Flatpak already shares ssl root certs with the host by using the p11-kit proxy (assuming everything is set up correctly for this in the os, but at least it works in e.g. fedora). Basically, anything that uses pkcs#11 modules in the sandbox load a module that talks with p11-kit-server on the host, exposing the ca roots. This only works for apps that use libraries that support pkcs#11 modules though, so no openssl atm, only gnutls and nss.
Since Flatpak apps read kdeglobal config they don’t load icons if the system icon theme is not available in Flatpak. Is there a way to solve this for icons and eventually for other assets mentioned in system config?
Flatpak actually exposes icons (as well as fonts) from the host system, so the icons themselves should be there. Not sure about the icon theme setting itself though.