Tech Insider					     Technology and Trends


		     Kerberos V5 Mailing List Archives

To: krbdev@MIT.EDU, gnu@cygnus.com
Date: Sun, 19 Mar 1995 15:18:06 -0800
From: John Gilmore <gnu@cygnus.com>

The KDC will no longer link, because including
/usr/kerberos/lib/libkrb.a also requires including
/usr/kerberos/lib/libdes.a, which contains a routine for getting the
time-of-day (because it was needed both in libdes for generating
random keys, and in libkrb for timing).

The new K5 Makefiles bring in /usr/kerberos/lib/libkrb.a but
substitute libdes425.a for libdes.a.

I suggest reverting the change.

	John

Date: Sun, 19 Mar 1995 18:56:37 -0500
From: "Theodore Ts'o" <tytso@MIT.EDU>
To: gnu@cygnus.com
Cc: krbdev@MIT.EDU, gnu@cygnus.com
In-Reply-To: <199503192318.PAA07842@cygnus.com> 
(message from John Gilmore on Sun, 19 Mar 1995 15:18:06 -0800)

   Date: Sun, 19 Mar 1995 15:18:06 -0800
   From: John Gilmore <gnu@cygnus.com>

   The KDC will no longer link, because including
   /usr/kerberos/lib/libkrb.a also requires including
   /usr/kerberos/lib/libdes.a, which contains a routine for getting the
   time-of-day (because it was needed both in libdes for generating
   random keys, and in libkrb for timing).

Oh, yeah.  I think we ran into this before.... the problem is that
Cygnus introduced a new function into des.a, that's not in MIT's des.a
(and hence isn't in des425.a).

The long term fix is that we need to include a copy of the V4 Kerberos
library into the V5 tree, both so that (a) it's easier to compile
Kerberos with v4 compatibility, and (b) to prevent skew problems like
this one.

I'd suggest the short-term fix of grabbing the Cygnus gettime of day
function, and dropping it into des425.a, instead of reverting the
change, though.  The whole point of des425.a is to avoid including two
copies of the DES library.  Which function is it that's missing from
des425.a, that the Cygnus krb.a needs?

						- Ted

To: "Theodore Ts'o" <tytso@MIT.EDU>
Cc: gnu@cygnus.com, krbdev@MIT.EDU, gnu@cygnus.com
In-Reply-To: Your message of "Sun, 19 Mar 1995 18:56:37 EST."
             <199503192356.SAA00395@localhost.mit.edu> 
Date: Sun, 19 Mar 1995 18:13:12 -0800
From: John Gilmore <gnu@cygnus.com>

> The whole point of des425.a is to avoid including two
> copies of the DES library.

Exactly.  Premature optimization -- the root of all evil.

> I'd suggest the short-term fix of grabbing the Cygnus gettime of day
> function, and dropping it into des425.a, instead of reverting the
> change, though.
>  Which function is it that's missing from
> des425.a, that the Cygnus krb.a needs?

It's called unix_time_gmt_unixsec, which is the Unix version of
a function that returns time, in zone GMT, in the Unix epoch, in seconds.
This is a heavily configured part of the tree, because it involves
very OS-specific stuff.  (On Windows, we read the hardware clock,
because Windows's time drifts too much!)

I *don't* recommend adding that to your lib425.  What I recommend is
not trying to break an interface in half and substitute for half of it.
If you bring in any piece of krb4, bring the whole thing in.  Saving
40K (or 400K) when built for V4-compatability is simply not a big deal.
Human time is what this project is really short on.  Disk space and RAM
we have gobs of.  Let's stop wasting our time on this.

	John

To: John Gilmore <gnu@cygnus.com>
Cc: "Theodore Ts'o" <tytso@MIT.EDU>, krbdev@MIT.EDU, gnu@cygnus.com
In-Reply-To: Your message of "Sun, 19 Mar 1995 18:13:12 PST."
             <199503200213.SAA10956@cygnus.com> 
Date: Mon, 20 Mar 1995 16:22:16 -0800
From: John Gilmore <gnu@cygnus.com>

What I recommend is not trying to break an interface in half and
substitute for half of it.  If you bring in any piece of krb4, bring
the whole thing in.

I have real work to do.

	John

Date: Mon, 20 Mar 1995 20:48:46 +0500
From: Theodore Ts'o <tytso@MIT.EDU>
To: John Gilmore <gnu@cygnus.com>
Cc: John Gilmore <gnu@cygnus.com>, "Theodore Ts'o" <tytso@MIT.EDU>,
        krbdev@MIT.EDU, gnu@cygnus.com
In-Reply-To: John Gilmore's message of Mon, 20 Mar 1995 16:22:16 -0800,
	< 199503210022.QAA16985@cygnus.com>

   1995 16:22:17 -0800
   Cc: "Theodore Ts'o" <tytso@MIT.EDU>, krbdev@MIT.EDU, gnu@cygnus.com
   Date: Mon, 20 Mar 1995 16:22:16 -0800
   From: John Gilmore <gnu@cygnus.com>

   What I recommend is not trying to break an interface in half and
   substitute for half of it.  If you bring in any piece of krb4, bring
   the whole thing in.

   I have real work to do.

As far as I'm concerned, the des.a represents a real interface, which
Cygnus *changed* when it added that function to des.a and made krb.a
depend on it.  You view all of krb4 plus its des library as one
interface.  I don't; I view them as two distinct interfaces.

In any case, all I need to do to fix things is to put in the Unix
version of the time routine.  The V4 compat libraries are only used by
the server-side code; they're not used by the clients.  Simply from a
perspective of *my* time, and the real work that *I* have to do, it's a
lot faster for me to slip in the necessary routines than to back out all
of the changes in all of the relevant Makefiles.

We'll have to revisit this decision later, but we can do so when we
finally get around to integrating the V4 libraries into the source tree.

							- Ted

P.S.  Note that we have a similar abstraction in the OS part of the
library --- krb5_os_gettimeofday().  So you're going to have to deal
with that "heavily conditionalized" time code eventually anyway.

			        About USENET

USENET (Users’ Network) was a bulletin board shared among many computer
systems around the world. USENET was a logical network, sitting on top
of several physical networks, among them UUCP, BLICN, BERKNET, X.25, and
the ARPANET. Sites on USENET included many universities, private companies
and research organizations. See USENET Archives.

		       SCO Files Lawsuit Against IBM

March 7, 2003 - The SCO Group filed legal action against IBM in the State 
Court of Utah for trade secrets misappropriation, tortious interference, 
unfair competition and breach of contract. The complaint alleges that IBM 
made concentrated efforts to improperly destroy the economic value of 
UNIX, particularly UNIX on Intel, to benefit IBM's Linux services 
business. See SCO vs IBM.

The materials and information included in this website may only be used
for purposes such as criticism, review, private study, scholarship, or
research.

Electronic mail:			       WorldWideWeb:
   tech-insider@outlook.com			  http://tech-insider.org/