<div dir="ltr">Hi Sean,<div><br></div><div>This is a tough question. I guess maybe the same granularity as the log messages: that is,</div><div>emitting a JFR event for every step where now a log message is logged, with similar parameters </div><div>would probably make sense?</div><div><br></div><div>At the same time, would anyone use JFR events to debug a Kerberos issue? I am unsure about that.</div><div>What do you think?</div><div><br></div><div>Best,</div><div>Peter</div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Seán Coffey <<a href="mailto:sean.coffey@oracle.com">sean.coffey@oracle.com</a>> ezt írta (időpont: 2024. márc. 13., Sze, 10:53):<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><u></u>

  
  <div>
    <p><br>
    </p>
    <div>On 13/03/2024 01:40, Wei-Jun Wang
      wrote:<br>
    </div>
    <blockquote type="cite">
      <pre><blockquote type="cite" style="color:rgb(0,124,255)"><pre>Thinking about this raises the question: wouldn't it be possible to have these components emit Flight Recorder events as well? 
I understand this is a dubious topic, as some arguments contain secrets, but it would be interesting to know.
Maybe restricting FR events when security debug logging is enabled anyways would be an option?
</pre></blockquote><pre>Seán is our expert on JFR events. He has already created some security-related events, like provider loading and security properties access. You can tell him what else you are interested in.</pre></pre>
    </blockquote>
    <p>Using JFR events is certainly worthy of discussion. What would
      those JFR events looks like ? Would you propose one for each log
      action currently in the krb5 code ? It becomes unmaintainable IMO.
      <br>
    </p>
    <p>The suggestion has also been made for the TLS logging code in the
      past. It's not trivial to convert every log entry to a JFR event.
      A typical client/server handshake in TLS can generate 1000's of
      lines of log output with -Djavax.net.debug=all enabled. It doesn't
      translate easily to JFR events. Reading text is probably easier
      also.<br>
      <br>
      On a related note, I think the current TLS logging is too verbose
      at the moment. Over 3,500 lines of output are generated before a
      ClientHello gets created in a typical TLS debug capture. It's too
      much. Most of it is iterating over certs found in the truststore
      (cacerts by default). Need to log a bug on that.</p>
    <p>regards,<br>
      Sean.<br>
    </p>
  </div>

</blockquote></div>