[Nix-dev] Improving security updates

Domen Kožar domen at dev.si
Fri Apr 10 21:52:51 CEST 2015


On Fri, Apr 10, 2015 at 3:49 PM, Christian Theune <ct at flyingcircus.io>
wrote:

> Hi,
>
> > On 10 Apr 2015, at 21:40, Domen Kožar <domen at dev.si> wrote:
> >
> > This is extremely important for companies. It's why Gentoo has failed so
> bad in any commercial environment.
>
> I agree in general, but would like to make a specific annotation: I like
> the Gentoo security update model _a lot_ more than any others.
>
> We run our machines (few hundred) on a snapshot of portage that can be a
> few months old: our environment is tightly checked for compatibility,
> almost like you guys do with channels. We like to pick updates.
>
> Gentoo (and I don’t know whether any of the others do this) provides us a
> tool that points out which of the installed packages have known
> vulnerabilities.
>
> This is basically *everything* I need for a reliable security process on
> my end. Actually providing a patch and integrating that patch into my
> environment is awesome if done at the same time in upstream, but I’d rather
> know which packages (of an old installation) are affected by security
> issues and then go ahead and fix them (e.g. by cherry picking some upstream
> updates).
>
> This has worked well for us with the exception of some Gentoo-specific
> annoyances, that I’m not sure apply here: cherry picking updates obviously
> becomes harder over time when you copy ebuilds around that require insane
> amounts of structural dependencies from the portage tree.
>

Yup - which translates to: if you're using Gentoo you're rolling your own
security updates. That's why the adoption is really low.


>
> > Everyone I talk to about Nix (in my past long experience at conferences,
> meetups, etc), they'd raise two questions:
> >
> > - How does it compare with docker and can it be used together?
> >
> > - How do you handle security updates
> >
> > I have poor answers to both questions as both topics are currently done
> very poorly. A lot to improve here, I think we should
> > start with meta-issues for discussion and general todos.
>
> My personal answer to question 1: is it provides a different axis and I’m
> kinda glad i don’t necessarily have to touch Docker … ;)
>
> While working towards getting nix in regular use over here I also keep
> pondering question number two.
>


It does provide a different axis but I also think that Docker needs Nix
desperately. Nix would allow Docker to build minimal runtime dependency
graphs that can be managed.

Small NixOS docker profile + multiple outputs to reduce closure size is a
great way to mostly achieve that goal.

Domen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.science.uu.nl/pipermail/nix-dev/attachments/20150410/1e6d7930/attachment.html 


More information about the nix-dev mailing list