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

[Jeffrey Altman]

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig93E0696BBE2A6624C8B21E4B
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 9/30/2010 4:37 AM, Harald Barth wrote:
>=20
>> ... I think separate products
>> should remain separate whenever possible...
>=20
> I have that opinion, too.
>=20
> If the build system does not support specifying an external
> dependency, fix the build system. If you can not fix the build system,
> it has to be done manually by the person who builds from source. We
> can hint on the web page where to get that external dependency. If
> they can't build anyway, they probably should not, so let them take
> the binary (you plan to supply a binary, don't you?).

Building the Windows packages is insanely difficult.  Unlike UNIX/Linux
we have to support a half-dozen compilers and matching run time
libraries, operating system version specific development kits, device
driver kits, help compilers, and internationalization libraries; all of
those being from Microsoft and many of which require paid licenses.

On top of that we have dependencies on Cygwin for the docbook and pdf
generation, Wix and NSIS for installation packages, and currently the
KFW SDK which is not available from MIT as a separate supportable
installation package.

If you want to build the Java code you need a specific version of the
Oracle JDK.  Perl bindings, something else.

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.

Back in 2003, the KFW SDK (headers and link libraries not the actual
DLLs) were added to the OpenAFS source tree in order to permit the
Windows packages to gain Kerberos v5 support.  This was done for one
very simple reason:

  The Windows build environment is fragile.  Adding a new dependency
  that causes a build environment to break between releases was not
  considered to be acceptable.

The purpose of the transition from the KFW APIs to the Heimdal
Compatibility APIs is to permit flexibility for end users.  The OpenAFS
for Windows binaries today will execute whether or not KFW is actually
installed.  We don't want to make building with Kerberos v5 support
conditional on whether the KFW SDK has been obtained and installed.
Instead we want that support to be mandatory so that all that is
required is for the Kerberos libraries to be installed on the end user
system in order for Kerberos v5 to become available as an authentication
method.

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.

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.

Does it make the OpenAFS git repository larger?  Certainly.  However, I
believe that is a small price to pay compared to the pain that
organizations are going to face when their builds start breaking.

>> ... It makes life for
>> distributions really hard when there are multiple copies of libraries,=

>> since security fixes become a huge pain in the ass.
>=20
> Yes, and it's a question of who to blame and the amount of work that
> is due when a security bug hits.

This argument does not apply to either the inclusion of the KFW SDK or
the Heimdal Compatibility SDK since in neither case is OpenAFS
distributing the actual Kerberos implementation.  OpenAFS does
distribute (as it is required to) the Microsoft run time libraries that
OpenAFS is built against.   When there are security issues in those
libraries we have in the past been forced to release updated packages.

Jeffrey Altman


--------------enig93E0696BBE2A6624C8B21E4B
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)

iQEcBAEBAgAGBQJMpJ3XAAoJENxm1CNJffh4OtkIAOmpCHFhRPOeS7ARG5HyNcuc
bT55kH86qRM0efxJ2rwgGRrvj9xgCuZa5VOyNLyVv7NQJ9pbMEZbOTcce19BZvpY
Git80huOzSYbJu15qFUWd5nYxKir0S1lvlUpNCxoCfSjjAG87DDkNibM5DUBh+qp
qBtqNSAN7LH6syp1E8Mvp6ZJblOuWKMCK1TGdGKJLtgYJ/CCA0i+HYZhzE435Met
ZNcCYxu3Rxee6ExJ6+z6vnrOqdIJn5mmeHoJu3MuvNBY2gCryqTl2H88B9yeUaC2
fhGiubA05eH91EZwvtk5oPagfSKxVWyIOqmJ8GDI7h1vgHUn26SAE4UTx5rPiF0=
=odMP
-----END PGP SIGNATURE-----

--------------enig93E0696BBE2A6624C8B21E4B--