JDK-6939778 : Mixed code warning for class.getResource("directory/") in 1.6.0_19
  • Type: Bug
  • Component: security-libs
  • Sub-Component: java.security
  • Affected Version: 6u10,6u19
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: solaris_8,windows_xp
  • CPU: x86
  • Submitted: 2010-03-31
  • Updated: 2011-02-16
  • Resolved: 2010-04-14
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 6
6u20 b01Fixed
Description
FULL PRODUCT VERSION :
java version "1.6.0_19"
Java(TM) SE Runtime Environment (build 1.6.0_19-b04)
Java HotSpot(TM) Client VM (build 16.2-b04, mixed mode, sharing)

ADDITIONAL OS VERSION INFORMATION :
Microsoft Windows XP Service Pack 3

A DESCRIPTION OF THE PROBLEM :
Querying the resource URL of a directory, e. g. Example.class.getResource("/example/"), triggers the mixed code warning introduced in JRE 1.6.0_19 even if all classes and resources in the Jar are signed.

We use this to get a list of all files in the directory as in
((JarURLConnection) getResource("/example/").openConnection()).getJarFile() and then iterating over the entries of the Jar file.

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
1. Create a Jar file which contains a directory ("example") and a class which does a getResource for the directory (Example.class.getResource("/example/")).
2. Sign the Jar file with jarsigner
3. Write a JNLP file which launches the Jar
4. Launch with Java Web Start


EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
No mixed code warning shown, getResource returns a JarURLConnection
ACTUAL -
Mixed code warning, if user clicks "Yes", getResource returns null.

REPRODUCIBILITY :
This bug can be reproduced always.

CUSTOMER SUBMITTED WORKAROUND :
Instead of getResource("/directory/"), access a file which you know exists in the directory, e. g. getResource("/directory/KNOWN_FILE")

Comments
SUGGESTED FIX Here are some comments from Dennis, which should help convince the customer of the trade offs and risks if such a thing is implemented: 1. If we create a file trusted.resources under C:\Program Files\Java\jre6\lib\security:trusted.file.extensions=.gif,.jpg,.png, this file located inside JRE install directory, and it is not easy for Administrator to change it for each individual user. 2. Controling the file by extension name is risky, attacker can just rename their file to those extension to bypass our mixed code restricition. As Jeff already mentioned, this is not a bug. The customer can file an RFE, however, considering the risks involved, no assurance can be made regarding implementation of such a feature.
30-08-2010

EVALUATION Not a bug because this is an invalid use of getResource() but we should "fix" our behavior to be more backwards compatible.
08-04-2010