[OpenAFS] Password transition to krb5 - your methods?

[Jeff Blaine]

Thank you for the usual thorough response, Ken.  It's
very welcome... and a bit amazing that you can construct
a response that thorough and clear in ~20 minutes :)

So my best bet, today, is to track down an MIT 1.3.0 release
to build afs2k5db against then?

Which is the next hurdle:

   http://web.mit.edu/Kerberos/historical.html

       ->

   http://web.mit.edu/Kerberos/krb5-1.3/krb5-1.3.html

       ->

   "Retrieve it here!"
   http://web.mit.edu/network/kerberos-form.html

       ->

   "The kerberos...blahblah has moved."
   Redirected in 1 second to main/modern dist. download page.

Off to the Kerberos list I go.

Ken Hornstein wrote:
>> 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
>