[OpenAFS] Password transition to krb5 - your methods?

[Ken Hornstein]

>IMO, it should be distributed with it and referenced
>in a new README.kaserver (which also should include
>the elders EOL statement regarding kaserver).
>
>It doesn't have to be referenced by the build process.
>
>I wouldn't surprise me to find that nobody agrees with
>me again.

Sigh.  Jeff, I got your private email about problems building afs2k5db;
I'm going to reply to this note and consider it a reply to your private
note as well, because they're related.

afs2k5db doesn't have a home, as you've discovered.  So it's not a case of
Redhat getting preferential treatment; the people who put the Redhat
package together did extra work to put it in there.

Why doesn't it have a home?  Well, it is unfortunately an odd program.
What afs2k5db needs to do is know about AFS internals (the format of the
kaserver database) _and_ MIT Kerberos internals (the necessary magic to
read a stash file or handle the master key, and output Kerberos dump
file formats).

When splitting up the various parts of the AFS-Kerberos 5 migration kit,
the MIT Kerberos people said that "things that act like a KDC" (such as
fakeka) they felt were better suited to ship with MIT Kerberos.  Utilities
such as aklog and asetkey are pretty obviously mostly AFS utilities that
happen to link against Kerberos libraries and use Kerberos public APIs,
so it makes sense to put them in OpenAFS.  However ... no one was really
sure what to do with afs2k5db.  The MIT Kerberos people didn't want it,
and the OpenAFS people understandably didn't want to ship with something
that required private header files and functions and was almost certainly
going to break in future MIT Kerberos releases.  So that's the situation
we're in now, to provide some history.

Now, what SHOULD we do?  Well, if it was up to me, I think afs2k5db
should be rewritten to use only public krb5 API functions and
manually do all of the encoding necessary to create dump file records
(most of that is there; you would need to parse the stash file and
encrypt the principal keys yourself, but that isn't terrible).
Since MIT Kerberos generally supports older dump file formats this
would be reasonably future-proof.  If this was done, I think it
would be reasonable to ship this program with OpenAFS.  But the
problem here is I don't see who is going to do the work; obviously
I transitioned our cell years ago, and I have no motivation or time
to do work on fixing up afs2k5db.  I think most other people are
in a similar situation.  While I regret that we're where we are
now, that's the situation as I see it.  Unfortunately that isn't
much help to you.

Regarding your specific compilation problem, Jeff ... looks like
to me that swapping the order of the includes of k5-int.h and krb5.h
would be a good first step.  But like Jeff Altman already told you,
newer versions of Kerberos are unlikely to work with it.

--Ken