[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RFC: Ubuntu Seeded Snaps

With snaps we no longer get crash reporting to  We
should add support for snap crash reporting to apport.  This isn't all that
useful without debug symbols, so we should investigate how we can make
builds with debug symbols available as well.  Just a couple things I think
we need to tackle sooner rather than later.


On Thu, Feb 8, 2018 at 6:10 PM, Steve Langasek <steve.langasek at>

> Dear developers,
> As I'm sure you know, Canonical has recently been putting a lot of work
> into
> the Snap Store[1], a repository for third-party packages that is the
> successor
> to the past[2] and click packages efforts.
> We are confident that snaps today represent a solid delivery vehicle for
> third-party software on top of Ubuntu, and that snaps stand as a
> first-class
> alternative to deb packages for Ubuntu users where appropriate.
> Snaps are already presented alongside debs in the software catalog on the
> Ubuntu Desktop, and with the 17.10 release, the Ubuntu MATE team took the
> first foray into including snaps by default in an Ubuntu flavor image.  Now
> in Ubuntu 18.04 LTS, we are looking at broadening the inclusion of snaps in
> Ubuntu images by default.  This raises important questions about what the
> policies should be for software installed by default as a snap, since the
> review processes around the Ubuntu archive for universe and main don't
> directly translate to the Snap Store.
> I have prepared a draft which lays out what I believe the requirements
> should be around snaps which we ship preinstalled, and I would greatly
> appreciate the feedback of the Ubuntu Developer community around this
> proposed policy:
> I have also included the text of this draft below for your convenience.
> = Goal =
> Snaps represent a new way of building packages with reduced barriers to
> entry.  By design, the snapcraft tooling imposes very little policy to
> avoid
> also introducing friction.  As more software becomes available as snaps, we
> want to take advantage of this body of packages as part of the default
> Ubuntu experience, but maintaining the Ubuntu communityâ??s commitments
> around
> this default experience means reintroducing policy on top of snaps.  This
> document is an attempt to translate existing policy for the Ubuntu archive
> to the new world of the Canonical Snap Store.
> = Channel availability =
> Including software in the default install of Ubuntu implies a certain
> commitment to handle upgrades cleanly and to provide continuity of behavior
> across updates within the stable release.  The best way to ensure this
> commitment holds true in the snap case is to only include snaps that come
> from the stable channel.
> As a side effect, since devmode snaps may not be published to the stable
> channel, only strict and classic confined snaps may be included.
> Snaps included in images will be installed referencing a per-Ubuntu-series
> branch.  This ensures forwards-compatibility by allowing publishing to this
> branch if the mainline of a snap becomes incompatible with a given Ubuntu
> release, without requiring up-front maintenance of multiple snap channels.
> = Maintainer =
> Packages in the Ubuntu archive arrive there by one of two means: they are
> synced from Debian as upstream, or they are uploaded by an Ubuntu
> developer.
> Similarly, to be included in an Ubuntu image, a snap should have as its
> publisher either the upstream, or the Ubuntu developer community.  For the
> latter, a common team should initially be created in the Snap Store whose
> membership is managed by the Developer Membership Board, and kept in sync
> with the ubuntu-motu team in Launchpad, with the Ubuntu Security team
> additionally included.
> = Source availability =
> Unlike Launchpad, the Snap Store allows publishers to upload binary snaps
> directly.  While a valuable option in the general case, for snaps installed
> by default we should ensure that they build from source in the common
> Launchpad environment.  This helps to avoid any increase to the build time
> attack surface and provides a known good environment that can be similarly
> duplicated if the snaps needs to be rebuilt in the future
> In addition, maintainability of the product demands that the package
> remains
> buildable if no changes have been made to the productâ??s source.  For .deb
> packages, we enforce this by only building against other packages in the
> Ubuntu distribution.  Launchpad allows snap builds to pull from third-party
> repositories; this means that if those repositories change - or disappear -
> the snap may no longer be functionally equivalent when rebuilt, or may not
> build at all.  To address this, official Ubuntu snaps should be built only
> from source that is available in Launchpad.  Snap recipe builds already
> require a launchpad-hosted branch to host the snapcraft.yaml, so it is a
> logical extension to require launchpad hosting for the parts also.
> Both of these requirements will likely depend on changes to Launchpad and
> possibly the Snap Store, to either support enforcing a different network
> policy at build time or to tag builds as compliant or not with this policy.
> = License =
> The license policy covering Ubuntu main and restricted is documented at
>  Snaps included by
> default in Ubuntu installs should comply with this policy the same as .debs
> do.
> Partner-specific images and images for community flavors may include
> software that does not meet the Ubuntu main/restricted licensing policy, at
> the discretion of those imagesâ?? owners, in accordance with existing
> practice.
> = Security Support =
> Maintenance of the snap must include a clear designation of ownership of
> security support.  The process for including a snap in an Ubuntu image
> should include a sign-off by the Ubuntu Security Team to confirm that the
> security support story is adequate.  The snap confinement model means that
> in-depth code reviews should not generally be required for strict-mode
> snaps
> that only require safe interface connections.  Classic mode snaps will
> likely require more scrutiny.  The same security checks listed on
> for debs in main
> are
> relevant to snaps.  The MIR team will be the gatekeeper for the snap
> inclusion process as well and coordinate with the Security Team as
> appropriate.  As an initial policy, â??as appropriateâ?? means every snap to be
> installed by default in the Ubuntu image.  This policy can be revisited
> after a period of one year.  Owning teams are responsible for security
> support in accordance with the Ubuntu Security Teamâ??s guidelines for
> security support of Canonical-supported snaps.  A report will be provided
> by
> the Ubuntu engineering team of the high-level CVE status across all the
> snaps included in the Ubuntu image.
> The Snap Store ecosystem empowers snap publishers to make their own
> decisions about how and whether to backport security fixes to stable
> releases vs. updating the package in the channel to a new upstream version.
> We accept this model as well for installed-by-default snaps, with the
> understanding that the publisher of each of these snaps is expected to
> deliver a good experience to their users.
> For cases where the Ubuntu community is the maintainer of the snap rather
> than upstream, it is recommended to prefer targeted backports of security
> fixes where possible.
> -------------------8<---------------------------------------
> ----------------
> Thanks,
> --
> Steve Langasek                   Give me a lever long enough and a Free OS
> Debian Developer                   to set it on, and I can move the world.
> Ubuntu Developer                          
> slangasek at                                     vorlon at
> [1]
> [2]
> --
> ubuntu-devel mailing list
> ubuntu-devel at
> Modify settings or unsubscribe at:
> mailman/listinfo/ubuntu-devel

Ubuntu - "I am what I am because of who we all are"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>