Control: reassign -1 openjdk-17-jre-headless Control: retitle -1 openjdk-17-jre-headless: AccessControlException in java.util.Properties when running with a security manager
The report is empty and I was tempted to close it as invalid. But the underlying issue is worth considering: java.util.Properties is patched in Debian to remove the timestamp in the header of the properties files to make them reproducible. The timestamp is removed when the SOURCE_DATE_EPOCH environment variable is defined. This look trivial but this creates a subtle incompatibility compared to the upstream JDK. Reading SOURCE_DATE_EPOCH when running with a security manager triggers an AccessControlException unless a rule is added in the policy file: java.security.AccessControlException: access denied ("java.lang.RuntimePermission" "getenv.SOURCE_DATE_EPOCH") at java.base/java.security.AccessControlContext.checkPermission(AccessControlContext.java:472) at java.base/java.security.AccessController.checkPermission(AccessController.java:897) at java.base/java.lang.SecurityManager.checkPermission(SecurityManager.java:322) at java.base/java.lang.System.getenv(System.java:996) at java.base/java.util.Properties.getFormattedTimestamp(Properties.java:1587) at java.base/java.util.Properties.store0(Properties.java:929) at java.base/java.util.Properties.store(Properties.java:918) So basically, any external Java application launched with the Debian JRE and using a security manager will break when attempting to write a properties files. This is bad and should be reverted or done differently. We could try adding a SOURCE_DATE_EPOCH property in jdk.internal.util.StaticProperty since these properties are initialized before the security manager is set. Or we could drop the patch and rely on strip-nondeterminism to remove the timestamp. Emmanuel Bourg