Changes for Kerb Client 2.5 Beta 3
mjv at MIT.EDU
Tue Jul 22 16:40:54 EDT 2003
>We just picked up the new client code 2.5 B3 and will be using that
>source as our base for our build of the Kerberos Client for Windows.
It is critical that you do NOT ship product based on KfW 2.5 beta 3.
There are serious bugs with that release that we know negatively
impact sites (due to bug reports) and compromise future
compatibility. They include:
* etype-info2 encoding issue (#1681, critical interop issue going forward)
* The UI issues associated with the "No Addresses" default value in krb5 1.3
* The LSA cache if it contains a TGT which is not of enctype
DES-CBC-CRC will flood the KDC with TGS requests
* Imported TGTs from the LSA cache may be expired
* An empty LSA cache will cause Importing to be disabled when in fact
it can succeed
* The export list from GSSAPI32.DLL is incorrect
* kinit.exe did not use krb524 in preference to a V4 TGS request
* ms2mit.exe suffers the same importation problems as Leashw32.dll
These issues will be fixed in the next beta release.
>1. The registry keys are still hard coded throughout the files. All
>registry paths should be defined in one global header file
> which can easily be replaced by any vendor. We suggest using
>defines such as:
> #define KRB4_REG_KEY "Software\\MIT\\Kerberos4"
> #define KRB5_REG_KEY "Software\\MIT\\Kerberos5"
> #define LEASH_REGISTRY_KEY_NAME "Software\\MIT\\Leash"
> #define LEASH_REG_PATH "Software\\MIT\\Leash32\\Settings"
> #define WS_HELP_REG_PATH "Software\\MIT\\WsHelper"
> #define APP_REG_KEY "MIT"
Discussion within the team concluded that collecting all of the
registry settings in auth\leash\leashdll\lshfunc.c was acceptable for
this release. Feedback was requested however no opinion was given by
the time we had to make the changes.
The next beta release will be have a list of all registry settings
used in "auth/leash/leashdll/leash-int.h".
To help us understand the situation better, what benefit do you see
to making this change?
>2. Any DLL/EXE which requires GUI resources does not use an NLS
>file and therefore the files are not easily localizable.
> Could all the resource be put into xxxx.nls files so that we
>can build multi-language support easily?
>3. All error messages should come from strings which are in the NLS files.
We do not have the resources available to do any of this work for the
KfW 2.5 release. We of course would consider patches or resource
donations for future releases of KfW.
>4. The Leash debug file name is hard coded in source file and again
>should be defined in a global header file
>5. The Leash Help file name is hard coded in source file and again
>should be defined in a global header file
>6. DLL names are hard coded in source file and again should be
>defined in a global header file
We're wondering for what purpose do you need these changes? For
uninstalling or maybe replacing the values?
As you saw from Sam's e-mail, we have strong concerns about any
changing of the DLL names as that alters the ABI. If you want to
change the values for these objects, is it your intent to try and
create a "Hummingbird KfW" that can be installed and run
independently of any other KfW installation on the machine?
>7. The new Initialize Ticket dialog is much better than the old with
>the moving OK button. But, could you please following Microsoft GUI
>standards and place the OK/Cancel buttons on the top right?
The Microsoft domain login dialogs place all button the buttons at
the bottom right, and that dialog is a fairly close kin to ours in
purpose. Additionally, we're trying to maintain more consistency with
the layout in Kerberos for Macintosh.
>Also, on that dialog there is a string "Copyright 2003". I don't
>think this belongs there. The copyright notice belongs in the About
The copyright string is provided because the dialogs are not part of
Leash32.exe but Leashw32.dll which can be called from any
application. It's missing the MIT portion which will be fixed in the
next beta release.
>8. The code which searches for the Debug window makes a programming
>assumption that the Listbox is the n'th window from the main window.
>There are better functions for getting child windows from parent
>windows. This code should be changed to make it more robust and not
>assume tabbing order.
The Debug Window should be removed in 3.0 when the KRB4_32.DLL
replaces KRBV4W32.DLL. The DebugWindow only receives output from
KRBV4W32.DLL. There is almost no output generated now that krb524 is
used. K4 TGS requests only occur if krb524 is unavailable or V5
support is deleted.
>9. Some dialogs have OK / Cancel / Help, some dialogs have Options /
>Cancel / OK. I would suggest that you
> make all GUI consistent for the order of the buttons.
The next beta release will make the Leash32.exe dialogs consistent
with the Leashw32.dll dialogs.
Marshall Vale | mjv at mit.edu | Information Systems
Massachusetts Institute of Technology
More information about the krbdev