- statically initialize all global spin locks. on hppa, 0 means
the lock is held, so leaving them with the default value doesn't work.
- compare functions pointers using a function-pointer type rather than
an integral type. on hppa, function pointers may be indirect,
so we need to trigger gcc to emit calls to the function-pointer
canonicalization routines in the millicode.
- on hppa the stack grows up, so handle that using the STACK_* macros.
versions used by others in libc weak, so that we have:
name: weak
__name: weak
___name: strong
- Add __name strong aliases of the dlfcn names in ld.elf_so, so that we have:
name: strong
__name: strong
This allows ld.elf_so to self-resolve both the name and __name variants
of the dlfcn functions, the former being required for dlfcn support in
applications, the latter being required for dlfcn support in libc.
Fixes the problem described in:
http://mail-index.netbsd.org/tech-toolchain/2004/07/17/0000.html
Reviewed by Nick.
(lha@NetBSD.ORG), to incorporate contemporary (last-year-ish)
set-password and change-password extensions derived RFC-3244
(Microsoft set-password/change-password extensions), and the
subsequent MIT-KRB5 APIs for changing and setting passwords.
Required for compatibility with recent (2002/2003-ish) open-source
code which uses the MIT KRB5 APIs for setting passwords, or for
joining Microsoft domains as a "computer account".
Modified files (for pullup tracking purposes):
lib/libasn1/Makefile
crypto/dist/heimdal/lib/asn1/k5.asn1
crypto/dist/heimdal/lib/krb5/changepw.c
crypto/dist/heimdal/lib/krb5/krb5-protos.h
crypto/dist/heimdal/lib/krb5/krb5.h
* Restore the signal mask with sigprocmask() instead of _UC_SIGMASK,
* since libpthread may want to interpose on signal handling.
Fixes regress/lib/libpthread/siglongjmp1.
The algorithm used is essentially PBKDF1 from RFC 2898 but using
hmac_sha1 rather than SHA1 directly (suggested by smb@research.att.com).
* The format of the encrypted password is:
* $<tag>$<iterations>$<salt>$<digest>
*
* where:
* <tag> is "sha1"
* <iterations> is an unsigned int identifying how many rounds
* have been applied to <digest>. The number
* should vary slightly for each password to make
* it harder to generate a dictionary of
* pre-computed hashes. See crypt_sha1_iterations.
* <salt> up to 64 bytes of random data, 8 bytes is
* currently considered more than enough.
* <digest> the hashed password.
hmac.c implementes HMAC as defined in RFC 2104 and includes a unit
test for both hmac_sha1 and hmac_sha1 using a selection of the Known
Answer Tests from RFC 2202.
It is worth noting that to be FIPS compliant the hmac key (password)
should be 10-20 chars.
