Changes for Kerb Client 2.5 Beta 3

[Pierre Goyette]

Marshall,

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

We already picked up the Beta 4 source to replace the B3. Thanks for the
info.

> >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?

Simple. Less amount of work for us to recode changes after a new source
release from MIT. Right now, we have to make changes in multiple places.
Also, from a development point of view, it would be far cleaner for you if
you define base paths for the registry as opposed to each module having its
own literal...

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

Well, we might be able to donate some resources after we ship our new
version in a few weeks... At this point, it would be items (2) and (3) above
assuming that you will incorporate the changes. I don't want to do a bunch
of work which won't get merged.  :-)

> >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?

We rebuild the Kerberos DLLs with different names so that we can offer
interoperability with existing MIT clients. With the new HostExplorer, you
can choose to use Hummingbird Kerberos or MIT Kerberos. Since we can install
the DLLs, we don't want to affect possible existing installation or other
older client programs. We also want to point to Hummingbird built Help
files.

As you might notice, many of my comments are designed to make the Kerberos
client code more OEMish so that anyone can pickup the source and rebuild it
into their mode (keeping copyrights naturally...). Kerberos is a product
which is receiving more attention but big commercial customers want 
support directly from vendors such as Hummingbird. We need to ship
Hummingbird Kerberos which we can support...

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

OK...

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

Do you seriously have to put up a copyright text for one dialog? The code is
copyright in all the appropriate locations. I've never seen any helper
dialog with its own copyright message.

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

Great.

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

Great.

Pierre Goyette
Senior Director, R&D
Hummingbird Ltd.
Montreal, Quebec, Canada