Application data dir, sailjail and OrganizationName

Store QA
#10

Hi, and thanks for the questions!

Yes, now is the time to start experimenting. Actually, the new Harbour rules are already in place. So you can already submit apps with sandboxing profiles to Harbour, but the profiles won’t have any effect yet. And the organization name does not have to start with harbour :slight_smile:

For those who are better at reading code than English, here’s the commit, defining the new rules: https://github.com/sailfishos/sdk-harbour-rpmvalidator/commit/9988aa5a06ea3d30193e7548a12016d004d4e353

As for migration - yes, we definitely should write some kind of guide. For now, I think the best thing to do is to just move the configuration files from the old directory to the new. It’s easy to do as your applications are not yet sandboxed.

1 Like
#11

Ok, I will need to write some migration code. It is easy. But when I add this configuration to desktop file:

[X-Sailjail]
Permissions=Internet;Audio;Location;RemovableMedia;Documents;Downloads
OrganizationName=cz.karry.osmscout
ApplicationName=harbour-osmscout

Sailjail refuses it:

[defaultuser@Xperia ~]$ /usr/bin/sailjail  -p harbour-osmscout.desktop /usr/bin/harbour-osmscout 2>&1 
[sailjail] ERROR: Invalid value harbour-osmscout for ApplicationName
[defaultuser@Xperia ~]$ version 
Sailfish OS 4.2.0.21 (Verla)

I may change app name it to OSMScout, but does it comply with Harbour rules? It will not match to HARBOUR_APP_NAME (as used in FAQ) then and it is kind of weird. It is necessary to match with name set by QCoreApplication::setApplicationName ?

#12

Yes, changing the name to OSMScout complies with the Harbour rules. The FAQ needs updating - I’m quite sure we have an open task about that. It is necessary to match the application name set in the code, but then again you don’t have to set it in the code. If you use libsailfishapp (like most Sailfish apps should), it will take care of setting the application name.

#13

TIL: You need to remove X-Nemo-Application-Type=silica-qt5 or it will try (and fail) to boost sailjail itself.
Edit: only when testing with sailjail as the executable.

#14

Thanks for your support. I made simple migration utility (c++/Qt), everyone can use it as inspiration: https://github.com/Karry/osmscout-sailfish/pull/270/commits/c4c4211e2c5f273a306ae5fd58cccbe3fe277e16

@vige I have last remaining issue. When I am using QSettings instance for storing application configuration (created with default constructor), it is using ~/.config/<organizationName>/<appName>.conf file, but Sailjail is creating and whitelisting ~/.config/<organizationName>/<appName> directory. Is there any global possibility to say QSettings to use config file in different directory? Or Sailjail to whitelist specific file?

2 Likes
#15

To me that sounds like a bug, and I filed it as such in our internal bug tracker.

1 Like
#16

So, I setup organization name (cz.karry.osmscout), prepare code for migration of configuration and new release was rejected, because:

Your application is creating misnamed folder under /home/defaultuser/.cache/cz.karry.osmscout and /home/defaultuser/.config/cz.karry.osmscout and /home/defaultuser/.local/share/cz.karry.osmscout. Folder name must be harbour-osmscout.

We will need some time (at least one application release) when applications will be using new locations, but still be running without sailjail - to make migration possible. Is there any plan when Harbour rules will be updated?

#17

Yes there is. I’m literally working on it right now. I hope we can get the new rules in place within a week. Of course, one should always expect the unexpected, and this is kind of busy week for us, so things might get delayed a bit, but anyway soon™ :slight_smile:

3 Likes
#18

Is it legal to set Orga name to “.”?

That would work around the problem that most(?) apps don’t use an orga name in their paths, and just have .foo/appname locations.

1 Like
#19

…and the new rules should be in place now. Please test and report if you still have issues uploading your apps which are using the new locations.

#20

You could make up Org name - it doesn’t have to be something available. Similar issue is with Flathub/Flatpak for example.

#21

Thank you for updating the Harbour FAQ, but the config files are not covered yet. As I wrote previously, QSettings is using ~/.config/<organizationName>/<appName>.conf file, not ~/.config/<organizationName>/<appName> directory.

#22

I somewhat disagree - the config files are covered. It just isn’t mentioned that QSettings by default uses path which isn’t compatible with Harbour rules. I would consider this a bug in QSettings, but we haven’t really decided yet what to do about it. In any case, for the time being, I suggest using QSettings by giving it a full path to the file.

#23

Could you make an official announcement with all those suggestions when this is the time? (when 4.3 is released I suppose)
It would be cool to have a quick FAQ and concrete examples, covering that kind of things:

  • The fact that we need to change our app name (or actually, set one, until now it just defaulted to harbour-myapp)
    • Also the recommended format for the organizationName
  • The fact that the renaming will make all apps losing their cache/config since the paths will change
    • Maybe how we can avoid that without asking users to copy the directories manually?
  • What exact change do we need to make for this QSettings “bug”
1 Like
#24

Taking into account that QSettings have been always using this path, I wouldn’t consider it as a bug and it seems to me that Harbour rules would have to account for it. Not that we can file QT BUG and hope for it to be fixed, right?

3 Likes
#25

Sure thing, will do!

2 Likes
#26

@vige, karry’s statement

contradicts your statement in your blog entry about the firejail-based sandbox implemented for SailfishOS:

with the default profile you will get ~/{.local/share,.config,.cache}/packagename directories mounted inside the sandbox.

I hope I am misunderstanding something, because @karry’s observation means the all applications (which use a ~/{.local/share,.config,.cache}/packagename directory; that is almost every app) will cease to run on SailfishOS ≥ 4.4 without being adapted.

Thus my concern is, if the statement “the default profile will mount ~/{.local/share,.config,.cache}/packagename inside the sandbox” still is conformant to Jolla’s plans / implementation?

Migrating configuration and data files for sandboxed apps
#27

Yes it is, no need to worry.

1 Like
Migrating configuration and data files for sandboxed apps
#28

I hope this helps: Migrating configuration and data files for sandboxed apps

#29

@vige, I cannot see that your new thread you are linking to answers @Sthocs’ questions, even though you replied “Sure thing, will do!” and now replied to this post of yours that you “hope this helps”.
Hence answers to @Sthocs’ questions for proper guidance to Jolla’s sandboxing still would be helpful, e.g., if app names with the “harbour” prefix (e.g., harbour-myapp) are technically still feasible when an app has activated the sandboxing (that was rather implicitly asked).

P.S.: It also would be helpful to know if the workaround @nephros suggested is going to be technically prevented or not. Even though that sure is not what you intended, I might be helpful as a quick & dirty workaround for developers who publish their apps at Openrepos or chum and are slow to fully adapt to Jolla’s sandboxing rules.
Side note: For me the intentions for such a fine grained “organisation” directory structure is not fully obvious, especially as it is a 180° turn from the old rules (i.e., every app has to have harbour- prefixed if it is going to be submitted to the Jolla Store, which was definitely more awkward, but one became used to it over the years).

Migrating configuration and data files for sandboxed apps