<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 Thu, Jun 13, 2024 at 9:01 AM Alan Bateman <<a href="mailto:Alan.Bateman@oracle.com">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 13/06/2024 14:22, David Lloyd wrote:<br>
    <blockquote type="cite">
      
      <div dir="ltr">:
        <div class="gmail_quote">
          <div><br>
          </div>
          <div>
            <div style="font-family:arial,helvetica,sans-serif">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.</div>
          </div>
          <br>
        </div>
      </div>
    </blockquote>
    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.<br></div></blockquote><div><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">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.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">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.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">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.</div></div><div><br></div><div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">The pull request number is 19702 [1]. It is a draft for now to enable further, more specific discussion.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">[1] <a href="https://github.com/openjdk/jdk/pull/19702">https://github.com/openjdk/jdk/pull/19702</a></div><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>