Pitfalls of verifying signed jar files

In the Java world, it’s possible to digitally sign a jar file using ‘keytool’ to generate or import a digital signature, and ‘jarsigner’ to do the signing. What isn’t so obvious is that when we use ‘jarsigner’ to verify a signed jar, it doesn’t verify that we trust the signature that signed the file. It simply tells us whether the contents were signed by a public key that was included with the jar file.

Surprisingly, there’s no option to tell jarsigner to check for trusted signatures.

In code, we can use java.util.jar.JarFile to check the validity of a jar file. By default, the constructor to JarFile says we want to check the validity. Code must then iterate through each entry in the JarFile and seek to the end of each input stream, otherwise, the integrity isn’t checked. In other words, the java.util.jar.JarFile doesn’t give us the integrity checking with a simple method call such as isValid(), and it doesn’t give us an easy way to check that we trust the signature that the entries were signed with.

Anyone, anywhere, can create their own certificate, and sign a jar file — so if we want to establish trust for a signed jar, we get to do extra work. On stackoverflow.com, Jarek Przygódzki linked to code that shows how to check for trusted signatures.

I wonder why establishing trust for a signed jar isn’t easier. Could it be that signed jar files originated in the bygone era when we ran Java applets in our web browsers? Did web browsers use their certificate authority database to verify some level of trust for the signature contained in a jar file?

Verifying trust is a delicate issue, as demonstrated by the recently hacked certificate authorities including Diginotar and Comodo. Perhaps it’s a good thing that Java’s libraries and command line tools don’t make it deceptively simple to check jar files based on certificates trusted by Certificate Authorities.

Still, I wish the documentation for jarsigner and JarFile would shed more light on the limits of their default verification. I’d call it “hash checking” or “integrity checking based on hashing”.


jvisualvm: A free Java memory and CPU profiler

I needed to profile a Java application, and since we had a JProfiler floating license, I used it. JProfiler works well, although it’s pricey. I was googling for other Java profiling tools, and [stackoverflow.com](http://stackoverflow.com/search?q=visualvm) made mention of [jvisualvm](https://visualvm.dev.java.net/), which comes bundled with JDK 6 release 7. I noticed that on my Fedora 10 box, the java-1.6.0-openjdk package includes jvisualvm. None of my coworkers had heard of it.

JProfiler introduces a significant performance penalty into the code it profiles, whereas other tools including jvisualvm and YourKit have a much lower impact. I’m going to give jvisualvm a try, once I get the target environment set up properly with the new JDK.

UPDATE: jvisualvm won’t profile remote applications like JProfiler can. jvisualvm is not quite as easy to use, and I haven’t figured out how to get stack traces on the CPU and memory hot spots. Overall, I like the tool.

UPDATE 2: jvisualvm can be configured to give a stack trace of memory hot spots. I’ve learned that performance between the Java 1.5 and 1.6 jvms can be very different. I’ve learned that I can run ‘kill -3 ‘ to print a stack trace of my running java processes. It’s helped me to narrow down bottlenecks in an application when the profiler wasn’t granular enough.