Put another way, applying the certificates this way would simply serve as an affirmation to site visitors that the JARs were downloaded from an actual ASF web server, in the same way that an SSL certificate affirms that the browser is communicating with an ASF web server. It says nothing about how the unsigned JARs actually get on server to begin with, and it doesn't need to, since we already have a security infrastructure in place for that. :-)
On Dec 8, 2009, at 6:11 PM, Greg Brown wrote: >> 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. > > Let me attempt to clarify my suggestion. Artifacts would never actually be > submitted to /lib/signed. This would be a "virtual" directory, so to speak. > Unsigned JARs would be deployed to /lib, signed on the fly by the web server, > and cached in /lib/signed. > > Only authorized users would be allowed to publish content to the lib > directory, in the same way that only authorized users can push other, > non-JAR, content out to a site. For example, let's say I want to update the > Pivot home page, and that the home page includes a Pivot applet. I would > publish the following files to the site's root directory: > > index.html > lib/ > pivot-core.jar > pivot-wtk.jar > pivot-wtk-terra.jar > pivot-demos.jar > > Now, if my applet doesn't require security privileges, it won't need to > request signed versions of these files. However, if it does, the web server > would automatically generate and return additional signed versions in the > /lib/signed directory. > > Any visitor to the web site is eligible to request those JARs. However, *only > authorized users* are allowed to push the unsigned JARs out to the server, > because only authorized users are allowed to update ASF site content. In > other words, putting files in /lib isn't necessarily making a request to sign > the JARs - it is simply deploying an update to a project site that happens to > contain JARs. Those JARs may later be signed, as needed, by the web server. > It is analogous to deploying a set of HTML pages to a web server that may > later be encrypted via SSL. Only authorized users are allow to update the > pages, but anyone can request a page that has been published over HTTPS. > > I hope that helps clarify the intent. > > Greg >
