RFC: Ubuntu Seeded Snaps

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

RFC: Ubuntu Seeded Snaps

Steve Langasek-6
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 extras.ubuntu.com[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:

  https://wiki.ubuntu.com/UbuntuSeededSnaps


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
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.

= 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
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.

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                                    http://www.debian.org/
[hidden email]                                     [hidden email]

[1] https://snapcraft.io/
[2] http://wiki.ubuntu.com/AppReviewBoard/Charter

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

signature.asc (817 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: RFC: Ubuntu Seeded Snaps

Robie Basak-4
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

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: RFC: Ubuntu Seeded Snaps

Colin Watson
In reply to this post by Steve Langasek-6
On Thu, Feb 08, 2018 at 03:10:08PM -0800, Steve Langasek wrote:
> = 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.

For better or worse, the snap store doesn't have teams.  Should this be
rephrased in terms of collaboration or something?

> = 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.

I've done the bulk of the Launchpad work for this, pending review:

  https://code.launchpad.net/~cjwatson/launchpad/db-snap-allow-network/+merge/336923
  https://code.launchpad.net/~cjwatson/launchpad/snap-allow-network/+merge/336924

--
Colin Watson                                       [[hidden email]]

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Reply | Threaded
Open this post in threaded view
|

Re: RFC: Ubuntu Seeded Snaps

Colin Watson
In reply to this post by Robie Basak-4
On Fri, Feb 09, 2018 at 09:37:17AM +0000, Robie Basak wrote:

> On Thu, Feb 08, 2018 at 03:10:08PM -0800, Steve Langasek wrote:
> > 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"?

Store channel names are formed as [track/]risk[/branch]; it's this kind
of branch that Steve is referring to.  (The spec should probably just
say "channel", though.)

I'm not sure how this can avoid requiring up-front maintenance of
multiple snap channels.  If the proposal is that we install snaps in a
way that will cause refreshes to pull from a pre-configured per-series
channel, then unless that channel actually exists then "snap refresh" is
surely going to be returning errors, which doesn't seem like a good
stock configuration.

This raises another point; when upgrading to versions beyond 18.04,
users' systems will need to be modified to follow the appropriate
per-series channel for each of these preinstalled snaps.  Somebody will
need to teach the upgrader to do this, and it will also need to be
documented for people who don't use update-manager/do-release-upgrade.

> 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.

If they were built on Launchpad with the proposed changes to disallow
external network access, then all the necessary information exists, but
there's currently no tooling to help users actually find it.

--
Colin Watson                                       [[hidden email]]

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Reply | Threaded
Open this post in threaded view
|

Re: RFC: Ubuntu Seeded Snaps

Oliver Grawert
In reply to this post by Robie Basak-4
hi,
Am Freitag, den 09.02.2018, 09:37 +0000 schrieb Robie Basak:


> >
> > 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?
this is an already existing store policy ... if your snap was built
with "confinement: devmode" you can not release it to stable, the store
checks this and blocks. so the "only stable" policy on the ubuntu side
should be enough.

ciao
        oli
--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

signature.asc (188 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: RFC: Ubuntu Seeded Snaps

Robie Basak-4
On Fri, Feb 09, 2018 at 11:20:53AM +0100, Oliver Grawert wrote:

> > 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?
>
> this is an already existing store policy ... if your snap was built
> with "confinement: devmode" you can not release it to stable, the store
> checks this and blocks. so the "only stable" policy on the ubuntu side
> should be enough.
I think you missed my point. Who sets the store policy? What is the
governance of the store policy? If it is Canonical, rather than Ubuntu,
then Ubuntu may consider it appropriate to "lock" its seeding policy,
rather than having a policy whose result varies according to external
changes.

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: RFC: Ubuntu Seeded Snaps

Oliver Grawert
hi,
Am Freitag, den 09.02.2018, 10:30 +0000 schrieb Robie Basak:

> I think you missed my point.

i definitely read it completely differently, yes,
sorry for the noise :)

ciao
        oli
--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

signature.asc (188 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: RFC: Ubuntu Seeded Snaps

Colin Watson
In reply to this post by Oliver Grawert
On Fri, Feb 09, 2018 at 11:20:53AM +0100, Oliver Grawert wrote:
> Am Freitag, den 09.02.2018, 09:37 +0000 schrieb Robie Basak:
> > 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?
>
> this is an already existing store policy ... if your snap was built
> with "confinement: devmode" you can not release it to stable, the store
> checks this and blocks. so the "only stable" policy on the ubuntu side
> should be enough.

Regardless of the question of governance of that policy, there's also
the fact that the spec calls for following a per-series channel, for
which I don't think a "no devmode" store policy is currently configured.

--
Colin Watson                                       [[hidden email]]

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Reply | Threaded
Open this post in threaded view
|

Re: RFC: Ubuntu Seeded Snaps

Ross Gammon-3
On 02/09/2018 12:18 PM, Colin Watson wrote:

> On Fri, Feb 09, 2018 at 11:20:53AM +0100, Oliver Grawert wrote:
>> Am Freitag, den 09.02.2018, 09:37 +0000 schrieb Robie Basak:
>>> 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?
>> this is an already existing store policy ... if your snap was built
>> with "confinement: devmode" you can not release it to stable, the store
>> checks this and blocks. so the "only stable" policy on the ubuntu side
>> should be enough.
> Regardless of the question of governance of that policy, there's also
> the fact that the spec calls for following a per-series channel, for
> which I don't think a "no devmode" store policy is currently configured.
>
Maybe not related to the policy as such, but one thing I have always
wondered about, but not had the time to investigate (as I have only
installed one snap deliberately on my system), is the release upgrade path.

When I installed my "one and only" snap, I had to manually remove the
old deb package manually.

Will this be managed automagically if a flavour chooses a snap in their
seed rather than the old deb package?

Cheers,

Ross



--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Reply | Threaded
Open this post in threaded view
|

Re: RFC: Ubuntu Seeded Snaps

Marcos Alano
IMHO, Snap Store is more like an app store (like Google Play Store),
than a regular package repository (archive.ubuntu.com, a PPA or a
third party repository).
I think some ground rules and some policies are necessary, but we must
avoid burocracy and give freedom to developer, so he/she can create
what he wants. So things like licensing should weaker enforced. The
idea is: think as an app store, not a package repository.

On Fri, Feb 9, 2018 at 2:32 PM, Ross Gammon <[hidden email]> wrote:

> On 02/09/2018 12:18 PM, Colin Watson wrote:
>> On Fri, Feb 09, 2018 at 11:20:53AM +0100, Oliver Grawert wrote:
>>> Am Freitag, den 09.02.2018, 09:37 +0000 schrieb Robie Basak:
>>>> 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?
>>> this is an already existing store policy ... if your snap was built
>>> with "confinement: devmode" you can not release it to stable, the store
>>> checks this and blocks. so the "only stable" policy on the ubuntu side
>>> should be enough.
>> Regardless of the question of governance of that policy, there's also
>> the fact that the spec calls for following a per-series channel, for
>> which I don't think a "no devmode" store policy is currently configured.
>>
> Maybe not related to the policy as such, but one thing I have always
> wondered about, but not had the time to investigate (as I have only
> installed one snap deliberately on my system), is the release upgrade path.
>
> When I installed my "one and only" snap, I had to manually remove the
> old deb package manually.
>
> Will this be managed automagically if a flavour chooses a snap in their
> seed rather than the old deb package?
>
> Cheers,
>
> Ross
>
>
>
> --
> ubuntu-devel mailing list
> [hidden email]
> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel



--
Marcos H. Alano
Linux System Administrator
[hidden email]

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Reply | Threaded
Open this post in threaded view
|

Re: RFC: Ubuntu Seeded Snaps

Ken VanDine-5
In reply to this post by Steve Langasek-6
With snaps we no longer get crash reporting to errors.ubuntu.com.  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.

Cheers,
Ken

On Thu, Feb 8, 2018 at 6:10 PM, Steve Langasek <[hidden email]> wrote:
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 extras.ubuntu.com[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:

  https://wiki.ubuntu.com/UbuntuSeededSnaps


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
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.

= 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
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.

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                                    http://www.debian.org/
[hidden email]                                     [hidden email]

[1] https://snapcraft.io/
[2] http://wiki.ubuntu.com/AppReviewBoard/Charter

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel




--
Ubuntu - "I am what I am because of who we all are"

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Reply | Threaded
Open this post in threaded view
|

Re: RFC: Ubuntu Seeded Snaps

Steve Langasek-6
In reply to this post by Colin Watson
Hi Colin,

On Fri, Feb 09, 2018 at 10:00:28AM +0000, Colin Watson wrote:
> On Fri, Feb 09, 2018 at 09:37:17AM +0000, Robie Basak wrote:
> > On Thu, Feb 08, 2018 at 03:10:08PM -0800, Steve Langasek wrote:
> > > 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"?

> Store channel names are formed as [track/]risk[/branch]; it's this kind
> of branch that Steve is referring to.  (The spec should probably just
> say "channel", though.)

> I'm not sure how this can avoid requiring up-front maintenance of
> multiple snap channels.  If the proposal is that we install snaps in a
> way that will cause refreshes to pull from a pre-configured per-series
> channel, then unless that channel actually exists then "snap refresh" is
> surely going to be returning errors, which doesn't seem like a good
> stock configuration.

My understanding was that if the branch does not exist, pulling by that
branch name would fall back to the stable channel.  It seems that may not be
the case:

$ snap refresh canonical-livepatch --channel stable/foo
error: snap "canonical-livepatch" not found (at least in channel "stable/foo")
$

Would this need further development in either the snap client or the snap
store in order to support such usage?

The intended behavior is that the publisher does not have to maintain these
channels when the content should be identical to the stable channel, but
that if a snap revision *is* published to the Ubuntu-specifc channel at any
point, all relevant Ubuntu clients will pick that version instead of stable.

> This raises another point; when upgrading to versions beyond 18.04,
> users' systems will need to be modified to follow the appropriate
> per-series channel for each of these preinstalled snaps.  Somebody will
> need to teach the upgrader to do this, and it will also need to be
> documented for people who don't use update-manager/do-release-upgrade.

Yes; I've captured the software requirement here:

  https://bugs.launchpad.net/ubuntu/+source/ubuntu-release-upgrader/+bug/1748581

For documentation, do you have a sense of where that could be put that would
be read by those who don't use ubuntu-release-upgrader?  The release notes
upgrade instructions already point to u-r-u.

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                                    http://www.debian.org/
[hidden email]                                     [hidden email]

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

signature.asc (817 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: RFC: Ubuntu Seeded Snaps

Mark Shuttleworth-2
In reply to this post by Colin Watson
On 02/09/2018 11:48 AM, Colin Watson wrote:
> For better or worse, the snap store doesn't have teams. Should this be
> rephrased in terms of collaboration or something?

Well, I'd rather we set the expectation that the snap store learn to use
LP teams.

Mark

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel