Allow harbour apps to have settings

[monich]

This patch allows harbour apps to install its settings .json file to /usr/share/jolla-settings/entries and install translations to /usr/share/translations. Everything else (including settings qml files) can remain in the app specific area as long as .json file points there.

[martyone]

LGTM but @jlehtoranta should approve. (Is the blank line necessary?)

[pvuorela]

This allows third party code run as privileged, not a good thing. Also .json format should be cleaned up a bit by removing unused obsolete things.

[monich]

I fail to see how this would make the platform less secure than it is now. Lack of support for app settings is pushing developers from Jolla store to openrepos which is not a good thing, IMO.

[pvuorela]

Currently we don't run third party code as privileged anywhere so it's definitely worse from security point of view. Also don't want to commit on supporting this api as stable. App settings are possible anyway, just not accessed via settings app.

[ghost]

Sailfish is based around integration with all messages available from the Messages application, all calls available from Phone, all settings available from Settings. With only official Jolla (and Android) application settings available from Settings, the Apps section is empty, useless and amateuristic, and has been this way for almost three years now.

[martonmiklos]

Any updates on this one?
Would it be possible to mark the Harbour uploaded apps json files to run the QML less privileged?
I know it would be require a system upgrade, and it would bring up questions about supporting the older systems, but the current situation breaks all the three basic UI principle listed here:
https://sailfishos.org/wiki/User_Interface_Development

Namely:

• Logic
• consistency
• intuitive

[pvuorela]

QML run less privileged is not an easy thing. Properly done it would require a separate process to be embedded running third party settings UI. So unfortunately no updates as of now.

[martonmiklos]

@pvuorela
If we could figure out a way how to run the QML less privileged do you have time/+spirit to push this whole thing out?

I would propose to create a list of the action items for solving this issue.

• 1. Figure out how to lower the privilege of the Harbour uploaded app's settings pages and implement it to the ApplicationsGridView.
• 2. Figure out how to modify the ApplicationsGrid to determine which privilege level does it need to run the app settings page.
     I see one possible option here. (Let me know if you have a different approach.)
     Introduce a separate folder for the Harbour uploaded app's settings pages. Lets say /usr/share/jolla-settings/entries-harbour. The entries from this folder shall be run with lower privileges.
     On older systems these settings pages could not be used. I do not think that these unused entries files should be considered as a security risks in this case. App developers would need to care for "pre-settings-page-supporting" OS versions either or other ways.

[pvuorela]

This has been discussed long time already and it's not a simple thing to fix. Problem is that to run qml securely there needs to be a separate non-privileged process executing it. It there's a separate process running, the resulting window needs to be embedded into settings. Either as settings being a wayland composer or then Lipstick handling the two windows as one.

[DylanVanAssche]

I was wondering if a quick solution would be like this:

• Go to Settings
• Apps
• Tap on a third party app
• Instead of opening a settings page, launch the app as nemo with some kind of argument

The developer can launch it's app then directly with it's settings page as nemo.
It's not ideal because you lose the functionality of the Apps Settings Page but it's better then the current implementation.

[Thaodan]

Have you thought about restricting the qml imports to settings pages to the absolute minium and check the dconf path they write and limit it to a name like the appname?

[pvuorela]

Have you thought about restricting the qml imports to settings pages to the absolute minium and check the dconf path they write and limit it to a name like the appname?

Yes. Those are easy to bypass and more or less impossible to prevent without modifying qml engine.

[Thaodan]

Then I have no idea except something like json file with a description and a dconf var for each settings. Its really a shame to let such a thing stay unfixed.