Subject: Re: krb5 integration proposal
To: None <current-users@netbsd.org, tech-userlevel@netbsd.org>
From: Aidan Cully <aidan@kublai.com>
List: current-users
Date: 07/20/1999 13:01:41
After a fair bit of thought, and recognizing a major brain-o, I've
modified this proposal..  With no objections, I'll start importing this
stuff on Friday.

On Tue, Jun 08, 1999 at 09:43:09PM -0400, Aidan Cully wrote:
> 2) Merge in my kerb5 changes to login and rlogin.  These build outside of
>    domestic (for the most part), but still can require libcom_err.

login has already been changed.

> 3) Import domestic/krb5.
> 	Perhaps this directory should be domestic/dist/krb5?

I will be going with crypto-us/dist/krb5

> 4) Reorganize libtelnet, according to my local model.
> 	This means the following hierarchy:
> 	src/lib/libtelnet -- almost all libtelnet sources.
> 	src/lib/libtelnet/Nocrypt -- libtelnet source that might be overridden
> 	    by crypto-enabled files.
> 	src/domestic/lib/libtelnet -- basically contains a reachover Makefile
> 	src/domestic/krb5/appl/telnet/libtelnet -- contains MIT's libtelnet
> 	    source
> 
> 	The src/lib/libtelnet Makefile will look something like
> .PATH: {$.CURDIR}/Nocrypt
> .include "${.CURDIR}/Makefile.inc"
> .include <bsd.lib.mk>
> 
> where Makefile.inc contains almost everything in the current libtelnet
> Makefile.
> 
> 	The src/domestic/lib/libtelnet Makefile will look something like
> .PATH: {$.CURDIR}/../../../lib/libtelnet
> .PATH: {$.CURDIR}/../../krb5/appl/telnet/libtelnet
> .include "${.CURDIR}/../../../lib/libtelnet/Makefile.inc"
> 
> SRCS += kerberos5.c kerberos.c &c.
> .include <bsd.lib.mk>

The following to steps
> 5) Merge in the rest of the "reachover" parts of domestic/
> 	This will finally and forever break krb4, except for krb5's
> 	compatibility code.
> 6) Make krb4 a package (to help with people upgrading from k4, at least..)

will be changed to
5) import kerberos5 programs that share names with krb4 programs (e.g.,
   kinit, kdestroy, &c.) as kinit5, kdestroy5, &c.  Modify the
   Makefile.frag in crypto-us/lib, crypto-us/usr.bin &c. like
.if (KERBEROS5 = "true")
# kerberos5 versions of utilities
SUBDIR+=${CRYPTOPATH}/kinit5 \
	${CRYPTOPATH}/kdestroy5
	&c.
.else
# kerberos4 versions of utilities
SUBDIR+=${CRYPTOPATH}/kinit \
	${CRYPTOPATH}/kdestroy
	&c.
.endif
   so that we don't break k4 for people that want it.

> 7) Add krb5 support to other existing tools (ftpd, ftp, rsh..) following
>    the libtelnet hierarchy.
> 8) Start work on other local changes, like libprotoauth which I proposed
>    to kenh a long time ago.
> 
> 
> Stuff that looks troublesome:
> GSSRPC.  On Ken Hornstein's advice, I've given up trying to merge libc's
> rpc implementation with krb5's gssrpc implementation..  There will be two
> RPC libraries installed on the system. (one of which is libc.)
> Where this breaks is in header files..  There should be only one set of
> header files for both the GSS and the _real_ RPC header files.  I'm
> currently just using a bunch of #ifdef GSSAPI blocks in the RPC headers..
> I'm not sure how exportable this is, so the source RPC header files have
> been moved into domestic/, and we can use unifdef to generate exportable
> versions for src/include.  There's probably a better method..

I've made a /usr/include/gssapi/rpc directory housing the GSSRPC headers.
This seems to work relatively well..

Any objections?
--aidan