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.
[Code reviewed by Love Hörnquist Åstrand <lha@kth.se>]
Added heim_db_*() entry points for dealing with databases, and
make krb5_aname_to_localname() use it.
The following enhancements to libheimbase are included:
- Add heim_data_t and heim_string_t "reference" variants to
avoid memory copies of potentially large data/strings.
See heim_data_ref_create() and heim_string_ref_create().
- Added enhancements to heim_array_t to allow their use for
queues and stacks, and to improve performance. See
heim_array_insert_value().
- Added XPath-like accessors for heim_object_t. See
heim_path_get(), heim_path_copy(), heim_path_create(), and
heim_path_delete(). These are used extensively in the DB
framework's generic composition of ACID support and in the
test_base program
- Made libheimbase more consistent with Core Foundation naming
conventions. See heim_{dict, array}_{get, copy}_value() and
heim_path_{get, copy}().
- Added functionality to and fixed bugs in base/json.c:
- heim_serialize();
- depth limit for JSON parsing (for DoS protection);
- pretty-printing;
- JSON compliance (see below);
- flag options for parsing and serializing; these are needed
because of impedance mismatches between heim_object_t and
JSON (e.g., heim_dict_t allows non-string keys, but JSON
does not; heimbase supports binary data, while JSON does
not).
- Added heim_error_enomem().
- Enhanced the test_base program to test new functionality and
to use heim_path*() to better test JSON encoding. This
includes some fuzz testing of JSON parsing, and running the
test under valgrind.
- Started to add doxygen documentation for libheimbase (but doc
build for libheimbase is still incomplete).
Note that there's still some incomplete JSON support:
- JSON string quoting is not fully implemented;
- libheimbase lacks support for real numbers, while JSON has
it -- otherwise libheimbase is a superset of JSON,
specifically in that any heim_object_t can be a key for an
associative array.
The following DB backends are supported natively:
- "sorted-text", a binary search of sorted (in C locale), flat
text files;
- "json", a backend that stores DB contents serialized as JSON
(this is intended for configuration-like contents).
The DB framework supports:
- multiple key/value tables per-DB
- ACID transactions
The DB framework also natively implements ACID transactions for
any DB backends that a) do not provide transactions natively, b)
do provide lock/unlock/sync methods (even on Windows). This
includes autocommit of DB updates outside transactions.
Future DB enhancements may include:
- add backends for various DB types (BDB, CDB, MDB, ...);
- make libhdb use heim_db_t;
- add a command-line tool for interfacing to databases via
libheimbase (e.g., to get/set/delete values, create/copy/
backup DBs, inspect history, check integrity);
- framework-level transaction logging (with redo and undo
logging), for generic incremental replication;
- framework-level DB integrity checking.
We could store a MAC of the XOR of a hash function applied to
{key, value} for every entry in the DB, then use this to check
DB integrity incrementally during incremental replication, as
well as for the whole DB.
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
Different ticket session key enctype selection options should
distinguish between target principal type (krbtgt vs. not), not
between KDC request types.
We can't test the key rollover support in the TGS in the x-realm
path using just Heimdal because the krb5_get_creds() path will try a
referral, which will produce a cross-realm TGT that has the
enc_part.kvno set. But we can test this for the plain TGT case.
AD issues x-realm TGTs with kvno 0. On key x-realm trust key change
we need to be able to try current and previous keys for trust, else
we will have some failures.
We were using the enctype from the PA-TGS-REQ's AP-REQ's Ticket to
decide what key from the service's realm's krbtgt principal to use.
This breaks when: a) we're doing cross-realm, b) the service's
realm's krbtgt principal doesn't have keys for the enctype used in
the cross-realm TGT.
The fix is to pick the correct key (strongest or first, per-config)
from the service's realm's krbtgt principal.
The previous fix was incomplete. But it also finally uncovered an
old check-des problem that I'd had once and which may have gotten
papered over by changing the default of one of the *strongest* KDC
parameters. The old problem is that we were passing the wrong
enctype to _kdc_encode_reply(): we were passing the session key
enctype where the ticket enc-part key's enctype was expected.
The whole enctype being passed in is superfluous anyways. Let's
clean that up next.
When I added support for configuring how the KDC selects session,
reply, and ticket enc-part keys I accidentally had the KDC use the
session key selection algorithm for selecting the ticket enc-part
key. This becomes a problem when using a Heimdal KDC with an MIT
KDB as the HDB backend and when the krbtgt keys are not in
strongest-to-weakest order, in which case forwardable tickets minted
by the Heimdal KDC will not be accepted by MIT KDCs with the same
KDB.
We don't need a cast in that case.
Before commit 1124c4872d
(KVNOs are krb5uint32 in RFC4120, make it so),
we compared krb5int32 casted to size_t with unsigned int,
which resulted in the following problem:
Casting krb5int32 to (size_t) is wrong, as sizeof(int)==4 != sizeof(size_t)== 8.
If you cast negative int values to size_t you'll get this:
int ival = -5000; // 0xFFFFEC78
size_t sval = (size_t)ival; // this will be 0xFFFFFFFFFFFFEC78
So we better compare while casting to (unsigned int).
This is important for Active Directory RODC support,
which adds a random number into the higher 16-bits of the
32-bit kvno value.
metze
Signed-off-by: Love Hörnquist Åstrand <lha@h5l.org>
We need to use the name that the HDB entry returned, otherwise we
will not canonicalise the reply if requested.
Andrew Bartlett
Signed-off-by: Love Hörnquist Åstrand <lha@h5l.org>
