svn rev #24533: trunk/src/ appl/ ccapi/lib/ ccapi/lib/mac/ ccapi/lib/win/ ccapi/server/win/ ...

[Jeffrey Altman]

On 11/26/2010 12:41 AM, Greg Hudson wrote:
> On Thu, 2010-11-25 at 21:12 -0500, Jeffrey Altman wrote:

> The OS platforms supported by SDK 7.1 are XP SP2, Vista, Server 2003,
> Server 2008, and Windows 7.  From my current position of ignorance, that
> seems like a reasonable set of OS platforms to support for a new KFW
> release.

My point was that MIT needs to specify that when building the code the
SDK is configured for XP mode for 32-bit builds and 2003 mode for 64-bit
builds.  (XP64 is really 2003).

> If there are APIs we want to use which aren't present in XP or Server
> 2003, we can detect the OS platform at runtime, right?  It looks like
> cc_mslsa.c already does some amount of that.

It does to make use of functions that are not present in Windows 2000.
If the lowest platform that is going to be supported is some service
pack of XP and 2003, then all of the code the mslsa code should be
rebased to the supported platform.
> 
>> The selection of SDK also determines the minimum visual studio tool
>> chain that can be used.  Typically, newer SDKs are not compatible with
>> older visual studio distributions.
> 
> The minimum visual studio chain that can be used for building apps
> against KFW, or building KFW itself?

For building KFW itself.

> I didn't need to install Visual Studio at all to get the core krb5 build
> working; the SDK included all of the necessary command-line tools
> (compiler, linker, nmake, etc.).  Will Visual Studio be needed to build
> some part of KFW itself, such as the installer?

There are three reasons you want visual studio.  One, until recently the
SDKs did not ship with compilers.  Two, the compilers that ship with the
SDK do not have support for profiling.  Three, the compilers that ship
with the SDK are back-level.

Visual Studio is also required to build many gui tools.

MIT needs to decide which tools are going to be supported.  There are
many large organizations that build KFW from source that are still using
the VS2003 tool chain.

>> Note that the command line tools distributed with KFW have not been
>> the krb5 versions.  The pismere tools have additional functionality
>> that will need to be migrated.
> 
> Noted.  So far I have only worked with the core krb5 build; I still need
> to learn about how that is turned into KFW and how we can simplify that.

As far as the installers go, they should be utterly reworked.  MIT has
traditionally supported the libraries as a bag of DLLs.  This has causes
all sorts of problems.  Back the Summer of 2008 Secure Endpoints (at the
request of MIT) developed a proposal for the use of Side-by-Side
Assemblies.  MIT decided not to hire Secure Endpoints to implement it.
However, the requirement is still present.  The proposal is still on the
Secure Endpoints web site.

  http://www.secure-endpoints.com/kfw/proposal-kfw-assemblies.html

Note that implementing assemblies will break compatibility with previous
KFW distributions.  Compatibility DLLs that forward to the assembly will
be required to implement backward compatibility.
If MIT chooses to implement assemblies, Secure Endpoints will add
support for them to the Heimdal Compatibility SDK.

  https://github.com/secure-endpoints/heimdal-krbcompat

Applications built against this SDK will work seamlessly with both
Heimdal and MIT Kerberos implementations.

Jeffrey Altman

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: OpenPGP digital signature
Url : http://mailman.mit.edu/pipermail/krbdev/attachments/20101128/89e39ae0/attachment.bin