Greg Brown wrote: > I have a suggestion as to how we might approach this. What if, rather than > providing a JAR signing service, we make JAR signing the responsibility of > the web server? Basically, the idea is that any client-side JARs would be > deployed to the web server unsigned - a URL pattern would be used to request > a signed version of the JAR, and a server module (or servlet filter) would > dynamically generate a signed version on demand. For example, the unsigned > version of pivot-core.jar might be served from: > > http://pivot.apache.org/demos/lib/pivot-core.jar > > The signed version could be obtained via the following URL (the signing > module or servlet filter would be mapped to /demos/lib/signed and would > handle the details of generating and returning the signed version): > > http://pivot.apache.org/demos/lib/signed/pivot-core.jar > > The signed version would be cached so it would only need to be regenerated > when the unsigned JAR changes. > > There are a couple of reasons why I think this approach might work well: > > 1) Any JAR-signing service that accepts an unsigned JAR and returns a signed > JAR would require some level of authentication. Presumably, if someone has > posted the JARs to an ASF web server, that user already has sufficient > privileges to do so, so it sidesteps the need to be an additional > authentication system. We'd simply take advantage of what is already in place. > > 2) It has parity with deploying SSL certificates, which is also done at the > web server level. SSL certs are used to encrypt request and response data, > and code signing certs would be used to sign server assets (JARs).
That wouldn't be acceptable unless we had the appropriate audit patterns in place, any arbitrary objects could be submitted to lib/signed/ and then immediately retrieved with a signature. The audit pattern would have to include a blackbox, controlled space which performs the signature, and we would have to know what was going in and out. What is audited? A permanent copy of the artifact before and after signature, and the user who asked for it to be signed. Ideally, it should be insufficient to just log in as that user. The dist.apache.org/repos/dist pattern is actually really useful for this task. Items can be recognized as requiring signature and committed back with the appropriate signature. I see where you might want to ship both a signed and unsigned object, however :) Bill
