infrastructure and using that infrastructure in programs.
* MKHESIOD, MKKERBEROS, MKSKEY, and MKYP control building
of the infratsructure (libraries, support programs, etc.)
* USE_HESIOD, USE_KERBEROS, USE_SKEY, and USE_YP control
building of support for using the corresponding API
in various libraries/programs that can use it.
As discussed on tech-toolchain.
pull in just about all of the differences from the crypto-us telnet
suite (which includes Kerberos 4 and connection encryption support).
Also bring in the Kerberos 5 support from the Heimdal telnet, and
frob a little so that it can work with the non-Heimdal telnet suite.
There is still some work left to do, specifically:
- Add Heimdal's ticket forwarding support to the Berkeley Kerberos 4
module.
- Add connection encryption support to the Heimdal Kerberos 5
module. Hints on this can be taken from the MIT Kerberos 5
module which still exists in crypto-us.
However, even with the shortcomings listed above, this is a
better situation than using the stock Heimdal telnet suite,
which does not understand the IPSec policy stuff, and is also
based on much older code which contains bugs that we have already
fixed in the NetBSD sources.
adding support for Heimdal/KTH Kerberos where easy to do so. Eliminate
bsd.crypto.mk.
There is still a bunch more work to do, but crypto is now more-or-less
fully merged into the base NetBSD distribution.
- We must include bsd.own.mk to get EXPORTABLE_SYSTEM from mk.conf.
Noted by Bernd Ernesti.
- If we're only generating man pages, we should deal with obj
directories as appropriate. Both Perry Metzger and I found this
independently.
This completes the tasks necessary to close PR 5519.
of the domestic build process. No domestic program actually builds its
own man pages but instead relies on those built in the exportable tree.
The result is missing telnet(1) and telnet(8) pages.
Fix this problem descending into the telnet and telnetd directories
regardless of whether we're doing an exportable build or not. Once there,
we generate only the man pages if we're building a non-exportable system.
to keep stuff out of the environment on the way to exec (we already have
one in the state machine that keeps them from arriving over the wire, so
this should be redundant, but it'll make any further updates easier to
have it present).
also, RCS Id police.
