JDK-6826789 : SecureClassLoader should not use CodeSource URLs as HashMap keys
  • Type: Enhancement
  • Component: security-libs
  • Sub-Component: java.security
  • Affected Version: 6,7
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2009-04-06
  • Updated: 2016-08-26
  • Resolved: 2015-06-12
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 Availabitlity Release.

To download the current JDK release, click here.
JDK 9
9 b70Fixed
Related Reports
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Description
SecureClassLoader.getProtectionDomain uses HashMap<CodeSource> to cache protection domains to speed up their construction. CodeSource.hashCode() uses URL.hashcode() and CodeSource.equals() uses URL.equals(). 
However, these URL may cause DNS lookups which are expensive if everything is cached. 

We should avoid them, e.g. by using URI.

Comments
It turns out that fixing this is straightforward by converting the URL to a String (using sun.net.util.URLUtil.urlNoFragString) and using that as a key to the HashMap. It does mean that URLs that are equivalent after name resolution may be placed in separate ProtectionDomains, but it is not a compatibility or security issue because the URLs will later be canonicalized (and resolved through the name service) by the Policy provider implementation before granting permissions.
2015-03-23

Changing to an enhancement, since this is a performance enhancement.
2013-09-30

EVALUATION This is difficult to fix without breaking compatibility. For example, the following two CodeSource URLs could be equal after name resolution: http://xxx.yyy.foo.com http://xxx.yyy Changing this could break a bunch of stuff as these CodeSources would now be placed into separate ProtectionDomains. It's possible we may be able to look at this from a different angle, and only do name resolution if a CodeSource is granted something other than AllPermission or the default sandbox permissions, or whenever policy processing is enabled in Plugin (usePolicy=true). But I need to think about it some more.
2009-09-11