Process for reviewing base snaps

Base snap review process


As of snapd 2.29, snappy supports type: base which allows the snap to be used as an alternate runtime for other snaps. Because base snaps provide libraries and other supporting files to snaps that depend on them, care must be taken in making them available to other snaps. As a practical matter, base snaps could not be widely used until base-template security policy was implemented, which is now included in snapd 2.45.

  • the review process in the snap store will flag for human review snaps that specify type: base
  • the store provides a mechanism for the reviewer to allow use of type: base to the snap so that subsequent uploads do not trigger human review
  • the publisher shall be vetted using the processes in this topic before use of type: base is granted by the store


  • Reviewers are in the @reviewers forum group
  • snappy architects are Mark, Gustavo, etc
  • advocacy team is @evan, @popey and @Wimpress
  • base snaps are defined as snaps specifying type: base


  1. the publisher creates a snap with type: base which denotes the ABI compatibility in the name in some manner. Eg, base-1804 or base-fedora26. The snap must also use assumes: [ snapd2.45 ]
  2. the publisher makes the request for use of type: base in the forum using the ‘store-requests’ tag
  3. the advocacy team, reviewers team and/or architects participate in vetting the snap/publisher and that the snap meets the technical requirements for base snaps

Some of the review criteria may include, but is not limited to:

  • Vetting the publisher similar to the process for classic snaps
  • Highly preferring that the base is maintained by a community or project rather than an individual
  • A base needs to contain empty directories for anything that snap-confine doesn’t create but mounts over.
  • Considering files in the base with ownership/permissions/etc that are not allowed by app snaps
  • Considering files in the base that are exposed that are not allowed by the default base template and runtime
  • Base snaps shall not use tracks
  • The base snap publisher must commit to not breaking other snaps (base snaps undergo additional review-tools checks from removed files and changed ABIs, but the publisher must also commit to being responsive to bugs and regressions in updates to the base snap)



I would like to request pinning this topic in the store category.

1 Like