Re: Snapcraft, Snappy

2016-07-10 Thread Oliver Grawert
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

Re: Snapcraft, Snappy

2016-07-10 Thread Ralf Mardorf
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

Re: Snapcraft, Snappy

2016-07-10 Thread Ralf Mardorf
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

Re: Snapcraft, Snappy

2016-07-10 Thread Oliver Grawert
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 ...

Re: Snapcraft, Snappy

2016-07-10 Thread John Moser
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

Re: Snapcraft, Snappy

2016-07-10 Thread 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.html I guess snapcraft/snappy and anything similar could be useful, but indeed, IMO those are good reasons to not become too much used