hx509_context_free() must call heim_config_file_free() on
the hx509_context.cf section binding. Otherwise the memory
is leaked.
Change-Id: Ib3350a5be67203904fc1aee727c342c3ed552978
PATH_SEP is declared on Windows to be ";" and not ":"
by include/config.h.w32.
lib/base/context.c and lib/hx509.c must not override an existing
setting. Otherwise, file lists cannot be separated and will be
treated as a single file name.
Change-Id: I5521188faca36e41fbae95fbb8942970eab261c8
Just like krb5.conf, but hx509.conf, with all the same default locations
on Windows, OS X, and elsewhere, and HX509_CONFIG as the environment
variable equivalent of KRB5_CONFIG.
Add two ways to exclude private keys when dealing with an hx509
certificate store. One as a load option (load no private keys, never
add private keys), one as a store option (store no private keys).
This is useful for CA code so it can have a single store with the
issuer's credentials _and_ the chain for it, and copy those to a store
with the issued certificate and _not_ accidentally include the issuer's
private key.
It would be much safer still to flip the default for this flag, but that
could break out-of-tree libhx509 dependents.
This commit adds:
- hx509_cert_init_private_key() for creating an hx509_cert object that
has just a private key
- hx509_cert_have_private_key_only() for checking whether an hx509_cert
object has just a private key
This also generalizes the get_key() internal function in hxtool, which
is tasked with reding or generating a private key for use in signing
CSRs. Now hxtool request-create can read/write private keys to/from PEM
files, not just DER files.
This is needed to support key types other than just RSA for CSRs and
certificates.
libhx509 is not built according to the same export and calling conventions
on Windows as the other libraries. This change declares and applies
HX509_LIB_FUNCTION, HX509_LIB_NORETURN_FUNCTION, HX509_LIB_CALL and
HX509_LIB_VARIABLE to lib/hx509.
As a result of this change the calling convention for exported functions
will be __stdcall instead of __cdecl.
Change-Id: Ibc3f05e8088030ef7d13798f1d9c9b190bc57797
In both hx509_cert_init() and hx509_cert_init_data(), there is an
output parameter for the error code but there are cases where the
error is used as a return value instead of the specified hx509_cert.
We fix these issues. We also check if error is non-NULL and only
set the error in this case, allowing the functions to be called
with error == NULL without segfault.
OpenSSL_add_all_algorithms() should only be run once per application
or it will cause data structures to expand. It's not a classic
memory leak as all of the memory will be free(3)d when EVP_cleanup()
is called but as we are a library we cannot call this. We provide
a short term fix here which is using heim_base_once_f() to ensure
that we only call it once.
But the long term fix should be to stop using OpenSSL_add_all_algorithms()
entirely because it both has side effects outside our library and
the caller may destroy our OpenSSL global variables by calling
EVP_cleanup() on his own. It is suboptimal to have potential
interactions between our library and other code in this way.
We turn on a few extra warnings and fix the fallout that occurs
when building with --enable-developer. Note that we get different
warnings on different machines and so this will be a work in
progress. So far, we have built on NetBSD/amd64 5.99.64 (which
uses gcc 4.5.3) and Ubuntu 10.04.3 LTS (which uses gcc 4.4.3).
Notably, we fixed
1. a lot of missing structure initialisers,
2. unchecked return values for functions that glibc
marks as __attribute__((warn-unused-result)),
3. made minor modifications to slc and asn1_compile
which can generate code which generates warnings,
and
4. a few stragglers here and there.
We turned off the extended warnings for many programs in appl/ as
they are nearing the end of their useful lifetime, e.g. rsh, rcp,
popper, ftp and telnet.
Interestingly, glibc's strncmp() macro needed to be worked around
whereas the function calls did not.
We have not yet tried this on 32 bit platforms, so there will be
a few more warnings when we do.
