CoSign: Collaborative Single Sign-On  

cosign-discuss at
general discussion of cosign development and deployment

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: cosign and MIT Kerberos

Well, Mark, we've never been ones to turn down an offer of help, and since you already have a suggestion and all... we'd love for you to implement it. :)


On Jul 6, 2004, at 11:44 AM, Mark Montague wrote:

On Tue, 6 Jul 2004, johanna bromberg craig wrote:

hey all,

We've recently discovered a minor conflict between Cosign and MIT
Kerberos 1.3.4 (tho we think it starts at a minimum, at 1.3.1).
Basically, MIT Kerberos no longer includes a libkrb524, and all the
symbols we need are now in either libkrb5 or libkrb4.

So, unless anyone has a need to run a legacy version of Kerberos ( we
we're running 1.2.8, I think ), I'd rather simplify things and require
a current version.

Hi, Johanna,

I'd prefer to see cosign's configure script use "krb5-config --version"
to determine if libkrb524 needs to be added or not. If krb5-config
does not exist on the system, configure should assume that it's a
really old version of 1.2.x that's installed (krb5-config is included
with the most recent 1.2.x releases -- everything after 1.2.3 maybe?)
At the same time, I think cosign should use "krb5-config --cflags"
and "krb5-config --libs" to figure out what compiler and linker
flags to use instead of guessing itself. Note that if gssapi support
is being included, krb5-config will need to be invoked as
"krb5-config --libs gssapi", etc. -- "krb5-config --help" for more info.
Since this is my suggestion, I'm willing to implement it if you'd
like me to do so (let me know).

Note that Solaris 9 is still shipping with Kerberos 1.2.x; Sun won't
be upgrading to 1.3.x until Solaris 10 later this year. So if you
require Kerberos 1.3.x for cosign, then anyone using Solaris 9 or
previous will have to replace (or supplement) the vendor-supplied
libraries with ones which they download, compile, and install themselves.
This extra step might wind up discouraging some people who might otherwise
try cosign.

Also, I don't know that I'd call Kerberos 1.2.x "legacy", exactly:
The incremental-replication and other University of Michigan patches
for Kerberos were only fully ported and tested recently, and many
units at the University of Michigan are still running Kerberos 1.2.x
for this reason.  I don't know if the same thing applies at other
institutions or not.

                Mark Montague
                LS&A Information Technology


Copyright © 2002 - 2004 Regents of the University of Michigan :  Page last updated 15-December-2010