Allow a flatpak to discover/call another flatpak #283
Comments
|
You can open URIs but it doesn't work for local |
|
How would it work exactly? I'm not sure I understand your workaround. For info, right now (out of flatpak), we discover the third-party app in a Linux OS by simply checking its availability in the path. |
|
You let the host handle file associations and you would just pass it the raw file. |
|
Not all RAW software will work well with GIMP (currently only darktable and rawtherapee). There is a coded layer between GIMP and the RAW software. This specific feature has been closely created together by developers of all 3 projects (GIMP, darktable and RawTherapee) so that there is a back-and-forth interaction/connection. In particular if we just let file association handle the file, once the user is done developing the RAW, the third party software would not give back the result to GIMP. And that also means we can't just give the file to the RAW software in a common way. GIMP actually runs a command with specific options.
So no, we can't just let the host handle file association. The point is not to redirect the file towards some other software and not hear about it anymore. That feature would make no sense at all (if that's what we want to do, we'd just say we don't support RAW images). The point is acknowledging that the RAW development is better done in a specialized software, but further image editing are better done in GIMP. This is basically a workflow where various more specialized software work together seamlessly and are connected, sharing images and work-in-progress at different steps, like a "Free Software graphics suite" or something. |
|
Well, thats just not how sandboxes work: they isolate applications from each other and from the host system. If you want deep integration, you can ship the auxiliary software as part of your flatpak, and have it run in the same sandbox. Otherwise, you may need an api between the two apps to facilitate this sort of interaction. A d-bus api would be much easier to integrate in the existing tooling than launching the app with special options. |
|
Ok we'll discuss this. |
|
This is basically a portal question, so moving it over to xdg-desktop-portal |
matthiasclasen
added
the
new portals
|
Given an application-specific D-Bus API, and The status quo is that, if you don't mind being GNOME specific and your app can talk to Or to install it (without user confirmation): Aside from the GNOME-specificity, there are some big caveats:
I imagine that a better interaction would be (on GNOME):
Seem plausible? @manuq can you comment from the point of view of wanting an API like this? One thought was whether we could instead add a hint to |
|
@wjt yes, your description matches exactly what an ideal portal API would look like.
And I agree, making this a user-facing portal mitigates the sandbox flaw of discovering other apps. Regarding app A start talking to app B, our use-case only needs app B installed. We talk to gnome-shell to launch the other app with the |
|
I think sneaking this into OpenURI might not work for all cases - you might not have a uri / file to open with the app, but instead a D-Bus request to make, or sth. The overall plan sounds good to me. If we are concerned about discovering installed apps, we could add a separate permission for that. |
|
One thing that I'm really not sure about is how you'd solve that original workflow without either questions that the user can't answer naturally, or a lack of question that would mean that too much is opened. What would the UI look like for those apps? How do you trigger those links/API calls between applications? From afar, it looks like a souped-up "OpenURI" with a signal back when editing is done, an "Edit In..." call, something which Android's Intent can already do. Should this be part of a wider "Sharing" mechanism between apps instead? Or do we really want to poke holes just between those applications and no others? |
On that, applications from the same domain on iOS have more open permissions between themselves, so that Google's YouTube application can offer to open a location in Google's Maps application rather than in the native/default maps application. I don't know if there's a mechanism to do that for arbitrary applications though. |
This is implemented as a workaround for now, checking the output of the flatpak command. flatpak/xdg-desktop-portal#283
It looks like Universal Links allows one iOS app to open another by attempting to opening a URL. A special file on the web server is checked at the time the target app is installed to determine whether it allows other apps to make it open a given URL. Notably, if the app is not installed, attempting to open a supported URL will open the URL in Safari; it won't take the user to the app's detail page in the App Store. The rationale is the user always gets an immediate, meaningful view of the resource without being prompted to install the app. But the website can have a clear "install the companion app for a better experience" link. The Android approach is more flexible and respectful of the user's wishes though, so it seems like a better model for us. Eg, if there's an OpenStreetMap-based app that claims to support URLs like "https://maps.google.com/*", the user can set the default handler. My understanding is, on iOS, only the controller of maps.google.com is allowed to determine which (at most one) app is allowed to handle each URL regex starting with its domain. |
|
Though I guess the original topic is best supported by a custom URI. The specific apps that support it could register as supporting that scheme and the calling app won't have to hard-code their names or URL structures. Opening a generic URI is a bit different than a service-specific URL though and only the former is appropriate for passing arbitrary local data. Sorry if the last comment was a bit of a divergence :) |
|
https://lists.freedesktop.org/archives/xdg/2014-January/013068.html - Problem 3 here is somewhat relevant. |
|
I see 3 use cases:
Number 2 is needed for browser native messaging host system like firefox's. It could also allow run extensions that just provide binary run with another set of permissions. Inkscape has a cli and sandboxed latex will help alot. |
|
Just piling onto the discussion here. Other cross-flatpak dependencies (already packaged) are that the OpenShot app leverages both Blender and Inkscape. One of the nice things about Flatpak is that the packaged apps don't need to be flatpak aware. Seems like many of the suggestions fundamentally want to change how programs are executed under linux. If an app has a preferences dialog to specify the path to another executable, why shouldn't I be allowed to type "flatpak run my.app.Here app " from within a sandbox? Or make a script in $HOME/bin that does the same? Seems like the choices are: flatpak adapts to apps as they are written, or it forces all app writers to add "flatpak support". The simple solution, of course, is to build flatpaks with combinations of apps. Need access to another app? Bundle it. This also gives the package maintainer control over the version bundled. |
|
I think no adaption is required, you just need some patches to have – as you said – some script in a |
|
I don't believe you can currently call flatpak from within flatpak. Check out the following and tell me what I'm missing: Need to have a command that runs before you can point an app to the command you want to run. |
|
No you cannot, but if this was implemented, the application inside the flatpak would not need to be adjusted, you would likely only need to put in some wrapper scripts for the used binaries. |
|
Lets raise this to flatpak to handle fine grained permission to flatpak(for all flapak commands, usefull fo flatseal software centre and this case) and also permission to expose ipc stored in $XDG_RUNTIME/app. |
|
Randomly casting about the internet, I learned about flatpak-spawn, which in line with my example up above should work like: That opened the standard blender gui. Tweak the command line to put in the required command line arguments, and viola. From the man page (guess it still pays to RTFM): |
|
Brief proposal, based on file sharing:
|
|
I think it's also important that Flatpaks are able to directly open another app, with certain arguments. For example, a Doom mod manager I was trying to package needed to be able to launch a Doom sourceport with certain arguments. |
Thing is, allowing that unconditionally would allow apps to break each others sandboxes, since an app A could just launch As such, such a mechanism would at least require a per-app opt-in. This would likely involve some kind of sanctioned ipc-command this may be, but not necessarily is, different from the main command already part of the manifest. . That said, I can think of a scheme (if someone is willing to do the one-time upfront work) that would enable this within the constraints of Flatpak’s existing infrastructure without burdening upstream projects:
Caveats of this approach:
Albeit caveat 1 may be a major issue for some Apps, I think that for most of the use-cases mentioned above it would not be a problem and, most importantly, not require any modifications to any of the applications involved. |
|
Reading this proposal, it seems to assume that App A has direct permission to communicate with App B's launcher. If this is that, then that's not correct for that part. The user should be asked about App A wanting to open App B and then grant permission to open App B or not. However, it's more than that: the user also needs to know why App A wants to open App B with commands. The problem with commands is that it's hard to communicate them in an understandable way in a user interface. When there is a file, we can say "App A wants to open the file with App B with custom settings", but even "custom settings" is not ideal... but the context helps if the user is asking to launch something with commands in App A. So remember that any proposal needs to be constructed in such a way that we can present a user interface that makes sense to grant the access. |
Flatpak certainly shouldn't go in a direction that would allow for that sort of interaction.
If the receiving app is expected to participate in being discovered or "called", then I don't think the full generality of arbitrary command-line parameters, environment variables, fds and working directory is necessary, or safe. "Most" applications can be subverted by a malicious caller if the malicious caller can set environment variables of their choice. I'd prefer an interface that looks more like receiving a message, or being asked to open a file or a URI - even if it's accompanied by a side-channel that provides a pipe/socket/fd for continuing communication with the caller. Obviously, if the receiving app wants to load potentially dangerous things from that file or URI, then that's up to its maintainer (and then they can deal with the resulting CVEs when an attacker tells them to do something malicious), but I think the interface needs to be set up so that the simplest/most naive implementation is not immediate arbitrary code execution.
As someone who thinks about security, I would be mentally reframing this as "App A wants to cause arbitrary code execution in App B" and I suspect I'd be right more often than not.
I think that's a key thing here. |
|
For commands, it's certainly possible to show all arguments by clicking a button or expander, but that wouldn't mean anything to naive users. The alternative is to say nothing about the commands and protect the file: read-only file, Internet access disallowed (or dynamic where access is requested from the side of the app that will open the file), and certainly other things I didn't think of. It would be the same for opening an app without a file. Also, although not really a case here, we will need a solution for commands as I am thinking of remote control apps such as an app controlling a presentation. Also, is it reasonable for this problem to just focus on sharing a file between apps and opening an app without arguments? (and therefore to leave aside the commands) What do you think? |
|
My proposal is intended as a “works right now” solution that is almost entirely transparent to shipped applications. It requires
The idea here is that the caller will submit as much information as possible and the callee will then only use the information it deems useful – in the case of environment variables that would usually mean ignoring all or most values, blindly applying all of them is a very bad idea, yes. Similarly, the callee should reject any combination of command-line parameters it deems problematic. I’ve added some wording to emphasize the importance of this.
I’m not sure I fully agree here. Exposing something that resembles the existing CLI environment that programs are used to would make it a lot easier to adopt for Flatpak maintainers, since it means that things will just work once they have figured out which parameter combinations are reasonable to accept. The key point here is that it has to be emphasized that it’s completely reasonable to start off just accepting a single file parameter and then expand the scope from there as use-cases demand more. Assuming it is implemented as a reusable project, App maintainers also don’t need any deep knowledge of D-Bus and the involved interfaces. In particular, the intricacies of sharing files between Flatpak apps can almost entire be hidden away. |
(Assuming you are talking about a portal-native solution here.) Perhaps requesting to open a single file while passing an arbitrary set of key-value attributes along would be acceptable though? The attributes would either be entirely hidden or displayed in some sort of details view and it be clarified to App maintainers that these must not be treated as arbitrary command-line arguments or environment variables. |
|
Sharing a file for co-editing, with apps being notified when the file has changed to update their view of the file, seems like a good start. If it's just to open a file in another application, the arguments can be added later. Also, what are the cases requiring opening a file with arguments in another application in the case of co-editing, editing in one and viewing in another, or co-viewing?
In my opinion, the only trusted source is the flatpak portals, not the maintainers. Like I said, I think the file could be protected if we don't want to show anything, but that requires other portals, but I want to be sure that's something accepted. |
|
Here is a proposal:
This is a proposal on what is needed. It is based on the comments above. What is to be known is if this is the direction to follow. Only after that, the missing elements to "know the cases" can be discussed. Window Focus Idea: #42 |
|
@Mikenux, for future reference, use tabs for indentation rather than spaces where possible, since it helps a lot when accessibility is a concern. |
|
@RokeJulianLockhart: No problem 😉 I used tabs but it was set to "Spaces" within Text Editor. |
|
Maybe some rules about commands:
Window Focus Idea: #42 |
|
I would like to also request functionality to grant full read access to another application's files, this can be useful when you want to load another application as a library, for example there is an addon for Blender called sverchok that has functionality to integrate with FreeCAD but this requires loading FreeCAD as a python module, it would be nice if blender could be allowed full read access to freecad's files so it may load it as a library |
|
Maybe the use case of opening temporary directories in file managers is related to this? Like opening a backup archive in a file manager (un-mounting it when the file manager is closed, closing the file manager when the backup tool is closed), or showing a directory on a certain git branch/commit as a git application. |
|
If it's the file manager mounting the archive or remote directory (for git; is that it?) by itself, then yes. However, the file manager must support the archive and the protocol. If we cannot assume support for all possible protocols or archives, the app has to mount the remote directory or archive on its own, then request the directory to be opened. This path is then probably not the concern of this issue. |
|
About the mockup in #283 (comment) without reading the proposal (txt file), I – as a flatpak/Linux user – don't get what the box "Access from file chooser" wants to tell me, nor what are the implications of enabling or disabling it. "Prevent the app from reading all assets at once" is also not helpful, because it invokes the following questions for me:
Also that free standing:
Huh? That sounds contradictory to me? Either conversion is unsupported, and they cannot be converted or it is actually supported and works? Did you miss a "[can]not" here? (Also "some" is vague again, but yeah maybe you cannot list them all… though maybe a number of files and how much can be converted may be useful?) Otherwise, this looks great. |
|
The "Access From File Chooser" option was designed to insert one or more assets from the file chooser rather than directly from the application (i.e. the application has its own presentation of files). If I remember correctly, I did this so the app wouldn't know that you gave access to another app's data and any assets you may possibly add. I had privacy in mind. However, this is now a bit ridiculous because the requester app can guess what other app you're using based on the assets you're adding, and because the requester requested access to that app. It's something to remove from the design. What I meant by "assets" is data such as adding PNG or SVG in Inkscape to create mockups. Also, for example, I saw that KiCad made its libraries available as extensions, like its 3D models. Regarding the name to use, I don't know which one would be the right one because English is not my native language. Usually I think we call it "Object_Name Library", but I don't know what name to use if it's to access all libraries. I'm not really into giving 1-3 examples, because then it would be better to show them all to the user (to be exact) if there is no telling name. "Some unsupported files can be converted" is correct because it is because the files are not supported by the app that they must be converted to get a supported file. For example, GIMP does not support opening RAW files directly. It must open an app that manipulates RAW files and will "convert" the RAW file to a file that is compatible (i.e. supported) with GIMP. A list of "unsupported" files can be displayed in the settings. It's best to keep the text in the banners as short as possible when we don't know the length of the translations. I hope this answers your questions. My design clearly needs some revision, but remember that in the end, the GNOME design team will have the final design (what I post here answers questions like "What kind of UI do we want?" and "Is it possible to make a UI?", the mockups themselves can only be a guide).
Thanks 🙂 |
Ah but the message implies the conversion is automatic, i.e. "can be" aka "they are going to be converted" (maybe better wording too). Or say "need to be converted" if it should say they are not going to be opened/included. No native speaker here neither BTW, so yeah, I let the other stuff to other people. |
and others
Hi!
GIMP has this nifty new feature for opening RAW images, which is we use third-party advanced RAW software for the job. The idea is: why bother reimplementing a shitty 3-slider RAW developer as a plugin which will mostly be a toy when there are really good complete ones, and several being Free Software, like darktable or rawtherapee.
So now when someone tries to open a RAW in GIMP, we detect installed darktable and rawtherapee and redirect the call to the user's favorite RAW software (if both are installed, one can choose one's favorite in GIMP's preferences). When the editing stops on this third-party software, it automatically sends back the result to GIMP for further editing.
Unfortunately this feature stopped working with flatpak. Flatpaked GIMP don't see DT/RT installed by the system packaging, nor installed as flatpak.
Let's say we don't mind not detecting non-flatpak DT/RT. After all, flatpak is a sandbox and one of the goal is to shield the system. But couldn't there be an API to detect other flatpaks and being able to run them? I see there is a darktable flatpak for instance. It would be awesome if we could detect it within GIMP flatpak and run org.darktable.Darktable.
The text was updated successfully, but these errors were encountered: