Kerberos for Windows Release Engineering

Release Engineering notes for the Kerberos for Windows 4.0.0 release

Software to test against new builds:

• SapGUI
• OpenAFS
• SecureCRT (and SecureFX?)
• SPNEGO (in multiple browsers?)
• Adobe Keyserver a.k.a the Sassafras key client
• SMTP/IMAP via Thunderbird (must disable SSPI though?)
• LDAP in some form?
• XMPP via, e.g., Pidgin

Upgrades scenarios to test:

• 32-bit to 32-bit, from 3.2
• 64-bit to 64-bit, from 3.2
• 32-bit to 64-bit, from 3.2
• 32-bit and 64-bit to 64-bit, from 3.2
• 32-bit to 64-bit, from 4.0
• 64-bit to 32-bit, from 4.0

When starting from 3.2, it probably suffices to test the Secure Endpoints versions once only, and assume that there will not be future changes to 4.0 which cause the upgrade process to fail for the SE version but not the MIT-distributed version. The NSIS upgrade path is a separate codepath and should be tested separately.

Current known issues:

• The version number implanted in various dlls no longer reflects the underlying krb5 version (instead using the KfW version); this may not actually be a bug.
• windows/README is outdated
• (Version) upgrades that go from 64-bit to 32-bit leave 64-bit binaries around but otherwise succeed.

Issues that we believe to be resolved:

• The uninstaller prompts to kill running processes but does not do succeed in doing so. There may be cases in which it just kills processes without prompting, which may still be a bug.
• The upgrade procedure attempts to kill running processes but does not succeed in doing so (these two may be sharing most of the code). The wix-users archives suggest that Util:CloseApplication may be useful to do this in pure WiX instead of a custom element
• There is a report of crashes on a multiprocessor machine unless CPU-pinning is used
• Uninitialized (NULL) TLS pointers that were most prominent on multi-processor machines, causing internal ccache errors that were reported as "unknown error" due to another minor bug.
• Thunderbird cannot do GSSAPI auth unless you disable SSPI
• Our DllMain attach/detach handler spews to the terminal when running command-line utilities. Possibly other debug print statements, too.

Versioning stuff:

• src/patchlevel.h
• src/windows/installer/wix/site-local.wxi
• src/windows/version.rc (copyright year)
• src/windows/winlevel.h
• src/windows/kerberos.ver

Procedure for building release binaries (MIT and non-MIT, i386 and amd64):

  On the VM host:
  
  rm -rf /path/to/share/kfw-4.1-beta2 && git archive --prefix=kfw-4.1-beta2/ [committish] | (cd /path/to/share/; tar x)
  rm -rf /path/to/share/kfw-4.1-beta2-mit && git archive --prefix=kfw-4.1-beta2-mit/ [committish] | (cd /path/to/share/; tar x)
  git archive --prefix=kfw-4.1-beta2/ --format=zip -o ../kfw-4.1-beta2-src.zip refs/tags/kfw-4.1-beta2
  
  
  mkdir C:\destdir
  mkdir C:\debug-symbols
  mkdir C:\debug-symbols\kfw-NNN-i386-mit
  mkdir C:\debug-symbols\kfw-NNN-amd64-mit
  mkdir C:\debug-symbols\kfw-NNN-i386
  mkdir C:\debug-symbols\kfw-NNN-amd64
  setenv /x86 /release
  set CPU=i386
  set KRB_INSTALL_DIR=C:\destdir
  set NODEBUG=1
  set DEBUG_SYMBOL=1
  set MIT_INTERNAL=1
  # do the MIT i386 build
  cd C:\kfw-NNN-mit\src
  nmake -f Makefile.in prep-windows
  nmake
  nmake install
  set DEBUG_SYMBOL=	# unset it
  mv C:\destdir\bin\*.pdb C:\debug-symbols\kfw-NNN-i386-mit
  cd windows\installer\wix
  nmake
  rename kfw.msi kfw-NNN-i386-mit.msi
  # time for the MIT amd64 build
  cd ..\..\..
  setenv /x64 /release
  set CPU=AMD64
  set DEBUG_SYMBOL=1
  nmake clean
  nmake
  nmake install
  set DEBUG_SYMBOL=	# unset it
  mv C:\destdir\bin\*.pdb C:\debug-symbols\kfw-NNN-amd64-mit
  cd windows\installer\wix
  nmake clean
  nmake
  rename kfw.msi kfw-NNN-amd64-mit.msi
  rm -r C:\destdir\bin
  rm -r C:\destdir\lib
  rm -r C:\destdir\include
  # fresh env for the non-MIT i386 build
  setenv /x86 /release
  set CPU=i386
  set DEBUG_SYMBOL=1
  set MIT_INTERNAL=	# unset it
  cd C:\kfw-NNN\src
  nmake -f Makefile.in prep-windows
  nmake
  nmake install
  set DEBUG_SYMBOL=	# unset it
  mv C:\destdir\bin\*.pdb C:\debug-symbols\kfw-NNN-i386
  cd windows\installer\wix
  nmake
  rename kfw.msi kfw-NNN-i386.msi
  cd ..\..\..
  # the non-MIT amd64 build
  setenv /x64 /release
  set CPU=AMD64
  set DEBUG_SYMBOL=1
  nmake clean
  nmake
  nmake install
  set DEBUG_SYMBOL=	# unset it
  mv C:\destdir\bin\*.pdb C:\debug-symbols\kfw-NNN-amd64
  cd windows\installer\wix
  nmake clean
  nmake
  rename kfw.msi kfw-NNN-amd64.msi
  [copy C:\kfw-NNN{,-mit}\src\windows\installer\wix\*.msi to the shared drive]
  [recursively copy C:\debug-symbols\kfw-NNN* to the shared drive]
  
  On the VM host, extract the build output for signing.

Use the arCHMage package to extract HTML from the CHM file for the web. The tool outputs some bogus absolute URLs for links and inline images, so use

   perl -pi -e 's,((?:href|src)=")/,\1../,g' */*

to postprocess.