@advocacy - can you please perform the vetting?
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?
/etc from the host is exposed directly to your snap’s runtime so the hostfs prefix isn’t needed there.
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.
I already added a jabref.browser-proxy app in the snap
I had forgotten about it.
The script runs confined as well
@advocacy - can someone please perform the vetting?
@advocacy - re-ping to perform the required vetting.
@advocacy - can someone please perform the vetting? It looks like upstream is also interested in this snap: System-files permission for jabref (native-messaging-hosts integration)
Is there anything that we can do to accelerate the vetting process?