8

We saw this exception from 3 different customer installs today (4/14/2015) in the span of a 30 minutes. 

java.lang.SecurityException: Can not verify security pack jar
com.sun.deploy.util.SecurityBaseline.verifyJar(Unknown Source)
com.sun.deploy.util.SecurityBaseline.access$200(Unknown Source)
com.sun.deploy.util.SecurityBaseline$1.run(Unknown Source)
java.lang.Thread.run(Unknown Source)

I don't think it's causing a problem as it's in a background thread started from deploy.jar (SecurityBaseline.java) trying to verify something?? The odd thing is that it happened at multiple customers at the same time. The only reason I know about it is that we install an default uncaught exception handler to log and report any unhandled exceptions in the app.

Has anyone else seen this or know what it means? I tried reading a decompiled version of the source, and it wasn't clear exactly where the failure would be. I got the line of the exception, but it could come from 2 different paths, both of which were very non trivial to an outsider.

I'm inclined to ignore it for now, but I'm worried it is foreshadowing a larger problem.

Chris Holt
  • 655
  • 1
  • 6
  • 19
  • Important details I forgot to include: Windows OS (Win7), and it seems to only come from installs where some of the machines are Java 8. I suspect it's from Java 8 clients, but can't be 100% sure. – Chris Holt Apr 14 '15 at 21:28
  • 1
    I can reproduce this under 1.8.0_25. I found that the securitypack.jar under the deployment/security directory is not signed. More google got me to this: http://bugs.java.com/view_bug.do?bug_id=8040668 which talks about automating the creation of that jar. A check of the same jar under a fresh 1.8.0_40 shows it to be signed by Oracle. I think someone forgot to sign it when they built 1.8.0_25.... (and maybe earlier versions?) – Chris Holt Apr 14 '15 at 21:58
  • Which concrete securitypack.jar on the filesystem do you mean? I think it's downloaded from https://javadl-esd-secure.oracle.com/update/securitypack.jar to ${user.home}\AppData\LocalLow\Sun\Java\Deployment\security on Windows. This file is not signed anymore, but it was before... – Holger Apr 16 '15 at 08:42
  • I observe the same error on Windows 7 with Java 8u31.It's reproducible, when we start our webstart app and the modification timestamp of the file ${user.home}\AppData\LocalLow\Sun\Java\Deployment\security\update.securitypack.timestamp is older than 24 hours. – Holger Apr 16 '15 at 08:47
  • Yes I was referring to the one in ${user.home}\AppData\LocalLow\Sun\Java\Deployment\security on Windows. It only seems to happen once per 24 hours per client machine, which is consistent with the code in deploy.jar. – Chris Holt Apr 16 '15 at 14:55

2 Answers2

2

I'm 100% sure that it's caused by https://bugs.openjdk.java.net/browse/JDK-8077736

If anyone has an account there please make a comment or if you know/can contact maintainers mentioned in the ticket any other way please do.

Andrej Urvantsev
  • 466
  • 4
  • 15
  • I filed a report at http://bugreport.java.com/ referenceing that ticket. I can't find any way to post a comment or bug to the OpenJDK site. So much the "Open" part :). – Chris Holt Apr 16 '15 at 15:13
  • @SaeidNourian, that one looks like mine. – Andrej Urvantsev Apr 16 '15 at 16:51
  • Looks like they already fixed JDK-8077736 bug, so your reported bug seem to be not caused by that. Instead they marked your bug report as a duplicate of another bug (JDK-8077905) but somehow I can't access that bug, guess it's a privately held bug. – Saeid Nourian Apr 16 '15 at 17:58
  • @SaeidNourian, in this "bug" they published updated securitypack.jar. Exactly after that SecurityException started to appear. – Andrej Urvantsev Apr 16 '15 at 19:00
  • ah I didn't realize the exception disappeared after this release. In that case, good job on correctly identifying the cause. – Saeid Nourian Apr 16 '15 at 19:09
1

This bug has been fixed. javadl-esd-secure.oracle.com/update/securitypack.jar has been updated.

To resolve this issue on systems that are experiencing this problem, simply reinstall 8u45. As the securitypack.jar has been updated, any new installations will not see this issue.

RogerLewis
  • 71
  • 1