> On Mar 12, 2024, at 5:35 PM, Horváth Péter Gergely > <horvath.peter.gerg...@gmail.com> wrote: > > Hi Weijun, > > That is brilliant, thank you. Do we have any developer documentation for > sun.security.util.Debug (apart from the code ;) )?
Probably not. The only info I know is the output of java -Djava.security.debug=help sun.security.util.Debug > > 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? 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. Thanks, Weijun > > Best, > Peter > > > Wei-Jun Wang <weijun.w...@oracle.com> ezt írta (időpont: 2024. márc. 11., H, > 16:40): > In fact, I've started working on it, see > https://github.com/openjdk/jdk/pull/18199. > > --Weijun > > > On Mar 11, 2024, at 9:21 AM, Wei-Jun Wang <weijun.w...@oracle.com> wrote: > > > > I've filed https://bugs.openjdk.org/browse/JDK-8327818. > > > > But first, in order to make sure the debug option in Krb5LoginModule and > > other JGSS/krb5-related system properties still work, there needs a way to > > instantiate a Debug object without providing the `-Djava.security.debug` > > system property. > > > > For example, in Krb5LoginModule, currently we have > > > > boolean debug = "true".equalsIgnoreCase((String)options.get("debug")); > > > > And I'm thinking of > > > > Debug debug = Debug.of("krb5loginmodule", > > (String)options.get("debug")); > > > > Hopefully this .of() method can automatically support thread info or > > timestamp if the "debug" option has it. > > > > Also, I am wondering if even without he "debug" option, user can set > > -Djava.security.debug=krb5loginmodule to show debug info there. However, > > some krb5 debug info might contain sensitive information like passwords or > > secret keys, so maybe there is a little danger to cover them with > > `-Djava.security.debug=all`. > > > > Thanks, > > Weijun > > > > > >> On Mar 11, 2024, at 5:43 AM, Sean Coffey <sean.cof...@oracle.com> wrote: > >> > >> > >> On 10/03/2024 16:01, Wei-Jun Wang wrote: > >>> Hi Seán, > >>> > >>> I know you are working on enhancing the security debug output with > >>> timestamps and thread info now. Do you think it can also cover Kerberos? > >> I'd love to see Kerberos fall under the same debug implementation used by > >> other JDK security libraries. I suspect it was a standalone product a long > >> time back and had its own debug impl as a result. I'd like to see it > >> worked separate to the ongoing decorator work that's taking place via > >> JDK-8051959. The debug stack for krb5 is different and managed via a Map > >> currently. Maybe Peter could start out by moving the debug output from > >> System.out calls to the sun.security.util.Debug calls as suggested. > >> > >> Using a Logger should be on the radar also. We'd have to use the > >> System.Logger interface since that's the only one guaranteed to be present > >> in the runtime. Maybe the Logger work can be done as a follow on task. I'm > >> also examining the potential for wider use of Logger in security libs. The > >> TLS javax.net.debug option already offers use of a Logger but the > >> configuration in both the calling code and backend remains a blocker to > >> adoption IMO. (e.g. no option to configure Level correctly and static > >> backend configuration options may not be set up correctly at the time > >> logger output becomes necessary to debug an issue) > >> > >> regards, > >> Sean. > >> > >>> > >>> Traditionally, Kerberos debugging is independent of other security areas > >>> and itself is quite complicated. It includes the "debug" label in JAAS > >>> LoginModule (as Peter pointed out below) and separate system properties > >>> like sun.security.krb5.debug, sun.security.jgss.debug, > >>> sun.security.nativegss.debug, and sun.security.spnego.debug. It will be > >>> definitely great if they can enjoy the enhancement of > >>> sun.security.util.Debug. > >>> > >>> BTW, Peter also mentioned a JUL logger. IIUC, our current debug messages > >>> are only sent to System.err, right? > >>> > >>> Thanks, > >>> Weijun > >>> > >>> > >>> > >>>> On Mar 9, 2024, at 4:15 PM, Horváth Péter Gergely > >>>> <horvath.peter.gerg...@gmail.com> wrote: > >>>> > >>>> Dear All, > >>>> > >>>> In the past, I had issues with debug logging in Krb5LoginModule: if > >>>> debug is enabled, > >>>> messages are simply written to the stdout. It is relatively hard to > >>>> correlate these > >>>> messages with application logs, as there are no timestamps for > >>>> Krb5LoginModule output messages. > >>>> > >>>> Imagine a server fails to service a request, due to its failure to > >>>> communicate with > >>>> another Kerberized server. The failure itself will be logged properly, > >>>> but there is no way > >>>> for an operator to easily find and correlate Krb5LoginModule debug > >>>> output. > >>>> (We are talking about servers unders heavy load) > >>>> > >>>> I think debug logging in Krb5LoginModule should be improved; e.g. at > >>>> least, messages > >>>> should be sent to both stdout and a JUL logger maybe? > >>>> > >>>> I would be happy to implement the code change if someone is willing to > >>>> sponsor this issue. > >>>> > >>>> Could someone please help here? > >>>> > >>>> Thanks, > >>>> Peter > > >
