Process for aliases, auto-connections and tracks

Definitions

  • Reviewers are in the @reviewers forum group
  • Architects are those responsible for the design of snapd.
  • Votes are in favor (+1), against (-1), abstain (+0)
  • Voting period is one week
  • Voting period extension is 3 days

Process

  1. Requester creates a forum post in the store-requests category and makes case for change. To disambiguate snaps, the requester should either give the store URL for the snap or give the name and publisher of the snap. Voting period starts at time of request.
  2. Requester may not vote on his/her own snap.
  3. Reviewers and/or architects vote using the voting procedure (see below). Each vote should include a short rationale for the cast vote (longer rationale is required for voting contrary to an established pattern)
  4. If after voting period there are not enough votes based on voting procedure, a voting period extension should be requested by a reviewer/architect. The extension starts the day of the request for extension
  5. At the end of the voting period, a reviewer/architects tallies the results from the voting period (and extension), summarizes in the forum post and performs any necessary actions.

Voting procedure

  • The voting procedure is the same for granting and revoking auto-connections, auto-aliases and track requests.
  • If reviewers and up to at most one architect voted: simple majority with at least 2 votes in favor at end of voting period/extension: perform requested action.
  • If two or more votes in favor/against from architects: reviewers votes are not tallied. If have only in favor votes from architects at end of voting period/extension: perform requested action, otherwise architects discuss until no against votes and at least one vote in favor from architects. If clear direction from architects, an architect may request the vote be tallied early.

alias request considerations

Granting aliases requires trust in the snap’s publisher and reasonable names for the aliases (eg, shouldn’t request an alias for something that is a widely known command of other software).

An alias should not be granted for the snap’s name since snapd already grants use of this name to the snap (eg, a snap named ‘foo’ with command ‘foo.foo2’ should not be granted the ‘foo’ alias, instead, the snap can rename the ‘foo2’ command to be ‘foo’ instead (and optionally request an alias for the ‘foo2’ command)).

auto-connection request considerations

In the snap ecosystem it is important to remember that there are several voices when considering auto-connection: snapd (base declaration policy), the gadget snap (for device-specific auto-connections, which does not apply to auto-connection requests), the store (snap declaration policy; ie, requests using this process) and the user.

For each snap interface, a determination is made for whether or not the interface should be manual or automatically connected based on a variety of criteria (the rationale is often in the snapd code base or pull requests) and this is codified in the base declaration.

A snap’s publisher may request that a normally manually-connected interface be auto-connected for a particular snap in the global, public store using the process outlined in this topic (brand store owners may grant auto-connections as appropriate for their brand). Granting auto-connection in the global, public store effectually means that the store is vouching for the publisher’s intent (maintenance, security updates, etc) and snap implementation (it does what it advertises, works well, etc) to the degree that the user’s initial choice on connection at install time is removed (the user may of course disconnect the interface after installation).

Reviewers must therefore consider various criteria to inform their vote on whether the request will be granted. Some of this criteria might include:

  • The “officialness” of the publisher of the snap
  • The “reasonableness” of the request. Eg, a “top-like” program will necessarily need the “system-observe” interface but not “network-control”
  • The snap name makes it clear that an interface should be auto-connected. Eg, a snap named “webcam” with it declaring the “camera” interface
  • The software is intended to be used by children
  • The sensitivity of the access relative to the “user’s voice” (see above)

For some interfaces there are patterns and rationale that can generally be applied. Please note the rationale is subject to change based on security concerns from the community (users, publishers, reviewers, snapd developers, etc), more appropriate technologies becoming available, new information and/or critical thinking, etc. Each request will be reviewed on its own merits and prior granting of auto-connection may be rescinded based on this new information.

  • alsa - auto-connection is generally limited to snaps requiring low-level, direct access to audio devices.
    • Rationale: a lot of hardware does not perform multiplexing of clients so a snap directly accessing the hardware might block audio for other applications on some systems. Sound servers like pulseaudio are designed to multiplex audio and snaps should typically instead plugs the audio-playback (and audio-record if needed), which grants access to pulseaudio
    • Reference: The alsa interface
  • content - the base declaration defines that snaps that plugs the content interface will auto-connect with other snaps from the same publisher. Global auto-connect for content providers is allowed only under certain circumstances
  • cups-control - auto-connection is limited to snaps whose core functionality is printing or design programs where printing is an expected part of the workflow. Granting requires a stated commitment from the developer that moving to a safer API will be performed (such as the Printing portal) when it is widely available
  • joystick - auto-connection generally limited to game snaps
  • mpris - slot side is generally granted provided the name attribute makes sense for the snap. auto-connection of plugs is typically not auto-connected unless the slot’s publisher also agrees
  • password-manager-service - typically not auto-connected due to the sensitive nature of the access and because the user’s voice in this access is so important
    • Rationale: the various keyring services do not provide sufficient isolation for snap access to the interface to be auto-connected by default. Not only can the snap see all stored passwords, but all other applications with access to the password services can also see the snap’s passwords.
    • Reference: NordPass auto-connect to password-manager-service interface
  • removable-media: typically not auto-connected since the optional access to widely varied data does not outweigh the user’s voice regarding potentially sensitive data. Certain classes of applications may be granted an exception under certain circumstances.
    • Rationale: by definition data that is not always present (as is the case with removable-media) is optional access for typical snaps. All snaps with this interface connected have unrestricted access to all data from any plugged media. Considering that removable-media may contain sensitive documents, sensitive pictures/media, encryption keys, etc and that snapd has no insight on the nature of the data, the user’s voice with regard to connection is preserved

    • Exceptions: the following classes of applications may be considered for removable-media auto-connection:

      • major browsers (rationale: the software is designed with security and user privacy in mind)
      • media (eg, sound, photo, video) editors (rationale: the software is very often used to import/edit/export large files on external devices)
      • media (eg, sound, photo, video) players/viewers (rationale: the software is very often used to import/preview/playback files on external devices)
      • media (eg, sound, photo, video) recorders/cameras (rationale: the software is very often used to export/edit files on external devices)

      If the application falls into one of the above categories, then the following criteria will also be considered:

      • the application itself is a mature, well-known application
      • the snap’s (vetted) publisher is a mature, well-known entity
      • the snap’s (vetted) publisher is the upstream of the software
      • if the snap is published by someone other than upstream, the publisher must be vetted and either be an established committer to the upstream or the wider snap ecosystem (eg, an established well-known contributor to the software itself, a member of the snapcrafters group, etc)
        • if the publisher doesn’t meet these criteria, other options may or may not be considered such as the publisher joining snapcrafters, snapcrafters becoming a collaborator on the snap, auto-connection granted conditional on the snap packaging being accepted upstream, upstream stating they trust the publisher with the packaging, etc.
    • Additional information:

      • The removable-media interface is considered a ‘transitional’ interface since, when connected, only traditional UNIX permissions are considered for file access. This allows, for example, a service in a snap to setup inotify/etc to programmatically monitor and exfiltrate/modify files on external media in the background
      • Eventually, applications will either use safer APIs for file access (eg, like portals) or future snapd-prompting mechanisms may be available to obviate the need for auto-connecting this interface
      • Security-conscious users may want to remove sensitive external media when installing snaps, then disconnect the interface from those snaps to prevent them from having access
      • In the future, snapd may grow controls to disable certain interface auto-connections for interfaces like removable-media

Manual connection mitigations

If auto-connection is not granted, options for snap publishers are:

  • have the snap check if the interface is connected via snapctl is-connected <iface> and instruct the user to use the snap connect CLI command or connect via the snap-store/gnome-software GUI. This could be done on startup or contextually at the time of access. Ideally when instructing the user, the details of the access would be explained so the user can make an informed choice. It is true that there is an extra step for the user, but done well, this need not be onerous and may even provide additional trust that your snap and the system as a whole are working to keep everything secure. Note, if using snapctl is-connected you should also add a corresponding assumes: 2.43 to your snapcraft.yaml since this is only available in snap since 2.43 to ensure this functions as expected.
  • use a newer, safer API. Eg, instead of using cups-control, the application could use the Printing portal. If an application needs access to a file from a disconnected interface/etc, use a file dialog that supports portals
  • fallback gracefully. Eg, if password-manager-service is disconnected, fallback to storing passwords locally

In the future, the snapd team plans to provide a prompt API for snaps to use that will not only provide appropriate messaging, but also allow the user to choose to connect within the prompt.

Finally, the desktop team has discussed the lack of isolation in secret-service with upstream GNOME and there are plans to improve the service (see ‘Active Attacks’) to provide the necessary isolation for auto-connecting. Hopefully, KDE/Plasma will follow with kwallet or move to the improved service.

Tracks

There is a simplified process for tracks for snaps with predictable cadence.

6 Likes
Simplified track request process for snaps with predictable cadence
Executing ping within a snap
Track request for subiquity: artful
Use of home and network plugs
Snapping CUPS Printing Stack: Avahi support, system users/groups
Request for 18 track for libc-shm-shim snap
MOOS applications
Interface request: "cups-control" on CUPS snap and including D-Bus
Kdenlive removable-media
Classic confinement request for cot
GTK2 Applications
Auto-connect request for lyricfier
Password-manager-service for lbry snap
Auto-connect interfaces request for auto-cpufreq
Classic confinement request for Erlang snap
User authentication in snapd (pam mediation)
Python3 application with external module
Snap package misses /usr/share/[data]
Fzf snap mount-observe doesn't seem to have an effect
Automatic aliases for ldc2 snap
Automatic aliases for ldc2 snap
Store assertions alias for vscode
Auto-connecting interfaces for bcc
Which snaps should be supported by canonical
Track requests for dmd snap package
Track request: new 1.4 track for ldc2 snap package
Request tracks for u1test-snap-with-tracks
Sanitisation of snaps' requested interfaces
Auto-connecting interfaces for easy-openvpn snap
Automatic alias for bluez snap (btmgmt command)
Track request for OpenStack projects
Track request for prometheus
Track request for OpenStack gnocchi and cinder snaps
Request aliases for torxakis
Classic confinement for ubports installer
Snapping CUPS Printing Stack: Avahi support, system users/groups
Kubernetes 1.9 snap tracks
Docker snap tracks request
Get a list of user-defined aliases of a snap
Classic confinement for yarn
Auto connecting removable media
[Help] Changing the snap name causes a failure in execution
Multi tracks for Apache Drill
New track "cali" for edgexfoundry-core snap
Requesting tracks for 'node' snap: 6, 8, 10
The snapd roadmap
Publish snap with classic confinement
How to load Iptable rules on startup, what plugs are needed?
Request automatic alias for ubuntu-make
How to get serial number of hard-disk in a snap packed application with strict confinement?
Please auto-connect camera interface for flock-chat (Was: Need classic confinement to get camera access and file download)
Confinement help with snapping indicator-sensors
2.3 track for Juju request
Tracks request for microk8s snap
Request for new "extended" track for "hugo" snap
Request: Autoconnect logs-observe for lnav
Track Request: network-manager 1.10
Pre-built apps
Python apps
Node apps
Auto connect "network-manager:service" interface
Making requests for snaps one does not maintain
Request for classic confinement: parsec
new track for snap: raptor
Track request: 1.9 for modem-manager snap
[revoked] Auto-connection for the hunspell-dictionaries-1-3-1604 content interface
Classic confinement for thefuck
NetBeans on Snapcraft
Requesting default aliases for libxml2-utils
Arguments accepted by the application
Go applications
Java applications
ROS2 applications
Ruby applications
Rust applications
New track request for the Ruby language
Some questions around snapping
Where did i go wrong?
Request home interface deny autoconnection for mosquitto
The personal-files interface
The system-files interface
The snapd-control interface
The kernel-module-control interface
Please allow use of personal-files for gitl [Was: Classic confinement for gitl]
Interface autoconnection request for the glances snap
The block-devices interface
Interface auto-connection request for the gallery-dl snap
Track request for bitcoin-core snap
Request for ubuntu-XX.YY track creation
Interface auto-connect request for the `nano-strict` snap
Request core18-3.4 track for ffmpeg-sdk-gplv3 stage snap
Interface auto-connect request for the guvcview snap (personal-files)
Interface auto-connect request for the redis-desktop-manager snap (personal-files)
Track request: 4.0 for snap juju-db
Track request for mosquitto
Interface auto-connect request for the mari0 snap
Interface auto-connect request for the mari0-ce snap
Dragon dbus
Track request for mosquitto
Track request(classic) for the tree snap
Snap Documentation (page deprecated)
Name collision with existing apt package
Snap documentation
Interface auto-connect request for the FeatherPad snap
C/C++ applications
Nemu - kvm permission denied
ROS applications
Clj-kondo personal-files request [Was: Clj-kondo linter classic snap]
Cw-sh requires personal-files
Deprecation notice: 5
Permission requests
Request for classic confinement: distrobuilder
Auto-connection of hardware-observe for webots [Was: Request for classic confinement: webots]
Inkscape autoconnect cups-control
Supported snap hooks
Interface auto-connect request for the couchdb snap
GTK3 applications
Personal-files request for kontena-lens
Create track for loopchain
Auto-connect removable-media
Personal-files request for ngrok
Qt5 and KDE Frameworks Applications
Auto-connect removable-media
JAVAFX App: personal-files interface doesn't give access to $HOME/.openjfx cache directory in Strict mode
Auto-connection request for sar2 (joystick)
Interfaces auto-connect for prusa-slicer snap
Removeable-media KDE snap
Request access personal-files for civo cli
Firefox - removable-media interface auto connect request
Request: auto-connection of removable-media for chromium
Auto-connect removable-media for netron
Auto-connection request for jdownloader2 (removable-media)
Auto-connection request for jdownloader2 (removable-media)
Auto connect requests for sayonara snap
Kdenlive removable-media
Opera requests auto-connect to removable-media
20.02.1 track creation for Slurm
How to use snap for development libraries
Auto-connect log-observe interface for prometheus-grok-exporter snap
Inkscape autoconnect cups-control
Kdenlive removable-media
Opera requests auto-connect to removable-media
Kdenlive removable-media
'plugs/system-files' for hostctl snap
Autoconnect 'office20' and 'abstractgames' to kde-frameworks-5-core18
Autoconnect ksnip to kde-frameworks-5-core18
Autoconnect ksnip to kde-frameworks-5-core18
Opera requests auto-connect to removable-media
Snapping Folding@Home, distributed computing for research on diseases

OTOH, I suggest that snappy architects and store reviewers get a vote such that:

  • if >= 2 +1s, grant after 1 week of initial request (to give architects, et al a chance to read)
  • if >= 2 +1s from architects, grant immediately regardless of number of reviewers’ -1s
  • if architects disagree, do nothing until they agree
  • reviewer may not vote on his/her own snap. An architect may vote on his/her own snap.

This should allow things to move ahead without needless red tape. If architects disagree at a later time, that is cause for re-discussion with the same voting procedure as above for revocation.

After giving some thought on corner cases last night, here is a more formalized proposal:

  • reviewers are https://launchpad.net/~myapps-reviewers
  • snappy architects are Mark, Gustavo, etc
  • votes are in favor (+1), against (-1), abstain (+0)
  • voting period is one week
  • voting period extension is 3 days

Process:

  • a requester creates a forum post with the ‘store’ tag and makes case for change. To disambiguate snaps, the requester should either give the store URL for the snap or give the name and publisher of the snap. Voting period starts at time of request
  • a requester (reviewer or architect) may not vote on his/her own snap
  • reviewers and/or architects vote using the voting procedure (see below)
  • if after voting period there are not enough votes based on voting procedure, a voting period extension should be requested by a reviewer/architect. The extension starts the day of the request for extension
  • at the end of the voting period, a reviewer/architects tallies the results from the voting period (and extension), summarizes in the forum post and performs any necessary actions

Voting procedure:

  • the voting procedure is the same for granting and revoking auto-connections and auto-aliases
  • if reviewers and up to at most one architect voted: simple majority with at least 2 votes in favor at end of voting period/extension: perform requested action
  • if two or more votes in favor/against from architects: reviewers votes are not tallied. If have only in favor votes from architects at end of voting period/extension: perform requested action, otherwise architects discuss until no against votes and at least one vote in favor from architects. If clear direction from architects (eg, no abstain votes), an architect may request the vote be tallied early.

Rationale and proposed process sounds like a great start, thanks for putting it in place Jamie.

As a minor addition, might be good to request the inclusion of a short rationale to back any positive or negative votes, so that others can comprehend the reason and correlate or not.

Then, as a trivial detail, store is actually a category in the forum rather than a tag.

Thanks @niemeyer

Based on that, here are the approved procedures:

Alias and Auto-Connection request and approval process

Definitions

  • reviewers are https://launchpad.net/~myapps-reviewers
  • snappy architects are Mark, Gustavo, etc
  • votes are in favor (+1), against (-1), abstain (+0)
  • voting period is one week
  • voting period extension is 3 days

Process

  • a requester creates a forum post with the ‘store’ category and makes case for change. To disambiguate snaps, the requester should either give the store URL for the snap or give the name and publisher of the snap. Voting period starts at time of request
  • a requester (reviewer or architect) may not vote on his/her own snap
  • reviewers and/or architects vote using the voting procedure (see below). Each vote should include a short rationale for the cast vote
  • if after voting period there are not enough votes based on voting procedure, a voting period extension should be requested by a reviewer/architect. The extension starts the day of the request for extension
  • at the end of the voting period, a reviewer/architects tallies the results from the voting period (and extension), summarizes in the forum post and performs any necessary actions

Voting procedure

  • the voting procedure is the same for granting and revoking auto-connections and auto-aliases
  • if reviewers and up to at most one architect voted: simple majority with at least 2 votes in favor at end of voting period/extension: perform requested action
  • if two or more votes in favor/against from architects: reviewers votes are not tallied. If have only in favor votes from architects at end of voting period/extension: perform requested action, otherwise architects discuss until no against votes and at least one vote in favor from architects. If clear direction from architects (eg, no abstain votes), an architect may request the vote be tallied early.
1 Like

@jdstrand Thanks for formatting it nicely. Would be nice to have that process as the first message of this topic, so people getting into it will see the actual approved process upfront.

I’ve done this just now.

One more request. Could the first message be updated to reflect the fact that this process also applies to track requests? So far I’ve been informally pointing people to this post and just saying “this also applies to tracks despite what the process specifies” but it’d be nice for that to be formalized.

Thanks!

1 Like

FYI, I did this yesterday.

1 Like

@jdstrand @niemeyer Is it possible that we can one or two people from CE into the list of reviewers to speed up reviews for certain commercial things?

1 Like

It is of course possible; I’ll leave the decision to @niemeyer if we want to do this.

My question is what in the existing process is causing trouble? You asked on this thread and I saw in another thread you wanted to speed up the one week waiting period. The one week waiting period is in place so reviewers have a chance to vote (ie, we want to support the case where 2 quick ‘yea’ votes are cast and then a ‘nay’ vote later). There is also a process for architects to waive the waiting period. Is this not sufficient for your needs?

1 Like

@morphis @jdstrand Everybody is welcome to review, but we need at least two reviews from people that are sitting here all the time and reviewing things all the time and that remain aware of current practices. Having someone sporadically reviewing and mainly when they want things in quickly feels like a recipe for bad reviews.

3 Likes

I’ve been meaning to investigate/document this for a while-- reviewers need not worry about granting an alias that is used by other snaps or an alias that is the name of a snap. snapd will prevent inconsistencies:

  • if a snap is installed with an alias, then installing a snap with the name of the alias (ie snap install <alias>) results in the snap being uninstallable until the alias is removed with snap unalias <alias>
  • if a snap is installed that has an automatic alias that matches the name of an already installed snap, then installing the snap with the alias results in the snap being uninstallable (this may be a bug, but it is safe)
  • if two snaps have an automatic alias with the same name, the second snap is not installable until the first’s alias is removed with snap unalias <alias>

I have polished a bit the topic and moved it into the documentation category.

In the process, I’ve also removed @jdstrand’s historical problem description from the post itself.

Here is the content for posterity:

So apparently myapps-reviewers is going away. In light of this, who are “reviewers” with regards to this topic?

1 Like

The current ‘myapps-reviewers’ from LP are:

IMO, the new forum group/team should consist of these people.

2 Likes

I would like to ask if the @reviewers group really exist? Directly clicking on the tag gives an “Access Denied while trying to load /groups/reviewers.json” error.

The group exists, yes. I’m able to see everyone in it by going to https://forum.snapcraft.io/groups/reviewers. You might have to be an admin to see it.

1 Like

I would like to request pinning this topic in the store category, if that makes sense.