Unsigning a signed jar

Hi,
I have a signed that I need to make changes to.
I thought it would be possible to do this by removing:
1.The digest entries in the manifest
2.Signature file
3.Signature block file
However, I get:
java.lang.Error: Unresolved compilation problems:
The import com.fineos.ta.servlet cannot be resolved
for files that are in the jar file, when I try to use this jar file.
Any ideas?
Thanks

I would unjar it, remove the manifest directory and compile what you need using the class files you just unjarred. Signing doesn't affect compiling unless you've corrupted the jar file.
After you make changes, you will need to re-sign the file however if you still need it signed.

Similar Messages

Is a signed jar with another unsigned jar possible?

Is it possible to use 1 signed jar with another unsigned jar with webstart. I read this wasn't possible with version 1.0, but what about higher versions? if so how to specify this?
Thanks
James
Edited by: fatbatman on Mar 26, 2009 1:01 PM

All jars within same jnlp must be signed with the same certificate, but you can use extensions to have many jnlp with different (or no) signature within the same application.
Bye.

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.

Signed jars + CGLIB = SecurityException

Good Day!
I have the following problem:
My project uses a number of JARs signed with a jarsigner tool from JAVA distribution package including hibernate2.jar (the jar with all the hibernate stuff), spring.jar and cglib.jar (I think, exact names doesn't matter). All this jars are signed off course for security reasons.
Then, I have my project working with Hibernate, and it uses lazy-initialized ORM-classes, so Hibernate tries to generate a proxy via CGLIB for these classes. But during initialization of Hibernate SessionFactoryImpl I'm getting a java.lang.SecurityException:
java.lang.SecurityException: class "cern.spsea.hibernatebeans.BeamFileHibernateBean$$EnhancerByCGLIB$$773cc7e9"'s signer information does not match signer information of other classes in the same package
cern.spsea.hibernatebeans.BeamFileHibernateBean is one of my ORM-classes and all my classes are not signed because they are in development (they are not in jar, so they can not be signed).
I think it happens because signed code (from hibernate.jar and cglib.jar) tries to generate another signed code (cern.spsea.hibernatebeans.BeamFileHibernateBean$$EnhancerByCGLIB$$773cc7e9) but relate it to my unsigned package (cern.spsea.hibernatebeans).
So, I have a couple of questions:
1. Does signed code generates also signed code?
2. If so, what can I do for development? I really need to avoid this problem only at development, because at release my classes will be also in the signed jars. Can I force CGLIB to generate not signed classes? Is it some options in JVM start command to skip security checking? May be something else?
Any help is appreciated!
Thanks a lot in advance!
Roman

In my jboss environment I hit the problem because I had a JWS client download war with signed versions of the jar files.
The fix was to have unsigned versions of the server-side war files (session ejbs with hibernate + pojos inside) FIRST in my application.xml file (jars enter the "classpath" in the order that they are in that file) ahead of the web app .war file for the JWS downloads.

CGLIB generation from signed classes(in signed jar) = SecurityException

Good Day!
I have the following problem:
My project uses a number of JARs signed with a jarsigner tool from JAVA distribution package including hibernate2.jar (the jar with all the hibernate stuff), spring.jar and cglib.jar (I think, exact names doesn't matter). All this jars are signed off course for security reasons.
Then, I have my project working with Hibernate, and it uses lazy-initialized ORM-classes, so Hibernate tries to generate a proxy via CGLIB for these classes. But during initialization of Hibernate SessionFactoryImpl I'm getting a java.lang.SecurityException:
java.lang.SecurityException: class "cern.spsea.hibernatebeans.BeamFileHibernateBean$$EnhancerByCGLIB$$773cc7e9"'s signer information does not match signer information of other classes in the same package
cern.spsea.hibernatebeans.BeamFileHibernateBean is one of my ORM-classes and all my classes are not signed because they are in development (they are not in jar, so they can not be signed).
I think it happens because signed code (from hibernate.jar and cglib.jar) tries to generate another signed code (cern.spsea.hibernatebeans.BeamFileHibernateBean$$EnhancerByCGLIB$$773cc7e9) but relate it to my unsigned package (cern.spsea.hibernatebeans).
So, I have a couple of questions:
1. Does signed code generates also signed code?
2. If so, what can I do for development? I really need to avoid this problem only at development, because at release my classes will be also in the signed jars. Can I force CGLIB to generate not signed classes? Is it some options in JVM start command to skip security checking? May be something else?
Any help is appreciated!
Thanks a lot in advance!
Roman

I've got the same problem, if someone could help us he'll be very helpful.
Regards,
Alx

Navigating between applets from the same signed jar (trusted CA) gives err

See [http://www.chrisnewland.com/java-7-update-21-signedunsigned-error-switching-between-applets-in-the-same-signed-jar-trusted-ca-339] for my investigations so far.
Clicking a link to navigate between applets contained in the same signed jar (signed by a trusted CA) pops up an error dialog complaining about a signed/unsigned code mix.
Loading each applet in a fresh browser works fine.
If you click from applet 1 to applet 2 via a non-applet page then both applets run without problem.
[EDIT: This is behaviour is new to 7u21]
Edited by: Chris Newland on Apr 17, 2013 3:19 AM

I tried that (Adding Trusted-Library true) to the jars and even the 3rd party jars. I still get the pop up and this error:
Exception in thread "thread applet-com/travelers/prefillapplet/PrefillApp.class-1" java.lang.NoClassDefFoundError: org/apache/log4j/Logger
Caused by: java.lang.ClassNotFoundException: org.apache.log4j.Logger
at sun.plugin2.applet.Applet2ClassLoader.findClass(Unknown Source)
at sun.plugin2.applet.Plugin2ClassLoader.loadClass0(Unknown Source)
at sun.plugin2.applet.Plugin2ClassLoader.loadClass(Unknown Source)
at sun.plugin2.applet.Plugin2ClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)

Error with Java WebStart Signed Jars on 1.6.0_19's new Mixed Code

All,
First, we have a valid code signing certificate/keystore from Thawte that works for signing webstart jars as of update 18. For some reason, if you run our webstart application on update 19 JRE, the runtime believes that some of the jars are not signed and some are. Even though we create and sign the jars in the exact same way and after inspecting the jar the JRE believes are not signed they have the necessary signing entries/files in the manifest folder. Not sure why the signing process would work for some of our jars and not for others. There is nothing really all that different.
So, because the JRE believes some of the jars are not signed the new security warning "...contains both signed and unsigned code." pops up ( [Error Description|http://java.com/en/download/help/error_mixedcode.xml] ). If I press yes, then I get the following exception.
java.lang.SecurityException: trusted loader attempted to load sandboxed resource from https://path-to-our.jar
     at com.sun.deploy.security.CPCallbackHandler$ParentCallback.check(Unknown Source)
     at com.sun.deploy.security.CPCallbackHandler$ParentCallback.access$1400(Unknown Source)
     at com.sun.deploy.security.CPCallbackHandler$ChildElement.checkResource(Unknown Source)
     at com.sun.deploy.security.DeployURLClassPath$JarLoader.checkResource(Unknown Source)
     at com.sun.deploy.security.DeployURLClassPath$JarLoader.getResource(Unknown Source)
     at com.sun.deploy.security.DeployURLClassPath.getResource(Unknown Source)
     at java.net.URLClassLoader$1.run(Unknown Source)
     at java.security.AccessController.doPrivileged(Native Method)
     at java.net.URLClassLoader.findClass(Unknown Source)
     at com.sun.jnlp.JNLPClassLoader.findClass(Unknown Source)
     at java.lang.ClassLoader.loadClass(Unknown Source)
     at java.lang.ClassLoader.loadClass(Unknown Source)
     at main.JwsMain.main(JwsMain.java:32)
     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
     at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
     at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
     at java.lang.reflect.Method.invoke(Unknown Source)
     at com.sun.javaws.Launcher.executeApplication(Unknown Source)
     at com.sun.javaws.Launcher.executeMainClass(Unknown Source)
     at com.sun.javaws.Launcher.doLaunchApp(Unknown Source)
     at com.sun.javaws.Launcher.run(Unknown Source)
     at java.lang.Thread.run(Unknown Source)If I press "no" I get the following exception (I get this exception if I try to run our WebStart application with no signed jars as well, no warnings about missing certs, just straight to error)
java.lang.NullPointerException
     at com.sun.deploy.cache.CachedJarFile.findMatchingSignerIndices(Unknown Source)
     at com.sun.deploy.cache.CachedJarFile.entryNames(Unknown Source)
     at com.sun.deploy.cache.DeployCacheJarAccessImpl.entryNames(Unknown Source)
     at com.sun.deploy.security.CPCallbackHandler.assertTrust(Unknown Source)
     at com.sun.deploy.security.CPCallbackHandler.access$700(Unknown Source)
     at com.sun.deploy.security.CPCallbackHandler$ParentCallback.check(Unknown Source)
     at com.sun.deploy.security.CPCallbackHandler$ParentCallback.access$1400(Unknown Source)
     at com.sun.deploy.security.CPCallbackHandler$ChildElement.checkResource(Unknown Source)
     at com.sun.deploy.security.DeployURLClassPath$JarLoader.checkResource(Unknown Source)
     at com.sun.deploy.security.DeployURLClassPath$JarLoader.getResource(Unknown Source)
     at com.sun.deploy.security.DeployURLClassPath.getResource(Unknown Source)
     at java.net.URLClassLoader$1.run(Unknown Source)
     at java.security.AccessController.doPrivileged(Native Method)
     at java.net.URLClassLoader.findClass(Unknown Source)
     at com.sun.jnlp.JNLPClassLoader.findClass(Unknown Source)
     at java.lang.ClassLoader.loadClass(Unknown Source)
     at java.lang.ClassLoader.loadClass(Unknown Source)
     at main.JwsMain.main(JwsMain.java:32)
     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
     at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
     at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
     at java.lang.reflect.Method.invoke(Unknown Source)
     at com.sun.javaws.Launcher.executeApplication(Unknown Source)
     at com.sun.javaws.Launcher.executeMainClass(Unknown Source)
     at com.sun.javaws.Launcher.doLaunchApp(Unknown Source)
     at com.sun.javaws.Launcher.run(Unknown Source)
     at java.lang.Thread.run(Unknown Source)Does anyone know why this would be happening? It only occurs with the new update. We use the same keystore and process for signing all of our jars so it really doesn't make since why some of them work and some of them don't. Also, our JNLP is correct or it wouldn't work in update 18.
Edit: We've tried it on Windows XP SP3 and compiled the code using update 18 and used jarsigner both from 18 and 19 with same results.
Edited by: chenthor on Apr 1, 2010 8:44 AM
Edited by: chenthor on Apr 1, 2010 8:51 AM

Hi All,
So we've been battling this bug for a year or so now, and I've come up with a solution to the webstart bugs
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6967414
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6805618
(see the bugs for more details)
From what we can tell the bug stems from the way that the jar signers information is "cached" by webstart.
When a jar is loaded by webstart, it is represented by a CachedJarFile instance. When loading and using classes the signature for the jar is verified. The signers used is the one that is stored in the CachedJarFile instances. These "signers" are stored as SoftReferences. SoftReferences are like WeakReferences, except that they only become eligible for garbage collection when there is a small amount of available heaps space remaining and that the object is only softly reachable. (That's a pretty crude description, but it will do for now)
So what we found was happening is that when the JVM reached a certain heap size threshold and needed to allocate more heap, that these soft references (and hence the signers information) werebeing garbage collected. if you attempt to load a class after this you get the security error.
So I came up with a hack to work around this. At application startup, iterate through all of the CachedJarFile objects on the classpath and create a hard reference to each of the signers info by putting them in a static list somewhere. From our tests this seems to work. (though with the intermittent nature of the problem, it has been hard to prove conclusively, though we've had some success repro-ing the issue, by reducing the intial heap size and using VisualVM to watch for heap expansions and forcing gc's)
Below is the code for the hack, to run it just call JarSignersHardLinker.go() and it will do some sanity checks (running on webstart on java 1.6 update 19 or higher) before spawning a new thread to create hard refs for all signers info for all jars on the classpath.
import java.io.IOException;
import java.lang.ref.SoftReference;
import java.lang.reflect.Field;
import java.lang.reflect.InvocationTargetException;
import java.lang.reflect.Method;
import java.net.JarURLConnection;
import java.net.URL;
import java.net.URLConnection;
import java.util.ArrayList;
import java.util.Enumeration;
import java.util.LinkedHashSet;
import java.util.List;
import java.util.Set;
import java.util.jar.JarFile;
* A utility class for working around the java webstart jar signing/security bug
* see http://bugs.sun.com/view_bug.do?bug_id=6967414 and http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6805618
* @author Scott Chan
public class JarSignersHardLinker {
    private static final String JRE_1_6_0 = "1.6.0_";
     * the 1.6.0 update where this problem first occurred
    private static final int PROBLEM_JRE_UPDATE = 19;
    public static final List sm_hardRefs = new ArrayList();
    protected static void makeHardSignersRef(JarFile jar) throws java.io.IOException {
        System.out.println("Making hard refs for: " + jar );
        if(jar != null && jar.getClass().getName().equals("com.sun.deploy.cache.CachedJarFile")) {
             //lets attempt to get at the each of the soft links.
             //first neet to call the relevant no-arg method to ensure that the soft ref is populated
             //then we access the private member, resolve the softlink and throw it in a static list.
            callNoArgMethod("getSigners", jar);
            makeHardLink("signersRef", jar);
            callNoArgMethod("getSignerMap", jar);
            makeHardLink("signerMapRef", jar);
//            callNoArgMethod("getCodeSources", jar);
//            makeHardLink("codeSourcesRef", jar);
            callNoArgMethod("getCodeSourceCache", jar);
            makeHardLink("codeSourceCacheRef", jar);
     * if the specified field for the given instance is a Softreference
     * That soft reference is resolved and the returned ref is stored in a static list,
     * making it a hard link that should never be garbage collected
     * @param fieldName
     * @param instance
    private static void makeHardLink(String fieldName, Object instance) {
        System.out.println("attempting hard ref to " + instance.getClass().getName() + "." + fieldName);
        try {
            Field signersRef = instance.getClass().getDeclaredField(fieldName);
            signersRef.setAccessible(true);
            Object o = signersRef.get(instance);
            if(o instanceof SoftReference) {
                SoftReference r = (SoftReference) o;
                Object o2 = r.get();
                sm_hardRefs.add(o2);
            } else {
                System.out.println("noooo!");
        } catch (NoSuchFieldException e) {
            e.printStackTrace();
            return;
        } catch (IllegalAccessException e) {
            e.printStackTrace();
     * Call the given no-arg method on the given instance
     * @param methodName
     * @param instance
    private static void callNoArgMethod(String methodName, Object instance) {
        System.out.println("calling noarg method hard ref to " + instance.getClass().getName() + "." + methodName + "()");
        try {
            Method m = instance.getClass().getDeclaredMethod(methodName);
            m.setAccessible(true);
            m.invoke(instance);
        } catch (SecurityException e1) {
            e1.printStackTrace();
        } catch (NoSuchMethodException e1) {
            e1.printStackTrace();
        } catch (IllegalArgumentException e) {
            e.printStackTrace();
        } catch (IllegalAccessException e) {
            e.printStackTrace();
        } catch (InvocationTargetException e) {
            e.printStackTrace();
     * is the preloader enabled. ie: will the preloader run in the current environment
     * @return
    public static boolean isHardLinkerEnabled() {
         boolean isHardLinkerDisabled = false; //change this to use whatever mechanism you use to enable or disable the preloader
        return !isHardLinkerDisabled && isRunningOnJre1_6_0_19OrHigher() && isRunningOnWebstart();
     * is the application currently running on webstart
     * detect the presence of a JNLPclassloader
     * @return
    public static boolean isRunningOnWebstart() {
        ClassLoader cl = Thread.currentThread().getContextClassLoader();
        while(cl != null) {
            if(cl.getClass().getName().equals("com.sun.jnlp.JNLPClassLoader")) {
                return true;
            cl = cl.getParent();
        return false;
     * Is the JRE 1.6.0_19 or higher?
     * @return
    public static boolean isRunningOnJre1_6_0_19OrHigher() {
        String javaVersion = System.getProperty("java.version");
        if(javaVersion.startsWith(JRE_1_6_0)) {
            //then lets figure out what update we are on
            String updateStr = javaVersion.substring(JRE_1_6_0.length());
            try {
                return Integer.parseInt(updateStr) >= PROBLEM_JRE_UPDATE;
            } catch (NumberFormatException e) {
                //then unable to determine updatedate level
                return false;
        //all other cases
        return false;
      * get all the JarFile objects for all of the jars in the classpath
      * @return
     public static Set<JarFile> getAllJarsFilesInClassPath() {
          Set<JarFile> jars = new LinkedHashSet<JarFile> ();
         for (URL url : getAllJarUrls()) {
             try {
                 jars.add(getJarFile(url));
             } catch(IOException e) {
                  System.out.println("unable to retrieve jar at URL: " + url);
         return jars;
     * Returns set of URLS for the jars in the classpath.
     * URLS will have the protocol of jar eg: jar:http://HOST/PATH/JARNAME.jar!/META-INF/MANIFEST.MF
    static Set<URL> getAllJarUrls() {
        try {
            Set<URL> urls = new LinkedHashSet<URL>();
            Enumeration<URL> mfUrls = Thread.currentThread().getContextClassLoader().getResources("META-INF/MANIFEST.MF");
            while(mfUrls.hasMoreElements()) {
                URL jarUrl = mfUrls.nextElement();
//                System.out.println(jarUrl);
                if(!jarUrl.getProtocol().equals("jar")) continue;
                urls.add(jarUrl);
            return urls;
        } catch(IOException e) {
            throw new RuntimeException(e);
     * get the jarFile object for the given url
     * @param jarUrl
     * @return
     * @throws IOException
    public static JarFile getJarFile(URL jarUrl) throws IOException {
        URLConnection urlConnnection = jarUrl.openConnection();
        if(urlConnnection instanceof JarURLConnection) {
            // Using a JarURLConnection will load the JAR from the cache when using Webstart 1.6
            // In Webstart 1.5, the URL will point to the cached JAR on the local filesystem
            JarURLConnection jcon = (JarURLConnection) urlConnnection;
            return jcon.getJarFile();
        } else {
            throw new AssertionError("Expected JarURLConnection");
     * Spawn a new thread to run through each jar in the classpath and create a hardlink
     * to the jars softly referenced signers infomation.
    public static void go() {
        if(!isHardLinkerEnabled()) {
            return;
        System.out.println("Starting Resource Preloader Hardlinker");
        Thread t = new Thread(new Runnable() {
            public void run() {
                try {
                    Set<JarFile> jars = getAllJarsFilesInClassPath();
                    for (JarFile jar : jars) {
                        makeHardSignersRef(jar);
                } catch (Exception e) {
                    System.out.println("Problem preloading resources");
                    e.printStackTrace();
                } catch (Error e) {
                     System.out.println("Error preloading resources");
                     e.printStackTrace();
        t.start();
}

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

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.

URLClassLoader + dynamically loading signed jar files

I have an applet that does not know all of the jar files it will need to load at startup.
I would like to dynamically load these signed jar files using the URLClassLoader, however it does not recognize these jar files as being signed and I get java.security.AccessControlException: access denied errors.
Any suggestions?
Thanks!

Try this classloader for loading the jars, it should to the trick:
import java.net.URL;
import java.net.URLClassLoader;
import java.net.URLStreamHandlerFactory;
import java.security.AllPermission;
import java.security.CodeSource;
import java.security.PermissionCollection;
import java.security.Permissions;
public class AllPermissionsClassLoader extends URLClassLoader {
    public AllPermissionsClassLoader (URL[] urls) {
        super(urls);
    public AllPermissionsClassLoader (URL[] urls, ClassLoader parent) {
        super(urls, parent);
        System.out.println(parent);
    public AllPermissionsClassLoader (URL[] urls, ClassLoader parent, URLStreamHandlerFactory factory) {
        super(urls, parent, factory);
    protected PermissionCollection getPermissions (CodeSource codesource) {
        Permissions permissions = new Permissions();
        permissions.add(new AllPermission());
        return permissions;
}

Peculiar issue with signed .jars and Linux (Debian unstable, 2.4.20-custom)

BACKGROUND:
I am a developer working on a Java3D application, which is to be deliverable over
the Web. Delivery as an applet seemed a natural choice, and so I spent a considerable amount of effort learning (I won't say "mastering") the process of
creating a self-signed .jar containing java3d-<some_version>.exe. I have in fact
successfully created a fully-fuctional from-scratch JPI/Java3D/myapp install. By
this I mean that Windows machine with only stock IE installed could hit my URL,
get the proper JPI installed, followed by the Java3D runtime I'd chosen, as well
as a third-party DXF loader, and finally (after much clicking of 'Yes', 'Accept',
'OK', etc.) see my app in a browser window.
That was on my old, slow, Windows2000 workstation. Now I have a shiny, new
workstation upon which my employer has graciously allowed me to run Linux. Sadly,
the re-creation of the self-signed .jar files under a new JDK has not gone smoothly.
PROBLEM DESCRIPTION:
When a user attempts to download the self-signed .jar containing the auto-install
executable for the Java3D runtime, the normal security warning prompts are displayed (one for granting to install the extension, one to accept the "suspect" certificate from me alone). The plugin happily downloads the .jar file, and then
a NullPointerException is thrown, with a
stack trace like:
NPE!
at java.util.zip.ZipFile.getInputStream (unknown source)
at java.util.jar.JarFile.getInputStream (unknown source)
<something>doPrivileged<something>
etc.
I apologize for the lack of a full stack trace; I would essentially have to type it in by hand after printing it out on the remote test box; I hope that I've caught the important details above.
After this, the pure-java signed .jar is downloaded and installed, and then the applet "loads" with the predictable ClassNotFoundException for javax.media.j3d.SceneGroup.
Downloading and installing the J3D runtime by hand and then re-visiting the URL results in a fully-functional applet.
I've tried Blackdown Linux JDKs 1.4 and 1.3.1, as well as Sun's JDKs 1.3.1_07 and 1.3.1_05 for the compiling, jar'ing, and jarsigner'ing of these files, all with the same result. At each new JDK, I re-did the HTML conversion so that he appropriate
JPI version was required on the client. I did complete uninstallations of all client JPI instances (including Web Start for 1.4.1_x, as well as cleaning the registry on the client).
When this strategy worked, it was on Sun JDK 1.3.1_05 for Windows runnning on Windows2000, unknown service pack.
DESIRED BEHAVIOR:
I would like my clients to be able to go from stock Windows2K/IE (this being an intranet without any other options) to some JPI version running the J3D extension, with only the need to click 'OK', 'Accept', 'Grant This Session', etc. a bunch of times on the part of the user. I want this to happen without my having to resurrect my decrepit old Compaq Deskpro just to play the role of "build host" for my
Java3D and loader .jar files, if at all possible.
FILES:
Here's what gets merged into the "main" applet's mainfest at creation time:
Manifest-Version: 1.0
Extension-List: java3d DxfLoader
java3d-Extension-Name: javax.media.j3d
java3d-Implementation-Vendor-Id: com.sun
java3d-Implementation-Version: 1.3
java3d-Specification-Title: Java 3D API Specification
java3d-Specification-Version: 1.3
java3d-Specification-Vendor: Sun Microsystems, Inc
java3d-Implementation-URL: http://10.1.1.1/heartcad/lib/java3d.jar
DxfLoader-Extension-Name: eupla.dxfloader
DxfLoader-Implementation-Title: Eupla DXFLoader
DXFLoader-Implementation-URL: http://10.1.1.1/heartcad/lib/DxfLoader.jar
And into the manifest for the J3D .jar:
Manifest-Version: 1.0
Implementation-Version: 1.3
Specification-Version: 1.3
Extension-Installation: "java3d-1_3-windows-i586-directx-rt.exe"
Extension-Name: javax.media.j3d
Implementation-Vendor-Id: com.sun
Implementation-Vendor: Sun Microsystems, Inc
Specification-Vendor: Sun Microsystems, Inc

I have seen that bug, and the problem I'm having seems to be different than it. The extension installer is in the first extension .jar my applet asks for, and it
never works automatically, regardless of how many times the applet is loaded.
The second .jar, which doesn't have to run any installer, always works fine, but the first one will never work (a manual install of the Java3D runtime is required). This seems to not be the behavior described in the bug.
I will continue to search for an answer to this problem, and of course if I should find anything I'll post it here.

Different signed jars need to be passed to the client.

Hi,
My requirement is that I have a list of my jar files that are signed by me and a set of another jar files that are not signed by me, but a third party. I require that these be signed by the third party only. I need to pass this files on to the client.
I cannot put the jars with different signatures under the same jnlp.
I am trying to embed one jnlp (the one that has third party signed jars) inside the main jnlp (the jnlp that will be called from my html). But I am not able to do so,
Please provide any help. Also is there any other approach that can be used.
Thaks in advance.

tcstcs,
One thing you could do is manually go in and delete the 3rd party's signature from the second JAR file, and re-sign that jar with your own signature. I'm not 100% sure this is what you should be doing, but you could give it a shot. Open up the 3rd party JAR in WinZip and delete the meta-inf path. This contains the signature. Now you can re-sign that jar with your own signature, and they will all match up so you can use them in the same JNLP file. Hope this helps,
Mark

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

IE - signed cab vs. signed jar problems

In IE on Windows when I sign an applet that is part of a package in a cab file it works like this; The first time the user hits the applet tag, IE downloads the cab and asks if you trust the applet. When the user clicks yes, it is installed to the downloaded program files system folder. The next time the user hits the applet tag the version in useslibraryversion param is compared to the installed cab and the applet is run without asking the user or attempting to download the cab, even if IE is restarted or the system rebooted.
When I use my signed jar I get two undesired results, when IE is restarted the jar is downloaded again and the user is asked if they trust it again. Any way to make this work like the cab as far as not downloading the second time and not asking the user again?

as far as not downloading the second time How about checking the server settings, (last-modified and expires??)
and not asking the user again?Allways trust?

JNLP: Signed jars but still not trusted

I have an applet that has signed jars that were signed by the same key, the applet shows the correct warnings on startup and works fine (allows access to the local file system, etc), however there still exists the 'yellow triangle warning' on one of two popups frames that the applet produces (but not the other one).
The applet does use native code (packaged in a signed jar and referenced in the JNLP). The jars are all signed by the same certificate from a CA. I originally didn't have the JNLP signed (by placing it in the main jar in JNLP-INF/APPLICATION.JNLP) but this didn't help. Also I didn't have the JNLP codebase set to a real URL (and really cant in production because its a solution we deploy to customers servers - its packaged software not hosted) but even after I tested with a codebase to a test server, it still didnt remove the famed yellow triangle. I have all-permissions set in the JNLP.
So two related questions:
1) Other than having not having signed jars (or not signed correctly), what other reasons cause the 'yellow triangle'?
2) The warning only appears on one of the popup Frames. What could be the possible reasons for that? Are there some privileges that show the icon whether the applet is signed or not?
Note: While changing the client policy setting (showWindowWithoutWarningBanner) works, this cant be a solution.
From the Java Console:
...It goes through all the jars (I only included one for brevity - there are 23 of them). Note it says 'have 1 common certificates'.. which I think indicates everything is signed by the same cert.
Is there any indication in the console logs I can use to determine why it is not trusted? It looks (to me) that everything is OK, until it says 'istrusted=false'.
security: Validating cached jar url=http://10.192.252.26/QMDesktop/native.jar ffile=C:\Documents and Settings\bunkowm\Application Data\Sun\Java\Deployment\cache\6.0\34\1df0b62-2c3ce377 com.sun.deploy.cache.CachedJarFile@d964af
cache: Reading Signers from 995 http://10.192.252.26/QMDesktop/native.jar | C:\Documents and Settings\bunkowm\Application Data\Sun\Java\Deployment\cache\6.0\34\1df0b62-2c3ce377.idx
security: Have 1 common certificates after processing http://10.192.252.26/QMDesktop/native.jar
security: Istrusted: null false
security: Loading certificates from Deployment session certificate store
security: Loaded certificates from Deployment session certificate store
security: Validate the certificate chain using CertPath API
security: Obtain certificate collection in Root CA certificate store
security: Obtain certificate collection in Root CA certificate store
security: Start to check whether root CA is replaced
security: The root CA hasnt been replaced
security: No timestamping info available
security: Found jurisdiction list file
security: No need to checking trusted extension for this certificate
security: The CRL support is disabled
security: The OCSP support is disabled
security: This OCSP End Entity validation is disabled
security: Checking if certificate is in Deployment denied certificate store
security: Checking if certificate is in Deployment permanent certificate store
security: Checking if certificate is in Deployment session certificate store
security: Mark trusted: null

Andrew - of course you were correct about the signed cert - I misspoke when the CA signed applet didn't show a warning. (You were also right that I must have checked 'always accept' the certificate on the server I had the CA signed cert on).
I think you guys are on to something about the privileged actions. It would explain where one popup has the icon and the other doesn't. We have Javascript making calls into the applet and we do use JNI (although I don't think there are any calls back). We do wrap these calls in privileged actions but maybe we missed something. What I've seen before is a security exception is thrown if we don't wrap them - but maybe there are areas where we don't and it doesn't throw an exception or it does and we eat it somehow (and for whatever reason doesn't cause anything noticeable).
Now that I know it could likely be the applet code and not necessarily a build issue with signing the jars, I have another place to look...
I'll check it out and let you know what I find.

Unsigning a signed jar

Similar Messages

Maybe you are looking for