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
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 an
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 call
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 ... compari
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 bu
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
