<p>Em 09/07/2011 02:16, "Ben Walton" <<a href="mailto:bwalton@opencsw.org">bwalton@opencsw.org</a>> escreveu:<br>
><br>
> Excerpts from Maciej Bliziński's message of Fri Jul 08 13:06:39 -0400 2011:<br>
><br>
> Hi Maciej,<br>
><br>
> > Another thought: perhaps it would not be that hard to implement a<br>
> > POC of automatic catalog signing. For example: a machine in a<br>
> > private network, controlled by a trusted person runs gpg agent with<br>
> > a timeout in the order of 3 days to a week. A cron job running on<br>
> > that machine pulls the catalog file, signs it and pushes it back for<br>
> > the rest of the automation to pick it up.<br>
><br>
> This is a good idea.  I've been contemplating the design of such a<br>
> system for a few days now.<br>
><br>
> > At this point, there is a problem, that there is no verification<br>
> > that the catalog pulled can be trusted. To fix that, we can<br>
><br>
> I think something more 'on demand' is better suited here as that lends<br>
> itself to better atomicity which will be important.  I'm thinking<br>
> something along the lines of:<br>
><br>
> Just before a mirror push is about to happen, something opens a socket<br>
> to a daemon and says "please sign catalog current/i386/5.9 having sha1<br>
> $sha1."  The daemon would then grab the catalog from a preset<br>
> location, ensure the sha1 matches and sign it.<br>
><br>
> The signature is then returned over the socket and the caller is<br>
> responsible for placing it appropriately with the files.<br>
><br>
> Having things designed like this removes some possible security<br>
> issues.<br>
><br>
> 1. If the client can only request catalog signatures based on the<br>
>   tuple (catalog, arch, os release) and the daemon then goes and<br>
>   reads the file from a run-time specified or hard coded directory,<br>
>   the client cannot get 'just anything' signed.<br>
> 2. Making the client responsible for placing the signature data means<br>
>   that, given 1, we don't need to protect the daemon with encryption,<br>
>   authentication, etc, as getting a catalog signature for a valid<br>
>   catalog is public data that will be available on the mirrors<br>
>   anyway.  It also removes privilege from the daemon so that it needs<br>
>   read-only access to the data it will sign.<br>
><br>
> If the client has enough access to manipulate the directory structure<br>
> that the daemon will read, it can make the daemon sign a manipulated<br>
> catalog.  This level of compromise means things are already in bad<br>
> shape though, so it shouldn't be worse than the risks we have today.<br>
><br>
> The daemon would, as you suggest, need a timeout so that a human needs<br>
> to re-initialize the agent storing the pass phrase periodically and it<br>
> could tell the caller if it was unable to perform signatures.<br>
><br>
> I'm willing to code the daemon.<br>
><br>
> With such a signing daemon in place, we can have a cron job running as<br>
> a dedicated catalog/mirror maintenance uid that has the access needed<br>
> to place catalogs and signatures and push to the live mirror area...It<br>
> will update catalogs, get them signed, etc.  If the release proposal<br>
> is accepted, this job could also be the one that moves things from<br>
> unstable to current.<br>
><br>
> As a side note, I'd like to mention to a wider audience than irc: I<br>
> think our signatures should be detached instead of clear signed.<br>
> These are nicer to work with all around.  It would require<br>
> coordinating a pkgutil update though.<br>
><br>
> > introduce signing of individual .pkg and .pkg.gz files. The script<br>
> > pulls not only the catalog file, but also the data files. It<br>
> > verifies that all files referenced in the index (the catalog file)<br>
> > are properly signed. If not, it complaints loudly.  If yes, it<br>
> > proceeds with signing.<br>
><br>
> This can be a separate topic, but I think it is something to look at.<br>
> The biggest hurdle here is ensuring that everyone gets a gpg key<br>
> created for this purpose and that we distribute the public portions of<br>
> the keys to client systems for verification.  This could be tied into<br>
> CSWcswpki that I've already laid groundwork for.<br>
><br>
> > The signatures could be uploaded with csw-upload-pkg.<br>
><br>
> Detached signatures for this would be best too.<br>
><br>
> > I do not have a good idea where to store the signatures. I can<br>
> > imagine an appendix to the catalog that lives in a parallel<br>
> > directory, or a subdirectory of e.g. unstable/sparc/5.9<br>
><br>
> CSWcswpki should pull them down and install them in a private keyring.<br>
><br>
> > There also is the (independent) problem of key revocation, presented<br>
> > in detail by William in Dublin.<br>
><br>
> Revoking a catalog signing key is different from revoking a maintainer<br>
> signing key.  If we revoke a catalog key, we can regenerate a new<br>
> catalog with the new key.  We may not be able to easily regenerate<br>
> signatures for all packages if the need arises.  If we sign packages<br>
> individually, we may want to use a generic (but different than the<br>
> catalog signer) key for this purpose too.<br>
><br>
> > The two stage implementation outlined above gives us the advantage<br>
> > that we can be back quickly and we can we have a plan how to improve<br>
> > the security chain between an individual maintainer and the user.<br>
><br>
> Agreed.<br>
><br>
> Thoughts?</p>
<p>Yes, here are some more. I like both ideas: the signing system initiating the connection (easier to secure it), and the buildfarm deciding when to sign. I have two alternative ideas.</p>
<p>1. The signing system listens, but the handling code is super simple, only sets a flag. Then the cron job notices it, and signing occurs.</p>
<p>2. The flag is set on buildfarm side, there is no listener on the signing side.</p>