I want to create a snap for F1viewer, a TUI for the streaming service F1TV.
The main functionality of F1viewer is to start media players (or any other software) to play or download videos from F1TV. For this to work F1viewer needs to be able to execute arbitrary commands and therefore needs classic confinement.
The default command to play a video with mpv is built in. Users can add more commands in a config file. You can find a more detailed description here.
Please let me know if you need more information.
Thank you.
Is it possible for f1viewer to use xdg-open to launch an external media player? This should allow it to still work with strict mode confinement - in general the ability to launch a viewer application from the host environment is not considered to require classic confinement for a snap (and in particular since this snap ships its own viewer in mpv).
Being only being able to use xdg-open would limit users. For example a common use case is to start ffmpeg and download a video. That would not be possible.
Additionally, I’m not sure xdg-open would work. Players have to open the .m3u8 URL directly, so xdg-open would just open a web browser, right?
Ok I see, the ability to configure and run arbitrary commands can only be achieved with classic confinement. The requirements for classic confinement are understood - @advocacy can you please perform the required vetting?
@alexmurray (cc @security) - please note that just because something doesn’t work today without classic confinement doesn’t mean that classic should be granted. When we say ‘the request for classic is understood’ we’re saying that either a) we know the path forward to make this strict by making changes to snapd or b) this isn’t going to be supported by snapd any time soon. In neither case does this mean that classic will be granted (we have Process for reviewing classic confinement snaps that lists known categories for things we’ve previously discussed; if it is listed in one of those categories, feel free to grant or deny classic but if it is not (like this one), we need to discuss further and make a call, sometimes with an architect). Put another way, we want to drive each classic request to an understanding that it fits one of the categories (adding new ones as they are discussed and fully understood) and if it does not, gather enough information that we can guide changes to snapd or guide the publisher to adjust the snap to work within the system.
In this particular case, it is known this snap will not work without classic today, but xdg-open can be updated to handle other files (see the recent https://github.com/snapcore/snapd/pull/7731#pullrequestreview-362900171). Now, xdg-open doesn’t work on file extensions, it works on URLs. Is there a URL type for F1viewer? Is there a mimetype for .m3u8 that already exists, or does F1viewer need to register a new mimetype?
xdg-open always parses the mime database, if there is a handler for .m3u8 in that database, the application linked to it (i.e. some media player) will be used by default …
@jdstrand To my reading, this falls into the b) case since I am not sure that snapd is going to support the launching of arbitrarily configured commands from a snap anytime soon - and so similar to applications which want to launch an external editor (which we then grant classic confinement for) I see this is quite similar, hence to me this meets the requirements of classic confinement for this use-case - https://github.com/SoMuchForSubtlety/F1viewer#custom-commands
I agree that ‘launching arbitrary configured commands from the snap’ won’t be supported any time soon, but that doesn’t in and of itself mean classic shall be granted. Our process doc lists this as an unsupported use case: “access to arbitrary files on the system because the application isn’t designed with confinement in mind (if a desktop application, use portals or xdg-open)”.
This is why I started probing on xdg-open in followups and if it could be made to work in a way that would allow F1viewer to function.
