Hi Steve,
Thank you for driving this. I'm looking forward to having leaf desktop
packages available and upgradeable via snaps.
On Thu, Feb 08, 2018 at 03:10:08PM -0800, Steve Langasek wrote:
> = 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.
Makes sense. Interestingly though, this isn't a property that exists for
the (deb) archive at the moment. Ubuntu developers can sync from Debian
experimental and we trust them to use their judgement. We also sometimes
deliberately ship something pre-release because of release schedule
alignment issues, with the expectation that an updates will be issued
shortly after release. What would be the equivalent for snaps? Would a
TB exception always be required, or should the policy allow the release
team to grant exceptions? Should it be a policy matter at all: can
Ubuntu developers be trusted to make the decision for themselves,
consulting with Ubuntu developers and the release team as appropriate?
> As a side effect, since devmode snaps may not be published to the stable
> channel, only strict and classic confined snaps may be included.
Should this be a side effect subject to change of store policy (which I
think is outside the scope of the Ubuntu project?), or should we define
"no devmode" as an Ubuntu policy now?
> 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.
I don't follow this. Are you suggesting that the seed list a snap
version number? Or a specific code branch in Launchpad from which the
snap ending up in the images will get built? If the former, wouldn't the
install base become "stuck"? If the latter, how and when would that
branch get updated, and how would that work if upstream are maintaining
the snap?
> = 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.
Sounds reasonable.
> = 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.
I'm very much in favour of the above two requirements, but there's also
a little more. With the current archive, these are some existing
properties that I think should be considered for inclusion in this
policy.
* _Users_ (rather than just developers) can retrieve the full source
associated with a package from Launchpad with no other external
dependencies and rebuild it themselves, and tooling exists for this.
* Users can find the build logs associated with every binary shipped
from the archive.
* The above two statements are true both for packages that a user is
considering installing but has not yet installed, and for packages
that a user has installed locally.
Does any of this exist with snaps today (that were built from source on
Launchpad)? I haven't been able to find any suitable connection to
identify the provenance of a snap in this way.
> = License =
> The license policy covering Ubuntu main and restricted is documented at
> https://www.ubuntu.com/about/about-ubuntu/licensing. 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.
Sounds reasonable.
> = 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
Is there a list of "safe" interface connections defined anywhere? For
example, I'm not sure /home/$USER/* is something that I'd consider safe.
> likely require more scrutiny. The same security checks listed on
> https://wiki.ubuntu.com/UbuntuMainInclusionRequirements 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.
Sounds reasonable.
> 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.
Will there be any requirement for a publisher to agree to anything
before inclusion into a seed? If not, do we have a plan on what to do if
a particular publisher falls short of our expectations? For example, one
way out might be to require, at MIR time, an Ubuntu development team to
have committed to taking up the slack.
Robie
