incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <>
Subject Re: Signing Java Jars, versus Apache Signing of distributed artifacts
Date Wed, 22 Aug 2007 00:23:28 GMT
Craig L Russell wrote:
> When I looked into Java signing and found it to be too burdensome. There
> are two basic issues with it that made me think that it wasn't suitable
> for use with Apache projects:
> 1. The certificates are the keys to the kingdom. Whoever has the ability
> to use the certificates warrants the contents of the jar, so the
> certificates need to be kept secret. It's not practical for Apache
> projects to have secrets like this, so each individual would need their
> own certificate.

Uhm, the key is the key to the certificate.  Certificates are public :)
The key they were signed with is private.

I don't see the difference between a PGP key used to
sign distributions and signing a .jar or .net assembly with a personal
developer certificate.

Of course the *key* (not certificate) must be the secret of waldorf.  I'd
be adverse to having asf signatures unless we want to set up a very secure
asf signing app on a trusted server.  (Verify signed by trusted @apache
committer, returns it signed by apache@apache).  The sort of app visible
to nobody but root.  So if users want to use an @apache individual dev
certificate, I don't see anything different from fetching up a PGP key
and having it signed by your fellow members.

For mod_aspdotnet, I distribute the key.  It was signed with a key, not
with a certificate.  Anybody could rebuild with that key.  Now, I don't
really care if someone can substitute another Apache.Web assembly in
place of the one installed in their .NET GAC.  But mod_aspdotnet did
care that it was signed before it would load the thing.

Rethinking it, I'm about to have the build generate an arbitrary key,
sign Apache.Web with it, tell mod_aspdotnet to trust it, and throw the
damned thing away :)  To patch, the user would just rebuild them both.
They simply need to stay in-sync.

> 2. The runtime cost of checking the certificate every time the jar is used.

Technical issue to be judged on it's own merit.  No opinion here.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message