Supported platforms

This page represents an official policy of the MIT Kerberos project. Edit this page only in accordance with changes agreed by the community; other changes will be reverted.

Extent of support

The word "support" here does not mean that the MIT Kerberos Team in any way provides commercial-grade end-user support for MIT Kerberos. This list of platforms is subject to change at any time, but we will make an effort to follow the principles described in the Rationale. Input from Consortium Sponsors will affect the list of supported platforms, particularly if a sponsor contributes resources (staff expertise, equipment, etc.) for that platform.

This list of supported platforms reflects our priorities for the functionality and portability of the cross-platform source code product. Special platform-specific products such as Kerberos for Windows (KfW) and Kerberos for Macintosh (KfM) are not addressed here.

A platform's appearance on the support list indicates that we will treat problems on that platform with the highest priority relative to problems on other platforms. It indicates the amount of resources that the MIT Kerberos Team is willing to expend to resolve such problems. Platforms not on the support list receive a lower priority. For example, a platform-specific problem reported on an unsupported platform will get preemptively closed unless accompanied by a very well-written patch that poses negligible integration cost for us.

On the supported platforms, we expect that the code on the Subversion trunk will normally build and function correctly. Where a supported platform is a family of platforms, (e.g., Linux, BSD) the MIT Kerberos Team may not have daily access to, or expertise with, every specific member of that family of platforms. For problems peculiar to a mainstream member of a family of supported platforms, but not present on a specific platform for which we have equipment or expertise, we will expend more effort working with the originator of a problem and with the Kerberos community to reach a solution than we would for an unsupported platform. Problems that relate to a specific CPU architecture on a supported platform, even a CPU architecture that we lack access to, will receive higher priority than CPU-architecture dependencies on unsupported platforms.

Supported platforms

• Mac OS X, specifically a "Darwin" command-line build treating the OS as a typical UNIX platform, but potentially using some features specific to Mac OS X. This is not the same as OpenDarwin.
• GNU/Linux (as an OS family; currently Debian, Ubuntu, or Red Hat on x86_64 and x86)
• Solaris (SPARC or x86_64/x86)
• BSD (as an OS family; currently NetBSD on x86_64 and x86)

Generally we use gcc on these platforms, but will also use Sun Workshop compilers on Solaris to achieve compiler diversity.

The specific operating system releases we use will vary, but will typically be a formal release no more than two or three years old. Under some circumstances, the specific operating system release will reflect MIT-specific concerns such as which release is currently used in the MIT Athena environment.

Rationale

CPU architecture

Most x86 or x86_64 platforms except Mac OS X client can run on a virtualized host. If we want to aggressively minimize physical hardware, we need only retain a small number of virtualization x86 hosts and a possibly larger amount of Mac and SPARC hardware.

We desire a certain breadth of CPU architecture coverage to detect regressions related to byte order issues or word size issues.

Our desired CPU architecture coverage is:

{ 32-bit, 64-bit } x { big-endian, little-endian }

and can be most easily achieved by:

• SPARC (big-endian 32-bit and 64-bit (on v9))
• x86_64 (little-endian 64-bit)
• x86 (little-endian 32-bit; subset of x86_64)

Strict alignment vs non-strict alignment is also useful to test, but not enough to justify another full axis to the coverage matrix. Currently, SPARC gives us the benefit of having strict alignment, while x86 is non-strict. Additional factors such as fixed-size instruction word vs variable-size instruction word are not worth additional effort at this time.

Desired OS flavors

• Mac
• Windows (not directly addressed in this article)
• System V
• GNU/Linux
• BSD

Retaining coverage of more "pure" System V derived OSes would be nice, but these are generally OSes that pose significant porting difficulties (e.g. HP-UX). We think that Solaris is sufficiently close to System V lineage for our purposes.

Compiler and libraries

We expect that any supported platform will provide a C compilation environment equivalent to a freestanding C89 (ISO/IEC 9899:1990) implementation. Support for the standard C library does not have to be complete, but we expect that substantially most of the C89 and SUSv3/POSIX.1 libraries is available. Freestanding language support for C99 (ISO/IEC 9899:1999) does not have to be complete, but we use some features such as inline.

We expect that the snprintf() family of functions from C99 and SUSv3/POSIX.1 is available and either conforms to the standards or deviates from the standard behavior in one of a small number of ways:

• It may return -1 if the target buffer is not sufficiently large.
• It may treat n of zero or a null target pointer as an error condition.

On Solaris, precision specifiers on string formats in printf() family functions may count columns rather than bytes if the application is not compiled in a standard-conforming environment. We are investigating the security impact of this behavior.