HCRYPTO_FALLBACK is a required definition for building lib/hcrypto.
However, it wasn't added to the Windows build system. This change
does so and enables fallback functionality.
Change-Id: I4a711c6da58e8832a61a3c0b2b8d9b10038425f0
This adds a new backend for libhcrypto: the OpenSSL backend.
Now libhcrypto has these backends:
- hcrypto itself (i.e., the algorithms coded in lib/hcrypto)
- Common Crypto (OS X)
- PKCS#11 (specifically for Solaris, but not Solaris-specific)
- Windows CNG (Windows)
- OpenSSL (generic)
The ./configure --with-openssl=... option no longer disables the use of
hcrypto. Instead it enables the use of OpenSSL as a (and the default)
backend in libhcrypto. The libhcrypto framework is now always used.
OpenSSL should no longer be used directly within Heimdal, except in the
OpenSSL hcrypto backend itself, and files where elliptic curve (EC)
crypto is needed.
Because libhcrypto's EC support is incomplete, we can only use OpenSSL
for EC. Currently that means separating all EC-using code so that it
does not use hcrypto, thus the libhx509/hxtool and PKINIT EC code has
been moved out of the files it used to be in.
Also, zero return means "success", non-zero means "failure" and the
non-zero value is a system error. That's how it is for the other
platforms' thread primitives.
(The no-threads defaults are still wrong though, as then are macros that
expand into do..while, which can't be used as expressions and don't
"return" values.)
patchset b9d7e33a2f introduced some
garbage at the beginning of the include/NTMakefile. remove it.
Change-Id: Ia24ea3a03aa9ed10b8076112b6486e23f1c36b7c
Normally one would dlopen() a shared object's basename, not its absolute
path. However, lib/krb5/plugin.c, in an effort to be zero-conf-ish,
wants to readdir() to find plugins to load, and in the process it ends
up defeating the RTLD's search-the-caller's-rpath.
This commit partially addresses this by allowing the use of $ORIGIN in
plugin_dir values and using them for the default (except on OS X).
This allows multiple Heimdal versions installed on the same host, but
with different plugin ABIs, to co-exist. A step forward for doing make
check on hosts where Heimdal is installed.
For now we hardcode $ORIGIN/../lib/plugin/krb5 (linux, Solaris, *BSD),
or $ORIGIN (Windows; for assemblies objects need to be in the same
directory) and we eval $ORIGIN by using dladdr() (Linux, Solaris) or
GetModuleHandleEx() (Win32, via a dladdr() wrapper in libroken) to find
the path to libkrb5 whose dirname to use as $ORIGIN. For Windows,
because we need the plugins to be in the same directory as libkrb5, we
require a prefix on plugin DLLs ("plugin_krb5_") to distinguish them
from other objects.
We should add a special token to mean "look in $ORIGIN, sure, but
dlopen() the plugin basenames only (so the RTLD can search the rpath)".
Add strtoll()/strtoull() to lib/roken
Add stdint.h to lib/roken (Windows only)
Add logic to detect whether to use lib/roken's stdint.h based on
Visual Studio version
Add include of stdint.h in generated ASN.1 code
Export missing symbols for 64-bit integers in lib/asn1
Export missing symbols for FAST
Add missing sources to kdc/NTMakefile
Fix issue in kuserok
Fix bsearch issues
Breakout the version data from windows/NTMakefile.config
and move it to windows/NTMakefile.version. This new file
contains only version data. This permits version data to
be safely referenced by third party components.
In addition, add version range information for those versions
of Heimdal for which this release is a compatible upgrade. If
there is a forward incompatible change to the assembly ABI, it
is not a compatible upgrade. This version data is used to specify
the Windows assembly redirect range.
Change-Id: Ic9f156212599cc4277e2be812f29a6497801046c
The pname to uid functionality at present assumes there is
an implementation of getpwnam() and that the local user
identifier is an integer. On Windows, the local user identifier
is a SId. Add NO_LOCALNAME as a build option so that Windows
(for now) can build without providing a getpwnam() implementation.
Change-Id: I04cfd6d2cd52e6228733f1da1dab420b453e6566
A colon can't be used to separate paths on Windows since they are used
in drive sepecification. Define a macro that can be used as a path
separator string. On Windows, this is defined as ";". It is a ":"
everywhere else.
