@niemeyer @jdstrand thanks a lot for looking into it and for your response.
This is indeed a different case from yarn, in that its main purpose is actually to manipulate the Ubuntu system itself in arbitrary ways, including the manipulation of pretty much every package management system on behalf of the user.
I do see some sensible arguments for denying classic confinement to this sort of snaps.
However, I am missing some sort of set of formalized rules specifying where exactly the red line between approval and disapproval lies here.
For example, the classic snapcraft snap is also able to install arbitrary software and manipulate the system in arbitrary ways with two main differences:
- the target users are developers
- the goal is packaging software rather than setting up a system
Therefore, is the decision between approval or disapproval also related to the target audience (“regular users” vs. “power users” users vs. developers)? Or is it solely based on what the packaged application is theoretically able to do to the system? Or is it more important what the publisher says the application mainly aims to do?
Since the snap store is a centralized store, application publishers are dependent on the approval of the store owners (or “gate keepers”). Unlike with other packaging systems, there are no alternative repositories or other ways to properly distribute snap applications.
Thus I think that from a publisher perspective, clear, transparent rules for whether or not a snap applies for classic confinement are crucial.
Maybe Process for reviewing classic confinement snaps could be expanded with such rules? Thanks 