From owner-cvs-user Sun Sep 17 12:58:51 1995 Return-Path: owner-cvs-user Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id MAA24245 for cvs-user-outgoing; Sun, 17 Sep 1995 12:58:51 -0700 Received: (from wpaul@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id MAA24237 ; Sun, 17 Sep 1995 12:58:44 -0700 From: Bill Paul Message-Id: <199509171958.MAA24237@freefall.freebsd.org> Subject: Re: cvs commit: src/eBones/usr.sbin/kerberos kerberos.c To: mark@grondar.za (Mark Murray) Date: Sun, 17 Sep 1995 12:58:43 -0700 (PDT) Cc: CVS-commiters@freefall.freebsd.org, cvs-user@freefall.freebsd.org In-Reply-To: <199509171923.VAA03044@grumble.grondar.za> from "Mark Murray" at Sep 17, 95 09:23:06 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 3209 Sender: owner-cvs-user@FreeBSD.org Precedence: bulk > > I'll gladly tar up the whole thing and give it to you, but nobody's > > answered my questions yet: > > > > - Do we really want to import the GNU mp library? > > How big is that? -rw-r--r-- 1 root bin 108358 Jul 21 00:17 /usr/src/gmp-1.3.2.tar.gz -rw-r--r-- 1 root sysman 261188 Jul 21 00:24 /usr/src/gmp-1.3.2/libgmp.a -rw-r--r-- 1 root sysman 110280 Jul 21 00:25 /usr/src/gmp-1.3.2/libmp.a The libmp.a library is the part we need: it's a clone of the 'Berkeley' libmp library. The libgmp.a library contains many other interesting things, none of which are strictly necessary for Secure RPC. Still, if we're going to do one, we may as wlel do both, since they're both GPL'ed. > > - Do we want to import the new rpcgen? > > Again - how big is it? Can it replace or compliment anything? About the same size as as the existing rpcgen. If you reverse the meaning of the -b flag, you could make it a drop-in replacemnt for the old rpcgen. However, its ability to generate TI-RPC code would be practically useless in FreeBSD, unless we suddenly grew some STREAMS-based networking code. (One hack I had to make was to prevent it from emitting an '#include ' line in backwards-compat mode.) > > - How the hell do we make the thing work in the core distribution > > where libdes isn't available? > > Make it a part of securedist, where DES is going to go? I'm not sure that will work: the core RPC code is _inside_ libc, which means you'd have to ship an alternate libc with the securedist. Installing a new libc.so is very tricky. Also, I'm not sure you can totally hide Secure RPC inside the library. Clients and servers that use RPC need to use extra functions (like authdes_create()) that aren't present in the stock RPC implementation. I'm not sure you could make things work with dummy functions. It might be necessary to sprinkle #ifdefs into the code and produce two versions of Secure RPC binaries -- one with AUTH_DES and one without. One idea that had occured to me was to create a dummy libdes with stub ebc_crypt() and cbc_crypt() functions that either didn't encrypt anything at all, or used some other encryption besides DES that wouldn't get us in hot water. The result would be that FreeBSD machines could make Secure RPCs between each other, but not with other systems. You could then install the appropriate libdes.so from the securedist to make it work with other systems (which would mean other Solaris systems at this point). The reason I was hesitant to suggest this is because I remember reading somewhere that code that calls encrpytion functions is every bit as restricted as the encryption code itself. The Secure RPC stuff certainly qualifies. Then again, Sun distributed the sources to Secure RPC without any trouble, so I may be overreacting. I'd like to avoid the 'dummy libdes' idea since it would destroy interoperability with other OSes, but we may have to deal with it. Anyway, I'm going to see what I can do about packaging up the stuff I've been working on so I can ship it out to you. I'm still hacking on a few things. Let me know how toy want to transfer things (I can either put the stuff on my FTP server or FTP it to you). -Bill