<div dir="ltr">Indeed, ReflectionFactory.
newConstructorForSerialization can be used to access otherwise-private constructors. Before JDK-8315810, it could even allocate one class and call the constructor of another class.<div><br></div><div>I strongly support your proposal to restrict ReflectionFactory.</div><div><br></div><div>Regards, Chen</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, May 15, 2024 at 6:23 PM David Lloyd <<a href="mailto:david.lloyd@redhat.com">david.lloyd@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, May 14, 2024 at 10:01 AM David Lloyd <<a href="mailto:david.lloyd@redhat.com" target="_blank">david.lloyd@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div style="font-family:arial,helvetica,sans-serif">(Moving to core-libs-dev)</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, May 14, 2024 at 9:40 AM Alan Bateman <<a href="mailto:Alan.Bateman@oracle.com" target="_blank">Alan.Bateman@oracle.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><u></u>
<div>
On 14/05/2024 14:42, David Lloyd wrote:<br>
<blockquote type="cite">
<div dir="ltr"><div class="gmail_quote"><div><div style="font-family:arial,helvetica,sans-serif">ReflectionFactory
allows access to serialization facilities without any
access checking (other than the defunct SecurityManager
checks). Perhaps this class could gain some more methods,
like this:</div>
<div style="font-family:arial,helvetica,sans-serif"><br>
</div>
<div style="font-family:arial,helvetica,sans-serif">*
`newGetterForSerialization(Field field)` - includes
ability to access `objectStreamFields` and
`serialVersionUID`, or these could be separate methods</div>
<div style="font-family:arial,helvetica,sans-serif">*
`newSetterForSerialziation(Field field)`</div>
</div>
<div><br>
</div>
<div>
<div style="font-family:arial,helvetica,sans-serif">Does this
seem workable?</div>
<br>
</div>
</div>
</div>
</blockquote>
The intention with ReflectionFactory is that serialization libraries
go through the readObject/writeObject and other magic methods, to
avoid field access.<br>
<br>
Probably best to being this to core-libs-dev for further discussion.<br></div></blockquote><div><br></div><div><div style="font-family:arial,helvetica,sans-serif">This doesn't match my recollection. The `readObject` and `writeObject` methods are optional private methods which serializable classes *may* provide when they want a bespoke serialization strategy (and the other methods that are accessed via this special class are similar in this regard). They are not in any way magical in that they do not provide the means to perform this part of the serialization process, and thus they are not a substitute for field access in serialization. According to JDK-8164908, these methods were added because at the time, Unsafe was still state of the art for custom serialization and IIOP to access fields (with libraries using Field actively moving to Unsafe instead). However Unsafe did not and does not provide access to methods, so in order to avoid the aforementioned `add-opens` explosion, these methods were added as a compromise. Now that Unsafe is being deprecated, it is my opinion that this does need to be revisited because at the time, Unsafe was the recommended approach.</div><br></div><div><div style="font-family:arial,helvetica,sans-serif">[1] <a href="https://bugs.openjdk.org/browse/JDK-8164908" target="_blank">https://bugs.openjdk.org/browse/JDK-8164908</a></div></div></div></div></blockquote></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">It seems to me that it might be a good idea (as part of 8305968 (Integrity by default)) to put the `ReflectionFactory` API behind a restricted method call somehow, even considered separately from the changes suggested above. Maybe in conjunction with a non-standard switch that works similarly to `--enable-native-access`, e.g. `--enable-serialization=org.serial.framework`? That would also somewhat mitigate the security risk of adding the aforementioned methods or something like them to this class.</div><div><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">Should I open a bug for either (or both) of these suggestions? Or perhaps there is a better way to proceed?</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature"><div dir="ltr">- DML • he/him<br></div></div></div>
</blockquote></div>