Bug#950213: openjdk-17-jre-headless: AccessControlException in java.util.Properties when running with a security manager

[Emmanuel Bourg]

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