Changes in release 0.6.3
* fix vulnerabilities in ftpd
* support for linux AFS /proc "syscalls"
* support for RFC3244 (Windows 2000 Kerberos Change/Set Password) in
kpasswdd
* fix possible KDC denial of service
* bug fixes
1) It's not documented anywhere.
2) The problem it's attempting to warn about is not documented anywhere.
3) There are no example configs (or any I found with Google) that use the
"listen" directive.
4) In any event, it's poorly worded and unclear what it's talking about.
(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
and without Kerberos 4 & 5 (MKKERBEROS=no). Previously checkflist
complained of missing files.
* move kerberos- and kerberos 4-only files into new flists,
distrib/sets/lists/*/krb.*
* make the flist generators grok MKKERBEROS{,4} variables
* fix Makefiles which treat MKKERBEROS=no as MKKERBEROS5=no.
9 out of 10 experts agree that it is ludicrous to build w/
KERBEROS4 and w/o KERBEROS5.
* fix header files, also, which treat MKKERBEROS=no as MKKERBEROS5=no.
* omit some Kerberos-only subdirectories from the build as
MKKERBEROS{,4} indicate
(I acknowledge the sentiment that flists are the wrong way to go,
and that the makefiles should produce the metalog directly. That
sounds to me like the right way to go, but I am not prepared to do
revamp all the makefiles. While my approach is expedient, it fits
painlessly within the current build architecture until we are
delivered from flist purgatory, and it does not postpone our
delivery. Fair enough?)
(per kernel policy) for crypto transforms for which hardware
acceleration is available. Affects:
crypto/dist/openssl/crypto/engine/eng_all.c
crypto/dist/openssl/crypto/engine/hw_cryptodev.c
crypto/dist/openssl/crypto/evp/c_all.c
as posted to tech-crypto for review/comment on 2003-08-21.
