Potential for sensitive runtime information to land in AOT archives

[Dan Heidinga]

Great question!

> if we need to think ahead to having to treat AOT archives more carefully than the runtime
> classpath as features that cache compiled code begin to land?

Even without compiled code,  the cache needs to be treated with the same care as jars on the classpath and the JDK executables / shared libraries.  This is nothing new, just standard care for deployment artifacts.

> Our job is made so much easier if we only need to be concerned about the provenance of
> an AOT archive, but when a colleague asked me about runtime decrypted secrets finding
> their way into static fields for example, I realised I didn't have an complete understanding
> of how far the caching of compiled code might go.

Cached AOT code doesn’t constant fold statics today so it can’t accidentally encode them into compiled code.  A very limited set of classes are initialized in the assembly phase - which is a requirement to have persisted objects - which further limits the possibility of secrets being accidentally recorded in the cache.

During my JVMLS talk this year [0], I touched on the challenges of persisting objects and dealing with identity.  Security is another aspect that makes heap snapshots difficult to deal with.

—Dan

[0] https://inside.java/2025/10/21/jvmls-assembling-project-leyden/#:~:text=Dan%20Heidinga%20on%20October%2021,Shopping



Confidential – Oracle Internal

From: leyden-dev <leyden-dev-retn at openjdk.org> on behalf of Danny Thomas <dannyt at netflix.com>
Date: Sunday, November 2, 2025 at 11:10 PM
To: leyden-dev at openjdk.org <leyden-dev at openjdk.org>
Subject: Potential for sensitive runtime information to land in AOT archives

Hi folks,

We're thinking ahead to caching compiled code and other optimisations that might include runtime information that wouldn't otherwise be available if you had access to the application classpath. I caught Dan's JavaOne talk recently, and it sounds like the assembly phase is intended to be hermetic and avoid exactly this kind of complication, but wanted to ask explicitly if we need to think ahead to having to treat AOT archives more carefully than the runtime classpath as features that cache compiled code begin to land?

Our job is made so much easier if we only need to be concerned about the provenance of an AOT archive, but when a colleague asked me about runtime decrypted secrets finding their way into static fields for example, I realised I didn't have an complete understanding of how far the caching of compiled code might go.

Cheers,
Danny
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/leyden-dev/attachments/20251103/fef8c7a9/attachment.htm>