IRC channel logs


back to list of logs

<zacts>congrats on the 0.5 release!
*civodul posts an updated road map
<civodul>hey hey!
<mark_weaver>happy solstice :)
<civodul>hey mark_weaver
<civodul>right, happy solstice!
<mark_weaver>I was born on such a soltice, too long ago...
<civodul>oooh, happy birthday mark_weaver!
<civodul>i guess you just turned 21
<civodul>in one base or another
<mark_weaver>21 in base 21 :)
<civodul>oh, so that's a very special day! :-)
<mark_weaver>I hadn't expected to do this, but I seem to have gone on a coding spree to implement R7RS in Guile.
<civodul>oh, neat
<civodul>well i'm still unsure what to expect from R7RS
<civodul>but the more the merrier ;-)
<mark_weaver>yeah, I'm not sure either.
<mark_weaver>I'm still more interested in R6RS, but I think it makes sense to support both.
<civodul>yeah, probably
<civodul>mark_weaver: does 'make check' work for you, with the new gcrypt stuff?
<dfsdfssad>civodul: I think it might have time to work on singed Hydra binaries, but I'll definitely need some help. For instance, will it be necessary to write Perl?
<civodul>hey dfsdfssad!
<civodul>well, the Hydra side of things may need a bit of Perl
<civodul>but it should be very small
<civodul>it will also need diplomacy, though ;-)
<civodul>it'd be good if you could re-read that thread
<dfsdfssad>civodul: Currently, I haven't though about it much, so I don't have a clear plan, do you?
<civodul>dfsdfssad: there was this discussion i linked to
<civodul>i was going to go for GPG signatures, next to the substitutes
<civodul>but Eelco was proposing something different
<civodul>i think what i proposed is less intrusive anyway
*dfsdfssad reads
<dfsdfssad>civodul: Note that I have to finish my current project first, which may take five days or so. But I really want to help out more since I don't want Guix to fail. It's important in general, and for GNU in particular.
<civodul>dfsdfssad: sure, np!
<civodul>we all have different agendas, that's fine
<civodul>help is always welcome :-)
<dfsdfssad>civodul: I'll read the mentioned links and think about this issue when I have more time. I'll drop you a line as soon as I have something valuable to say.
<dfsdfssad>civodul: See you.
<mark_weaver>civodul: regarding the digital signatures, I think it's important to design things such that the signature made by the build machine is in no way central. the system should allow the collection of signatures from anyone, much like the GPG key servers accept our signatures on other people's GPG keys to be merged into the keyring made available to others.
<civodul>yeah, that's why i suggested the authorized key thing
<mark_weaver>then, as we achieve bit-for-bit reproducability of each package, it will hopefully become common for many packages to be signed by more than one person.
<civodul>but remember that the thing i wrote about is not the preferred mechanism to exchange between users
<civodul>aah, i see what you mean
<civodul>i'm not sure it's applicable here, but yes, it's worth keeping it in mind
<civodul>oh sorry, you were talking about substitute signatures, right?
<civodul>in that case, yes, that's definitely applicable
<civodul>good point
<mark_weaver>yes, I'm thinking about substitutes.
<civodul>so yes, we should be able to provide multiple signatures
<mark_weaver>oh, I see now that there's a whole thread about this, which I haven't read.
<mark_weaver>I think that hydra should allow users to submit their own signatures on substitutes, and users should also be able to query the signatures that hydra has collected.
<mark_weaver>and users should able to configure a policy (implemented by their substituter) on what signatures are necessary to consider a substitute to be trusted.
<mark_weaver>I think that each build machine should have its own digital key for making signatures.
<mark_weaver>and hydra will also have a configuration for what signatures are needed to consider a substitute trusted enough to make available for public download.
<mark_weaver>(in my vision; I don't mean to imply that my ideas will be adopted necessarily :)
<mark_weaver>but I don't want the MIPS binaries to be corruptable by any Intel-based host, for example.
<mark_weaver>I don't want any Intel-based host to have access to the private key used to sign MIPS substitutes.
<mark_weaver>I'd like to hear what others think about this, of course :)
*mark_weaver reads the thread
<civodul>the bottom line is: we don't want to invest too much in Hydra
<civodul>i think we should keep decentralized distribution in mind
<mark_weaver>I agree!
<civodul>so to me Hydra serves two goals: continuous integration, and short-to-medium-term distribution mechanism
<gzg>So what's the deal with media-players and/or codecs again? Like would mplayer be applicable -- what about the "bad and ugly" parts of gstreamer?
<mark_weaver>civodul: having now read your message, I think your plan is good :)
<mark_weaver>civodul: just one comment: regarding the signatures on substitutes, I think it's important to authenticate "end to end" and not for each individual hop from one build machine to the next.
<mark_weaver>if we authenticate each hop, then any machine along the way could corrupt the package.
<mark_weaver>authenticating end-to-end means that only the original build machine can corrupt a substitute.
<mark_weaver>and if a substitute is found to be corrupted, we know which machine has been compromised.
<civodul>yes, agreed
<mark_weaver>so I guess I'd prefer to think of the signature as being applied when the package is built, rather than when it's exported.
<mark_weaver>because if I import a package from hydra, and then pass it along to you, it's not appropriate for me to sign it myself.
<mark_weaver>it's only appropriate for me to sign it myself when I independently verify its authenticity.
<mark_weaver>(which means when I build it)
<mark_weaver>if I export something that I merely imported, then I'm just passing along the substitute along with any signatures that have been attached to it by other.
<mark_weaver>does that make sense?