On Fri, 9 Sep 2022 14:13:09 GMT, Alan Bateman <al...@openjdk.org> wrote:
>> ### Summary of the change >> >> The LDAP Naming Service Provider implementation's default settings are >> changed to disallow deserialization and reconstruction of Java objects from >> different LDAP attributes (RFC 2713). Currently, only the deserialization is >> controlled by the `com.sun.jndi.ldap.object.trustSerialData` system >> property, and it is allowed by default. >> The change proposed here switches the default value of the` >> com.sun.jndi.ldap.object.trustSerialData `system property to `"false"`, and >> also extends its scope to cover the reconstruction of RMI remote objects >> from the `javaRemoteLocation` LDAP attribute. >> >> CSR for this change can be viewed >> [here](https://bugs.openjdk.org/browse/JDK-8290369). >> >> ### List of code changes >> - Switch the default value of the 'com.sun.jndi.ldap.object.trustSerialData' >> system property to "false". >> >> - Extend the scope of the property to also cover the reconstruction of RMI >> remote objects from the deprecated 'javaRemoteLocation' LDAP attribute. >> >> - Document the support for `javaRemoteLocation` and the >> `javaReferenceAddress` LDAP attributes in `java.naming`'s module-info. >> >> ### Test changes >> - New `test/jdk/com/sun/jndi/ldap/objects/RemoteLocationAttributeTest.java` >> test has been added to test that `com.sun.jndi.ldap.object.trustSerialData` >> system property can be used to control reconstruction of RMI objects from >> the `javaRemoteLocation` LDAP attribute. >> >> - `test/jdk/javax/naming/module/RunBasic.java` was modified to pass >> `com.sun.jndi.ldap.object.trustSerialData=true` to the sub-tests that rely >> on reconstruction/deserialization from LDAP attributes. >> >> - During the update for `test/jdk/javax/naming/module/RunBasic.java`, it was >> spotted that sub-tests apps launched in separate processes were returning >> the '0' exit value irrelevant to their execution status. All these sub-tests >> were modified to throw an exception when failure is observed. It helps to >> ensure that the exit value of launched process is not '0' for failed >> sub-tests. >> >> ### Testing >> >> `tier1`-`tier3` and JNDI regression/JCK tests not showing any failures >> related to this change. >> No failures observed for the modified regression tests. > > src/java.naming/share/classes/module-info.java line 82: > >> 80: * <li>{@systemProperty com.sun.jndi.ldap.object.trustSerialData}: >> 81: * <br>The value of this system property is the string >> representation of a boolean value >> 82: * which allows to control the deserialization of java objects >> from the {@code javaSerializedData} LDAP > > "allows to control"? Maybe this should be "that controls". > > Is there anywhere that "javaRemoveLocation", and "javaReferenceAddress" could > link to? `javaReferenceAddress` is defined in RFC 2713, section 3.6 - but `javaRemoteLocation` is not - it's marked deprecated in our code base so maybe it came from some early draft of this representation. ------------- PR: https://git.openjdk.org/jdk/pull/10228
