Verifying signed JARs is crap!

I sign & verify my JARs with jarsigner. The jarsigner works well and the JARs are signed correctly.
jarsigner -verify myjar.jarResult:
jar verified.But I do not understand why my JARs were still verified when I delete a class file. Is there no checksum for the whole JAR. That's number one.
I need a pure java solution to verify a JAR. That's number two.
I tried e.g.
//java.util.jar.JarFile(File file, boolean verify)
java.util.jar.JarEntry(jar,true)and
//java.util.jar.JarInputStream(InputStream in, boolean verify)
java.util.jar.JarInputStream(in,true)but the verify flag doesn't show any difference. No SecurityException.
Thanks for your help.
greetz polyurethan
Edited by: polyurethan on May 12, 2009 10:08 AM

As I understood the jar file signing/checksum concept - a JAR file is just tampered if it got changed, not if a class file got deleted.

Similar Messages

Verifying signed jar files programmatically

Hi,
We need to verify the signatures of jar files without using system commands ( e.g. jarsigner.exe ).
The code below is how I tried to extract the certificates associated with the jar entries:
FileInputStream fileIs = new FileInputStream( somefile );
boolean verify = true;
JarInputStream jarIs = new java.util.jar.JarInputStream( fileIs, verify );
JarEntry entry = null;
while ( ( entry = jarIs.getNextJarEntry() ) != null ) {
if ( !entry.isDirectory() && ! isManifest( entry ) ) {
... read entire the byte stream associated with the entry
Certificate[] certs = entry.getCertificates();
// certs always returns null
I am not able to extract certificates associated with the jarentries this way, because the entry.getCertificates always return null.
What is it that I do not understand? Is there a way to do this?
regards,
jorrit

I got the same problem. And I have done some experiment. The code below it works. Note: in order to use the code direcctly, the last entry has to be class that has a certificate. You might try with a signed jar that have only one class inside. I am lazy to write for other cases.
   try {
      File file = new File(jarFilename);
      FileInputStream fileIs = new FileInputStream(file);
      boolean verify = true;
      JarInputStream jarIs =
            new java.util.jar.JarInputStream(fileIs, verify);
      JarEntry entry = null;
      JarEntry Entry = null;
      while ((entry = jarIs.getNextJarEntry()) != null ) {
         if (!entry.isDirectory()) {
            Entry = entry;
      Certificate[] certs = Entry.getCertificates();
      if(certs == null)
         System.out.println("The entry has no certificate.");
      else {
         System.out.println(Array.getLength(certs));
         for(int i = 0; i < Array.getLength(certs); i++)
            System.out.println(certs.toString());
} catch (Exception e) {
System.out.println("Something went wrong.");
System.out.println(e.toString());
The problem is that we need to read the jarIs until you reach the last entry before you getCertificates. I sounds stupid, isn't it.
Enjoy your work.
Nawa

Verifying signed Jar using Java code

Hi,
I have been looking for a way to verify signed or unsigned jar from java code.
I have to use the jar name and from here, I have to verify the digital signature. For this goal I have found some Java classes which can be useful for me. These classes would be JarEntry class, from which I could get the certificates. Signature class, whose methods let me verify the digital signatures, and Certificate class. I also found a class called SignedObject from I could get the signature data which the method getSignature (), but the problem here it is that I need a private key in the SignedObject constructor, which is not possible since I want to verify a signed jar which I am not able to know the private key, just public key. So, could anybody tell me how I could solve this problem?
My code would be some as shown below:
jar = new JarEntry (location);
          jarcertificates = jar.getCertificates();
          /* We should check all the certificates
          if (jarcertificates != null){
               for (int i=0;i<jarcertificates.length;i++){
                    sig.initVerify(jarcertificates);
                    sig.update(jar.getExtra());
                    sig.verify( DIGITAL SIGNATURE FROM JAR SHOULD BE HERE);
I guess that I have to use jar.getExtra () in order to get the data to put in Signature.update() method but I am not sure, am I wrong?
Thanks in advance

Here is some sample code to verify a jar file:
        JarFile jf = new JarFile(args[0], true);
        byte[] buffer = new byte[8192];
        Enumeration e = jf.entries();
        ArrayList entries = new ArrayList();
        while (e.hasMoreElements()) {
            JarEntry je = (JarEntry) e.nextElement();
            entries.add(je);
            InputStream is = jf.getInputStream(je);
            while (is.read(buffer, 0, buffer.length) != -1) {
                // we just read. this will throw a SecurityException
                // if a signature/digest check fails.
            is.close();
        }To validate the certificate chain, you can call JarEntry.getCertificates(), create a CertPath from the array of Certificates (using a CertificateFactory), and then use the CertPathValidator APIs. For more information, see the PKI Programmer's guide: http://java.sun.com/javase/6/docs/technotes/guides/security/certpath/CertPathProgGuide.html

Could not verify signing in patched jar

I have encountered a strange bug in JWS verification of the signing of a resource updated via a jardiff patch.
We have a jar resource where the only change is the contents of a text file, and when the webstart client downloads the patch created by the jnlp-servlet, it reports:
Could not verify signing in resource: (http://oas-psolis-test.health.wa.gov.au:9002/PSOLIS-SwingApp-TES/PSOLIS-GUI-graphics.jar, 1.2)
The wrapped exception is:
java.lang.SecurityException: SHA1 digest error for Themes/DESERT.properties
at sun.security.util.ManifestEntryVerifier.verify(ManifestEntryVerifier.java:191)
at java.util.jar.JarVerifier.processEntry(JarVerifier.java:207)
at java.util.jar.JarVerifier.update(JarVerifier.java:194)
at java.util.jar.JarVerifier$VerifierStream.read(JarVerifier.java:380)
at com.sun.javaws.security.SigningInfo.checkSigning(Unknown Source)
at com.sun.javaws.cache.DownloadProtocol$RetrieveAction.actionDownload(Unknown Source)
at com.sun.javaws.cache.DownloadProtocol.doDownload(Unknown Source)
at com.sun.javaws.cache.DownloadProtocol.getResource(Unknown Source)
at com.sun.javaws.LaunchDownload.downloadJarFiles(Unknown Source)
at com.sun.javaws.LaunchDownload.downloadEagerorAll(Unknown Source)
at com.sun.javaws.Launcher.downloadResources(Unknown Source)
at com.sun.javaws.Launcher.handleApplicationDesc(Unknown Source)
at com.sun.javaws.Launcher.handleLaunchFile(Unknown Source)
at com.sun.javaws.Launcher.run(Unknown Source)
at java.lang.Thread.run(Thread.java:536)
v1.2 is the new version of the jar in question (PSOLIS-GUI-graphics.jar). DESERT.properties is NOT the changed text file, but rather another text file which has not changed (ie: being used from the v1.1 previously downloaded).
The patch jar contains an essentially empty index.jd file, with just the line:
version 1.0
As you can tell from the above, no resources have been renamed, just one text/properties file has different contents (so this is not immediately obviously <http://developer.java.sun.com/developer/bugParade/bugs/4474211.html> - but regarding 4474211, how does one enable the -nonminimal switch to jardiff from the JNLP servlet?).
Nor is it obvious that this is an instance of bug 4739089 <http://developer.java.sun.com/developer/bugParade/bugs/4739089.html>
As you would expect, the patch jar file also contains the modified text file, plus the manifest.mf and the signing data files.
If I delete the webstart cache first the application downloads and runs fine (which proves there is nothing wrong with the signing in this jar). Another workaround is not to include the base/old version (v1.1) of the jar in the war.
Both these workarounds are impractical - I can't get all the users to delete their webstart caches on each new version (of which we have many (both users and version releases)), and my build/deploy process automatically creates versioned jars (based on whether any source files have changed), I would need to modify my process to never provide diffs for this very large jar (and perhaps, any of my jars?), and hence lose jardiffing benefits altogether (I just spent a long time developing this build process to automate versioned jars for webstart!)
These jar files are never altered once created, and the signing is the last stage of creating the jar files (though as I mentioned above, that the signatures are fine is demonstrated by both workarounds, it is only the patching which causes the issue).
We have reproduced this problem using both JWS v1.4.1 clients and JWS v1.0.1 (from JRE v1.4.0) client - our users use the latter as they require support for Windows 95, sigh.
While I have a copy of a v1.4.1 cache in a state from which I can reproduce the error, I haven't managed to get a case where I can clear the cache, deploy version A, download it, deploy version B and download it to reproduce the error. This means that I haven't got a process to setup a test of v1.4.2_02 of JWS.
I am using the jnlp-servlet.jar from the "JNLP Developers Pack v1.2 FCS".
Has anyone else encountered a similar problem, or know of a solution (which works with the 1.0.1 JWS client for long suffering 95 users)?
An interesting side-note for OC4J standalone users - when oc4j expands the EAR (and its component WAR files) under the j2ee/home/applications directory, it does not clear out the old contents from any previous deployment of the same application (name) - I modified my deploy to not include previous jar versions, and yet the client was still patching - because the old jar file versions were left there by oc4j, joy!

Even I am facing a similar kind of problem. When webstart is downloading JRE_1.4.2_02.jar, I am getting the following error the very time itself.
java.lang.SecurityException: SHA1 digest error for jre.jar
     at sun.security.util.ManifestEntryVerifier.verify(Unknown Source)
     at java.util.jar.JarVerifier.processEntry(Unknown Source)
     at java.util.jar.JarVerifier.update(Unknown Source)
     at java.util.jar.JarVerifier$VerifierStream.read(Unknown Source)
     at com.sun.javaws.security.SigningInfo.checkSigning(Unknown Source)
     at com.sun.javaws.cache.DownloadProtocol$RetrieveAction.actionDownload(Unknown Source)
     at com.sun.javaws.cache.DownloadProtocol.doDownload(Unknown Source)
     at com.sun.javaws.cache.DownloadProtocol.getResource(Unknown Source)
     at com.sun.javaws.LaunchDownload.downloadJarFiles(Unknown Source)
     at com.sun.javaws.LaunchDownload.downloadEagerorAll(Unknown Source)
     at com.sun.javaws.Launcher.downloadResources(Unknown Source)
     at com.sun.javaws.Launcher.handleApplicationDesc(Unknown Source)
     at com.sun.javaws.Launcher.handleLaunchFile(Unknown Source)
     at com.sun.javaws.Launcher.run(Unknown Source)
     at java.lang.Thread.run(Unknown Source)
JRE_1.4.2_02.jar is a signed and verified jar that contains jre.jar. This is being downloaded on to the client for the first time. Webstart version used is 1.0.1. Can any tell me what may be the problem?

Could not verify signing in resource (JAR + Pack200)

It seems I always ended up getting JWS error I never have had before these days...
Ok, long story short:
- this is about a JavaFX 1.3.1 app with packed JARs
- changed computer, switched from JDK 1.6.0_22 that I used for several month for signing and pack files to JDK 1.6.0_29 and JDK 1.7.0_02. This issue did not happen with JDK 1.6.0_22.
- it's currently deployed to an internal web server for testing purposes, files and URL are correct and can be reached from my workstation.
- every single JNLP file validates OK with JaNeLA.
- the certificate used to sign the libs is valid.
- the offending JAR file report as being Ok and signed when checked with jarsigner.
The error from Java Web Start is:
>
Unable to launch the application.
Error: Could not verify signing in resource: http://devlin01.noumea.spc.local/~fabriceb/Web/TUMAS/lib/OFP-fx.jar.pack.gz
>
The exception is:
com.sun.deploy.net.JARSigningException: Could not verify signing in resource: http://devlin01.noumea.spc.local/~fabriceb/Web/TUMAS/lib/OFP-fx.jar.pack.gz
     at com.sun.deploy.security.JarVerifier.authenticateJarEntry(Unknown Source)
     at com.sun.deploy.security.EnhancedJarVerifier.validate(Unknown Source)
     at com.sun.deploy.cache.CacheEntry.processJar(Unknown Source)
     at com.sun.deploy.cache.CacheEntry.access$2200(Unknown Source)
     at com.sun.deploy.cache.CacheEntry$9.run(Unknown Source)
     at java.security.AccessController.doPrivileged(Native Method)
     at com.sun.deploy.cache.CacheEntry.writeFileToDisk(Unknown Source)
     at com.sun.deploy.cache.Cache.downloadResourceToTempFile(Unknown Source)
     at com.sun.deploy.cache.Cache.downloadResourceToCache(Unknown Source)
     at com.sun.deploy.net.DownloadEngine.actionDownload(Unknown Source)
     at com.sun.deploy.net.DownloadEngine.getCacheEntry(Unknown Source)
     at com.sun.deploy.net.DownloadEngine.getCacheEntry(Unknown Source)
     at com.sun.deploy.net.DownloadEngine.getResourceCacheEntry(Unknown Source)
     at com.sun.deploy.net.DownloadEngine.getResourceCacheEntry(Unknown Source)
     at com.sun.deploy.net.DownloadEngine.getResource(Unknown Source)
     at com.sun.javaws.LaunchDownload$DownloadTask.call(Unknown Source)
     at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source)
     at java.util.concurrent.FutureTask.run(Unknown Source)
     at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
     at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
     at java.lang.Thread.run(Unknown Source)The wrapped exception is:
java.lang.SecurityException: SHA1 digest error for org/spc/ofp/javafx/scene/control/dialog/TitleLabel$TitleLabel$Script.class
     at sun.security.util.ManifestEntryVerifier.verify(Unknown Source)
     at java.util.jar.JarVerifier.processEntry(Unknown Source)
     at java.util.jar.JarVerifier.update(Unknown Source)
     at java.util.jar.JarVerifier$VerifierStream.read(Unknown Source)
     at com.sun.deploy.security.JarVerifier.readAndMaybeSaveStreamTo(Unknown Source)
     at com.sun.deploy.security.JarVerifier.authenticateJarEntry(Unknown Source)
     at com.sun.deploy.security.EnhancedJarVerifier.validate(Unknown Source)
     at com.sun.deploy.cache.CacheEntry.processJar(Unknown Source)
     at com.sun.deploy.cache.CacheEntry.access$2200(Unknown Source)
     at com.sun.deploy.cache.CacheEntry$9.run(Unknown Source)
     at java.security.AccessController.doPrivileged(Native Method)
     at com.sun.deploy.cache.CacheEntry.writeFileToDisk(Unknown Source)
     at com.sun.deploy.cache.Cache.downloadResourceToTempFile(Unknown Source)
     at com.sun.deploy.cache.Cache.downloadResourceToCache(Unknown Source)
     at com.sun.deploy.net.DownloadEngine.actionDownload(Unknown Source)
     at com.sun.deploy.net.DownloadEngine.getCacheEntry(Unknown Source)
     at com.sun.deploy.net.DownloadEngine.getCacheEntry(Unknown Source)
     at com.sun.deploy.net.DownloadEngine.getResourceCacheEntry(Unknown Source)
     at com.sun.deploy.net.DownloadEngine.getResourceCacheEntry(Unknown Source)
     at com.sun.deploy.net.DownloadEngine.getResource(Unknown Source)
     at com.sun.javaws.LaunchDownload$DownloadTask.call(Unknown Source)
     at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source)
     at java.util.concurrent.FutureTask.run(Unknown Source)
     at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
     at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
     at java.lang.Thread.run(Unknown Source)The main JNLP is:
<jnlp spec="1.0+" codebase="http://devlin01.noumea.spc.local/~fabriceb/Web/TUMAS/" href="TUMAS-fx.jnlp">
<information>
    <title>TUMAS development standalone version</title>
    <vendor>CPS-SPC Secretariat of the Pacific Community</vendor>
    <homepage href="http://www.tumas-project.org/"/>
    <description>Management Option Visualisation Tool</description>
    <description kind="short">Management Option Visualisation Tool</description>
    <description kind="one-line">Management Option Visualisation Tool</description>
    <description kind="tooltip">Management Option Visualisation Tool</description>
    <icon kind="default" href="MOViT.gif" width="128" height="128" size="10948"/>
    <icon kind="shortcut" href="MOViT.gif" width="128" height="128" size="10948"/>
    <icon kind="splash" href="MOViT.gif" width="128" height="128" size="10948"/>
    <offline-allowed/>
    <shortcut online="false">
      <desktop/>
      <menu submenu="TUMAS"/>
    </shortcut>
</information>
<security>
    <all-permissions/>
</security>
<update check="always"/>
<resources>
    <java max-heap-size="800m" version="1.6+"/>
    <jar href="TUMAS-fx.jar" main="true" size="154269"/>
    <extension name="MOViT" href="MOViT.jnlp"/>
    <extension name="l2fprod-7.3" href="l2fprod-7.3.jnlp"/>
    <extension name="JFXtras-0.7" href="JFXtras-0.7.jnlp"/>
    <extension name="gnujpdf-1.7" href="gnujpdf-1.7.jnlp"/>
    <extension name="Apache-POI-3.6" href="Apache-POI-3.6.jnlp"/>
    <extension name="SwingX-1.6.1" href="SwingX-1.6.1.jnlp"/>
    <extension name="OpenMap-5.0" href="OpenMap-5.0.jnlp"/>
    <extension name="JavaFX 1.3.x Runtime" href="http://dl.javafx.com/1.3/javafx-rt.jnlp"/>
    <property name="jnlp.packEnabled" value="true"/>
</resources>
<application-desc main-class="com.sun.javafx.runtime.main.Main">
    <argument>MainJavaFXScript=org.spc.ofp.project.tumas.TUMAS</argument>
    <argument>--development</argument>
</application-desc>
</jnlp>The JNLP which contains the offending lib is:
<?xml version="1.0" encoding="UTF-8"?>
<jnlp spec="1.0+" codebase="http://devlin01.noumea.spc.local/~fabriceb/Web/TUMAS/" href="MOViT.jnlp">
    <information>
        <title>MOViT</title>
        <vendor>CPS-SPC Secretariat of the Pacific Community</vendor>
        <homepage href="http://www.tumas-project.org/"/>
        <description>Management Option Visualisation Tool</description>
        <offline-allowed/>
    </information>
    <security>
       <all-permissions/>
    </security>
    <resources>
       <jar href="lib/OFP-core.jar" part="MOViT" size="384817"/>
       <jar href="lib/OFP-GIS.jar" part="MOViT" size="10608"/>
       <jar href="lib/OFP-fx.jar" part="MOViT" size="2325354"/>
       <jar href="lib/OFP-fx-mappane.jar" part="MOViT" size="3277991"/>
       <jar href="lib/MFCL-IO.jar" part="MOViT" size="82454"/>
       <jar href="lib/MOViT-templates.jar" part="MOViT" size="5142641"/>
       <jar href="lib/MOViT-ztm.jar" part="MOViT" size="59484"/>
       <jar href="lib/MOViT-ztp.jar" part="MOViT" size="56450"/>
       <jar href="lib/MOViT-zte.jar" part="MOViT" size="41706"/>
       <jar href="lib/MOViT-fishery.jar" part="MOViT" size="66291"/>
       <jar href="lib/MOViT-fx.jar" part="MOViT" size="3282871"/>
       <jar href="lib/SPINiT-fx.jar" part="MOViT" size="332428"/>
       <property name="jnlp.packEnabled" value="true"/>
    </resources>
    <component-desc/>
</jnlp>The following command lines are used when packing + signing the file (extra private bits have been removed) :
► Normalizing file: "<path to file>OFP-fx.jar"
Executing: "C:\Program Files (x86)\Java\jdk1.6.0_29/bin/pack200" --repack --effort=9 --segment-limit=-1 --modification-time=latest --strip-debug "<path to file>OFP-fx.jar"
process exited with error code: 0
► Signing file: "<path to file>OFP-fx.jar"
Executing: "C:\Program Files (x86)\Java\jdk1.6.0_29/bin/jarsigner" -verify "<path to file>OFP-fx.jar"
process exited with error code: 0
Executing: "C:\Program Files (x86)\Java\jdk1.6.0_29/bin/jarsigner" -tsa <timestamp server> -J-Dhttp.proxyHost=<our proxy host> -J-Dhttp.proxyPort=<our proxy port> -keystore <our store> -storepass <our password> "<path to file>OFP-fx.jar" <our alias>
process exited with error code: 0
► Packing file: "<path to file>OFP-fx.jar"
Executing: "C:\Program Files (x86)\Java\jdk1.6.0_29/bin/pack200" "<path to file>OFP-fx.jar.pack.gz" "<path to file>OFP-fx.jar"
process exited with error code: 0Any idea, besides reinstalling an older JDK and/or runtime?

bouye wrote:
Thanks for the suggestion and let's hop they put some process to prevent similar issues from hapening again in the future.False hope. Programming is hard, release management is hard, testing is hard, people make mistakes, budget restrictions cause mistakes to slip through, etc. etc.
The most important factor in all this really is us and more specifically our willingness to properly report problems.

Is it possible to verify a signed jar-file from a program?

Is it possible to verify a signed jar-file from a program
(using some API) likewise jarsigner does?

Is it possible to verify a signed jar-file from a
program
(using some API) likewise jarsigner does?Hi,
You would have to open the jarfile, read each jar entry and for each of them do a getCertificates() and then in turn verify each certificate with the public key of the enclosed certificates in the jar file.
An easier solution would be to use the verify flag of the JarFile or JarInputStream.
Hope it helps..
Cheers,
Vijay

NullPointerException thrown in PKCS12KeyStore when verifying a signed JAR

Hi,
java -versionjava version "1.6.0_07"
Java(TM) SE Runtime Environment (build 1.6.0_07-b06)
Java HotSpot(TM) Client VM (build 10.0-b23, mixed mode, sharing)
(WinXP)
I've signed a JAR with a new pkcs12 certificate using:
jarsigner -keystore mystore.p12 -storetype pkcs12 -verbose my.jar myaliasNo errors or warnings were generated and each class file was listed as it was signed. When I attempt to verify the JAR, I get a NullPointerException from jarsigner, as it attempts to read the first signed entry (.class):
jarsigner -keystore mystore.p12 -storetype pkcs12 -verbose -verify -debug my.jar5450 Sun Oct 05 07:53:06 EST 2008 META-INF/MANIFEST.MF
0 Sun Oct 05 07:52:22 EST 2008 com/my/package/subpackage1
0 Sun Oct 05 07:52:22 EST 2008 com/my/package/subpackage2
jarsigner: java.lang.NullPointerException
java.lang.NullPointerException
at com.sun.net.ssl.internal.pkcs12.PKCS12KeyStore.engineGetCertificateAl
ias(PKCS12KeyStore.java:721)
at java.security.KeyStore.getCertificateAlias(KeyStore.java:1092)
at sun.security.tools.JarSigner.inKeyStore(JarSigner.java:791)
at sun.security.tools.JarSigner.verifyJar(JarSigner.java:491)
at sun.security.tools.JarSigner.run(JarSigner.java:193)
at sun.security.tools.JarSigner.main(JarSigner.java:74)
Anyone seen anything like this before or can suggest what might cause it? Is there something wrong with my new certificate?
Thanks
Brett

The jarsigner -verify command only verfies the authenticity of the signed JAR file using the certificate inside the .DSA file in the JAR.That's not true. See the Javadoc for the 'jarsigner' tool, in 'verify' mode, 'keystore' option.

Loading images in a signed jar

Hi,
I am trying to run an application using signed jars.
One of the jars contains gif and jpeg files (icons).
When I sign icons.jar and try to run the code (from
the command line), I get the error listed below.
Any help would be greayly appreciated.
Thanks
Charles
An unexpected exception has been detected in native code outside the VM.
Unexpected Signal : EXCEPTION_ACCESS_VIOLATION (0xc0000005) occurred at PC=0x76136B9
Function=JNI_OnLoad+0x24D
Library=C:\j2sdk1.4.2_02\jre\bin\jpeg.dll
Current Java thread:
     at sun.awt.image.JPEGImageDecoder.readImage(Native Method)
     at sun.awt.image.JPEGImageDecoder.produceImage(JPEGImageDecoder.java:144)
     at sun.awt.image.InputStreamImageSource.doFetch(InputStreamImageSource.java:254)
     at sun.awt.image.ImageFetcher.fetchloop(ImageFetcher.java:172)
     at sun.awt.image.ImageFetcher.run(ImageFetcher.java:136)
Dynamic libraries:
0x00400000 - 0x00407000      C:\j2sdk1.4.2_02\bin\javaw.exe
0x77F50000 - 0x77FF6000      C:\WINDOWS\System32\ntdll.dll
0x77E60000 - 0x77F45000      C:\WINDOWS\system32\kernel32.dll
0x77DD0000 - 0x77E5B000      C:\WINDOWS\system32\ADVAPI32.dll
0x78000000 - 0x7806E000      C:\WINDOWS\system32\RPCRT4.dll
0x77D40000 - 0x77DC6000      C:\WINDOWS\system32\USER32.dll
0x77C70000 - 0x77CB0000      C:\WINDOWS\system32\GDI32.dll
0x77C10000 - 0x77C63000      C:\WINDOWS\system32\MSVCRT.dll
0x08000000 - 0x08138000      C:\j2sdk1.4.2_02\jre\bin\client\jvm.dll
0x76B40000 - 0x76B6C000      C:\WINDOWS\System32\WINMM.dll
0x10000000 - 0x10007000      C:\j2sdk1.4.2_02\jre\bin\hpi.dll
0x00820000 - 0x0082E000      C:\j2sdk1.4.2_02\jre\bin\verify.dll
0x00830000 - 0x00849000      C:\j2sdk1.4.2_02\jre\bin\java.dll
0x00850000 - 0x0085D000      C:\j2sdk1.4.2_02\jre\bin\zip.dll
0x03240000 - 0x0334F000      C:\j2sdk1.4.2_02\jre\bin\awt.dll
0x73000000 - 0x73023000      C:\WINDOWS\System32\WINSPOOL.DRV
0x76390000 - 0x763AA000      C:\WINDOWS\System32\IMM32.dll
0x771B0000 - 0x772C0000      C:\WINDOWS\system32\ole32.dll
0x5AD70000 - 0x5ADA4000      C:\WINDOWS\system32\uxtheme.dll
0x033C0000 - 0x03410000      C:\j2sdk1.4.2_02\jre\bin\fontmanager.dll
0x73760000 - 0x737A5000      C:\WINDOWS\System32\ddraw.dll
0x73BC0000 - 0x73BC6000      C:\WINDOWS\System32\DCIMAN32.dll
0x73940000 - 0x73A07000      C:\WINDOWS\System32\D3DIM700.DLL
0x07610000 - 0x0762E000      C:\j2sdk1.4.2_02\jre\bin\jpeg.dll
0x76C90000 - 0x76CB2000      C:\WINDOWS\system32\imagehlp.dll
0x6D510000 - 0x6D58C000      C:\WINDOWS\system32\DBGHELP.dll
0x77C00000 - 0x77C07000      C:\WINDOWS\system32\VERSION.dll
0x76BF0000 - 0x76BFB000      C:\WINDOWS\System32\PSAPI.DLL
Heap at VM Abort:
Heap
def new generation total 576K, used 571K [0x10010000, 0x100b0000, 0x104f0000)
eden space 512K, 99% used [0x10010000, 0x1008ecb8, 0x10090000)
from space 64K, 99% used [0x100a0000, 0x100afff8, 0x100b0000)
to space 64K, 0% used [0x10090000, 0x10090000, 0x100a0000)
tenured generation total 1784K, used 1163K [0x104f0000, 0x106ae000, 0x14010000)
the space 1784K, 65% used [0x104f0000, 0x10612c28, 0x10612e00, 0x106ae000)
compacting perm gen total 6912K, used 6759K [0x14010000, 0x146d0000, 0x18010000)
the space 6912K, 97% used [0x14010000, 0x146a9c48, 0x146a9e00, 0x146d0000)
Local Time = Sun Oct 26 16:26:58 2003
Elapsed Time = 10
# The exception above was detected in native code outside the VM
# Java VM: Java HotSpot(TM) Client VM (1.4.2_02-b03 mixed mode)
# An error report file has been saved as hs_err_pid3068.log.
# Please refer to the file for further information.
Corrupt JPEG data: bad Huffman code

http://developer.java.sun.com/developer/bugParade/bugs/4675817.html
You must try using WinZip & not compressing the jpeg's.

Could not verify signing in resource

Hi all.
I've been banging my head against a wall for the past 2 days trying to figure this out to no avail. I'm simply trying to use Java Web Start to distribute my Swing application but always receive the same error dialog :
com.sun.deploy.net.JARSigningException
Could not verify signing in resource : ***.jar
I'm using Netbeans 6 and have tried manually signing all the jars as well as the netbeans web start self-signed feature : both give the same behaviour.
I have used jarsigner -verify -certs which confirms the certificate for the jar and I've tried with 1.5 and 1.6 jdks.
I've searched tonnes of websites and forums but can't find the answer - hopefully someone can help.
Any ideas?
JGreg
SCJD
Zoom Software

Thanks Joe.
The jar in question is a 3rd party library.
I have checked it with jarsigner -verify ***.jar and get the following output :
jar is unsigned. (signature missing or not parsable).
So that should confirm the original jar is not signed. Unless you can hide a signature from jarsigner -verify with obfuscation?
Also, I think they removed the single signature requirement in jdk 6.
Still completely stuck on this unfortunately.
JGreg
www.zoom-software.com

Problem Packing Signed JARs of more than 10 MB

Hi friends of Java,
there seems to be a size issue when packing signed JARs.
When I try to pack a signed JAR of about 5 MEGs (such as the jbossall_client.jar file) it works (i.e. jarsigner can verify the result),
but if i try doing it with a JAR of about 11 MEGs the jarsigner can't verify the packed (and unpacked again) file.
Example:
C:\p\u\ccm_wa\basis_web\santafu~tnagel\santafu>dir temp\webstart\BasisWebClient.jar
06.03.2009 17:32 10.943.963 BasisWebClient.jar
C:\p\u\ccm_wa\basis_web\santafu~tnagel\santafu>pack200 --repack temp\webstart\BasisWebClient.jar
C:\p\u\ccm_wa\basis_web\santafu~tnagel\santafu>jarsigner -storepass xxxxxx -keystore resources\build\key\BasisWebKeystore temp\webstart\BasisWebClient.jar BasisWeb
C:\p\u\ccm_wa\basis_web\santafu~tnagel\santafu>jarsigner -verify temp\webstart\BasisWebClient.jar
jar verified.
C:\p\u\ccm_wa\basis_web\santafu~tnagel\santafu>pack200 temp\webstart\BasisWebClient.jar.pack.gz temp\webstart\BasisWebClient.jar
C:\p\u\ccm_wa\basis_web\santafu~tnagel\santafu>unpack200 temp\webstart\BasisWebClient.jar.pack.gz test.jar
C:\p\u\ccm_wa\basis_web\santafu~tnagel\santafu>jarsigner -verify test.jar
jarsigner: java.lang.SecurityException: SHA1 digest error for basisweb/vg/presenter/SchluesselBezeichnungDialogPresenter.class
The same with a smaller file:
C:\p\u\ccm_wa\basis_web\santafu~tnagel\santafu>dir temp\webstart\jbossall-client.jar
31.08.2007 07:31 4.895.807 jbossall-client.jar
C:\p\u\ccm_wa\basis_web\santafu~tnagel\santafu>pack200 --repack temp\webstart\jbossall-client.jar
C:\p\u\ccm_wa\basis_web\santafu~tnagel\santafu>jarsigner -storepass xxxxx -keystore resources\build\key\BasisWebKeystore temp\webstart\jbossall-client.jar BasisWeb
C:\p\u\ccm_wa\basis_web\santafu~tnagel\santafu>jarsigner -verify temp\webstart\jbossall-client.jar
jar verified.
C:\p\u\ccm_wa\basis_web\santafu~tnagel\santafu>pack200 temp\webstart\jbossall-client.jar.pack.gz temp\webstart\jbossall-client.jar
C:\p\u\ccm_wa\basis_web\santafu~tnagel\santafu>unpack200 temp\webstart\jbossall-client.jar.pack.gz test.jar
C:\p\u\ccm_wa\basis_web\santafu~tnagel\santafu>jarsigner -verify test.jar
jar verified.
It also works when I split the original JAR in multiple parts. Any ideas?
Used Java Version:
java version "1.6.0_12"
Java(TM) SE Runtime Environment (build 1.6.0_12-b04)
Java HotSpot(TM) Client VM (build 11.2-b01, mixed mode, sharing)
OS: Windows XP Pro Version 2002 SP2
PC: Intel Pentium 4 3.2GHz, 2GB RAM, 160 GB HD
Regards from Germany,
Thomas Nagel

Hello Bryan,
I dont have a solution yet. Currently we use the jars uncompressed. Sad, but that works.
For the future, we are not really sure wether we can stick with JWS, as the signed JNLP-file-issue might make us even more trouble.
I've done some error search. Look at the following.
Try for your own with some different sized jar's, and maybe post the results (definitely if they all pass):
--- snip ----
package ctest;
import java.io.File;
import java.io.FileOutputStream;
import java.io.IOException;
import java.util.Enumeration;
import java.util.Map;
import java.util.jar.*;
import java.util.jar.Pack200.*;
* @author tnagel
public class PackTest implements Runnable {
     String test1 = "junit";
     String test2a = "xalan";
     String test2 = "jbossall-client";
String test3 = "BasisWebClient2";
String dir = "/tmp/";
String ext1 = ".jar";
String ext2 = ".jar.pack.gz";
//String infile = "/tmp/BasisWebClient.jar";
//String outfile = "/tmp/BasisWebClient.jar.pack.gz";
//String testfile = "/tmp/testaus.jar";
* @param args the command line arguments
public static void main(String[] args) {
     PackTest me = new PackTest(args);
public PackTest(String[] args) {
this.run();
public void setProperties(Packer packer) {
// Initialize the state by setting the desired properties
Map p = packer.properties();
// take more time choosing codings for better compression
p.put(Packer.EFFORT, "9"); // default is "5"
//// use largest-possible archive segments (>10% better compression).
// p.put(Packer.SEGMENT_LIMIT, "-1");
//// reorder files for better compression.
//p.put(Packer.KEEP_FILE_ORDER, Packer.FALSE);
//// smear modification times to a single value.
//p.put(Packer.MODIFICATION_TIME, Packer.LATEST);
//// ignore all JAR deflation requests,
//// transmitting a single request to use "store" mode.
//p.put(Packer.DEFLATE_HINT, Packer.FALSE);
//// discard debug attributes
//p.put(Packer.CODE_ATTRIBUTE_PFX+"LineNumberTable", Packer.STRIP);
// throw an error if an attribute is unrecognized
p.put(Packer.UNKNOWN_ATTRIBUTE, Packer.ERROR);
//// pass one class file uncompressed:
//p.put(Packer.PASS_FILE_PFX+0, "mutants/Rogue.class");
@Override
public void run() {
     doTest(test1, true);
     doTest(test2, true);
     doTest(test3, true);
     doTest(test3, true);
     doTest(test3, true);
private void doTest(String test, boolean compare) {
String infile = dir + test + ext1;      // "/tmp/BasisWebClient.jar";
String outfile = dir + test + ext2; // "/tmp/BasisWebClient.jar.pack.gz";
String testfile = dir + test+ "-aus" + ext1;
try {
     countJar(infile, false);
     JarFile jarFile = new JarFile(infile);
FileOutputStream fos = new FileOutputStream(outfile);
// Create the Packer object
Packer packer = Pack200.newPacker();
setProperties(packer);
// call the packer
long startTimeMethode =System.currentTimeMillis();
packer.pack(jarFile, fos);
System.out.println("Time for Pack: " + (System.currentTimeMillis() - startTimeMethode));
jarFile.close();
fos.close();
File f = new File(outfile);
FileOutputStream fostream = new FileOutputStream(testfile);
JarOutputStream jostream = new JarOutputStream(fostream);
Unpacker unpacker = Pack200.newUnpacker();
// Call the unpacker
startTimeMethode =System.currentTimeMillis();
unpacker.unpack(f, jostream);
System.out.println("Time for Unpack: " + (System.currentTimeMillis() - startTimeMethode));
// Must explicitly close the output.
jostream.close();
     countJar(testfile, false);
     if(compare) compareJars(infile,testfile);
} catch (IOException ioe) {
     System.err.println(ioe);
ioe.printStackTrace();
private void countJar(String filename, boolean showDetails) {
     JarFile jarFile1 = null;
     try {
          int entries = 0;
          long sizeTotal = 0L;
          long compressedSum = 0L;
          jarFile1 = new JarFile(filename);
          Enumeration e = jarFile1.entries();
          while(e.hasMoreElements()) {
               JarEntry jarE = (JarEntry) e.nextElement();
               entries ++;
               sizeTotal += jarE.getSize();
               compressedSum += jarE.getCompressedSize();
               if(showDetails) {
                    System.out.println( jarE.getName() + " s= " + jarE.getSize() + " c= " + jarE.getCompressedSize() );
          System.out.println( filename + ": " + entries + " entries, " + sizeTotal + " Byte, compressed " + compressedSum + " Byte" );
} catch (IOException ioe) {
     System.err.println(ioe);
ioe.printStackTrace();
} finally {
     try { if(jarFile1 != null) jarFile1.close(); } catch (Exception e) { }
private void compareJars(String erstes, String zweites) {
     JarFile jarFile1 = null;
     JarFile jarFile2 = null;
     try {
          int fehler = 0;
          int entries = 0;
          jarFile1 = new JarFile(erstes);
          jarFile2 = new JarFile(zweites);
          Enumeration e1 = jarFile1.entries();
          Enumeration e2 = jarFile2.entries();
          while(e1.hasMoreElements()) {
               JarEntry jarE1 = (JarEntry) e1.nextElement();
               if(e2.hasMoreElements()) {
                    JarEntry jarE2 = (JarEntry) e2.nextElement();
                    entries++;
                    if(!jarE1.getName().equals(jarE2.getName())) {
                         System.out.println( "Name different at Index= " + entries+ " n1=" + jarE1.getName() + " n2=" + jarE2.getName() );
                         fehler ++;
                         break;
                    if(jarE1.getSize() != jarE2.getSize()) {
                         System.out.println( "Size different at bei " + jarE1.getName() + " Index= " + entries + " s1=" + jarE1.getSize() + " s2=" + jarE2.getSize());
                         fehler ++;
                    if(jarE1.getCrc() != jarE2.getCrc()) {
                         System.out.println( "CRC different at " + jarE1.getName() + " Index= " + entries + " s1=" + jarE1.getCrc() + " s2=" + jarE2.getCrc());
                         fehler ++;
                    if(jarE1.getMethod() != jarE2.getMethod()) {
                         System.out.println( "Method different at " + jarE1.getName() + " Index= " + entries + " m1=" + jarE1.getMethod() + " m2=" + jarE2.getMethod());
                         fehler ++;
          System.out.println( "Errors= " + fehler + " entries=" + entries );
} catch (IOException ioe) {
     System.err.println(ioe);
ioe.printStackTrace();
} finally {
     try { if(jarFile1 != null) jarFile1.close(); } catch (Exception e) { }
     try { if(jarFile2 != null) jarFile2.close(); } catch (Exception e) { }
--- snip ----
Cheers,
Thomas

Problems during execution of signed JARs applet...

Hi Everyone,
I noticed that AppletViewer used for development allows a wider range of operation not permitted during the execution in browser of a signed JAR.
I would be interested to know if this is caused because I am using a not real certificate (generated for testing). Anyone with a real certificate may tell me if for example URLClassLoader works well with jar applet signed with his real certificate?
Thanks, bye

Thanks, you confirm what I was not anymore able to verify in my browser :)
In fact the very first time I launched my applet in browser, the browser was showing a detailed message dialog pane complaining the untrustable certificate and restricted access privileges, so I thought to accept untrusted certificate as default and I tried to set up some options in security panel of the browser to trust untrusted certificate. Consequentely I was receiving only the untrusted certificate warning without any restriction message warning.
I understood that applets signed with untrusted certificates gives some more privilege than applet not signed, but evidently the security level of untrusted certificate does not give all total priviliges that trusted certificate does.

Problems with Signed jar

I am having a problem with signed jar and deploy in html
get this error on the page
self signed
/dist/testfx.html
JavaFX application could not launch due to system configuration. See java.com/javafx for troubleshooting information.Unsigned jar works perfectly but has security and permission issues when using classes.
This was working in beta 45

Can you post an example project that demonstrates the problem? There were changes to the ant tasks and netbeans support around B45 that could cause problems depending on which version of the SDK and NetBeans you have. Similarly, if you wrote ant scripts prior to B44 and then use them with a later build you could have problems. And of course, if you're producing the Jar file and deployment artifacts without using the provided ant tasks (for example, using the normal ant jar task) you'll have problems.
I've verified that this works as expected in the FX 2.0 GA release using ant from the command line, and with the NetBeans 7.1 beta release using the FX 2.0 GA release.

Three questions about signed jar file and applet

I use three signed jar file. Each of them signed by different certificate. First of JARs contain applet class. When I start applet from html page I see message “This applet was signed by…… but Java cannot verify it… Do you trust…?”. All times I press “Yes I trust” and after this questions applet stop to work end exit. If I use only one certificate for signing of three JARs then applet continue to work after question. 1) What should I do to fix this bug? 2) Is it any method to check from applet that user press Trust button? Is it any method to emulate work of SecurityManager to check that Certificate object is trusted (I want do call some method check(Certificate) and if certificate is not trusted I want to see message with question: “Do you want to trust this certificate” and so on)?

Hello Jarman,
1. If I have a signed jar file, then as long as the
certificate is recognised as trusted that applet can
run as a fully trusted application on the client
machine. So I should not have to add lines such as
permission java.lang.RuntimePermission
"readFileDescriptor", "read" ;
permission java.lang.RuntimePermission
"writeFileDescriptor", "write" ;
to my java.policy file. true/false ?true
2. If I am running a signed jar file in the Java
plugin then I do not need to have a verisign or thawte
certificate (however to allow my certificate to be
accepted I do have to import it into the cacerts file
on the client machine). True/false?true
3. Following on from question 2, if I want to be able
to run an applet on a client machine, without messing
around with ANY files on those machines, I need a
verisign or thawte certificate. True/false?true
4. (And finally) Apart from a security exception
saying that I need to add one of the lines like those
of question 1, is there any way I can get other debug
information as to why the signed jar file is not being
recognised as signed?No. This could be a problem of importing your certifcate into the wrong place.
The information on the following link is a little bit dated but it helped me to successfully install a testcertificate and sign an applet with it.
http://www.suitable.com/Doc_CodeSigning.shtml

Verify modified jar files

Hi all,
I would like to address a few issues that I have with signed jar files.
1. I have signed a jar file and am still able to open and change in WinZip. Can I encrypt it so that the contents are not visible in WinZip. If I have an XML or a Text file. I can still change it in WinZip and after I verify it, it verifies successfully, even though the file structure and time-stamp changed.
Web Start does not recognize the change in the time-stamp because the time on the client is newer than the timestamp of the jar file on the server and hence It does not update.
Any ones thoughs?
Thank you
Sameer Jaffer

1. I have signed a jar file and am still able to open
and change in WinZip.Which is correct behaviour.
A signed jar is a jar which comes with a list of signatures for
its entries.
The META-INF/MANIFEST.MF lists entries plus their cryptographic hash number.
The idea is not to hide content, but to show that the contents are authentic, by providing others a means to calculate and compare cryptographic hash numbers.
Can I encrypt it so that the
contents are not visible in WinZip. If I have an XML
or a Text file. I can still change it in WinZip and
after I verify it, it verifies successfully, This is strange. I guess that xml or test file doesn't show up in the manifest.
It should look like this:
Manifest-Version: 1.0
Main-Class: com.foo.bar
Created-By: 1.3.0 (IBM Corporation)
Name: org/w3c/dom/html/HTMLDivElement.class
SHA1-Digest: KEGYSI2N6pAlc/5X7uVJu8JgEz0=
Name: com/klg/jclass/util/swing/icons/JCBraceIcon32.gif
SHA1-Digest: WPiVbRyUePXzwDmBwRJVAsrN6Qo=
Because you should have provided a new hash once you changed the entry.
Otherwise Web Start, when verifying the entries (which means it calculates its own hash numbers of the jar entries and then compares them to the hash number listed in the manifest) should complain.
Regards,
Marc

Sign jar using PGP

Hi folks,
I do have long used PGP keys (over 7 years). I would like
to sign jar file using those my PGP key. How should I do that?
I mean I can just sign jar in standard PGP way, but I would like
to sign jar file in way jarsigner does. Such that in jar meta
one would see PGP signature and could verify it using jarsigner
or other software of that kind. How it's possible?
Please help. Bunch of dukes are awaiting you! Urgent!
Paul

Sure it knows nothing about PGP. You have to use PGP
tools to export that key to one of the formats those
can be understanded by keytool (such as x509 or
pkcs12). I do know nothing about these PGP tools to export PGP keys
to x509 and/or pkcs12 - please hint me what tools you
are talking about?The universal hint is: Google -> "PGP key export" -> Search
Another possibility is to export RSA key to the DER
encoding and then write a little program to read it
and then add to the keystore. This is looks like an
easy task. I believe you can easily find source to
convert pkcs12 keystore to JKS and use that one as a
starting point.I would be happy if you will point me the source to convert
pkcs12 keystore into JKS. BTW what's JKS?Google -> "convert pkcs12 to JKS" -> Search
JKS == Java Key Store
Sorry for my stupidity... I've last touched PGP/RSA issues
5 or 6 years ago, since that time technology a bit changed :)It is a good idea to read some fundamental first. Take a look at http://java.sun.com/products/jce/index-14.html

Verifying signed JARs is crap!

Similar Messages

Maybe you are looking for