Ken Hornstein wrote: > 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). > > 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.
The MIT License is compatible with OpenAFS. Someone could simply copy the necessary routines out of MIT Kerberos and build a package that doesn't require MIT Kerberos at all. Or the inverse could be done. The kaserver database routines could be extracted and added to a tool that could be built by MIT without AFS being present. Since MIT already has all of the crypto library functions necessary, going in this direction might be less work. Jeffrey Altman
smime.p7s
Description: S/MIME Cryptographic Signature
