Re: Snapcraft, Snappy
On Mon, 2016-07-11 at 20:13 +0200, Oliver Grawert wrote: > snapd is the tool that gets you the "snap" command ... > (i.e: "snap install $package.snap") and is needed to run snaps Thank you, I installed snapd. Regards, Ralf -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Snapcraft, Snappy
On Mon, 11 Jul 2016 19:27:45 +0200, Oliver Grawert wrote: >you want snapd though and uninstall snappy again (sadly the snappy >media player own the package name a little longer already :) I didn't install snappy for Ubuntu. Arch's "snappy" is the same as Ubuntu's "libsnappy1v5". Arch: $ pacman -Ql snappy | grep so.1 snappy /usr/lib/libsnappy.so.1 snappy /usr/lib/libsnappy.so.1.3.0 Ubuntu: $ sudo systemd-nspawn -q dpkg -L libsnappy1v5 | grep so.1 /usr/lib/x86_64-linux-gnu/libsnappy.so.1.3.0 /usr/lib/x86_64-linux-gnu/libsnappy.so.1 I didn't install snapd, since it's neither a(n optional) dependency of snapcraft, nor of libsnappy1v5. Is it needed [1]? Btw. I only maintain Ubuntu by systemd-nspawn, since I use Arch most of the times. If I use Ubuntu, then I don't run it in a systemd-nspawn container. Regards, Ralf [1] by a quick search I found this ( http://www.omgubuntu.co.uk/2016/06/snap-to-be-universal-linux-package-format): Here is a quote directly from the snapcraft.io site to help stop people from being scared away: "Snaps don’t intrinsically depend on the Ubuntu store, that’s just what snapd does today, and we expect people will have different stores for their snaps in future." -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Snapcraft, Snappy
hi, Am Montag, den 11.07.2016, 19:15 +0200 schrieb Ralf Mardorf: > On Mon, 2016-07-11 at 15:51 +0200, Oliver Grawert wrote: > > > > in case you want to know more details ... > If I find the time to care about it, I'll give it a go. > I started with installing snappy and snapcraft ;). cool ... > > [rocketmouse@archlinux moonstudio]$ sudo systemd-nspawn -q dpkg -l > libsnappy1v5 snapcraft snapcraft-examples|grep ii > ii libsnappy1v5:amd64 1.1.3-2 amd64fast > compression/decompression library > ii snapcraft 2.12 all easily craft snaps > ii snapcraft-examples 2.12 all examples and demos > for snapcraft > [rocketmouse@archlinux moonstudio]$ pacman -Q snappy snapcraft > snappy 1.1.3-2 > snapcraft 2.12-1 > you want snapd though and uninstall snappy again (sadly the snappy media player own the package name a little longer already :) i'm curious how/if it works under systemd-nspawn ciao oli signature.asc Description: This is a digitally signed message part -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Snapcraft, Snappy
On Mon, 2016-07-11 at 15:51 +0200, Oliver Grawert wrote: > in case you want to know more details ... If I find the time to care about it, I'll give it a go. I started with installing snappy and snapcraft ;). [rocketmouse@archlinux moonstudio]$ sudo systemd-nspawn -q dpkg -l libsnappy1v5 snapcraft snapcraft-examples|grep ii ii libsnappy1v5:amd64 1.1.3-2 amd64fast compression/decompression library ii snapcraft 2.12 all easily craft snaps ii snapcraft-examples 2.12 all examples and demos for snapcraft [rocketmouse@archlinux moonstudio]$ pacman -Q snappy snapcraft snappy 1.1.3-2 snapcraft 2.12-1 -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Snapcraft, Snappy
hi, Am Montag, den 11.07.2016, 13:17 +0200 schrieb Oliver Grawert: ... there is a very detailed description at https://developer.ubuntu.com/en/snappy/guides/security-whitepaper/ in case you want to know more details ... ciao oli signature.asc Description: This is a digitally signed message part -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Snapcraft, Snappy
hi, Am Montag, den 11.07.2016, 12:27 +0200 schrieb Ralf Mardorf: > On Mon, 2016-07-11 at 10:34 +0100, Robie Basak wrote: > > but see: reality > > I only see an advantage for Ubuntu LTS releases. For regular Ubuntu > releases, let alone rolling releases, such as Arch, this approach IMO is > a step into the wrong direction. say i'm an upstream dev who wants to provide his app to as many users as possible with as little work for me as possible (i'm an upstream dev, not a packager, why should i learn rpm or deb packaging) ... do you think i would provide a package for rolling distro $X where all libraries i depend on are constantly changing ? i would have to permanently monitor that one distro to make sure my app still works ... instead i can have a package format that works on all distros (snapd is in ubuntu, debian, arch and gentoo, it is available for fedora and opensuse) and that i can define with a few lines in a single snapcraft.yasml file. if i want to do a release i have to do exactly one upload and my app is avaliable to all distros, be it LTS enterprise ones, or the latest rolling release of foobar what do you think i as upstream would pick here ? OTOH ... i as a distro maintainer appreciate that i do not have to actually care for enduser apps anymore and i can fully concentrate on the base install and make that rock, the distro focus gets a lot smaller which frees up a lot manpower for bug fixing and improvements. (also note that there is a snappy distro image (where rootfs, kernel and bootloader are snaps too), which is a completely rolling distro, if ubuntu ever goes fully rolling, snappy will be the base i guess) ciao oli signature.asc Description: This is a digitally signed message part -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Snapcraft, Snappy
On Mon, Jul 11, 2016 at 12:27:47PM +0200, Ralf Mardorf wrote: > On Mon, 2016-07-11 at 10:34 +0100, Robie Basak wrote: > > but see: reality > > I only see an advantage for Ubuntu LTS releases. For regular Ubuntu > releases, let alone rolling releases, such as Arch, this approach IMO is > a step into the wrong direction. Snaps take nothing away from the traditional distribution. If you want to keep consuming distribution packages, you can. If you want to keep maintaining distribution packages, you can. [...] > A distro might provide a buggy package and instead of reporting bugs, > users simply snap something from upstream or a third party. The installs > become rag rugs, users don't share similar set ups anymore, communities > as we know them today will die out. Instead of distros, with different > targets, it leads to a vast, chaotic community without a clear target. If this happened, users would prefer the distribution packages because they'd clearly be better. It would be self-correcting. I really don't think your predicted apocalypse will happen. We already see this today: upstreams produce third party deb repositories or "curl ...|sudo sh" installers, yet distribution maintainers still package them and (some) users still use them. > Such containers are garden fence inside user space. This is what makes > restricted operating systems less good, than open operating systems. On the contrary. You're still Free (as in speech) to adjust things on your own system. But enforcing a more modular approach makes for better quality software. As a distribution engineer, I'm too familiar in finding broken packages or upstreams which accidentally stomp somewhere on the system that they shouldn't. The reason that release upgrades aren't more reliable is because of this lack of modularity. Sure, they are bugs and they get fixed. But modular systems with well-defined interfaces between them have a lower bug rate. -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Snapcraft, Snappy
On Mon, 2016-07-11 at 10:34 +0100, Robie Basak wrote: > but see: reality I only see an advantage for Ubuntu LTS releases. For regular Ubuntu releases, let alone rolling releases, such as Arch, this approach IMO is a step into the wrong direction. I consider to use it for my Ubuntu LTS, but just for exceptions, if it really should make sense, otherwise it wouldn't make sense to stay with an LTS at all. Sometimes this approach could be useful to provide some kind of long term support within regular Ubuntu releases or rolling release distros. OTOH there already is the option to chose between LTS releases and releases that are closer to upstream, mixing LTS and non-LTS IMO only is useful for exceptions. If it's done on a regular basis, it might not necessarily directly affect security, but it affects the way the community works. A distro might provide a buggy package and instead of reporting bugs, users simply snap something from upstream or a third party. The installs become rag rugs, users don't share similar set ups anymore, communities as we know them today will die out. Instead of distros, with different targets, it leads to a vast, chaotic community without a clear target. Such containers are garden fence inside user space. This is what makes restricted operating systems less good, than open operating systems. This is my POV without even having tested Snappy or something similar. I might change my mind after I have tested it. However, I'm sceptic. Regards, Ralf -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Snapcraft, Snappy
On Sun, Jul 10, 2016 at 05:11:06PM +0200, Ralf Mardorf wrote: > there's an interesting counter-argument against something similar to > snapcraft/snappy. > > https://lists.archlinux.org/pipermail/arch-general/2016-July/041579.html The fact is that third parties ship unconfined binaries directly to users today. Look at the number of projects which instruct users to add a third party deb repository to sources.list, or to "curl ... | sudo sh" or similar. >From this perspective, Snappy improves the situation massively. If a user's choice is between running some third party's binary installer as root, and installing a Snap, then it's clear which is the better option. It's all very well to say that all of these Snaps should instead be distribution packages in backports (or equivalent) pockets, but see: reality. There's a reason fpm exists. And even if distribution archive were perfectly up to date, distribution packages don't currently provide the same level of individual package isolation that Snaps do. -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Snapcraft, Snappy
hi, Am Montag, den 11.07.2016, 00:08 +0200 schrieb Ralf Mardorf: > The important concern is related to lose track of what is inside all > those containers. Imagine some containers depend on > except that there are no containers ... yes, it might be that an app ships a vulnerable TLS lib in the snap... that single app would be vulnerable until the upstream updates it ... there is an opportunity to ship a TLS lib inside he execution env as well and make it available to all snaps ... in which case you would have this bit covered by the ubuntu security team... another option is to use the upcoming content interface that allows sharing of binary content between snaps (i.e. libs) so a libssl snap provided from the ubuntu security archive would be an opportunity too in case you are a lazy upstream and do not want to update your snap for such issues ... snappy is very flexible here ;) ciao oli signature.asc Description: This is a digitally signed message part -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Snapcraft, Snappy
On Mon, 11 Jul 2016 00:08:48 +0200, Ralf Mardorf wrote: >The important concern is related to lose track of what is inside all >those containers. Imagine some containers depend on > >https://cve.mitre.org/cgi-bin/cvename.cgi?name=cve-2014-0160 > >Two years ago, all communities were aware about it and after a few days >it wasn't an issue anymore. > >If the so called averaged computer user does roll her own containers, >it's much harder to rule out such an issue that quickly. I read the security risk existed for 27 month, but IIRC when it became public it was quickly eliminated, within a week or so. -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Snapcraft, Snappy
The important concern is related to lose track of what is inside all those containers. Imagine some containers depend on https://cve.mitre.org/cgi-bin/cvename.cgi?name=cve-2014-0160 Two years ago, all communities were aware about it and after a few days it wasn't an issue anymore. If the so called averaged computer user does roll her own containers, it's much harder to rule out such an issue that quickly. -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Snapcraft, Snappy
hi, Am Sonntag, den 10.07.2016, 17:11 +0200 schrieb Ralf Mardorf: > Hi, > > there's an interesting counter-argument against something similar to > snapcraft/snappy. > > https://lists.archlinux.org/pipermail/arch-general/2016-July/041579.h > tml well, this is about flatpack not snappy ... comparing apples with peas ... ;) snappy uses completely different confinement mechanisms (apparmor, seccomp, packages being 100% readonly, the exec env being readonly etc), and while it is true that shipped dependencies of an app can actually be compromised, the confinement will save you from ill effects on your system through that. yes, one app *can* have a compromised libssl in the snap, but that security breach will exactly only apply to that one app, there is no way for it to affect the system or any other apps (unless the user told it to by enabling any cross snap interfaces) if your kernel would be broken enough to actually circumvent the used security mechanisms above, i guess issues in snap packages would be the least of your problems :) ciao oli signature.asc Description: This is a digitally signed message part -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Snapcraft, Snappy
On Sun, 2016-07-10 at 17:11 +0200, Ralf Mardorf wrote: > Hi, > > there's an interesting counter-argument against something similar to > snapcraft/snappy. > > https://lists.archlinux.org/pipermail/arch-general/2016-July/041579.h > tml > That's the security team going off into lala land with a bunch of overblown wargarble. Basically, containers completely, 100% perfectly isolate software on the system from other software execution environments. That means the file system, devices, network stacks (tcpdump!), and so forth are all as reachable as if you're on another machine. The Security team points out that a kernel-level exploit will allow you to route around this. They take that observation to mean that containers supply zero security, and that a compromise in a container is a system level compromise. To follow that logic completely: there's no such thing as security anyway, because Linux has to accept a TCP packet into its network stack to even look at it in iptables, thus any network-reachable machine is already compromised. The argument from the security team essentially fails to create risk models and assess probability and severity of the compromises they describe. Instead of recognizing, categorizing, and accounting for those risks, they just run around flailing their arms and scream that the sky is falling into the face of every passer-by to whom they can get close enough. Whoever wrote that message isn't qualified to handle computer security concerns. > I guess snapcraft/snappy and anything similar could be useful, but > indeed, IMO those are good reasons to not become too much used to > this > approach. > > Regards, > Ralf > -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Snapcraft, Snappy
Hi, there's an interesting counter-argument against something similar to snapcraft/snappy. https://lists.archlinux.org/pipermail/arch-general/2016-July/041579.html I guess snapcraft/snappy and anything similar could be useful, but indeed, IMO those are good reasons to not become too much used to this approach. Regards, Ralf -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Snapcraft, Snappy
On Sat, 09 Jul 2016 17:21:03 +0200, Oliver Grawert wrote: >hi, >Am Samstag, den 09.07.2016, 16:52 +0200 schrieb Ralf Mardorf: >> Hi, >> >> on Ubuntu devel "snapcraft" was mentioned today. I made some Internet >> research and Snappy was even mentioned on a RME forum. I wonder it >> it's >> a sandbox or virtualization, that could cause issues with real-time >> and/or jack connections with "regular" apps. IOW I don't understand, >> if >> there is an additional layer, a separation or if it's just like a >> regular install to /opt, without using shared libs, but also without >> a >> layer, IOW without a separation? >> >> Sometimes German Ubuntu help pages are better than the English pages, >> but regarding this topic, there seem to be no German Ubuntu Wikis at >> all. >> >the snap/snapcraft mailing list is at https://lists.ubuntu.com/mailman/ >listinfo/snapcraft > >some details about snappy can be found at http://snapcraft.io/ > >regarding the setup, it is kind of neither virtualization, nor >container, nor sandbox ... > >snapd ships its own execution environment for snaps (which you could >call a container), but then bind mounts bits and pieces from the host >system readonly into that environment. then it wraps all execution with >apparmor and seccomp monitoring (which you could call a sandbox, but it >reallly isnt one :) ) ... > >that confinement then offers interfaces a snap can use through which >you get direct access to i.e. hardware or other system resources (...if >the user permits, imagine the android or IOS permission system here) >snaps can offer interfaces for other snaps or just consume existing >interfaces. > >so to answer your question about realtime, it should be completely >possible to have realtime apps use snappy but will likely need >additional interfaces added (you can always install a snap with the -- >devmode option which switches off all confinement. in this case it >would not behave different to some bundled binary you simply installed >to /opt as you described above) > >i hope that clearifies some bits ;) > >ciao > oli Hi Oli, too funny, my intention was to sent it to Ubuntu Studio devel mailing list, I send it by accident to this list. I hope that somebody from Ubuntu Studio devel has got experiences with audio apps and this approach. Thank you, for the summarized explanation. I still will send a request to Ubuntu Studio devel and I'll add a link to your explanation ;), or simply forward this reply. Regards, Ralf -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Snapcraft, Snappy
hi, Am Samstag, den 09.07.2016, 16:52 +0200 schrieb Ralf Mardorf: > Hi, > > on Ubuntu devel "snapcraft" was mentioned today. I made some Internet > research and Snappy was even mentioned on a RME forum. I wonder it > it's > a sandbox or virtualization, that could cause issues with real-time > and/or jack connections with "regular" apps. IOW I don't understand, > if > there is an additional layer, a separation or if it's just like a > regular install to /opt, without using shared libs, but also without > a > layer, IOW without a separation? > > Sometimes German Ubuntu help pages are better than the English pages, > but regarding this topic, there seem to be no German Ubuntu Wikis at > all. > the snap/snapcraft mailing list is at https://lists.ubuntu.com/mailman/ listinfo/snapcraft some details about snappy can be found at http://snapcraft.io/ regarding the setup, it is kind of neither virtualization, nor container, nor sandbox ... snapd ships its own execution environment for snaps (which you could call a container), but then bind mounts bits and pieces from the host system readonly into that environment. then it wraps all execution with apparmor and seccomp monitoring (which you could call a sandbox, but it reallly isnt one :) ) ... that confinement then offers interfaces a snap can use through which you get direct access to i.e. hardware or other system resources (...if the user permits, imagine the android or IOS permission system here) snaps can offer interfaces for other snaps or just consume existing interfaces. so to answer your question about realtime, it should be completely possible to have realtime apps use snappy but will likely need additional interfaces added (you can always install a snap with the -- devmode option which switches off all confinement. in this case it would not behave different to some bundled binary you simply installed to /opt as you described above) i hope that clearifies some bits ;) ciao oli signature.asc Description: This is a digitally signed message part -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Snapcraft, Snappy
Hi, on Ubuntu devel "snapcraft" was mentioned today. I made some Internet research and Snappy was even mentioned on a RME forum. I wonder it it's a sandbox or virtualization, that could cause issues with real-time and/or jack connections with "regular" apps. IOW I don't understand, if there is an additional layer, a separation or if it's just like a regular install to /opt, without using shared libs, but also without a layer, IOW without a separation? Sometimes German Ubuntu help pages are better than the English pages, but regarding this topic, there seem to be no German Ubuntu Wikis at all. Regards, Ralf -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
