Changes for Kerb Client 2.5 Beta 3

[Marshall Vale]

Hi Pierre,

>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 
(Leash_import)

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 
>box.

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
-- 
Marshall Vale    | mjv at mit.edu | Information Systems   
Massachusetts Institute of Technology