note above requirements make no mention of ESL, or of which security prompts will be affected - note that at default security level, unsigned, self-signed, and expired cert signed apps may be blocked, so it may be necessary to put app on ESL, or reduce security level to medium , to take advantage of this.
We propose this effect:
1.) unsigned dialogs (including normal, and local apps), but not unsigned and below base (expired dialog).
2.) self-signed or signed with expired cert dialog for sandbox-permissions
3.) self-signed or signed with expired cert dialog for all-permissions
4.?) is there any reason to also handle CA-signed not-expired dialog ? (already has always remember checkbox)
Mechanism will be to record the remember till date in the LAP
Reduce Frequency of Security Dialogs when application or applet is run multiple times.
Engineering wiki: http://wiki.se.oracle.com/display/JPGC/Dialog+Frequency
- feature is completed when:
Reduction in Dialog frequency is achieved as expressed in the requirement on:
- Pass rate for nightly, promotion testing:
NA - this metric should not be part of a bug description
- Performance implications:
none - This feature should not have any measurable performance impact.
- Internal EA sign-off
NA - signoff from SQE and Dev should not be part of a bug description
see implementation wiki at: http://wiki.se.oracle.com/display/JPGC/Dialog+Frequency
TBD (by SQE) unless specific testing requirements are anticipated developer, testing requirements should not be part of a bug description
Risks and Assumptions
no known extraordinary risks or assumptions
- Compatibility: N/A
- Security: (security team rep should review changes)
- Performance/scalability: N/A
- User experience: N/A
- I18n/L10n: N/A
- Portability: N/A
- Packaging/installation: N/A
- Documentation: need change in Release Note / deployment docs
- TCK: N/A
- Internationalization: REPEAT FIELD
- Localization: REPEAT FIELD
- Legal: N/A
latest webrev at: http://oklahoma.us.oracle.com/www/webrevs/aherrick/1.7.0_55/8029649/deploy/webrev/
includes fix for html applet lap problem caused by the fix for https://bugs.openjdk.java.net/browse/JDK-8021391 (in 7u55) or
https://bugs.openjdk.java.net/browse/JDK-8028517 (in 8u5)
That fix breaks lap files for html applets.
In conjunction with other changes in LaunchDesc.getCanonicalHome() (made by various other security fixes) it may also break lap files for jnlp applets that have no href in the jnlp file.
The reason is, the basis of Cache.getNewLapFileName() requires that a the (url, version) passed in identifies a cached object (or at least refers to an existing resource on the net that can be downloaded).
CacheEntry ce = getCacheEntry(url, version, dir, ResourceProvider.DOWNLOAD_NORMAL);
if (ce == null)
causes null to be returned whenever dummy url is used to identify the lap file location.
ai.setLapURL(new URL(getCodeBase().toString() + "/" + ai.getTitle()));
which is a dummy URL used not to refer to any real resource, but only for referring to the lap file.
(this causes the problem for html applets)
It can also cause the same problem for jnlp applets, since applet jnlp file is cached (in plugin) based on it's real location on the web, but LaunchDesc.java uses getCanonicalHome() which returns (for jnlp file w/o href) the url to the main jar + "jnlp", also a dummy.
In webstart, this is what the jnlp file is actually cached as, but in plugin (where we always know the real location) the jnlp file is cached based on it's real location.
This is not a problem yet in jdk8, but should be seen in 8u5 since the above change is resolved in 8u5.
It is required that persistent lap file data exists in all cases, so I propose the following as part of my fix to 8029649:
1.) change to LaunchDesc.getCanonicalHome(), such that if getLocation() is null, but getSourceURL() is not null, the return getSourceURL() instead of constructing the canonical URL.
2.) temporarily change Cache.getNewCacheFileName(), instead of returning null when there is no corresponding cache entry, to return getCacheFileName().
3.) file a follow-on bug to fix the fix to JDK-8021391 , (filed bug #JDK-8031130 ) so that the new complex file name for the LAP can be computed without requiring an index file for the cached object ever actually exists.