On 9/30/2010 4:37 AM, Harald Barth wrote: > >> ... I think separate products >> should remain separate whenever possible... > > I have that opinion, too. > > 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. > > 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
signature.asc
Description: OpenPGP digital signature
