>> For what it's worth, in the Java apps I've written that required signed
>> jars, the class loader complained if the jars weren't all signed with
>> the same cert. Since Pivot's a library and not an application, that
>> would imply that developers building apps against Pivot wouldn't want
>> the jars to be signed by our cert at all. I've been going under the
>> impression that we'd only sign the jars that serve our demos and
>> tutorials on the web site -- *not* the jars that we release.
>
> That's a very interesting point; I'll ask Verisign's folks about this
> puzzle the next time we talk.
>
> Is the classloader complaining they aren't signed by the 'same' cert, or
> just not signed by a trusted cert?
The classloader will prompt the user to trust each different signer. For
example, let's say that we sign the Pivot JARs with an ASF cert, and acme.com
deploys an application that uses those JARs. The JAR(s) containing the acme.com
app would be signed using the Acme cert, and the user would be prompted twice -
once to trust the ASF JARs and again to trust the Acme JARs.
This is probably not an ideal user experience - Acme's users don't necessarily
need to know that parts of the application came from Apache - they just need to
trust Acme. So, our assumption is that Acme would sign all the JARs used by the
application, including the Pivot JARs, with their own certificate. This way,
the user only gets prompted once, to trust acme.com.
Another reason our release binaries aren't signed is that not all applications
require local privileges. Many applications can run just fine in the sandbox,
and it would be unnecessary to prompt the user to trust the application in this
case (users are prompted to trust signed JARs regardless of whether or not the
code attempts to invoke a privileged operation).
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).
I'm not an expert in writing Apache HTTP Server modules, but I'd be happy to
take a stab at writing a servlet version as a proof of concept, if that would
help.
Greg
