Invalid ProtectionDomain

ZeroTurnaround Homepage Forums JRebel Support Invalid ProtectionDomain

This topic contains 3 replies, has 2 voices, and was last updated by  ristoparnapuu 1 month ago.

Viewing 4 posts - 1 through 4 (of 4 total)
  • Author
    Posts
  • #66759

    chrempl
    Participant

    After upgrading from jrebel 7.1.0 to 7.1.3 we’ve detected that loaded classes have an invalid protection domain:

    jrebel 7.1.0:

    ProtectionDomain (file:/C:/<pathToProject>/../<pathToJar>/bcprov-jdk15on-1.52.jar

    (identical if the web application is running without jrebel)

    jrebel 7.1.3:

    ProtectionDomain (file:/C:/<pathToProject>/file:/C:/<pathToProject>/../<pathToJar>/bcprov-jdk15on-1.52.jar!/org/bouncycastle/jcajce/provider/asymmetric/rsa <no signer certificates>)

    • This topic was modified 1 month, 1 week ago by  chrempl.
    #66762

    chrempl
    Participant

    Some more details:

    * the CodeSource#location in ProtectionDomain of loaded Classes seems to be invalid with jrebel 7.1.3
    * we are using Tomcat 7.0.82, (also reproducible with Tomcat 7.0.79)

    The result is e.g. this java.lang.SecurityException:

    
    Caused by: java.lang.SecurityException: Cannot verify jar:file:/C:/<pathToProject>/file:/C:/<pathToProject>/../<pathToJar>!/org/bouncycastle/jce/provider!/
    	at javax.crypto.JarVerifier.verifySingleJar(JarVerifier.java:446)
    	at javax.crypto.JarVerifier.verifyJars(JarVerifier.java:361)
    	at javax.crypto.JarVerifier.verify(JarVerifier.java:289)
    	at javax.crypto.JceSecurity.verifyProviderJar(JceSecurity.java:159)
    	at javax.crypto.JceSecurity.getVerificationResult(JceSecurity.java:185)
    	at javax.crypto.JceSecurity.getInstance(JceSecurity.java:97)
    	... 142 common frames omitted
    Caused by: java.security.PrivilegedActionException: null
    	at java.security.AccessController.doPrivileged(Native Method)
    	at javax.crypto.JarVerifier.verifySingleJar(JarVerifier.java:424)
    	... 147 common frames omitted
    Caused by: java.io.FileNotFoundException: file:/C:/<pathToProject>/file:/C:/<pathToProject>/../<pathToJar> (Die Syntax für den Dateinamen, Verzeichnisnamen oder die Datenträgerbezeichnung ist falsch)
    	at java.util.zip.ZipFile.open(Native Method)
    	at java.util.zip.ZipFile.<init>(ZipFile.java:225)
    	at java.util.zip.ZipFile.<init>(ZipFile.java:155)
    	at java.util.jar.JarFile.<init>(JarFile.java:166)
    	at java.util.jar.JarFile.<init>(JarFile.java:103)
    	at sun.net.www.protocol.jar.URLJarFile.<init>(URLJarFile.java:93)
    	at sun.net.www.protocol.jar.URLJarFile.getJarFile(URLJarFile.java:69)
    	at sun.net.www.protocol.jar.JarFileFactory.get(JarFileFactory.java:109)
    	at sun.net.www.protocol.jar.JarURLConnection.connect(JarURLConnection.java:122)
    	at sun.net.www.protocol.jar.JarURLConnection.getJarFile(JarURLConnection.java:89)
    	at javax.crypto.JarVerifier$2.run(JarVerifier.java:438)
    	at javax.crypto.JarVerifier$2.run(JarVerifier.java:425)
    	... 149 common frames omitted
    

    The error is reproducible with jrebel 7.1.1, 7.1.2 and 7.1.3.

    Unless this isn’t fixed, we can’t upgrade to 7.1.1+.

    #66764

    chrempl
    Participant

    Further investigations showed that the problem occurs only if the affected jar is in Tomcats “Virtual Classpath” and hence its classes are loaded with the VirtualWebappLoader.

    If the jar is located in the /WEB-INF/lib-Directory, the CodeSource is set correctly.

    We have isolated the problem in an small application, which can be provided for tests.

    #66788

    ristoparnapuu
    Rebel Staff

    To whoever may come across this issue again,

    The previous should now be fixed in our nightly build available for download from https://zeroturnaround.com/software/jrebel/download/nightly-build/. The fix will also be included in our next release (JRebel 7.1.4).

    Best regards,
    Risto

Viewing 4 posts - 1 through 4 (of 4 total)

You must be logged in to reply to this topic.