Mark J Cox wrote: > On Mon, Dec 7, 2009 at 6:16 PM, Greg Brown <gkbr...@mac.com > <mailto:gkbr...@mac.com>> wrote: > > > To be the ASF code signing cert, that request must originate from > corporate officers. > > > Last year we started signing JAR files at Red Hat with a number of code > signing certificates. Because we have so many different product groups > and QA groups for each product we used our signing server for this > (basically it's a dedicated machine which has a small server allowing > remote requests to sign files, compare with stored ACL's, return signed > files). On the signing server itself we actually use nCipher crypto > hardware to keep the keys safe (keys generated in the hardware). The > idea being that no one at Red Hat ever has access to any key, just a > short-term ACL-controlled ability to sign with that key. > > The server software itself we've not released as it's not really useful > (acls and server based on our internal krb5 setup). And the crypto > boards are not cheap, but maybe we could get some help from nCipher with > one. However, even without the hardware having a separate more > tightly-controlled machine would be the way forward.
That's how I envisioned working with this; only root of the signing machine would be responsible for placing the keys, otherwise it's a black box sort of operation (using published source code, of course for the signing app, under the site-dev/infra-dev auspices.) What I hope to understand from Greg et al is whether submit-one-jar, receive-one-signed jar is an adequate model for java code signing. Would it be sufficient if this was not automated initially? Or will we have the scenario under our java projects where a tar must be unpacked, the jars signed, and repacked? Obviously automation will be a wonderful thing when we arrive there :) Bill
