Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 17 Sep 1995 12:58:43 -0700 (PDT)
From:      Bill Paul <wpaul>
To:        mark@grondar.za (Mark Murray)
Cc:        CVS-commiters@freefall.freebsd.org, cvs-user@freefall.freebsd.org
Subject:   Re: cvs commit: src/eBones/usr.sbin/kerberos kerberos.c
Message-ID:  <199509171958.MAA24237@freefall.freebsd.org>
In-Reply-To: <199509171923.VAA03044@grumble.grondar.za> from "Mark Murray" at Sep 17, 95 09:23:06 pm

next in thread | previous in thread | raw e-mail | index | archive | help
> > 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 <stropts.h>' 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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199509171958.MAA24237>