Classic confinement for app-outlet

[messiaslima]

App Outlet is an application thas aim to put together Snaps, Flatpaks and AppImages.

We just want to be able to run CLI commands like ´snap install app-outlet´ or ´flatpak install flathub com.spotify.Client´.

So the users will be able to install packages using App Outlet interface.

Github link: https://github.com/app-outlet/app-outlet
Latest release: https://github.com/app-outlet/app-outlet/releases

[messiaslima]

Do you need more information about the package?
Is my request under evaluation?

[alexmurray]

For the case of snaps - these could be installed instead by taking advantage of the snapd-control interface - however there is no similar interface for flatpak / AppImage - so at this stage classic makes the most sense. +1 from me.

[messiaslima]

With how many upvotes, the permission is given?

[ogra]

@alexmurray

these could be installed instead by taking advantage of the snapd-control interface

while this is true, the snapd-control interface is exclusive to brand stores only, by store policy snaps using it will be blocked from uploads to the global store, so this is likely not an option here …

[popey]

@ogra

while this is true, the snapd-control interface is exclusive to brand stores only, by store policy snaps using it will be blocked from uploads to the global store, so this is likely not an option here …

That may have been the policy, but other snaps exist which use snapd-control in the global store.

alan@KinkPad-K450:~$ snap connections snap-store | grep contr
snapd-control             snap-store:snapd-control             :snapd-control   

To enable app-outlet to “install” an AppImage, that’s effectively just downloading the .appimage file into ~/AppImages (or whatever) and marking executable. Launching it will be problematic from the app-outlet application, as it won’t be able to launch arbitrary executables.

For flatpak I think there needs to be an interface developed, as there’s more integration needed there.

While I appreciate classic might be a short term option as @alexmurray suggests, it’d be way cleaner and more re-usable (if other store app frontends come along) if an interface existed.

[Wimpress]

While it would be technically possible to install snaps in a confined snap using snapd-control (as the Snap Store snap does) it would not be possible to install/launch AppImages or flatpaks from a confined snap.

I am inclined to agree with @alexmurray that, at this time, classic confinement is required for app-outlet to function as a snap. +1 from me

[ogra]

@popey

That may have been the policy, but other snaps exist which use snapd-control in the global store.

yes, canonical owned snaps like the snap-store one have been the exception to this policy (though indeed it could have been changed recently)

i also remember that we in general used to not allow managers for other package formats into the store, not sure if that rule still stands … IIRC @niemeyer and/or @jdstrand established that rule a while back…

EDIT: i dug up an older reply about the package management topic:

Requesting classic confinement for buttermanager

Ah, this is the key point for the whole conversation since it will require classic confinement for the foreseeable future and thus far we’ve not allowed snaps that require use of the package management commands are problematic for a snap that is distributed via the Global store. @pedronis - at this point, the current guidelines dictate that the request be denied. I will point out that the application isn’t meant to install arbitrary applications and instead only manage upgrades. We can’t enfor…

[alexmurray]

@pedronis - there is a question on the general policy regarding package managers in the store - see @ogra’s comment above - can you comment on what the current status is for this, and whether it is appropriate to grant classic confinement for app-outlet as a result?

[messiaslima]

Hello guys. @alexmurray, @ogra, @pedronis

There’s some update about my request?

[pedronis]

Two points for context:

• we have distinguished package managers for language libraries vs applications, the assumption with the former is different audience expectations
• snap-store is confined strict

The issue with application package managers in the store is that all the policy/security questions that applies to single app snaps, here turn into meta questions. The security and policy picture gets fairly complicated.

Rarely but we had to unpublish snaps. What would/should be the response if a package manager features some malaware (not packaged as a snap) either by mistake or intentionally? To me it looks like a complicated situation for all parties involved.

(About strict snaps with snapd-control in the main store, the discussion over time afair is that it would be considered for large Open Source communities…)

[jdstrand]

Note that historically ‘installer snaps’ are not allowed (I’ve recently updated the process to reflect this). Some of the reasons include:

1. if the snap is used to install traditional distribution packages (eg, debs, rpms, etc) then the snap has instant root, can break the system, can replace snapd, etc accidentally or intentionally in a way that cannot be predictably rolled back. While all classic snaps are in a position to do this, an installer snap is specifically in the business of installing software and modifying the system to use it.
2. another aspect, as @pedronis alluded to, is that installer snaps are typically used to advertise software from different stores/archives and there is no guaranteed gatekeeping of those stores. The global Snap Store has all kinds of processes, checks, cryptography, processes to revoke/unpublish snaps, etc to make sure things are safe. An installer snap that installs arbitrary content onto the system circumvents this
3. similarly, most installer snaps do not provide a mechanism for launching what they installed under confinement. The installed applications are integrated directly onto the host or launched by the classic-confinement snap itself, in both cases unconfined

For context, the snap-store snap is strictly confined and is allowed to install snaps through the snap store using snapd. While this is a highly-privileged snap, it does not suffer from the same problems as the above. There is also packagekit-control interface to be used with traditional packages, but this interface is reserved for official distribution software managers, not 3rd party installer snaps.

In the specific case of app-outlet, it wants to install snaps, flatpaks and AppImages. IME, my point ‘1’ need not be considered since it doesn’t want to install traditional packages. ‘3’ is mostly addressed since snaps and flatpaks are expected to run under confinement after installation (though, see my questions below), but AppImages are not run under confinement. Which leaves point ‘2’; presumably the official global Snap Store is where app-outlet would get snaps, but where does it get flatpaks? Does it need to configure flathubs on the system? Where is it getting AppImages? Are the added flathubs and AppImages verified/gatekept in any way? Does app-outlet allow ‘sideloading’ flatpaks and AppImages?

Does app-outlet provide a launching facility? If so, specifically, how does it launch each of snaps, flatpaks and AppImages? Does it write out desktop files? If so, specifically what are the contents for each of snaps, flatpaks and AppImages?

@pedronis - it feels like app-outlet may be out of scope with its inclusion of AppImages. Flatpaks could be made to work with an additional interface, but then this brings in your questions and mine wrt provenance of the software and who is responsible in the event of malware, etc. I wonder if there was a flatpak interface if it, like packagekit-control, should be limited to distribution software managers and not 3rd party installer snaps?

[jdstrand]

@pedronis and I discussed this in Vancouver and came to the conclusion that unfortunately this is out of scope for classic confinement in the curated public store. The reasoning is as follows:

• in the case of AppImages, the downloaded application is run without confinement. Furthermore for AppImages, there is no mechanism provided by snapd to manage the application after the fact for rollbacks, revocations, etc. Finally, the provenance of the installed AppImage is not tied to the Snap Store, so there are no guarantees to the user on where the resulting binary came from.
• While flatpaks run under confinement and there is an imaginable path forward for adding APIs and exposing them via snap interfaces to allow an application to install flatpaks, that doesn’t exist today. These APIs would need to be extended to support rollbacks and revocations as well. Furthermore the question of provenance applies to flatpaks when considering flathubs. Finally, if a snapd interface was created to allow for this, it would be a highly trusted interface reserved for distribution software managers and not 3rd party app installers.

While I appreciate this is an undesired outcome, allowing the use of installer snaps like app-outlet in the curated ecosystem of the public Snap Store would undermine several principles for which snapd is designed.