Support XDP Desktop Portal proxy resolver

[janbrummer]

In order to make use of libproxy in a flatpak environment, we need to support XDP proxy resolver. Add support.

@DimStar77 Could you please have a look and review this one?

[janbrummer]

Check possibility of adding a flatpak test

[janbrummer]

https://gitlab.com/freedesktop-sdk/freedesktop-sdk/-/blob/master/elements/components/libproxy.bst?ref_type=heads

needs to be changed to enable curl and duktape for automatic proxy support.

[janbrummer]

@mcatanzaro In case you have some time, could you please have a look at this PR? Works fine in my test flatpak app, but maybe i missed something important....

Next step would be to adjust freedesktop runtime

[janbrummer]

https://gitlab.com/freedesktop-sdk/freedesktop-sdk/-/blob/master/elements/components/libproxy.bst?ref_type=heads

needs to be changed to enable curl and duktape for automatic proxy support.

Recommended options:

                "-Dconfig-env=false",
                "-Dconfig-kde=false",
                "-Dconfig-gnome=false",
                "-Dconfig-sysconfig=false",
                "-Dconfig-xdp=true",
                "-Dintrospection=false",
                "-Drelease=true",
                "-Ddocs=false"

[mcatanzaro]

The freedesktop runtime is not only used by flatpaks. It's also used by host systems, like GNOME OS, and also for images for embedded systems. So a "disable everything" approach doesn't make sense. We should decide which backend to use at runtime, not compile time.

[mcatanzaro]

I think you should enable it by default.

[mcatanzaro]

Hm, thorny question: what priority should it have, relative to the other settings providers? If this is not the highest-priority provider, then the other providers will get used instead and possibly return bad results because libproxy doesn't realize it's not running on the host system, right? But if this is the highest-priority provider, then all the other non-Windows providers are suddenly no longer getting tested anymore, because almost everyone will have xdg-desktop-portal installed on Linux. And libproxy will probably be slower, too, since it has to rely on sync D-Bus calls.

Hm, another possible problem: the proxy resolver portal could itself be using libproxy, and in practice it will whenever running outside GNOME. So if all backends are always enabled at build time, then this will turn into an infinite loop where libproxy and the portal both try to look up proxy settings from each other. OK, proposed solution: libproxy should check if it's running under flatpak or snap, and only use the portal if so. That should work, right?

[janbrummer]

Hm, thorny question: what priority should it have, relative to the other settings providers? If this is not the highest-priority provider, then the other providers will get used instead and possibly return bad results because libproxy doesn't realize it's not running on the host system, right? But if this is the highest-priority provider, then all the other non-Windows providers are suddenly no longer getting tested anymore, because almost everyone will have xdg-desktop-portal installed on Linux. And libproxy will probably be slower, too, since it has to rely on sync D-Bus calls.

Hm, another possible problem: the proxy resolver portal could itself be using libproxy, and in practice it will whenever running outside GNOME. So if all backends are always enabled at build time, then this will turn into an infinite loop where libproxy and the portal both try to look up proxy settings from each other. OK, proposed solution: libproxy should check if it's running under flatpak or snap, and only use the portal if so. That should work, right?

At the moment every plugin is checked, but config-env does have an higher priority. In case no configuration is found, the plugin returns nothing at all. Only iff all plugins returned nothing, px manager will add a direct rule as a global return value.

The config-xdp plugin already checks whether it is running in a flatpak environment and disables itself in a non-flatpak environment. All the other plugins are still working and that might also be legit as flatpak permission can transfer e.g. access to sysconfig or dconf or kde configuration files..

So that means that the order in a flatpak environment would be the same as in a non flatpak environemnt:

• config-env
• all the rest

Sounds good to me, right?

[janbrummer]

Recommended options:

                "-Dintrospection=false",
                "-Drelease=true",
                "-Ddocs=false"

[mcatanzaro]

Yeah OK, sounds good, no problem then. Except you'll want to use the portal under snap too, not just flatpak.

[janbrummer]

Yeah OK, sounds good, no problem then. Except you'll want to use the portal under snap too, not just flatpak.

Thanks, I've added a snap check as well.

[janbrummer]

https://gitlab.com/freedesktop-sdk/freedesktop-sdk/-/issues/1717