Hi Andrei,
> On May 26, 2023, at 5:00 PM, Andrei Pangin <apan...@openjdk.org> wrote: > > As @pron mentioned, the presence of `-agentlib/agentpath` option serves as > an explicit user consent to use the tool, and disallowing such agents (or > issuing a warning about them) is a non-goal of the JEP. > > With the current behavior, users will be tempted to add > `-XX:+EnableDynamicAgentLoading` option instead of putting one particular > agent on the command line. This again does not serve the purpose of > strengthen the integrity. > > The use cases I mentioned here are quite natural and supported by popular > profilers: a user may want to use a tool some time after the JVM startup, or > reconfigure it later at runtime similarly to how `jcmd JFR.configure` works. Call me dumb.. but… I would have the say that the most puzzling piece of this entire JEP/proposal is that I’m failing to make the connect between how an agent is loaded and how that strengthens integrity. I keep re-reading this JEP looking for clues but I keep bumping my head again… "Giving free reign to tools would imply giving free reign to libraries, which is tantamount to giving up on integrity by default.”. IMO, this is a false equivalency that is not supported by any other point in the document. IOWs, there is nothing in this document that is giving me a clue as to how turning off dynamic attach improves integrity when I can achieve the same effects with a direct attach. What I do know is that turning off dynamic attach by default will cause grief to those that already having to cope with exceptionally complex deployment. I would argue that the complexity of these deployments have dramatically increased since 2017. Do we really want to add to that complexity or should we be refocusing on adding features that help to reduce that complexity. Kind regards, Kirk
