Windows does not yet support the kcm. However, the header
is now required for building lib/gssapi/ntlm so install it.
Change-Id: I9949794d1159797e11c3e6fdd5675ae857cf04a1
Load configuration data in the registry into a krb5_config_section.
Each registry key corresponds to a krb5_config_section and each
registry value becomes a bound string value.
The set of values contained in the root Heimdal registry key is
treated as if they were defined in the [libdefaults] section.
E.g. the configuration file:
[libdefaults]
foo = bar
[Foo]
x = y
y = {
baz = quux
}
is equivalent to the registry keys:
[HKEY_CURRENT_USER\Software\Heimdal]
"foo"="bar"
[HKEY_CURRENT_USER\Software\Heimdal\Foo]
"x"="y"
[HKEY_CURRENT_USER\Software\Heimdal\Foo\y]
"baz"="quux"
lib/krb5/crypto.c was a large, monolithic block of code which made
it very difficult to selectively enable and disable particular
alogrithms.
Reorganise crypto.c into individual files for each encryption and
salt time, and place the structures which tie everything together
into their own file (crypto-algs.c)
Add a non-installed library (librfc3961) and test program
(test_rfc3961) which builds a minimal rfc3961 crypto library, and
checks that it is usable.
During a test run, cross check the Windows exports list against the
version-script files. For the test to pass, all symbols on either
list should be accounted for.
If there are symbols that are specific to Windows or symbols that are
not included on Windows, they should be annotated in the .def file as
follows:
;! non_windows_symbol
common_symbol
windows_only_symbol ;!
Once DLLs and EXEs are built, they need to have their manifests
processed and signed. These steps are encapsulated in the EXEPREP and
DLLPREP Makefile macros. Use them instead of invoking each processing
macro individually.
