On Sep 29, 2010, at 12:25 PM, Jeffrey Altman wrote: > The last release of Kerberos from MIT for Windows was issued nearly > three years ago. In an e-mail to [email protected] on 11 August 2010, > Stephen Buckley (MIT Kerberos Consortium) stated publicly for the first > time what has been suspected for many years: Kerberos for Windows is not > a priority for the Consortium and future development should not be > expected any time soon. . .
> . . . I do not want to see the build scripts require > git on the build machine to download the package at build time as that > will fail for some large institutional users that build from source. > > What do you think? I think your last sentence is a clue. :-) Caveat: I have no actual insight into the MIT kerberos consortium, but I've watch MS do business and seen how hard they're pushing Active Directory and integration between AD and Kerberos. Based on that: IMHO the long-term source of kerberos authentication for windows will come more and more from Active Directory and ever-closer integration and trust between AD and Kerberos realms. That's the solution Microsoft would prefer. Since they're a member of the kerberos consortium they probably swing some weight on the topic. So not only is MIT kfw effectively orphaned, it's deliberately slated for death by neglect. Nor do I see enough demand for it that it would ever be adopted by anyone with enough resources to make it generally useful in the open source world. > As part of the conversion to support Heimdal the KFW SDK can be removed > from the OpenAFS repository. The question that remains is how should > Windows developers obtain the Heimdal Compatibility SDK? > > 1. Should it be imported into the OpenAFS repository from github as > an external? > 2. Should it be required that developers download it and install it > themselves? Assuming I understand you correctly, you're proposing to remove kfw from the oAFS distribution, and if this is done, then you'd like opinions on where folks should get the Heimdal compatibility sdk. My answer is somewhat dependent on just what we'd like to see happen when someone *does* need kfw from this point forward. If we're going to make it a separate git repository at oafs.org, then I'd say make the Heimdal shims a separately downloadable repository as well. Conversely, if we direct folks who need kfw to the MIT distribution, it seems both reasonable and consistent to direct those needing the Heimdal shims to the github.org repository. I strongly suspect the size of the community that would need the Heimdal shims is small and will shrink over time. Conversely, those sites which are actively downloading and running Heimdal on windows have de-facto demonstrated a great deal of savvy on finding and installing software they need. As long as we clearly document where they can get the Heimdal shims for oAFS on Windows, having it be a separate load from a separate site makes sense to me. I therefore would vote to remove KFW from the oAFS repository, and put directions to both KFW and the Heimdal shims in the distribution notes. Removing kfw from the standard oAFS git repository also helps reduce the number of things that are 'part of' oAFS and which users might expect us to be supporting. IMHO that's a win. In addition, I think it would result in user complaints about kfw going directly to the Consortium. That's likely to carry more weight than our second-hand repetition of those complaints. As an aside, note that if we completely remove the kfw distribution from the openafs.org git repository, there's nothing to say we can't revisit that. Should future versions of oAFS require a kfw that we've fixed and if the MIT consortium is unwilling to release those fixes, we should either add a fixed kfw as a separate git item in openafs.org or include a patch set that folks could then apply to MIT kfw. I'm not sure which of those two is preferable, but we can burn that bridge when we come to it. Similar comments apply to a future in which the Heimdal shims become moribund. Steve_______________________________________________ OpenAFS-devel mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-devel
