lprng uses private Kerberos Functions?

Patrick Powell papowell at astart.com
Fri Feb 22 10:58:00 EST 2002


> From meeroh at MIT.EDU Wed Feb 20 05:50:59 2002
> Date: Wed, 20 Feb 2002 08:49:23 -0500
> To: Patrick Powell <papowell at astart.com>, hua-ying at usa.net, krbdev at MIT.EDU,
>    lprng at lprng.com
> From: Miro Jurisic <meeroh at MIT.EDU>
> Subject: Re: lprng uses private Kerberos Functions?
>
> >  > >I'm trying to compile LPRNG with Kerberos support for MacOS X but
> >  > >I'm getting an undefined symbols for _krb5_read_message
> >  > >_krb5_write_message _krb5_xfree _valid_cksumtype.  I have included
> >  > >the Kerberos5Core framework which seems to have these symbols
> >>  >defined.  This is the prototype found in the code, are they
> >>  >different from the version of Kerberos for the Mac?
> >
> >Try downloading the latest Kerberos release from MIT, install
> >it,  then use:
> >
> >./configure --with-ldopts="-L/usr/local/lib" \
> >   --with-cppopts="-I/usr/local/include" --enable-kerberos
>
> This is not a useful answer. It is not helpful to tell him to replace 
> a component with his own, because a. it will be blown away the next 
> time he upgrades the OS b. his users won't have the 'fixed' version 
> anyway c. your suggestion wouldn't even work correctly because you 
> would end up with /usr/lib binaries which work differently from 
> /System/Library/Frameworks binaries, which is a recipe for disaster.
>
> >  > krb5_read_message, krb5_write_message, krb5_xfree, valid_cksumtype
> >>  are private functions internal to the Kerberos 5 library.  As a
> >>  result, they are not exported by the Kerberos framework, and you
> >>  should not be calling them.  Yes, I realize that they are in the
> >>  krb5.h header file, but they shouldn't be.
> >
> >Ummm... have you heard of 'legacy software support?'
>
> Yes, we have. This is one of the cases in which we consciously 
> decided to break it. This API has been wrong to use for years, and 
> that didn't have any influence on whether people use it or not. Now 
> that we removed it, finally people are fixing their code. Since they 
> have to recompile for Mac OS X _anyway_, it was a reasonable point to 
> force them to fix their code in our opinion.

OK, this is reasonable.  Of course, you realize that this will
break compatibility with the OLDER versions of LPRng that use
these functions.  So,  I suggest you wander down the hall (at MIT)
and brace the folks there with the suggestion that they redeploy
all of the printing software currently in use.

Sigh...

I will make you a deal:

Send me a sample set of program with makefiles, etc. that
(Note the critical stuff):

Client:
 a) opens a connection to the Server
 b) does the authenication step  ** using KRB stuff **
 c) opens a 'send this' file for reading , and a 'got this' file for writing
 d) reads from the 'send this' file descriptor and copies 
    input to destionation. ** using KRB stuff **
    note: you may need to send the file length first so you can
    tell how many bytes that will be sent...
 e) reads from the connection,  copies input to
    the 'got this' file descriptor ** using KRB stuff **
    (same thing about length)
 f) sends a string "OK, all done, bye" to the Server ** using KRB stuff **
    (same thing about length)
 g) reads from the connection,  copies input to
    the 'got this' file descriptor ** using KRB stuff **
    (same thing about length)
 h) closes, etc. files, exits.

Server: Does the inverse
 a) opens a listening socket and 
 b) does the authenication step ** using KRB stuff **
 c) opens a 'send this' file for reading , and a 'got this' file for writing
 d) reads from the connection,  copies input to
    the 'got this' file descriptor
 e) reads from the 'send this' file descriptor and copies 
    input to destionation.
 f) reads from the connection,  copies input to
    the 'got this' file descriptor
 g) sends a string "OK, all done, bye" to the Client ** using KRB stuff **
 h) closes, etc.

I will massage the stuff into the next release.

>
> >The various kerberized utilities use them,  and I ripped the
> >code out of the kerberos utilities :-)
>
> That is what we recommend in general -- it is not the responsibility 
> of Kerberos libraries to provide you with network send and receive 
> code, but if you need an example of how to do it, you should feel 
> free to look at our code which does it. Sounds like that's exactly 
> what you are doing :-)
>
> hth
>
> meeroh
> -- 
>
> <http://web.meeroh.org/> | MIT I/S Mac developer | KB1FMP
>
> "Well, I must endure the presence of two or three caterpillars if I 
> wish to become acquainted with the butterflies." -- Antoine de 
> Saint-Exupery, "The Little Prince"
>



More information about the krbdev mailing list