Re: Signed archives (preliminary patch)

[Ludovic Courtès]

Mark H Weaver <address@hidden> skribis:

> address@hidden (Ludovic Courtès) writes:
>
>> The difficulty here will be to compute the hash up to the Signature
>> field.  To do that, ‘read-narinfo’ should probably:
>>
>>   1. read everything from PORT with ‘get-string-all’ in a string (make
>>      sure PORT’s 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’s a single “signature sexp”
(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’t know yet.  Partly because it’s unclear to me that
modifying Hydra to support such things is the right thing to do.

For the kind of operation you mention, I’d 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–i.e., who signed them–, compare their hash, etc.

This is pretty much related to the GNUnet software update idea.

Alternately, we could write a Guile web server that publishes a user’s
store using Hydra’s protocols, and from there gradually adjust
substitute-binary to intelligently handle multiple servers.  (That would
even make a good GSoC project, no?)

Thanks,
Ludo’.