From mboxrd@z Thu Jan 1 00:00:00 1970 From: ludo@gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=) Subject: Re: Signed archives (preliminary patch) Date: Fri, 28 Feb 2014 11:37:13 +0100 Message-ID: <87mwhb5xra.fsf@gnu.org> References: <87txcqesqv.fsf@karetnikov.org> <87eh3ure1r.fsf@gnu.org> <87bnyyiv2u.fsf_-_@karetnikov.org> <87ha8qo7rl.fsf@gnu.org> <8761p5jv1g.fsf@karetnikov.org> <87r47tfmes.fsf@gnu.org> <8738k0pj8c.fsf@karetnikov.org> <874n4fnhs7.fsf@gnu.org> <87ppmigld8.fsf@karetnikov.org> <87y514dv2u.fsf@gnu.org> <87y50wffjy.fsf_-_@karetnikov.org> <874n3kp46f.fsf@gnu.org> <87txbjoan3.fsf@yeeloong.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:36325) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WJKok-0007nE-Tf for guix-devel@gnu.org; Fri, 28 Feb 2014 05:37:27 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WJKoe-0000wF-QM for guix-devel@gnu.org; Fri, 28 Feb 2014 05:37:22 -0500 Received: from hera.aquilenet.fr ([2a01:474::1]:38624) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WJKoe-0000w3-Cy for guix-devel@gnu.org; Fri, 28 Feb 2014 05:37:16 -0500 In-Reply-To: <87txbjoan3.fsf@yeeloong.lan> (Mark H. Weaver's message of "Fri, 28 Feb 2014 04:21:36 -0500") List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org To: Mark H Weaver Cc: guix-devel@gnu.org Mark H Weaver skribis: > ludo@gnu.org (Ludovic Court=C3=A8s) writes: > >> The difficulty here will be to compute the hash up to the Signature >> field. To do that, =E2=80=98read-narinfo=E2=80=99 should probably: >> >> 1. read everything from PORT with =E2=80=98get-string-all=E2=80=99 in = a string (make >> sure PORT=E2=80=99s encoding is UTF-8); >> >> 2. isolate the lines before the ^[[:blank:]]*Signature[[:blank:]]: >> line; >> >> 3. compute the hash of those lines; >> >> 4. do (fields->alist (open-input-string the-whole-string)); >> >> 5. pass the hash to the signature verification procedure. >> >> Does that make sense? > > Apologies in advance if I'm failing to understand, but I'm concerned > about bundling a single principal signature into the narinfo file. > Not only does it cause the complications discussed above, but more > importantly, it seems to introduce an architectural bias toward an > authentication scheme where everyone is encouraged to place their > trust in a single centralized build system. Well, narinfos are a protocol for Hydra, which is a centralized build system. Nevertheless, the signatures we use are canonical sexps, so we could really put anything in there. Currently it=E2=80=99s a single =E2=80=9Csig= nature sexp=E2=80=9D (which includes a public key) though; it could be that of the hydra.gnu.org front-end, or that of a build slave, eventually. > How do you envision the transition from this single-signature > architecture to one where other users and/or independent build farms > can add their signatures to hydra? Will those signatures be treated > differently than the signatures created by hydra.gnu.org? Will they > be stored and sent to users using a different mechanism? Honestly I don=E2=80=99t know yet. Partly because it=E2=80=99s unclear to = me that modifying Hydra to support such things is the right thing to do. For the kind of operation you mention, I=E2=80=99d rather have some sort of distributed store, where people can publish binaries they have produced. Then users could look up specific store file names in there, check where they originate from=E2=80=93i.e., who signed them=E2=80=93, compare their h= ash, etc. This is pretty much related to the GNUnet software update idea. Alternately, we could write a Guile web server that publishes a user=E2=80= =99s store using Hydra=E2=80=99s protocols, and from there gradually adjust substitute-binary to intelligently handle multiple servers. (That would even make a good GSoC project, no?) Thanks, Ludo=E2=80=99.