[Nix-dev] Improving security updates

[Nicolas Pierron]

On Sun, Apr 12, 2015 at 7:45 PM, James Cook <james.cook at utoronto.ca> wrote:
>>> Side questions:
>>> - Why does stdenv.mkDerivation need to be clever? Why not just blindly
>>> apply all the fixes to every package?
>>
>> The substitution is not as simple as doing a "mapAttrs", as this would
>> lead to infinite loops, and would imply that you have to download all
>> the binary version of the fixed packages.
>
> I don't understand the infinite loop part. Don't we want something
> like the following?
>
> pkgs.wget = applyFixesFrom fixes pkgsBeforeFixes.wget
> pkgs.foobar = applyFixesFrom fixes pkgsBeforeFixes.foobar
> ...

No we don't want something which is independent of the dependencies.
And, in your previous expression, if pkgsBeforeFixes.wget depends on a
library which it-self depend on a vulnerable library, then we want
this one to be fixed as well.

Because of the previous reason, making the transformation independent
would imply that all packages would have to be build, which is exactly
what we want to avoid as this is either not working / time consuming
(otherwise hydra would have done it).

> Where is the infinite loop?

The infinite loop comes with the fact that we don't want the
pkgsBeforeFixes.wget, but the pkgsWithFixedDependencies.wget, which
happens to be the one that we are trying to produce.  Thus if the
applyFixesFrom is independent of the list of dependencies, then this
would lead to an infinite loop.

> The issue of having to download all the fixes makes sense. Maybe for
> now the fixes can be divided into rebuild-the-world fixes (which you'd
> probably have to download anyway) and non-rebuild-the-world fixes,
> which can be applied to master the normal way since they won't slow
> down Hydra?

This is not an issue if we redefine mkDerivation, as we would only use
the fixes on which we depend on.

We don't want to have fixes which are rebuilding the world, because
this might be the reason why hydra is lagging behind, but fixes are
likely to be patching the world.

>>> - What are the `small` and `last` you rever to above?
>>
>> I use small (or quick-fix) to refer to the tiny channel of quick fixes.
>> I use last (or stable) to refer to the last good known state of the channel.
>>
>> The security channel is made out of these two, such that we inherit
>> all packages from the stable channel while doing something similar to
>> a mutation based approach on pre-build stable packages with the ABI
>> compatible changes from the quick-fix channel.

On a second thought, I do not think we need a special quick-fix channel at all.
What matters is that we can identify ABI compatible packages, in which
case the nixpkgs-security is just a mirror of the latest channel
update with all changes to all ABI compatible packages applied.

-- 
Nicolas Pierron
http://www.linkedin.com/in/nicolasbpierron - http://nbp.name/