Proposal to use Windows Side-by-side Assemblies for KFW distribution

Jeffrey Altman jaltman at secure-endpoints.com
Tue Jul 29 11:51:27 EDT 2008


Douglas E. Engert wrote:
>
> Sounds like a good idea.
>
> Are you leaning toward the single assembly or the multiple assemblies?
The proposal describes multiple merge modules.  Assemblies are for 
libraries.  We
would have one shared side-by-side assembly for the core libraries and 
one for the
credential cache. Then there would be separate merge modules for the 
command line
tools, the integrated logon support and the credential manager 
(currently NetIDMgr).
>
> You name the assemblies MIT.KerberosV...
MIT.KerberosV was selected because this assembly is for the krb5 related 
libraries.
Other names would be selected for the other merge modules and assemblies.
For those requiring Krb4 support for example the existing libraries 
could be
packaged into a MIT.KerberosIV assembly.
> But for the Common Application Data, you use ...\MIT\Kerberos
\MIT\Kerberos is the name which is already in use for the installation 
and the
top-level software registry keys.  
> Is there some reason for having the V in one but not the other?
One is general and the other is not.
>
> You talk about third party applications. OpenAFS and PuTTY are two that
> come to mind. What would be an upgrade strategy for these?
Future versions of OpenAFS and Putty would ship with the KFW merge 
modules built
into their installation packages.  
>
> If some application did not get upgraded, I assume it could still use
> the current version of KfW.
Yes.  In fact it would be required to because the old application would 
be unable to
find the libraries in the shared assembly.  An old application could be 
updated by adding
a .manifest file for each module to the same directory that contains the 
application's
executables.
>
> If an application had its own private copy of a Kerberos assembly,
> what about the ticket cache? Is it shared, could each have its own?
The credential cache will be shared as long as the two applications each 
are using
a compatible credential cache format whether that be a compatible ccache 
server,
a compatible file format, or something else.

Today on 64-bit Windows 32-bit apps in the WOW64 environment use the 32-bit
KFW and the 64-bit apps use the 64-bit KFW.  They each have their own 
ccache
server instance.  Whichever one gets started first is the one that is 
used.  The other
instance sees the first and exits. 

However, if the ccache server RPC messaging changes (as will happen when 
CCAPIv2
is replaced by CCAPIv?), then individual ccache servers will be running 
and the two
applications will no longer be able to share the CCAPI credential cache.
>
> Could one install the Debug version of the assembly, but not the
> Debug version of the command line tools? Or would one just install
> the debug version.
You could install the Debug version of the libraries but the command 
line tools
will not be linked to it.  The command line tools are just another set 
of applications on
the machine. 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3355 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mailman.mit.edu/pipermail/kfwdev/attachments/20080729/50a698e2/attachment.bin


More information about the kfwdev mailing list