P4
A DESCRIPTION OF THE PROBLEM :
I would like to propose to remove jdk.InitialEnvironmentVariable and jdk.InitialSystemProperty, as well as any other events that easily will leak private information, from the default and profile .jfc files.
My reasoning is the following:
1. While these can be both disabled and scrubbed, it is unlikely that a user would know to do. E.g. https://docs.oracle.com/en/java/java-components/jdk-mission-control/8/user-guide/using-jdk-flight-recorder.html does not mention this, and even if it did, people tend to read the least amount of docs they can.
2. Both environment variables and system properties often contain secret, or sensitive information.
3. JFR files are useful to share with e.g. colleagues or other people who might be able to help you with your problem.
4. I'd argue that these events are some of the least important events for JFR, and it can easily be obtained from outside the JVM.
All in all I think that the security risk of accidentally exposing secrets through .jfr files created using the default.jfc/profile.jfc settings (which is what most tutorials refer to) outweighs the usefulness these have in a jfr recording. Users who want it could chose to opt-in.
There is a similar issue with the jdk.JavaExceptionThrow event - users may include sensitive information in exception messages. This event is slightly more useful though, and it is likely that such security issues would show up in logs as well. Not sure if this should be included as well.
I would like to propose to remove jdk.InitialEnvironmentVariable and jdk.InitialSystemProperty, as well as any other events that easily will leak private information, from the default and profile .jfc files.
My reasoning is the following:
1. While these can be both disabled and scrubbed, it is unlikely that a user would know to do. E.g. https://docs.oracle.com/en/java/java-components/jdk-mission-control/8/user-guide/using-jdk-flight-recorder.html does not mention this, and even if it did, people tend to read the least amount of docs they can.
2. Both environment variables and system properties often contain secret, or sensitive information.
3. JFR files are useful to share with e.g. colleagues or other people who might be able to help you with your problem.
4. I'd argue that these events are some of the least important events for JFR, and it can easily be obtained from outside the JVM.
All in all I think that the security risk of accidentally exposing secrets through .jfr files created using the default.jfc/profile.jfc settings (which is what most tutorials refer to) outweighs the usefulness these have in a jfr recording. Users who want it could chose to opt-in.
There is a similar issue with the jdk.JavaExceptionThrow event - users may include sensitive information in exception messages. This event is slightly more useful though, and it is likely that such security issues would show up in logs as well. Not sure if this should be included as well.