Snaps and Fedora

[Neal Gompa]

Hello all,

Over the course of this week, I've been involved in the first Snap
sprint focused on making the Snap system broadly useful and workable
across a wide variety of Linux distributions. While I obviously did
not represent Fedora in any official capacity (and I'm not even really
sure it's possible for a person to represent such a diverse community
such as ours), I ensured that Fedora was part of the conversation when
it came to evolving the Snap system.

There are some interesting highlights from the event that I think are
quite relevant to Fedora:

* Snaps are intended to evolve beyond Ubuntu. While snaps have their
origins in Click for Ubuntu Touch user apps, the Snap system is
clearly designed to support a broader array of capabilities and
systems. Snaps can be used to handle OS components, services, CLI
tools, desktop applications, build environments, web services, and so
on.

* Runtimes are supported in snaps. While technically there's no
specific "type" of snap, it's possible to build a snap that contains
common libraries and services that can be connected to other snaps.
This is done through the "plugs" and "slots" that can be used to
create interfaces among them. This is a true superset of the
capability provided by Flatpak through Portals, since it can be used
to export non-DBus oriented communications mechanisms. This is
described on the Snapcraft documentation[0].

* SELinux-based confinement is a _very_ high priority. As most know,
snapd currently only works on systems using AppArmor and seccomp, and
only those using AppArmor patches developed by Ubuntu that are in the
process of being upstreamed. For SELinux support, we aren't exactly
sure how this will be pulled off. I proposed something along the lines
of how confinement works for Docker containers and virtual machines
(sVirt), but I'm not sure if that's the right approach for enabling
proper confinement while allowing the sandboxes to support the
interconnection capabilities of snaps. The way that the Snap system
enforces confinement using AppArmor and seccomp is by generating a
profile for the snap on the fly that defines what it can and cannot do
and access for the mounted snap filesystem (from the squashfs image).
This policy is applied, locking down the snap's environment. I'm
curious to hear from others on how the approach should be for
providing confinement using SELinux.

* Detection and auto-configuration of confinement is coming.
Snap-confine currently relies on build time configuration to figure
out whether it should support confinement. However, this will change.
Snap-confine will be merged into snapd and snapd will be set up to
query and set up whatever confinement is possible, given the
information returned from the kernel and systemd about what
confinement mechanisms are supported.

* The snap format is simple and lends itself to being able to be
generated by many kinds of tools. While the current main tool used to
make snaps is Snapcraft, there's no reason someone couldn't build a
"snapbuild" (like rpmbuild, debbuild[1], and pkgbuild[2]) that could
theoretically use RPM spec format (or a derivative of it) to build
snaps.

* Snapcraft is currently Ubuntu specific, but will be reworked to
remove that. Snapcraft and the snapcraft.yaml format will change to
enable easily and reproducibly building snaps using Debian and RPM
based distro bases in addition to Ubuntu[3]. The goal is to make it
possible for a distribution like Fedora to be able to easily add
support for building snaps and snap parts from Fedora infrastructure
using Fedora packages/software, along the lines of what we do now for
Docker images, so that people can use them in their own snaps or
solutions.

* The VideoLAN project now officially offers a VLC snap[4], and the
Elementary OS folks are working on snaps for their Pantheon Desktop
applications and tying it to an Elementary GTK runtime snap.
Similarly, the KDE Neon folks are developing a KDE Frameworks 5
runtime snap and building application snaps to use them.

* Using snapd with alternative stores is possible. In fact, the tests
done on snapd builds rely on a "fake store" set up locally to be able
to test all the functionality. The store API is fully documented[5]
and there's even a simple implementation of it[6].

* Support for snaps to offer AppStream metadata is coming. The Snappy
development team is highly interested in implementing support for
AppStream so that it's easier for software centers and other tools to
be able to discover and interact with snaps through snapd. Snapd
support for AppStream XML through its API[7] for software centers is
planned as well.

* Fedora packaging of the snap system is under active development.
Zygmunt Krynicki (zyga) is extremely enthused to get the system in
Fedora fully functional, and I'm mentoring him on various aspects of
Fedora packaging, including maintenance and policies.

* Snap development is rather fast, with releases expected to occur
every two weeks. There's no intention to break the API between snapd
and the rest of the system, so interaction points should be fine. The
pace is well-suited for being able to push updates to Fedora in a
timely fashion so that users can get the best experience possible for
using applications and services under the system.

I know that the Workstation WG is very much behind Flatpak right now,
but I see no reason that we cannot offer both. In fact, it is in the
best interests of our users to fully enable both systems to the best
extent we can, so that they have the freedom to develop and use
applications as they see fit.

So, what does everyone think of Snappy, given this new information?
Constructive feedback is highly valuable and very welcome, especially
at this early stage!

Best regards,
Neal

[0]: http://snapcraft.io/docs/reference/interfaces
[1]: https://github.com/ascherer/debbuild
[2]: http://pkgbuild.sourceforge.net/
[3]: https://bugs.launchpad.net/snapcraft/+bug/1602258
[4]: https://uappexplorer.com/app/vlc.videolan
[5]: http://search.apps.ubuntu.com/docs/
[6]: https://github.com/noise/snapstore
[7]: https://github.com/snapcore/snapd/blob/master/docs/rest.md

-- 
真実はいつも一つ！/ Always, there's only one truth!

[Haïkel]

http://www.ubuntu.com/legal/contributors

2016-07-23 2:46 GMT+02:00 Neal Gompa <ngompa13(a)gmail.com&gt;:
>  Hello all,
>
>  Over the course of this week, I've been involved in the first Snap
>  sprint focused on making the Snap system broadly useful and workable
>  across a wide variety of Linux distributions. While I obviously did
>  not represent Fedora in any official capacity (and I'm not even really
>  sure it's possible for a person to represent such a diverse community
>  such as ours), I ensured that Fedora was part of the conversation when
>  it came to evolving the Snap system.
>  
Thanks Neal for sharing your notes.
It's interesting to have accurate status of snappy on Fedora.


>  There are some interesting highlights from the event that I think
> are
>  quite relevant to Fedora:
>
>  * Snaps are intended to evolve beyond Ubuntu. While snaps have their
>  origins in Click for Ubuntu Touch user apps, the Snap system is
>  clearly designed to support a broader array of capabilities and
>  systems. Snaps can be used to handle OS components, services, CLI
>  tools, desktop applications, build environments, web services, and so
>  on.
>  
Well, I know first hand, that non-Ubuntu system support is still alpha at best.
It's welcome that Canonical is working to expand support to other
distributions, windowing system, and kernel security modules, though.

>  * Runtimes are supported in snaps. While technically there's no
>  specific "type" of snap, it's possible to build a snap that contains
>  common libraries and services that can be connected to other snaps.
>  This is done through the "plugs" and "slots" that can be used to
>  create interfaces among them. This is a true superset of the
>  capability provided by Flatpak through Portals, since it can be used
>  to export non-DBus oriented communications mechanisms. This is
>  described on the Snapcraft documentation[0].
>  
I wouldn't be so affirmative on that, it slightly inaccurante but I'll
let people with more knowledge of flatpak internals answering that.

>  * SELinux-based confinement is a _very_ high priority. As most know,
>  snapd currently only works on systems using AppArmor and seccomp, and
>  only those using AppArmor patches developed by Ubuntu that are in the
>  process of being upstreamed. For SELinux support, we aren't exactly
>  sure how this will be pulled off. I proposed something along the lines
>  of how confinement works for Docker containers and virtual machines
>  (sVirt), but I'm not sure if that's the right approach for enabling
>  proper confinement while allowing the sandboxes to support the
>  interconnection capabilities of snaps. The way that the Snap system
>  enforces confinement using AppArmor and seccomp is by generating a
>  profile for the snap on the fly that defines what it can and cannot do
>  and access for the mounted snap filesystem (from the squashfs image).
>  This policy is applied, locking down the snap's environment. I'm
>  curious to hear from others on how the approach should be for
>  providing confinement using SELinux.
>  
To be more precise, until recently, snappy website recommended to
setenforce 0 as it didn't interact well with SELinux.
That statement was removed though it's still not fixed.

>  * Detection and auto-configuration of confinement is coming.
>  Snap-confine currently relies on build time configuration to figure
>  out whether it should support confinement. However, this will change.
>  Snap-confine will be merged into snapd and snapd will be set up to
>  query and set up whatever confinement is possible, given the
>  information returned from the kernel and systemd about what
>  confinement mechanisms are supported.
>
>  * The snap format is simple and lends itself to being able to be
>  generated by many kinds of tools. While the current main tool used to
>  make snaps is Snapcraft, there's no reason someone couldn't build a
>  "snapbuild" (like rpmbuild, debbuild[1], and pkgbuild[2]) that could
>  theoretically use RPM spec format (or a derivative of it) to build
>  snaps.
>
>  * Snapcraft is currently Ubuntu specific, but will be reworked to
>  remove that. Snapcraft and the snapcraft.yaml format will change to
>  enable easily and reproducibly building snaps using Debian and RPM
>  based distro bases in addition to Ubuntu[3]. The goal is to make it
>  possible for a distribution like Fedora to be able to easily add
>  support for building snaps and snap parts from Fedora infrastructure
>  using Fedora packages/software, along the lines of what we do now for
>  Docker images, so that people can use them in their own snaps or
>  solutions.
>
>  * The VideoLAN project now officially offers a VLC snap[4], and the
>  Elementary OS folks are working on snaps for their Pantheon Desktop
>  applications and tying it to an Elementary GTK runtime snap.
>  Similarly, the KDE Neon folks are developing a KDE Frameworks 5
>  runtime snap and building application snaps to use them.
>
>  * Using snapd with alternative stores is possible. In fact, the tests
>  done on snapd builds rely on a "fake store" set up locally to be able
>  to test all the functionality. The store API is fully documented[5]
>  and there's even a simple implementation of it[6].
>  
In practice, distributing snap packages requires relying on
Canonical's proprietary store, as the client is tied to that API.
Yes, one can implement its own store, but no guarantee that the API
won't change in the future, nor that Canonical will accept to let the
community participate in defining that API if they want to.


>  * Support for snaps to offer AppStream metadata is coming. The
> Snappy
>  development team is highly interested in implementing support for
>  AppStream so that it's easier for software centers and other tools to
>  be able to discover and interact with snaps through snapd. Snapd
>  support for AppStream XML through its API[7] for software centers is
>  planned as well.
>
>  * Fedora packaging of the snap system is under active development.
>  Zygmunt Krynicki (zyga) is extremely enthused to get the system in
>  Fedora fully functional, and I'm mentoring him on various aspects of
>  Fedora packaging, including maintenance and policies.
>  
Great, thanks to Zygmunt!

>  * Snap development is rather fast, with releases expected to occur
>  every two weeks. There's no intention to break the API between snapd
>  and the rest of the system, so interaction points should be fine. The
>  pace is well-suited for being able to push updates to Fedora in a
>  timely fashion so that users can get the best experience possible for
>  using applications and services under the system.
>  
No intention to change interfaces, but still happened recently.


>  I know that the Workstation WG is very much behind Flatpak right
> now,
>  but I see no reason that we cannot offer both. In fact, it is in the
>  best interests of our users to fully enable both systems to the best
>  extent we can, so that they have the freedom to develop and use
>  applications as they see fit.
>  
There are two things here: first, providing snappy in our
repositories, second, making it our preferred next-gen packaging
format for desktop app.
AFAIK, as long as Fedora Packaging guidelines are respected, there's
nothing preventing the former, it's even encouraged if there are
volunteers to maintain it in Fedora. On the other hand, the latter is
unlikely to happen unlike some company ill-advised marketing press
releases said w/o ever consulting us.

Again, I'm speaking in my own name, but there are significant flaws
that are not in favour of choosing snappy as next-gen packaging
format.
0. flatpak is currently slightly more mature than snappy.
1. contributing to snap requires signing Canonical CLA, that has
proven in the past a powerful repellant to community-based
contribution.
http://www.ubuntu.com/legal/contributors
2. snappy is still essentially a single-vendor project while flatpak
has been developped within the GNOME community by people from various
companies (Red Hat, Collabora, Mozilla, Endless, CodeThink just to
list top contributors).
3. distributing snappy apps still relies on Canonical proprietary
store. Without strong commitment in that read, this will hinder
adoption by other distros.

You can argue that 1 and 2 are non-technical points, but there are
still very relevant within an open source community context.
3. is critical aspect for adoption.

In the end, Fedora contributors will choose whatever projects they
feel like to integrate in Fedora, flatpak, snappy or something
completely different.

>  So, what does everyone think of Snappy, given this new information?
>  Constructive feedback is highly valuable and very welcome, especially
>  at this early stage!
>
>  Best regards,
>  Neal
>  
As a reminder, Neal is no affiliated to Canonical, and I'm grateful
that he accepted to share his vision about snappy.
So please, keep the discussion civilized.


Regards,
H.


> [0]: http://snapcraft.io/docs/reference/interfaces
> [1]: https://github.com/ascherer/debbuild
> [2]: http://pkgbuild.sourceforge.net/
> [3]: https://bugs.launchpad.net/snapcraft/+bug/1602258
> [4]: https://uappexplorer.com/app/vlc.videolan
> [5]: http://search.apps.ubuntu.com/docs/
> [6]: https://github.com/noise/snapstore
> [7]: https://github.com/snapcore/snapd/blob/master/docs/rest.md
>
> --
> 真実はいつも一つ！/ Always, there's only one truth!
> --
> devel mailing list
> devel(a)lists.fedoraproject.org
> https://lists.fedoraproject.org/admin/lists/[e-mail]

[Andrew Lutomirski]

On Jul 22, 2016 5:48 PM, "Neal Gompa" <ngompa13(a)gmail.com&gt; wrote:
>  This is done through the "plugs" and "slots" that
> can be used to
>  create interfaces among them. This is a true superset of the
>  capability provided by Flatpak through Portals, since it can be used
>  to export non-DBus oriented communications mechanisms. This is
>  described on the Snapcraft documentation[0].
>  
I think (from reading the docs a bit -- I haven't tried it or looked at the
code) that snap interfaces are powerful but not in a good way for desktop
apps.  They seem to work a lot like Android permissions -- an app asks for
an interface and won't work without it.  The trouble is that they're very
coarse grained and grant global access.  I, as a user, don't want to give
my apps $HOME access, and I don't want apps written to expect $HOME
access.  Apps should automatically get permission to show a file open box
and get that file only.

Flatpak gets this right.

Admittedly, the Flatpak approach won't work directly for, say, a web
server.  But IMO it would much better if, instead of "network-bind", there
was "bind-port" and admins could connect their server to the specific port
it needed.

--Andy

[Michael Catanzaro]

On Sat, 2016-07-23 at 02:46 +0200, Neal Gompa wrote:
>  I know that the Workstation WG is very much behind Flatpak right
> now,
>  but I see no reason that we cannot offer both. In fact, it is in the
>  best interests of our users to fully enable both systems to the best
>  extent we can, so that they have the freedom to develop and use
>  applications as they see fit. 
Hi,

It's unlikely that Workstation WG will take any action on snappy in the
foreseeable future, so go right ahead with packaging/reviewing it and
getting it into Fedora. There was never much interest in attempting to
block snappy packaging, and I doubt we could get that past FESCo
anyway.

We just don't want it installed by default in Workstation at this time.

Michael

[Zygmunt Krynicki]

>  Wiadomość napisana przez Neal Gompa <ngompa13(a)gmail.com&gt; w dniu
> 23.07.2016, o godz. 02:46:
>  
>  Hello all,
>  
>  Over the course of this week, I've been involved in the first Snap
>  sprint focused on making the Snap system broadly useful and workable
>  across a wide variety of Linux distributions. While I obviously did
>  not represent Fedora in any official capacity (and I'm not even really
>  sure it's possible for a person to represent such a diverse community
>  such as ours), I ensured that Fedora was part of the conversation when
>  it came to evolving the Snap system. 
I was at the spring with Neal. I will add some notes on my perspective.

>  
>  There are some interesting highlights from the event that I think are
>  quite relevant to Fedora:
>  
>  * Snaps are intended to evolve beyond Ubuntu. While snaps have their
>  origins in Click for Ubuntu Touch user apps, the Snap system is
>  clearly designed to support a broader array of capabilities and
>  systems. Snaps can be used to handle OS components, services, CLI
>  tools, desktop applications, build environments, web services, and so
>  on. 
I very much share this view. Snaps are just glorified zip files (squashfs images) that
have just enough meta-data to make themselves useful. Because snaps just declare the
integration the particular implementation can figure out how to actually do things that
are meaningful in a given context. This can include command line tools, graphical
applications and the security interaction are just not hardcoded in the actual snap but
are only declared in a very high-level form and language that can be implemented correctly
in various ways, depending on the environment in which the snap is being used.

>  * SELinux-based confinement is a _very_ high priority. As most know,
>  snapd currently only works on systems using AppArmor and seccomp, and
>  only those using AppArmor patches developed by Ubuntu that are in the
>  process of being upstreamed. For SELinux support, we aren't exactly
>  sure how this will be pulled off. I proposed something along the lines
>  of how confinement works for Docker containers and virtual machines
>  (sVirt), but I'm not sure if that's the right approach for enabling
>  proper confinement while allowing the sandboxes to support the
>  interconnection capabilities of snaps. The way that the Snap system
>  enforces confinement using AppArmor and seccomp is by generating a
>  profile for the snap on the fly that defines what it can and cannot do
>  and access for the mounted snap filesystem (from the squashfs image).
>  This policy is applied, locking down the snap's environment. I'm
>  curious to hear from others on how the approach should be for
>  providing confinement using SELinux. 
I’ve started some initial work on SELinux support, I could really use some help on this to
at least bootstrap support for the basic confinement features. I’d like to invite
developers interested in SELinux and security technologies in general to help me out. I
will address this separately after I push some initial patches (probably next week but I’m
currently traveling so I cannot be sure). The snapd codebase has a concept of a security
backend. It is perhaps a misnomer as each actual installation uses many „backend” at the
same time. Since snaps (applications) don’t actually contain their apparmor profiles it is
possible to offer both a SELinxu and apparmor implementation of each concept that snaps
operate on. Obviously the devil is in the details but I have a few initial pointers to
explore (as Neal said above)

>  
>  * Detection and auto-configuration of confinement is coming.
>  Snap-confine currently relies on build time configuration to figure
>  out whether it should support confinement. However, this will change.
>  Snap-confine will be merged into snapd and snapd will be set up to
>  query and set up whatever confinement is possible, given the
>  information returned from the kernel and systemd about what
>  confinement mechanisms are supported. 
This is pretty simple, I just have to stop moving around so that I can actually implement
it. Snapd already does dynamic identification, it just has to be a little bit smarter. As
for snap-confine it currently uses build-time configuration to ensure it cannot be used as
a source of attack. What I want to do instead is so that snapd does all the detection and
puts a file that snap-confine can read (but creating or changing that snap requires root
access) and snap-confine can trust the decisions there to control the type of confinement
or any other choices that currently have to be in sync across the two processes.

>  * The snap format is simple and lends itself to being able to be
>  generated by many kinds of tools. While the current main tool used to
>  make snaps is Snapcraft, there's no reason someone couldn't build a
>  "snapbuild" (like rpmbuild, debbuild[1], and pkgbuild[2]) that could
>  theoretically use RPM spec format (or a derivative of it) to build
>  snaps. 
Yes! My first snaps were built with just make compiling my code and writing the meta-data
file. While snapcraft is a kind of a meta build system that just taps into existing build
systems, you can always just build your snap with a totally custom way, as long as in the
end you get the meta-data in place (one file) and put your application inside in a way
that makes it run. It’s just a blessed zip file with some 

>  
>  * Snapcraft is currently Ubuntu specific, but will be reworked to
>  remove that. Snapcraft and the snapcraft.yaml format will change to
>  enable easily and reproducibly building snaps using Debian and RPM
>  based distro bases in addition to Ubuntu[3]. The goal is to make it
>  possible for a distribution like Fedora to be able to easily add
>  support for building snaps and snap parts from Fedora infrastructure
>  using Fedora packages/software, along the lines of what we do now for
>  Docker images, so that people can use them in their own snaps or
>  solutions. 
As soon as snapcradt upstream makes that part configurable I will work on packaging a pure
RPM-based snapcraft.

>  * Fedora packaging of the snap system is under active development.
>  Zygmunt Krynicki (zyga) is extremely enthused to get the system in
>  Fedora fully functional, and I'm mentoring him on various aspects of
>  Fedora packaging, including maintenance and policies. 
Yes! And I’d like to thank you for all the time you’ve spent teaching me and reviewing the
packages (the more people reviewing the better so do please look at my code and correct me
if I’m doing something wrong).
The packaging is close to done, there will be a few things I will defer (like getting the
permission to use preset to start snapd socket, etc) but overall it feels close to being
available in F25 without major problems.

>  * Snap development is rather fast, with releases expected to occur
>  every two weeks. There's no intention to break the API between snapd
>  and the rest of the system, so interaction points should be fine. The
>  pace is well-suited for being able to push updates to Fedora in a
>  timely fashion so that users can get the best experience possible for
>  using applications and services under the system. 
One thing I could use some help with is to have snapd integration tests (that run on all
merges) also support Fedora properly. There are a few things that will be ubuntu specific
for now (those can be easily fixed or just disabled for now) and some things will be
known-broken before the selinux support is in place but this should give us much better
confidence when the actual upstream release is done and when downstream distributors will
ensure it can be released. Currently the way this works is that a throwaway VM is created,
the whole source tree is copied there, packaging is applied and the package is built and
installed. This is something that just needs love so that it is 1) easy for everyone to
reproduce 2) extended to support particular distributions.

Spread [1] (the testing tool used by snappy upstream) supports LXD, Linode and (almost
finished) QEmu. You can have a look at the snap-confine [2] and snapd [3] tests. Please
keep in mind that they are actually spread out into various task.yaml files. What I’d like
to do is that a developer can 

[1] https://github.com/snapcore/spread
[2] https://github.com/snapcore/snap-confine/blob/master/spread.yaml
[3] https://github.com/snapcore/snapd/blob/master/spread.yaml

>  I know that the Workstation WG is very much behind Flatpak right
> now,
>  but I see no reason that we cannot offer both. In fact, it is in the
>  best interests of our users to fully enable both systems to the best
>  extent we can, so that they have the freedom to develop and use
>  applications as they see fit. 
Obviously my view is biased but I obviously agree. Unlike past differences between
distributions (e.g. deb and rpm) all bundle packaging systems can co-exist peacefully on
one machine without conflicts.

Now for a small bit of additional information. I’m currently quite busy with an ongoing
sprint but I will be at the Fedora flock conference next week in Krakow. I will be there
just for a day or two but if anyone wants to chat about SELinux or snappy in particular
I’m glad to do that. After I’m done sprinting and traveling I plan to actually make good
on my claims by writing some code :-)

Best regards
ZK

[Matthew Miller]

On Thu, Jul 28, 2016 at 02:27:19PM +0200, Zygmunt Krynicki wrote:
>  I very much share this view. Snaps are just glorified zip files
>  (squashfs images) that have just enough meta-data to make themselves
>  useful. Because snaps just declare the integration the particular
>  implementation can figure out how to actually do things that are
>  meaningful in a given context. This can include command line tools,
>  graphical applications and the security interaction are just not
>  hardcoded in the actual snap but are only declared in a very
>  high-level form and language that can be implemented correctly in
>  various ways, depending on the environment in which the snap is being
>  used. 
Is there any effort to coordinate this with the Open Container
Initiative?


-- 
Matthew Miller
<mattdm(a)fedoraproject.org&gt;
Fedora Project Leader