IRC channel logs


back to list of logs

<gzg>Woops, meant for vm. :^P
<civodul>mark_weaver: yes it does
<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>yes, i see
<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 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>well, yes and no
<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>and it includes closures
<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>that said...
<civodul>Hydra creates its .nar using the same mechanism anyway (the 'export-paths' RPC)
<civodul>so hmm...
<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>it signs it.
<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
<civodul>no need for the derivation here
<mark_weaver>is the store file name included in the bits that are being signed?
<mark_weaver>okay, I guess that covers it then.
<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
<civodul>so that's something to check
<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>so you don't sign when you create a nar.
<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>(sorry, thinking out loud here)
<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>yes, that makes sense
<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>I think the same trust models apply.
<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>s/competence/competence and trustworthiness/
<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.
<civodul>could be
<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