Re: Improving logging in Krb5LoginModule

[Wei-Jun Wang]

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?

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 
>  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

Re: [External] : Re: PEM API github repo

[Anthony Scarpino]

On Mar 9, 2024, at 8:09 AM, Karl Scheibelhofer 
 wrote:


... try again from from my subscribed mail account...

Hi Tony,

in my jdk fork, I created a branch named pem-feedback-karl.

https://github.com/KarlScheibelhofer/jdk/tree/pem-feedback-karl

It is based on the pem branch of your jdk fork.
In this pem-feedback-karl branch, I did some cleanup without changing
the API. Your tests pass as before.

My original pem-keystore implementation for the SUN provider is in this branch

https://github.com/KarlScheibelhofer/jdk/tree/pem-keystore

It did not use the PEM API.

In the branch

https://github.com/KarlScheibelhofer/jdk/tree/pem-keystore-pem-api

I modified the PEM keystore implementation to use the PEMDecoder and PEMEncoder.
To make it pass all tests, I had to fix some issues with the PEM api:

* fix missing line-breaks when encoding certificates (and CRLs)
* use uniform line length for PEM encoding keys and certificates

It sounds like I did my repo update to use MimeEncoder after you had pulled the 
changes.

During this work, I took some notes regarding the PEM api:

* Consider decoupling the raw PEM encoding and decoding from SecurityObject.
  This would make the API usable for general purpose PEM encoding and
decoding, not just for keys and certificates, as it is now.

There has been discussions about adding a generic PEM object that would have 
methods to return the header, footer, and PEM text, instead of processing into 
a class or KeySpec. Is there something more “general purpose” you had it mind?

* For this PEM keystore implementation it is essential to parse the
preceding explanatory text lines.
  The PEM decoder should support this.
  As it is now, the keystore implementation must parse the PEM objects
itself, including reading PEM header and footer lines.
  Having to handle half the work in the application diminishes the
value of the PEMDecoder.
  It only delegates the decoding of certificates and keys to the PEMDecoder.

* PEMDecoder should be able to handle or pass through unknown PEM
objects gracefully.
  Otherwise the application has to check the PEM labels in advance
itself, which does not make sense.

So do you not have a structured data file?  I expected the application would 
parse its own metadata, then when the structured code got to a PEM tag, it 
would pass the InputStream to PEMDecoder.

I am concerned about a generic PEM object storing an unknown amount of 
application metadata and returning it back.  I feel handling non-PEM should be 
in the scope of the encoder/decoder.


* Though supporting InputStream/OutputStream for reading and writing
makes sense,
  supporting Reader/Writer feels even more essential for robust
support for all character encodings.
  Multi-Byte character encodings won't work with InputStream/OutputStream.

A Reader will read ahead, buffering the input data.  I saw this when I had 
`decode(Reader)` in the API.  It would return the first PEM object, but the 
read pointer was at the end of the file, missing the remaining PEM objects.

Is the multi-byte characters for the keystore metadata?  I don’t see how this 
affects Base64.


* The standard line separator for PEM is "\r\n".
  For PEM files stored in a typical linux file system, "\n" is
typically used, however.
  See the output of openssl, for example.
  Because there are still several command line utilities that do not
work well with "\r\n" line breaks.
  Supporting a different line-separator than "\r\n" is a good idea in
my opinion.
  Base64.getMimeEncoder also supports selecting a custom line separator.

The standards I saw says the line separator is “\r\n”.  I realize decoders have 
to be more flexible because many may not follow the line separators or 
cut-n-paste removes them.  I think having a configurable line separator for 
encoding is likely to create more incompatibility rather than lessen for 
cross-platform and using with other applications.


* The PEMEncoder encodes the predefined SecurityObjects only.
  There is no way to use it to PEM encoded any other type of object.
  Consider opening a path to generic use.

The generic PEM object I mentioned previously I think fits this case.  It would 
still be a SecurityObject as I don’t see value in passing in any object.


* If an application has a DER encoded certificate, it has to decode
and parse the certificate before
  it