IRC channel logs
2013-12-22.log
back to list of logs
<gzg>Woops, meant for vm. :^P <civodul>perhaps that would means extending the SQLite DB with a flag that says "built here" or "substituted" <mark_weaver>I don't think we need a specific flag for that. Rather than "built here", we should store a set of signatures on each build. *gzg wonders how trivial it'd be to just hack together a little media player with gnome-guile on top of gstreamer. <mark_weaver>if the local key signed the package, that means "built here". <mark_weaver>something can be both a substitute and built here at the same time. <civodul>either way the DB schema must be augmented <mark_weaver>it might start out as a substitute (we wanted to install in a hurry), and then later we built it ourself to verify it, at which point we merely add our signature to it. <civodul>we'll have to make sure to remind Nikita of the multiple-signature requirement :-) <mark_weaver>I think he's in the habit of reading these IRC logs, or at least he was. <mark_weaver>Nikita: if you're reading this: feel free to send me more email :) (apologies for sometimes not responding) <mark_weaver>civodul: in your current code, what exactly is being signed? is the hash of the derivation included in the thing being signed? <mark_weaver>in other words, I want to make sure that it is the pair (derivation,outputs) that is digitally signed, and not merely the outputs. <civodul>the thing i posted is *not* about substitutes <civodul>it signs the contents of packages, roughly <civodul>search local-store.cc for OPENSSL_PATH <mark_weaver>well, I see no important difference between {build-machine}=>{hydra} and {hydra}=>{end-user}. I see no reason for a different mechanism. <mark_weaver>both {hydra} and the {end-user} must check that the build was signed by {build-machine}. <civodul>substitutes are downloaded implicitly (when they're enabled) <civodul>and it's the user that initiates things <civodul>whereas archives are explicitly for transfers <civodul>dunno, it's definitely similar, but not quite the same either <mark_weaver>well, it's true that in the {build-machine}=>{hydra} case, it is the {build-machine} that decides when it's time to do a transfer, so that's a "push", whereas in the {hydra}=>{end-user} case it is the user who decides when, so it's a "pull". <mark_weaver>but I still see no difference other than who initiates the process. once the process begins, they are the same I think. <civodul>Hydra creates its .nar using the same mechanism anyway (the 'export-paths' RPC) <civodul>we could tweak it to create signed nars <mark_weaver>anyway, the main point I was trying to make before is this: it is not enough for the signature to certify that an output was the result of some build process. we need to make sure the derivation itself (or a hash of it) is included in the thing being signed as well. in other words, the association (derivation,outputs) has to be signed, not just (outputs). <civodul>unless it's a fixed-output derivation, the derivation isn't really needed <civodul>because there's only one derivation leading to a given output file <mark_weaver>here's my concern: I ask the build machine to create a modified version of a package where I have inserted a trojan horse. <mark_weaver>now, when you ask for a substitute of that package, I intercept your connection with hydra and arrange for you to received the substitute of the trojaned version. <mark_weaver>it's still signed by the build machine, but it's not the substitute for the derivation you wanted. <mark_weaver>so somehow, the derivation has to be included in the thing that's signed. <civodul>but in the .nar you get from the build machine, there's a store file name <civodul>so you can check if that's the one you asked for <mark_weaver>is the store file name included in the bits that are being signed? <mark_weaver>as long as the substituter verifies that the store file name in the recieved nar is correct. <civodul>yes, and i'm not sure it's currently the case :-P <mark_weaver>so I think the sqlite DB should include a set of signatures associated with item in the store. <mark_weaver>the daemon should sign each output after it's complete. (the build user should not have access to the private key material) <mark_weaver>instead, the nar includes whatever signatures are already in the DB. <mark_weaver>or, perhaps the signatures shouldn't be in the nar, but rather sent on a separate channel... because it should be possible to fetch signatures without getting the nar. <mark_weaver>when I independently verify a build, I'll send my signature to hydra without sending the nar. <mark_weaver>and after I download a nar, I might want to periodically fetch any new available signatures on it, to gain confidence in it. <mark_weaver>or more generally, friends can share their signatures with each other to contribute to each other's trust in the built outputs. <mark_weaver>it occurs to me that GPG's handling of key signatures is basically what's needed here also. <mark_weaver>for example, when GPG imports a key, it merges the set of key signatures it already has with the newly recieved key signatures. we need the same thing. <civodul>you should post a summary of these ideas before we forget! <mark_weaver>and with GPG, you can tell it how much you trust a key, and then this is used to compute an measure of how much you can trust that a given (uid,public-key) association is valid. <mark_weaver>we need the same thing, but for (derivation,output) associations. <mark_weaver>when you say that you trust a given key, that means the following: "I trust that this key has not been leaked, and I trust the competence of the key's owner to certify a given (uid,public-key) association. <mark_weaver>and in our case, it's directly analogous. when we say we trust a given key, it means that we trust the competence and trustworthiness of the owner of that key to administer a secure build machine. <mark_weaver>hmm, I wonder how hard it would be to reuse the trust model code in GnuPG for our purposes. <mark_weaver>or maybe it's simple enough that we should just copy the ideas in scheme code. <mst>mark_weaver: it occurs to me that gpg handles only trustworthiness of identity <mst>mark_weaver: and that 'trustworhtiness of identity', 'trustworthiness of competence', and transitive properties thereof, might not be the same thing <mst>mark_weaver: I can think of people that I trust to -do- things, but not to certify other people's competence at the doing of those things, for example <mst>mark_weaver: I'm not sure the additional complexity required to model that is actually worthwhile, but it seems like if so the choice that it isn't worthwhile should be taken consciously and documented