<div dir="ltr"><div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">>    Agents are used by profiling tools to instrument Java applications,<br>
>    but agents can also be misused to undermine the integrity of the<br>
>    Java Platform.<br>
<br>
I don't think it is fair to assume that profilers are the only "valid"<br>
use case for agents and imply that all other use cases are a mis-use<br>
of the API.<br></blockquote><div><br></div><div>First, I don't read the JEP as implying that all non-profiler use cases are misuse.</div><div><br></div><div>Having said that, I do think that agents can in fact strengthen the integrity of the platform. Case in point is that when the Java serialization vulnerabilities hit around 2015, I could very quickly ( a few hours) whip together the "NotSoSerial" serialization firewall agent [1] to efficiently prevent exploits. I later got word that a large CMS vendor deployed it to their platform which included some of the world's busiest websites. I don't know if they used the attach mechanism to plug their serialization holes, but they surely could at the time.</div><div><br></div><div>With microservices gaining popularity over the years, restarts are probably more common and automated now, including configuration of JVM options. So attaching to long-running instances to prevent restarts is probably becoming less useful over time.</div><div><br></div><div>The agent misuse that the JEP is referring to here is perhaps mostly concerning libraries using the attach mechanism to get access they otherwise would not have in a running JVM? Perhaps the JEP could be updated to be more clear on this?</div><div><br></div><div>Cheers,</div><div>Eirik.</div><div><br></div><div>[1] <a href="https://github.com/kantega/notsoserial/">https://github.com/kantega/notsoserial/</a></div><div><br></div><div><br></div></div></div>
</div>