db7763ca7b
("asn1: X.681/682/683 magic handling of open types")
renamed 'DOMAIN_X500_COMPRESS' to 'domain_X500_Compress'
for compliance with ASN.1 which requires values to start with
lower case and types to start with upper case.
This change adds a CPP macro DOMAIN_X500_COMPRESS for use by
third-party applications that rely upon the prior name.
Change-Id: I2eb6fec2c795c8adeeef893b00909a202257ad74
12826c9586
("Handle partial writes on non-blocking sockets") introduced
unconditional use of 'use_write' which is only declared if
defined(SOCKET_IS_NOT_AN_FD).
Change-Id: I0c43ed44a86b4f245acba849afabeb9ce739d0e5
ee2a92c547 ("bits: Fix warnings")
introduced unconditional use of snprintf(). Use of snprintf in
most of the tree is acceptable whenever roken is available because
roken provides snprintf() for platforms that do not provide it.
However, bits.c cannot use roken and therefore must not
unconditionally call snprintf().
This change restores the prior implementation of BITSIZE(TYPE)
when HAVE_SNPRINTF is undefined.
Change-Id: Ibbd2f003abe9f9fb612719266544cfd545809a18
The hc_evp_md_init, hc_evp_md_update and hc_evp_md_final typedefs
are defined as functions returning an int, but null_Init, null_Update
and null_Final are defined as void, and cast with the typedef when
assigned to the function vector.
This might result in some uninitialized value being returned to the
caller, if some of them make use of the return value. It also causes
warnings if the -Wcast-function-type warning is enabled.
Change the type to in to match the typedef, and return 1 (success).
This is not a very good fix, though the warnings remain. Such errors
can in principle be a problem because in C there is no standard enum
sizing.
In this case we have two enums with the same elements and so the same
size, so it's clearly not a problem.
This commits allows `heim_object_t` as a type and causes the generated
code to use the `heim_retain()` and `heim_release()` functions for
copying and releasing values of such types.
Also, now one can have more than one decoration per-type.
If the decorated external type is a void *, don't include the decoration
header in the ASN.1 header, only in the template implementation. This allows
the copy constructor and destructor to be implementation private.
This adds support for asn1_compile --decorate=... variation that causes
decoration of an ASN.1 SET/SEQUENCE type with a field of a non-ASN.1
type.
This means we can now have an ASN.1 type to represent a request that can
then have a "hidden" field -- hidden in that it is neither encoded nor
decoded. This field will be copied and freed when the decoration is of
an ASN.1 type or of a external, C type that comes with copy constructor
and destructor functions. Decoration with a `void *` field which is
neither copied nor freed is also supported.
We may end up using this to, for example, replace the `hdb_entry_ex`
type by decorating `HDB_entry` with a C type that points to the `HDB` in
which the entry was found or to which it should be written.
Fix regression introduced in 9427796f, where checked in files matching asn1_*.c
would be clobbered by "make clean".
Change-Id: Ifc4bbe3c46dd357fdd642040ad964c7cfe1d395c
Recent auditing changes (b1dcc1a4) introduced a leak into pa_enc_ts_validate()
where the encryption type name and error message could be leaked.
This patch fixes a compile error in the original commit.
We have a Heimdal special where when the acceptor sends back an error
token for clock skew or ticket-not-yet-valid errors then the acceptor
application will get GSS_S_CONTINUE_NEEDED from gss_accept_sec_context()
so that the initiator may retry with the same context.
But we were retaining the auth_context, which means that when the
initiator does send a new token, the acceptor leaks memory because
krb5_verify_ap_req2() doesn't clean up the auth_context on reuse. The
end result is that we leak a lot in those cases.
The implementation of GSS name attributes for Kerberos (or any mechanism
with more than a tiny handful) is much nicer as a table-driven
implementation.
We now have stubs for setting and deleting attributes as well, though
these currently always fail.
The Heimdal KDC does not add a PAC if an anonymous ticket was issued. As such,
test_context should not expect PAC naming attributes to be present if the
--anonymous option was passed. (This is irrelevant for now as GSS_C_ANON_FLAG
is not honored by the krb5 mechanism.)
When unsigned char values are shifted, they are promoted to int (unless
sizeof(int) == sizeof(char)). This means that the change in be708ca3cf
ultimately leads to a sign extension bug.
Use uintptr_t for hash type; this is consistent with CoreFoundation, which uses
32-bit integers on 32-bit platforms for the hash code, and 64-bit integers on
64-bit platforms. (libheimbase is modelled on CoreFoundation.)
Previously we used unsigned long, which would have the same behavior on
LP32/LP64 systems, but not on Windows (where unsigned long is 32-bits on 64-bit
platforms).
Cast integer constants to (void *) with an intermediate cast to
(uintptr_t). On Windows this avoid warnings about a signed
integer being cast to a pointer of larger size.
No functional change.
Change-Id: I7289fb772870c5f492c1a8b988e0d80cf008b7f4
