SailJail: How will it work with sharing plugins?

Applications
#21

To rephrase: the sharing plugins that are loaded into the sharing dialog are having lots of permissions. It’s not possible to limit the access of a binary plugin loaded into a process.

And because of that we have been implementing a separate mechanism to register applications to be used for sharing. Those will be also presented on the dialog’s method list and if the user chooses such, the app will be launched to handle the sharing further. This is something we can even allow in Harbour.

But both of the mechanisms will remain and technically there shouldn’t be obstacles in keeping using custom sharing binary plugins. They are just not going to be harbour allowed.

2 Likes
#22

Wait, so sharing plugins are not jailed?
(Or do they have the full base set of permissons like apps that don’t declare any?)

#23

Not jailed. The privileges are per process and plugins are loaded within a process.

1 Like
#24

@pvuorela, is sharing via the the “old” (introduced with SFOS 4.2.0), not harbour-allowed sharing API interoperable with software which uses the new (introduced with SFOS 4.4.0) sharing API?
Or are they two completely separate sharing mechanisms?

#25

I guess you mean sharing from an app? As the scope of this thread has mostly been what to do in the actual plugins themselves, there could be some mixups. I too don’t see any reason to suspect that sharing from an app has changed (and it should be easy enough to verify).

#26

Seems we are getting a SeaPrint sharing plugin after all…

I probably got something wrong, some names need adjusting, and i should add the new formats that SeaPrint supports… but it works!

Feel free to use as inspiration. This also demonstrates that at least the transfer plugins remain unjailed.

1 Like
#27

Cool! Thanks for sharing. Cough, cough.

1 Like
#28

Yes, from and to an app.

As the scope of this thread has mostly been what to do in the actual plugins themselves, there could be some mixups.

O.K., I obviously do lack sufficient knowledge how the “sharing” in SailfishOS / Nemo-Transferengine is designed and works in practice.
But documentation for this topic seems to be really scare, basically all just one-liners:

Do I really have to try understanding the source code of nemo-transferengine-qt5 and libnemotransferengine-qt5 to get a gist of its design and usage?

I too don’t see any reason to suspect that sharing from an app has changed (and it should be easy enough to verify).

You mean “wait and see, if bug-reports are coming in”? Yes, that is easy, but for everything beyond that I have no idea and no entry point to educate myself.

#29

Understandably, this is hard to digest and very much “ungooglable”.
Much head-desking on my end to make it work.

Sharing from an app is as easy as your first link, but follow the link from there some 3 levels deep:

Fill out the ShareAction object, and call the trigger function. (I assume you know this, but for completeness and other readers).
I don’t believe this part changed for 4.4, and this i believe should be easy enough to test yourself, or if you for some reason don’t have 4.4, ask someone (like me) to test. Or indeed go digging, but that sounds terrible.

Anyway, after that the transferengine takes charge and displays an overlay (now running out of process) with the relevant sharing methods for the supplied data. To this you can plug in sharing plugins if you want to provide a sharing method. And since recently this menu also include more regular mime-type and uri scheme based open-with functionality in that same list (primarily Android apps that registered “intents”, but also some stock ones).

It is here, in the plugins themselves (like my SeaPrint plugin), that apis/structure changed which i referred to above. A sharing plugin no longer consists of a TransferPlugin and it no longer has both PluginInfo and Uploader living with it in the same .so file.
Now there is SharingPlugin living with PluginInfo in one library, and optionally an associated TransferPlugin and Uploader in another .so library.

I don’t claim to fully understand the purposes and distinctions, but in my (ab)use i have SharingPlugin and SharingPluginInfo to register what mimetypes i handle and get my QML in the UI. Then TransferPlugin is where i get to run C++ code for “doing the thing”. In my case i just abuse this to call SeaPrint in a detached QProcess.

What i have here is just a poor-mans open-with, or mime type registration functionality that is really overly complicated.

So receiving a share action to an app is not just one thing…
However in the future (or arguably already) any share-to-app should just be a registration as mime/uri handler and some dbus method magic (see link by poetaster/answer by Karry).
Only fancy integrations like some stock apps, and things like qrshare should need to faff with sharing plugins ever again (wohoo!).

1 Like
#31

This is the wrong thread for that.