Thanks @jdstrand, and sorry if I insisted
I agree that the better solution would be to have an path exposed via the content interface.
This could also be used by the gnome extentions addon, since I believe that uses native messaging as well.
Regarding non snapped browsers only the native script would be run outside the confinement.
It then calls the jabref program like if it was run from the command line, so with the selected confinement.
But I understand your point.
The only question I have is: should I use /var/lib/snapd/hostfs on the /etc path as well?
I may have been a little terse in my summary from yesterday. The use of system-files being discussed here allows for sandbox escape because there is nothing preventing the snap from not invoking via /snap/bin. Part of the agreement for allowing you use of the interface in this manner (and why we are performing publisher vetting) is that lib/native-messaging-host/firefox/org.jabref.jabref.json will use /snap/bin/jabref.<something> and thus register something that will run under confinement and not undermine the security properties of confinement.
In the browser snap/content interface scenario, the json file you register would need to point to something else you are giving to the browser snap’s provided content slot, and thus executing under the confinement of the browser.
@jdstrand
This is getting a bit hard to follow up on… Can the vetting start from the jabref team? Since they are involved and the snapcraft yaml is on their github account…
Who can we contact to get the vetting started directly?
Thanks
@LyzardKing - fyi, looking at the snapcraft.yaml in the store, I see that:
a) it is malformed (‘plugs’ is under ‘plugs’)
b) you are using hostfs to access files in /etc. Just use /etc
Looking at you latest snapcraft.yaml, adjust to use:
Notice that when you use a top-level ‘plugs’ and you don’t use ‘plugs’ under the ‘apps’ commands, all of the toplevel plugs are used for the app. If this isn’t what you want, remove all the ‘null’ items from the top-level plugs and do something like:
Point is, if you are going to specify plugs down under apps that are different for each command, then specify them all there, referencing the interface references in the top-level plugs. Otherwise, just use the top-level plugs and omit the ones down under apps.
@LyzardKing - finally, while the store now has the snap declaration in place, there is a review-tools change that is needed that I’ve made to master but isn’t in production yet. Feel free to upload new revisions based on my comments above and we can manually approve them until the store has the change in production.
Thanks @popey! @jdstrand I had used only top-level plugs since the second app (browser-proxy) is a “launcher” for the first one (via the messaging hosts).
I’ll remove the nested plug (likely a typo on my end) and republish.