[External] : Re: New candidate JEP: 471: Deprecate the Memory-Access Methods in sun.misc.Unsafe for Removal

[David Lloyd]

On Thu, Jun 13, 2024 at 9:01 AM Alan Bateman <Alan.Bateman at oracle.com>
wrote:

> On 13/06/2024 14:22, David Lloyd wrote:
>
> :
>
> I've updated with a few commits today which solve (I think) the access
> control issue, moves constant descriptors to constants in a holder class,
> moves the bootstrap to `ConstantBootstraps`, just says "no" to caching, and
> cleans up a few other minor issues. I guess I'll go ahead and update
> JDK-8333796 to reference this new strategy and start preparing to put up a
> PR, unless someone raises an objection to the final approach taken here.
>
> Just to set expectations on a possible PR, this is not a change that can
> be rushed in. It's controversial to extend this backdoor and may make it
> hard for this backdoor to be removed in the future.  I think we will also
> need to get the security/vulnerability folks to go over this.
>

Of course. I've tried to design the change with due consideration to
security, but I recognize that this is a tricky area and there may be
tricky aspects to it as a consequence.

It might be helpful to think of it not as a backdoor, but as a somewhat
more obscure front door. :-) When a user declares a class to be
`Serializable`, they are opting in to aspects of the serialization
specification that imply that their private fields are accessible beyond
the scope of the JLS. These accesses are not fully open-ended: they're
governed by the serialization spec which has some specific allowances and
restrictions. So, my intention is to allow no more than what the
specification allows.

That said, it might be desirable to extend a few extra protections beyond
what is already specified and what is being proposed. I'm certainly open to
all of that kind of discussion, and discussion of other alternative
solutions.

The pull request number is 19702 [1]. It is a draft for now to enable
further, more specific discussion.

[1] https://github.com/openjdk/jdk/pull/19702

-- 
- DML • he/him
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240613/0f0ae02c/attachment.htm>