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
http://www.ubuntu.com/legal/contributors
2016-07-23 2:46 GMT+02:00 Neal Gompa ngompa13@gmail.com:
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.
-- 真実はいつも一つ！/ Always, there's only one truth! -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
On Jul 22, 2016 5:48 PM, "Neal Gompa" ngompa13@gmail.com 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
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
Wiadomość napisana przez Neal Gompa ngompa13@gmail.com 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
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?
-
Andrew Lutomirski -
Haïkel -
Matthew Miller -
Michael Catanzaro -
Neal Gompa -
Zygmunt Krynicki