United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-6939778 Mixed code warning for class.getResource("directory/") in 1.6.0_19
JDK-6939778 : Mixed code warning for class.getResource("directory/") in 1.6.0_19

Details
Type:
Bug
Submit Date:
2010-03-31
Status:
Closed
Updated Date:
2011-02-16
Project Name:
JDK
Resolved Date:
2010-04-14
Component:
security-libs
OS:
solaris_8,windows_xp
Sub-Component:
java.security
CPU:
x86
Priority:
P3
Resolution:
Fixed
Affected Versions:
6u10,6u19
Fixed Versions:
6u20 (b01)

Related Reports

Sub Tasks

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
EVALUATION

Not a bug because this is an invalid use of
getResource() but we should "fix" our behavior
to be more backwards compatible.
                                     
2010-04-08
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.
                                     
2010-08-30



Hardware and Software, Engineered to Work Together