> 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
