[Nix-dev] Improving security updates

[James Cook]

>> Dependency replacement has me pretty confused. If someone will indulge
>> me, I want to make sure I understand the above point, or at least how
>> replace-dependency.nix works (assuming that's what you're talking
>> about).
>>
>> First of all, am I correct in assuming that replace-dependency.nix
>> works by taking the output of the old derivation and doing some
>> relatively fast post-processing, looking for symlinks to the old
>> package and replacing with the new?
>
> Almost, basically this looks like doing a search and replace of the
> hash dependency by another in one output.
> Redefining mkDerivation is just a simple way to collect all "patches"
> which have to be done to the output.
>
>> Now, let's work with an example: wget depends on gnutls and gnutls
>> depends on libtasn1. libtasn1 needs to be bumped (GitHub issue 7333).
>>
>> We stalt by building everything with the vulnerable version of libtasn1, right?
>
> If you were to use the --fallback option while using the
> nixpkgs-security channel, yes.
> I guess we can easily restrict this substitution if the derivation
> match one of the pre-built packages of the "lastest" channel (on-top
> of which the nixpkgs-security is build) such that non-prebuilt
> binaries can be build from the latest sources only.

I guess by "building" I meant "downloading the hydra output if you're
following a channel, otherwise building".

(snip)

>> 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
...

Where is the 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?

>> - 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.

Thanks for taking the time.