Proposed lexer for parsing krb5.conf files

[Wyllys Ingersoll]

Jeffrey Altman wrote:
>  Wyllys Ingersoll wrote:
>
> > I think it is worth some more thought and investigation, there are
> > definite benefits in developing an XML schema for the config data
> > and I don't think it would be all that difficult as compared to
> > rewriting the current profile parsing code.
> >
> > -Wyllys
>
>  I don't think you grasp the scope of the problem.   Kerberos is not a
>  library that you replace and suddenly all of the applications that
>  use the krb5.conf file become updated.   The Kerberos world is one in
>  which there are multiple stacks from multiple vendors on the same
>  machine.  Sometimes they are dynamic libraries and sometimes the
>  libraries are static.
>
>  It is not acceptable for an upgrade of one krb5 library to suddenly
>  start breaking others.   Part of the reason we need to re-write the
>  profile library is to make the writing of profile data back to the
>  krb5.conf file occur in a more consistent manner.  In particular, if
>  entries in [capaths] are ordered in a certain way, reading and
>  writing the profile should not change that order.   While fixing
>  these problems we are also going to fix some of the parsing issues
>  that have annoyed people over the years.


I disagree here, Jeff.  I do grasp the problem and understand all
too well the need to maintain backwards compatibility.  I was not
suggesting that support for the current profile be broken or
abandoned.  I propose that if you are going to the trouble of rewriting
the profile code, why not take some time to design it such
that it can evolve in a more standard format that can
be specified by a schema (XML) and processed by third party apps
and libraries?  XML can be as easily parsed in Windows
as it can in Unix, registry entries cannot.

Nothing says you cannot maintain backwards compatibility with
the old format.  As I said, some simple pre-processing of the
config file would easily reveal the format and tell the
code how to proceed - use XML or use the old format.


>  Now, it may be the case that someone wants to develop multiple
>  backends for the profile files.  We currently have "FILE:" and
>  someone might want to develop "XML:" or "REGISTRY:" (for Windows).
>  However, if the library sees a traditional krb5.conf it must use it
>  in the existing format and it cannot change that format.  Doing so
>  would break interoperability.


Agreed, I was not proposing that at all.   Keep support for the
old format, but design the new one in XML - make the code
smart enough to know how to choose the right way to parse it.
I don't see how this would break interop.

-Wyllys