[OpenAFS-devel] Building OpenAFS for Windows with Heimdal Compatibility

Russ Allbery rra@stanford.edu
Thu, 30 Sep 2010 10:46:44 -0700


Jeffrey Altman <jaltman@secure-endpoints.com> writes:

> Each one of these packages comes from a different place for which there
> is not a canonical URL that you can point someone at that is going to
> give them the most up to date (aka secure) version that works for the
> OpenAFS build environment.

I'm certainly okay with hosting copies of the latest downloads that
everyone needs so that we can point to specifically blessed versions and
tell people to use those.  I don't think this means, or should mean, that
these copies need to be in the OpenAFS source tree, though.

> The actual usage of the Kerberos libraries within OpenAFS is quite
> indirect.  Today there is are several implementations of slightly
> different shim layers in the OpenAFS source tree.  One for the NIM
> plug-in, one for afscreds.exe, afslogon.dll, and TaServerManager.exe.
> Then there is aklog.exe.  This shim layer provides the ability to link
> against Kerberos DLLs but work even if they are not present and work
> even if the version of the DLLs that the code is built against are not a
> perfect match for what is installed.

> What Asanka and I decided to do when adding Heimdal support was to
> generalize this interface so that it can be used not just for OpenAFS
> but for all applications that wish to work against an arbitrary version
> of Kerberos/GSS installed on the machine.  We could have just updated
> the shim layers we already had.

This is all great, of course.  I'm all in favor.

> The benefit of adding these headers and libs to the tree is that they
> represent the smallest amount of glue code necessary to gain the
> required functionality without breaking the fragile build environments
> that are currently in use.

I don't think I understand why externalizing this as a separate package
that we also host but which needs to be downloaded as a prerequisite
breaks this necessary functionality.  That would be the direction I'd
personally lean.

-- 
Russ Allbery (rra@stanford.edu)             <http://www.eyrie.org/~eagle/>