Re: [Nix-dev] Funding Hydra Development
On 01/22/2015 10:43 PM, Raahul Kumar wrote: bit-identical builds. How far are we from that point? Is it the timestamps that most build tools add to their build that prevents it? What's the blocker? We still don't even have fully reproducible stdenv, not even with all of https://github.com/NixOS/nixpkgs/pull/2281 . I have some further WIP on perl, but it ate many days of my time and still isn't fully deterministic. Timestamps are relatively easy to detect, as they always differ, but other things are more difficult: uname, build user name, etc. I think in most cases it just needs some work on *each* package to track it down, although you don't know if it's difficult until you try. Some impurity sources are already blocked generally in all builds. AFAIK only Haskell needs nontrivial changes upstream https://ghc.haskell.org/trac/ghc/ticket/4012 , but there might be more such problems hidden. (I even read about security research that introduces non-determinism into compiler output in a way that's supposed to make common exploits unusable on multiple outputs of the same compilation, so you supposedly wouldn't be able to attack many systems at once.) 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] Funding Hydra Development
nixos@home would be impossible to secure until derivations are bit-for-bit identical on multiple builds. Then you could do something like, have 1000 builders, and if 501 builders get the same output hash for a derivation, it gets accepted on the public ledger of input/output hashes. Grow the builders as the popularity of NixOS grows. You need to subvert a majority of builders to subvert the binaries. ...but we don't have bit-identical builds... yet. On Thu Jan 22 2015 at 3:46:48 AM stewart mackenzie setor...@gmail.com wrote: Forgive me, this is my fault for not being clear enough. Yes I too would feel uncomfortable about a nixos@home setup unless of course it includes some kind of blockchain. Even then it would be too expensive to run. ___ 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] Funding Hydra Development
On Thu, Jan 22, 2015 at 8:52 PM, Vladimír Čunát vcu...@gmail.com wrote: (They can distribute the content signed by trusted people, but distribution isn't much of a problem in our case, IMHO.) Data dissemination over a point-to-point network is a costly affair. It's a problem. Why pay amazon when we could do it ourselves and distribute the cost of bandwidth across all Nixers? This frees up more money that could be channeled into paying full time devs on Hydra. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Funding Hydra Development
This thing is about trust, and personally I'd prefer signing the derivation-output hash pairs and having some web-of-trust-like solution. (Although some build redundancy is certainly good, for multiple reasons.) The problem with seti@home -like solutions is that verifying correctness is generally no cheaper than full rebuild. Therefore, the untrusted computers bring very little added value. (They can distribute the content signed by trusted people, but distribution isn't much of a problem in our case, IMHO.) On 01/22/2015 01:29 PM, Wout Mertens wrote: Then you could do something like, have 1000 builders, and if 501 builders get the same output hash for a derivation, it gets accepted on the public ledger of input/output hashes. I'm not sure about such schemes either. It isn't very economical to build everything 1000-times. I do see the bitcoin-like inspiration (I guess), but I wouldn't apply it here, at least not in this way. (Do we want to give most decision power to those who make most claims on the build results? Even if we extend them with some additional proof-of-work?) 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] Funding Hydra Development
bit-identical builds. How far are we from that point? Is it the timestamps that most build tools add to their build that prevents it? What's the blocker? Aloha, RK. On Thu, Jan 22, 2015 at 10:29 PM, Wout Mertens wout.mert...@gmail.com wrote: nixos@home would be impossible to secure until derivations are bit-for-bit identical on multiple builds. Then you could do something like, have 1000 builders, and if 501 builders get the same output hash for a derivation, it gets accepted on the public ledger of input/output hashes. Grow the builders as the popularity of NixOS grows. You need to subvert a majority of builders to subvert the binaries. ...but we don't have bit-identical builds... yet. On Thu Jan 22 2015 at 3:46:48 AM stewart mackenzie setor...@gmail.com wrote: Forgive me, this is my fault for not being clear enough. Yes I too would feel uncomfortable about a nixos@home setup unless of course it includes some kind of blockchain. Even then it would be too expensive to run. ___ 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 ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Funding Hydra Development
On Thu, Jan 22, 2015 at 1:52 PM, Vladimír Čunát vcu...@gmail.com wrote: This thing is about trust, and personally I'd prefer signing the derivation-output hash pairs and having some web-of-trust-like solution. (Although some build redundancy is certainly good, for multiple reasons.) Absolutely. The problem with seti@home -like solutions is that verifying correctness is generally no cheaper than full rebuild. Yes, you need some rebuilds. In a large network that should not be a problem IMO. Any distributed system with redundancy needs to do redundant work. Therefore, the untrusted computers bring very little added value. (They can distribute the content signed by trusted people, but distribution isn't much of a problem in our case, IMHO.) I don't understand how this follow from the previous point. Yes the untrusted computer needs to be associated with a crypto key so there is some consequence of it lying. That's better. However, a completely untrusted computer can still be used to generate contested outputs (look for signed outputs that are lying). A contested output is valuable as something that many people can try building so we can figure out how to react to the person that signed the output (was it a flaky build, non-determinism, attack). Thus a normal NixOS (unknown, untrusted computer) can still recompile some random package that is being installed in order to strengthen trust in the official builds. On 01/22/2015 01:29 PM, Wout Mertens wrote: Then you could do something like, have 1000 builders, and if 501 builders get the same output hash for a derivation, it gets accepted on the public ledger of input/output hashes. I'm not sure about such schemes either. It isn't very economical to build everything 1000-times. I do see the bitcoin-like inspiration (I guess), but I wouldn't apply it here, at least not in this way. (Do we want to give most decision power to those who make most claims on the build results? Even if we extend them with some additional proof-of-work?) Comparing to bitcoin or consensus protocols is not correct. In bitcoin or consensus protocols we try to agree on *an order of events*. Therefore we need a majority to agree. The problem we have here is agreement on a mapping a set of inputs to a set of outputs. This can be done fully in parallel and only a single proof of cheating is enough to prove that someone is dishonest and do whatever is needed to kick them out. Alexander ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Funding Hydra Development
On 01/22/2015 04:12 PM, Alexander Kjeldaas wrote: Therefore, the untrusted computers bring very little added value. I don't understand how this follow from the previous point. [...] From a kind-of paranoid point of view, if I don't trust a computer at all, it shouldn't be able to increase my trust in anything. I can't know for sure whether it did compile anything at all or just copied the result of the one it wants to confirm. In such a setting the majority-vote with anyone free to join is cheap to manipulate. (That is why e.g. bitcoin requires proof-of-work, so it needs superior computational power to manipulate it.) Thus a normal NixOS (unknown, untrusted computer) can still recompile some random package that is being installed in order to strengthen trust in the official builds. Of course, unknown people can rebuild random packages themselves to increase *their* trust in what they downloaded, etc. But for redundant builds to work at all, we would first need better determinism and purity. 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
[Nix-dev] Funding Hydra Development
Dear all, A recent thread regarding contributors brought up a point about throwing a stack of money at further devlopment and refinement of Hydra. Wouldn't it be nice to: - be able to do as they do in the OpenBSD world by living on master. When things break the fix comes in quick. No hanging around for days. Releases are a by product of the world of sw distribution on CDs and DVDs. - (most importantly) Create a distributed community wide Hydra that disseminates binaries over something like named data networking. Might we create an indiegogo campaign? I know NixOS gets limelight on sites likes hackernews, so I suspect the campaign could well be a success. What is your opinion? Kind regards Stewart ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Funding Hydra Development
On 01/21/2015 10:32 PM, Wout Mertens wrote: Not sure if throwing money at the Hydra codebase will speed up compiles (apart from setting it up to use ccache). I understood that rather as having more build power at Hydra.nixos.org 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] Funding Hydra Development
On Wed, Jan 21, 2015 at 10:34 PM, Vladimír Čunát vcu...@gmail.com wrote: On 01/21/2015 10:32 PM, Wout Mertens wrote: Not sure if throwing money at the Hydra codebase will speed up compiles (apart from setting it up to use ccache). I understood that rather as having more build power at Hydra.nixos.org It would be useful to have a ballpark figure wrt what is needed. A good start would be to update https://nixos.org/wiki/Hydra with the specs of the current machines, and list them all. I see builds on rackspace-[1-4] which are not listed for example. Alexander ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Funding Hydra Development
Vladimír Čunát vcu...@gmail.com writes: On 01/21/2015 10:32 PM, Wout Mertens wrote: Not sure if throwing money at the Hydra codebase will speed up compiles (apart from setting it up to use ccache). I understood that rather as having more build power at Hydra.nixos.org The other suggestion is quite nice too - I'd be glad to provide *some* of the power of my Homeserver to a shared hydra instance. An approach like this would cause other issues though: Slow servers, low bandwidth, etc. Distributed computing is just hard. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev -- signature.asc Description: PGP signature ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Funding Hydra Development
On 21 January 2015 at 14:10, Moritz Ulrich mor...@tarn-vedra.de wrote: Vladimír Čunát vcu...@gmail.com writes: On 01/21/2015 10:32 PM, Wout Mertens wrote: Not sure if throwing money at the Hydra codebase will speed up compiles (apart from setting it up to use ccache). I understood that rather as having more build power at Hydra.nixos.org The other suggestion is quite nice too - I'd be glad to provide *some* of the power of my Homeserver to a shared hydra instance. An approach like this would cause other issues though: Slow servers, low bandwidth, etc. Distributed computing is just hard. What about security? I wouldn't use binaries from a hydra cluster that's open to anyone on the Internet to contribute to, because unless I misunderstand, that means everyone has the opportunity to substitute malicious binaries. James ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Funding Hydra Development
I also refer to the use of Content Centric Networking (CCN) or Named Data Networking (NDN) to disseminate binaries. Please note, CCN builds security into the TCP/IP overlay protocol. So a binary is automatically signed by a trusted NixOS maintainer whom is also running a private hydra node. Typically in these types of situations when a web of trust is formed, one attends meetings bringing along some kind of official identification. One shows the identification to other nixers and then hands over the public key. The list of trusted keys is then signed by a globally trusted member - eelco comes to mind. This key list can be disseminated via CCN to all other hydra nodes and Nix/NixOS nodes. When a Nix node wants a package it asks its CCN library. If the binary (which has been signed by a trusted maintainer) is not in the CCN's local Least Recently Used buffer, it floods the request to other Nix/NixOS + Hydra nodes. That binary is then copied leaving a breadcrumb trail through the graph. Any future close proximity requests for that package will then find it quicker somewhere an the breadcrumb trail. I believe this article gets to the root of my argument regarding living on master: homing-on-code.blogspot.hk/2015/01/code-rot-openbsd.html (read the OpenBSD section) Kind regards Stewart On Thu, Jan 22, 2015 at 9:51 AM, James Cook james.c...@utoronto.ca wrote: On 21 January 2015 at 17:25, stewart mackenzie setor...@gmail.com wrote: James you execute code that wasn't written on your machine all the time. What difference is there between not tursting the code writer vs code compiler? Use a web of trust certificate system of course. Anyway if we could find away to live on master I think we'll get more momentum. (Did you mean to reply-all? Feel free to include my response too if you did.) Using a web of trust or something like that partly mitigates the problem. I am still worried, though. Code committed to open source projects can be reviewed later. If someone submits a malicious binary, how will anyone ever know? So my bar for trusting binaries is much higher than my bar for trusting source from a popular open source project. I agree that it would be nice to live on master. I agree with Alexander that it would be nice to have a ballpark figure for what is needed. Maybe this can just be solved with donations of money. James ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Funding Hydra Development
Ah, if the set of trusted people is a relatively small group of people someone like Eelco has met in person, then I'm much happier. When I first saw the suggestion, I was imagining some sort of seti@home kind of thing. Thanks, James On 21 January 2015 at 18:30, stewart mackenzie setor...@gmail.com wrote: I also refer to the use of Content Centric Networking (CCN) or Named Data Networking (NDN) to disseminate binaries. Please note, CCN builds security into the TCP/IP overlay protocol. So a binary is automatically signed by a trusted NixOS maintainer whom is also running a private hydra node. Typically in these types of situations when a web of trust is formed, one attends meetings bringing along some kind of official identification. One shows the identification to other nixers and then hands over the public key. The list of trusted keys is then signed by a globally trusted member - eelco comes to mind. This key list can be disseminated via CCN to all other hydra nodes and Nix/NixOS nodes. When a Nix node wants a package it asks its CCN library. If the binary (which has been signed by a trusted maintainer) is not in the CCN's local Least Recently Used buffer, it floods the request to other Nix/NixOS + Hydra nodes. That binary is then copied leaving a breadcrumb trail through the graph. Any future close proximity requests for that package will then find it quicker somewhere an the breadcrumb trail. I believe this article gets to the root of my argument regarding living on master: homing-on-code.blogspot.hk/2015/01/code-rot-openbsd.html (read the OpenBSD section) Kind regards Stewart On Thu, Jan 22, 2015 at 9:51 AM, James Cook james.c...@utoronto.ca wrote: On 21 January 2015 at 17:25, stewart mackenzie setor...@gmail.com wrote: James you execute code that wasn't written on your machine all the time. What difference is there between not tursting the code writer vs code compiler? Use a web of trust certificate system of course. Anyway if we could find away to live on master I think we'll get more momentum. (Did you mean to reply-all? Feel free to include my response too if you did.) Using a web of trust or something like that partly mitigates the problem. I am still worried, though. Code committed to open source projects can be reviewed later. If someone submits a malicious binary, how will anyone ever know? So my bar for trusting binaries is much higher than my bar for trusting source from a popular open source project. I agree that it would be nice to live on master. I agree with Alexander that it would be nice to have a ballpark figure for what is needed. Maybe this can just be solved with donations of money. James ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Funding Hydra Development
Forgive me, this is my fault for not being clear enough. Yes I too would feel uncomfortable about a nixos@home setup unless of course it includes some kind of blockchain. Even then it would be too expensive to run. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Funding Hydra Development
Sure, but who or what gets the money? Will it fund more build systems or will the money go to a recreation of Hydra in a more popular language? Not sure if throwing money at the Hydra codebase will speed up compiles (apart from setting it up to use ccache). On Wed Jan 21 2015 at 4:57:15 PM stewart mackenzie setor...@gmail.com wrote: Dear all, A recent thread regarding contributors brought up a point about throwing a stack of money at further devlopment and refinement of Hydra. Wouldn't it be nice to: - be able to do as they do in the OpenBSD world by living on master. When things break the fix comes in quick. No hanging around for days. Releases are a by product of the world of sw distribution on CDs and DVDs. - (most importantly) Create a distributed community wide Hydra that disseminates binaries over something like named data networking. Might we create an indiegogo campaign? I know NixOS gets limelight on sites likes hackernews, so I suspect the campaign could well be a success. What is your opinion? Kind regards Stewart ___ 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
