Re: [Nix-dev] Improving security updates
The page https://nixos.org/wiki/Security_Updates isn't very user friendly. It requires too much of the user (treats servers like pets and not like cattle): 1. Monitor package vulnerabilities. 2. Manually override the packages that have vulnerabilities. Rebuild. 3. Manually remove the the override when it no longer needs it. Rebuild. Multiply that by each server. It really should be automatic or at least through one command that is prompted. Secondly I'd prefer step 3 to not be required. Once its overridden, and if/when the channel catches up it shouldn't cause another change. The bot idea sounds great. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Improving security updates
On 04/11/2015 01:13 AM, Roger Qiu wrote: The page https://nixos.org/wiki/Security_Updates isn't very user friendly. It requires too much of the user (treats servers like pets and not like cattle): 1. Monitor package vulnerabilities. 2. Manually override the packages that have vulnerabilities. Rebuild. 3. Manually remove the the override when it no longer needs it. Rebuild. Multiply that by each server. It really should be automatic or at least through one command that is prompted. Secondly I'd prefer step 3 to not be required. Once its overridden, and if/when the channel catches up it shouldn't cause another change. IMO it's all work that has to be done by some humans in the end. Sure, they can use tools (like nixpkgs monitor for 1); and they can e.g. commit this into a separate nixpkgs branch containing the manual overrides atop some other channel, so others can just use this branch. But there's a question whether some people will do this work. It seems to me there aren't too many vulnerabilities for which people prefer doing such extra work instead of e.g. waiting a few days for the -small channel (perhaps I'm wrong). I always see some vulnerabilities on nixpkgs monitor that don't get fixed in any way for many weeks or months; they probably aren't too important, and I'm trying to fix those looking dangerous from time to time, but still... Step 3 requires changing of hashes in paths (at least until intensional store). Vladimir smime.p7s Description: S/MIME Cryptographic Signature ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Improving security updates
On 12 April 2015 at 11:57, Nicolas Pierron nicolas.b.pier...@gmail.com wrote: On Sun, Apr 12, 2015 at 7:45 PM, James Cook james.c...@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). Right, that makes sense. Thanks for the explanation. James ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Improving security updates
On 10 April 2015 at 14:16, Nicolas Pierron nicolas.b.pier...@gmail.com wrote:
Hi,
On Fri, Apr 10, 2015 at 7:12 PM, CodeHero codeh...@nerdpol.ch wrote:
So, after this huge update delay for nixos-unstable I think we should
talk about improving the way security updates are handled. One can
currently install security upgrades by using the instructions on this
page (https://nixos.org/wiki/Security_Updates), but it's a lot of work
to find all the libs that need those updates; and flagging packages as
security updates will most likely not work without a dedicated security
team.
We've been brainstorming a little bit on the irc
(https://botbot.me/freenode/nixos/2015-04-10/?msg=36316600page=4), and
we came up with a few ideas. I personally like the extra security branch
idea, but i'm not sure how it would work out
(https://botbot.me/freenode/nixos/2015-04-10/?msg=36318539page=5), so
that's why I'm asking here. Maybe somebody has some ideas and the
know-how to make things better.
The question is: who has suggestions on how to improve the installation
of critical security updates; who knows how to implement the best
suggestion; and who will maintain it?
I want to enumerate a few points that we should keep in mind:
1. This should be done as part of nixpkgs, and not as part of nixos
2. This should be transparent for the end user.
3. We should provide tools to watch for security updates. (polling /
push-notifications)
Currently the only way to provide fast security updates is to
substitute in-place the packages which are vulnerable. I do not think
that we have better alternative here.
Still, I think there is a problem with the approach suggested on the
wiki (https://nixos.org/wiki/Security_Updates ), which is that there
is no automatic relation between the original package and the fix.
The problem I can see with `replaceDependency`, is that we replace
`hash-vul` by `hash-fix` in one derivation, but not in all derivations
which are depending on `hash-vul`.
This leads to 2 questions:
- How do we know that `hash-vul` is vulnerable ?
- How do we know that one derivation depends on `hash-fix` ?
Nixpkgs does not know about anything about runtime dependecies (except
for cross-compilation), it only know things about build dependencies.
This implies that one package can depend on a dependency of its
dependencies. Thus we have to carry over the hash substitution of the
dependencies.
A: buildInputs = [ B ];
B: buildInputs = [ C ];
C: [ { vul = ; fix = ; } ]
A: [ /* A */ { vul = ; fix = ; } /* B */ { vul = ; fix = ; } /* C */ {
vul = ; fix = ; } ]
B: [ /* B */ { vul = ; fix = ; } /* C */ { vul = ; fix = ; } ]
C: [ /* C */ { vul = ; fix = ; } ]
So basically, we want a channel, which is constructed by merging the
`last`, with the `small`. Basically, the merge will flag all `small`
(fix) packages as being a replacement of the `last` (vulnerable).
Then we replace the `stdenv.mkDerivation` function to do the
substitution if the original derivation depends on a fixed small
package.
This method implies that we should never bump the version of small
packages across ABI-incompatible changes. Which means that we would
have to ensure that any small package is versioned in nixpkgs, at
least until the next `last` channel update.
At the end, the small channel should mirror the latest channel, with
delta binary patches for all fixes of the small packages.
I think this is all :)
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?
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?
Then, because of some magic (you're suggesting in
stdenv.mkDerivation), a new version of everything that depends
directly or indirectly on libtasn1 (or any other fixed package) is
built. This building is fast, since it just involves taking the
original output and doing some post-processing. (Does this happen by
renaming pkgs to pkgsBeforeFixes, and setting pkgs =
fancyNewApplyFixesFunction pkgsBeforeFixes in all-packages.nix?)
Is that correct?
Side questions:
- Why does stdenv.mkDerivation need to be clever? Why not just blindly
apply all the fixes to every package?
- What are the `small` and `last` you rever to above?
I hope my questions make sense.
Thanks,
James
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Improving security updates
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. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Improving security updates
On Sun, Apr 12, 2015 at 7:45 PM, James Cook james.c...@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/ ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Improving security updates
On Sat, Apr 11, 2015 at 12:57 AM Jonathan Glines auntie...@gmail.com wrote: 2015/04/10 15:54 Bjørn Forsman bjorn.fors...@gmail.com: On 10 April 2015 at 23:35, Jonathan Glines auntie...@gmail.com wrote: [...] I think it would be useful to have a bump bot for nixpkgs that could scan meta data and catalog exactly which packages are out of date. The bot would pull data from multiple sources (package mirrors, other distros, security feeds) to warn about major version bumps and security advisories. Maintainers could then use output from the bot to see at a glance which of their packages are out of date. Maybe even with a web interface with graphs and charts to compare against other Linux distros and upstream. Distrowatch already does something similar for select few important packages. Sounds very much like the Nixpkgs Monitor :-) Wow, that's amazing. How did you set that up so quickly? ;) The Monitor has been there for a year or so. http://monitor.nixos.org/ - Bjørn ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Improving security updates
Hi, On 10 Apr 2015, at 21:40, Domen Kožar do...@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. 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. Christian — Christian Theune · c...@flyingcircus.io · +49 345 219401 0 Flying Circus Internet Operations GmbH · http://flyingcircus.io Forsterstraße 29 · 06112 Halle (Saale) · Deutschland HR Stendal HRB 21169 · Geschäftsführer: Christian. Theune, Christian. Zagrodnick signature.asc Description: Message signed with OpenPGP using GPGMail ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Improving security updates
On Fri, Apr 10, 2015 at 3:49 PM, Christian Theune c...@flyingcircus.io wrote: Hi, On 10 Apr 2015, at 21:40, Domen Kožar do...@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 ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Improving security updates
Hi, On 10 Apr 2015, at 21:52, Domen Kožar do...@dev.si wrote: Yup - which translates to: if you're using Gentoo you're rolling your own security updates. That's why the adoption is really low. Right. Obviously I’d like to have eat my cake and have it. My gain is a support-horizon for a certain “release” that is different/longer than what upstream does (i.e. I can make my own choices whether updating really fits on my plate in sync with upstream). Wiggle room is nice to have - but we have to pay for it, of course. But: my point was that my experience with the multi-step system is a good one. a) noticing which packages have a problem b) marking packages as afflicted c) noticing which of those packages are actually in use. What Gentoo lacked for a while (and this was extremely critical at times) was good tooling that keeps the effort low (it was supposedly insane to do the work so nobody really volunteered) and the security team was almost non-existent at some point. It’s better now but not as good as I’d like it. Interestingly the hardest part is the “discover which vulnerabilities exist and which are important to us” needs to be solved by everyone, and apparently, everyone anew. Everything after that seems trivial to me, but I might be blind. ;) Christian — Christian Theune · c...@flyingcircus.io · +49 345 219401 0 Flying Circus Internet Operations GmbH · http://flyingcircus.io Forsterstraße 29 · 06112 Halle (Saale) · Deutschland HR Stendal HRB 21169 · Geschäftsführer: Christian. Theune, Christian. Zagrodnick signature.asc Description: Message signed with OpenPGP using GPGMail ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Improving security updates
On Fri, Apr 10, 2015 at 4:03 PM, Christian Theune c...@flyingcircus.io wrote: Hi, On 10 Apr 2015, at 21:52, Domen Kožar do...@dev.si wrote: Yup - which translates to: if you're using Gentoo you're rolling your own security updates. That's why the adoption is really low. Right. Obviously I’d like to have eat my cake and have it. My gain is a support-horizon for a certain “release” that is different/longer than what upstream does (i.e. I can make my own choices whether updating really fits on my plate in sync with upstream). Wiggle room is nice to have - but we have to pay for it, of course. But: my point was that my experience with the multi-step system is a good one. a) noticing which packages have a problem b) marking packages as afflicted c) noticing which of those packages are actually in use. What Gentoo lacked for a while (and this was extremely critical at times) was good tooling that keeps the effort low (it was supposedly insane to do the work so nobody really volunteered) and the security team was almost non-existent at some point. It’s better now but not as good as I’d like it. Interestingly the hardest part is the “discover which vulnerabilities exist and which are important to us” needs to be solved by everyone, and apparently, everyone anew. Everything after that seems trivial to me, but I might be blind. ;) I can fully agree - which basically translates to: once enough companies we using Nix we can sit down and write this up :) ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Improving security updates
On 10 Apr 2015, at 22:07, Domen Kožar do...@dev.si wrote: I can fully agree - which basically translates to: once enough companies we using Nix we can sit down and write this up :) Can’t follow you here. Write what up? I’m not decided whether more tooling/automation for monitoring potential issues and then checking them out is needed or whether just more manual labour needs to be distributed in a standardized and reliable way, or something else. Also, from a company perspective I’d be happy if we can contribute small (read: reasonable, scalable) amounts of time (and effort) to help with something that we use substantially. How does that fit in your perspective? I’d be happy to join earlier if that helps. Christian — Christian Theune · c...@flyingcircus.io · +49 345 219401 0 Flying Circus Internet Operations GmbH · http://flyingcircus.io Forsterstraße 29 · 06112 Halle (Saale) · Deutschland HR Stendal HRB 21169 · Geschäftsführer: Christian. Theune, Christian. Zagrodnick signature.asc Description: Message signed with OpenPGP using GPGMail ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Improving security updates
On Fri, Apr 10, 2015 at 4:09 PM, Christian Theune c...@flyingcircus.io wrote: On 10 Apr 2015, at 22:07, Domen Kožar do...@dev.si wrote: I can fully agree - which basically translates to: once enough companies we using Nix we can sit down and write this up :) Can’t follow you here. Write what up? I’m not decided whether more tooling/automation for monitoring potential issues and then checking them out is needed or whether just more manual labour needs to be distributed in a standardized and reliable way, or something else. Also, from a company perspective I’d be happy if we can contribute small (read: reasonable, scalable) amounts of time (and effort) to help with something that we use substantially. How does that fit in your perspective? I’d be happy to join earlier if that helps. That's what I meant - sitting down together (sprints!) and writing those tools to help us automate security vulns monitoring for Nix. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Improving security updates
So the next level on discussion from there would be: what kind of tooling to people expect and what workflow should they support? Is there anything in peoples heads already? Is that something that I just missed by being late to the game and the “work just needs to be done”? Or are we at the point of “need some design that the community agrees upon”? Yup, that's part of the sitting down. In any case: I’ll likely drop out of the conversation for now as I’m minutes away to head off to vacation mode … :) Cheers and hope everyone enjoys Pycon! o/ ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Improving security updates
Hi,
On Fri, Apr 10, 2015 at 7:12 PM, CodeHero codeh...@nerdpol.ch wrote:
So, after this huge update delay for nixos-unstable I think we should
talk about improving the way security updates are handled. One can
currently install security upgrades by using the instructions on this
page (https://nixos.org/wiki/Security_Updates), but it's a lot of work
to find all the libs that need those updates; and flagging packages as
security updates will most likely not work without a dedicated security
team.
We've been brainstorming a little bit on the irc
(https://botbot.me/freenode/nixos/2015-04-10/?msg=36316600page=4), and
we came up with a few ideas. I personally like the extra security branch
idea, but i'm not sure how it would work out
(https://botbot.me/freenode/nixos/2015-04-10/?msg=36318539page=5), so
that's why I'm asking here. Maybe somebody has some ideas and the
know-how to make things better.
The question is: who has suggestions on how to improve the installation
of critical security updates; who knows how to implement the best
suggestion; and who will maintain it?
I want to enumerate a few points that we should keep in mind:
1. This should be done as part of nixpkgs, and not as part of nixos
2. This should be transparent for the end user.
3. We should provide tools to watch for security updates. (polling /
push-notifications)
Currently the only way to provide fast security updates is to
substitute in-place the packages which are vulnerable. I do not think
that we have better alternative here.
Still, I think there is a problem with the approach suggested on the
wiki (https://nixos.org/wiki/Security_Updates ), which is that there
is no automatic relation between the original package and the fix.
The problem I can see with `replaceDependency`, is that we replace
`hash-vul` by `hash-fix` in one derivation, but not in all derivations
which are depending on `hash-vul`.
This leads to 2 questions:
- How do we know that `hash-vul` is vulnerable ?
- How do we know that one derivation depends on `hash-fix` ?
Nixpkgs does not know about anything about runtime dependecies (except
for cross-compilation), it only know things about build dependencies.
This implies that one package can depend on a dependency of its
dependencies. Thus we have to carry over the hash substitution of the
dependencies.
A: buildInputs = [ B ];
B: buildInputs = [ C ];
C: [ { vul = ; fix = ; } ]
A: [ /* A */ { vul = ; fix = ; } /* B */ { vul = ; fix = ; } /* C */ {
vul = ; fix = ; } ]
B: [ /* B */ { vul = ; fix = ; } /* C */ { vul = ; fix = ; } ]
C: [ /* C */ { vul = ; fix = ; } ]
So basically, we want a channel, which is constructed by merging the
`last`, with the `small`. Basically, the merge will flag all `small`
(fix) packages as being a replacement of the `last` (vulnerable).
Then we replace the `stdenv.mkDerivation` function to do the
substitution if the original derivation depends on a fixed small
package.
This method implies that we should never bump the version of small
packages across ABI-incompatible changes. Which means that we would
have to ensure that any small package is versioned in nixpkgs, at
least until the next `last` channel update.
At the end, the small channel should mirror the latest channel, with
delta binary patches for all fixes of the small packages.
I think this is all :)
--
Nicolas Pierron
http://www.linkedin.com/in/nicolasbpierron - http://nbp.name/
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Improving security updates
2015-04-10 14:20 GMT-06:00 Christian Theune c...@flyingcircus.io: Hi, On 10 Apr 2015, at 22:16, Domen Kožar do...@dev.si wrote: That's what I meant - sitting down together (sprints!) and writing those tools to help us automate security vulns monitoring for Nix. So the next level on discussion from there would be: what kind of tooling to people expect and what workflow should they support? I think the typical sysadmin attitude towards security is I don't have time for this, but I still gotta cover my ass. So it would be nice to have a set and forget type of tool that can be trusted to automatically (or semi-automatically) pull in out-of-band security patches, similar to how Ubuntu security updates work. Is there anything in peoples heads already? Is that something that I just missed by being late to the game and the “work just needs to be done”? Or are we at the point of “need some design that the community agrees upon”? Speaking of things in my head, I have been thinking about something related to this... I think it would be useful to have a bump bot for nixpkgs that could scan meta data and catalog exactly which packages are out of date. The bot would pull data from multiple sources (package mirrors, other distros, security feeds) to warn about major version bumps and security advisories. Maintainers could then use output from the bot to see at a glance which of their packages are out of date. Maybe even with a web interface with graphs and charts to compare against other Linux distros and upstream. Distrowatch already does something similar for select few important packages. That's my practical solution to the opaqueness of manually comparing package versions in nixpkgs to a security feed that we trust someone is actually watching. Just throwing that out there. If it sounds useful, give me some tips/encouragement and I might prototype something. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Improving security updates
On 10 April 2015 at 23:35, Jonathan Glines auntie...@gmail.com wrote: [...] I think it would be useful to have a bump bot for nixpkgs that could scan meta data and catalog exactly which packages are out of date. The bot would pull data from multiple sources (package mirrors, other distros, security feeds) to warn about major version bumps and security advisories. Maintainers could then use output from the bot to see at a glance which of their packages are out of date. Maybe even with a web interface with graphs and charts to compare against other Linux distros and upstream. Distrowatch already does something similar for select few important packages. Sounds very much like the Nixpkgs Monitor :-) http://monitor.nixos.org/ - Bjørn ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Improving security updates
This Bump bot could open PRs on GIthub (I know, even more PRs...), it's the best place to be sure a person looks at it. It might make sense to start writing down our ideas into a Google Doc? N. On Fri, Apr 10, 2015 at 11:36 PM Jonathan Glines auntie...@gmail.com wrote: 2015-04-10 14:20 GMT-06:00 Christian Theune c...@flyingcircus.io: Hi, On 10 Apr 2015, at 22:16, Domen Kožar do...@dev.si wrote: That's what I meant - sitting down together (sprints!) and writing those tools to help us automate security vulns monitoring for Nix. So the next level on discussion from there would be: what kind of tooling to people expect and what workflow should they support? I think the typical sysadmin attitude towards security is I don't have time for this, but I still gotta cover my ass. So it would be nice to have a set and forget type of tool that can be trusted to automatically (or semi-automatically) pull in out-of-band security patches, similar to how Ubuntu security updates work. Is there anything in peoples heads already? Is that something that I just missed by being late to the game and the “work just needs to be done”? Or are we at the point of “need some design that the community agrees upon”? Speaking of things in my head, I have been thinking about something related to this... I think it would be useful to have a bump bot for nixpkgs that could scan meta data and catalog exactly which packages are out of date. The bot would pull data from multiple sources (package mirrors, other distros, security feeds) to warn about major version bumps and security advisories. Maintainers could then use output from the bot to see at a glance which of their packages are out of date. Maybe even with a web interface with graphs and charts to compare against other Linux distros and upstream. Distrowatch already does something similar for select few important packages. That's my practical solution to the opaqueness of manually comparing package versions in nixpkgs to a security feed that we trust someone is actually watching. Just throwing that out there. If it sounds useful, give me some tips/encouragement and I might prototype something. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Improving security updates
2015/04/10 15:54 Bjørn Forsman bjorn.fors...@gmail.com: On 10 April 2015 at 23:35, Jonathan Glines auntie...@gmail.com wrote: [...] I think it would be useful to have a bump bot for nixpkgs that could scan meta data and catalog exactly which packages are out of date. The bot would pull data from multiple sources (package mirrors, other distros, security feeds) to warn about major version bumps and security advisories. Maintainers could then use output from the bot to see at a glance which of their packages are out of date. Maybe even with a web interface with graphs and charts to compare against other Linux distros and upstream. Distrowatch already does something similar for select few important packages. Sounds very much like the Nixpkgs Monitor :-) Wow, that's amazing. How did you set that up so quickly? ;) http://monitor.nixos.org/ - Bjørn ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
