Difference between revisions of "Kerberos for Windows Release Engineering"
From K5Wiki
(we resolved some issues) |
|||
| Line 24: | Line 24: | ||
* The version number implanted in various dlls may no longer reflect the underlying krb5 version (instead using the KfW version) |
* The version number implanted in various dlls may no longer reflect the underlying krb5 version (instead using the KfW version) |
||
* windows/README is outdated |
* windows/README is outdated |
||
| ⚫ | |||
| ⚫ | |||
Issues that we believe to be resolved: |
Issues that we believe to be resolved: |
||
| Line 32: | Line 30: | ||
* There is a report of crashes on a multiprocessor machine unless CPU-pinning is used |
* 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. |
* 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. |
||
| ⚫ | |||
| ⚫ | |||
Revision as of 14:21, 17 September 2012
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 may no longer reflect the underlying krb5 version (instead using the KfW version)
- windows/README is outdated
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.
