On Thu, 13 Jan 2005 10:51:30 -0500, Tim O'Brien <[EMAIL PROTECTED]> wrote:
> Would we be talking about "gpg --armor --output
> commons-foo-1.2.jar.md5.asc --detach-sig commons-foo-1.2.jar". Or, is
> there some other mechanism we would need to go through?
It would be essential for java download if the signature validation
could be done in Java. Upload I dont care about; though I'd be
somewhat biased to Java...C works for me if it is portable.
Java signing stuff is built around
It doesnt take that many lines to open a binary file and produce a
checksum or signature, or verify the same. More fiddly is probably
saving the sig to a file in a good format, loading that format in and
then selecting the key to verify against. But that isnt particulary
Note there is an OSS(?) impl that is generally viewed as better:
> Even if someone compromised the repository they would need to get your
> private key and passphrase to create a valid, signed MD5. I know people
> here are touchy about scope, but JAR signing seems limiting in that it
> only applies to jar files and is entirely specific to Java.
yes. Jar signing would be limited to only a subset of the artifacts.
But if it hadnt had the side effect of sealing stuff, it would have
been nice. Nice because every JAR would retain the signatures; over
time they would be fairly ubiquitous. This makes it easier to field
bugreps - get a list of which jars are signed, and which look like
More critically, when you run Java RMI, you need to share JAR files
over some URL schema if you want to do dynamic code download. And for
that to be sensible, you need signed JARs. So things like transit and
smartfrog both benefit from signed jars; The latter requires you to
create your own CA and sign everything; if you want to send some other
artifact (like a deployment descriptor), it has to get put into a JAR
and then signed.