<div dir="ltr"><div>> > For white-box testing of code in user modules, build tools and 
testing frameworks should automatically emit --add-exports, --add-opens,
 and --patch-module for the module under test, as appropriate (for 
example, patching the module under test with the contents of the test 
module allows the testing of package access methods)… APM tools should 
require the application to deploy their agents with the -javaagent or 
-agentlib option. This explicitly grants the agent permission to 
instrument and modify classes. Mocking libraries that employ an agent to
 change classes' behavior should do the same.<br>
<br>> I.e. mocking libraries should load their agent at startup and have no need to load it dynamically.</div><div><br></div><div>Exactly! I'm not advocating against this change, but clearly given the popularity of mocking libraries (and likely other related test libraries) this will surely make this change highly visible once enabled.<br></div><div><br></div><div>> > 2. I was wondering however about the relation of this JEP with the following property :<br>
> > <br>> 
> ```<br>> 
> -Djdk.attach.allowAttachSelf=true<br>> 
> ```<br>> 
> <br>
> > This affects the attachment not agent loading, however I believe 
this JEP should at least mention this property as well as it seems 
directly tied to one of the mentioned problems about detecting who loads
 the agent.<br>
> <br>
> <br>> 
The JEP already does. It says:<br>
> <br>> 
> To maintain integrity, JDK 9 and later releases prevent code from connecting to the current JVM by default. <br>
> <br>> 
Perhaps I’ll mention the property by name.<font color="#888888"><br></font></div><div><br></div><div>Indeed thank you, I missed that.<br></div><div><br></div><div><br></div><div><br></div><div>Apologies if I missed that in the previous exchanges. Auditability was mentioned, but if functionality has to be restored agent loading will be enabled via `<code>-XX:+EnableDynamicAgentLoading</code>`, but then the code base could load any agent. It might still be possible to audit via `<code>-Djdk.instrument.traceUsage</code>` but you're still exposed if some functionality is needed. Is it considered to restrain dynamic agent loading to specific libraries, e.g. via an _allow-list_, like the `--add-opens` options or the only option forward to restrain is declaring them via `--javaagent` / `--agentlib`.<br></div><div><br></div><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div>-- Brice</div></div></div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, May 17, 2023 at 1:21 PM Ron Pressler <<a href="mailto:ron.pressler@oracle.com">ron.pressler@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"><br>
<br>
> On 15 May 2023, at 23:24, Brice Dutheil <<a href="mailto:brice.dutheil@gmail.com" target="_blank">brice.dutheil@gmail.com</a>> wrote:<br>
> <br>
> Hi,<br>
> <br>
> I do share some concerns of the community, however many have voiced it with a better english that I could ever do. But I'd like to mention two things:<br>
> <br>
> 1. There is another usage that I think will be visibly impacted : in tests it's often necessary to alter part of the system to stress some parts. In doing so some libraries offer these capabilities, often by relying on an ad hoc agent ; I hope this falls in the useful application of this mechanism. I understand the goal is mostly about applications running in production, yet it's likely the effect will be visible well before code reaches production. <br>
<br>
The informational JEP linked at the beginning of this one (<a href="https://openjdk.org/jeps/8305968" rel="noreferrer" target="_blank">https://openjdk.org/jeps/8305968</a>) refers to this use-case when it comes to both agents and other encapsulation-breaking mechanisms:<br>
<br>
> For white-box testing of code in user modules, build tools and testing frameworks should automatically emit --add-exports, --add-opens, and --patch-module for the module under test, as appropriate (for example, patching the module under test with the contents of the test module allows the testing of package access methods)… APM tools should require the application to deploy their agents with the -javaagent or -agentlib option. This explicitly grants the agent permission to instrument and modify classes. Mocking libraries that employ an agent to change classes' behavior should do the same.<br>
<br>
I.e. mocking libraries should load their agent at startup and have no need to load it dynamically.<br>
<br>
> <br>
> 2. I was wondering however about the relation of this JEP with the following property :<br>
> <br>
> ```<br>
> -Djdk.attach.allowAttachSelf=true<br>
> ```<br>
> <br>
> This affects the attachment not agent loading, however I believe this JEP should at least mention this property as well as it seems directly tied to one of the mentioned problems about detecting who loads the agent.<br>
<br>
<br>
The JEP already does. It says:<br>
<br>
> To maintain integrity, JDK 9 and later releases prevent code from connecting to the current JVM by default. <br>
<br>
Perhaps I’ll mention the property by name.<br>
<br>
— Ron</blockquote></div>