[ On Sunday, September 14, 2003 at 14:43:18 (-0400), Roland Dowdeswell wrote: ]
> Subject: Re: BSD auth for NetBSD 
>
> The rather obvious fact that my Kerberos 5 password did not actually
> let me log in via xdm(1) was the first clue that it didn't have
> support.  I tend to trust that a little more than reading the code.

Well, reading the right code might reveal to you that you've made a very
naive coice of trusting whomever built your binaries.

The point is that native support for kerberos (and s/key) will continue
to be found in major applications regardless of what NetBSD does, just
as it _is_ there today despite your attempt to claim otherwise.

Furthermore many people will suggest that the problem with kerberos
support on NetBSD is with the kerberos APIs offered by NetBSD, not the
choice of APIs made by the applications, and they may not be far from
the truth.

> Luckily, though, you'll actually find if you examine the code that
> it was written against an old beta version of MIT krb5 and does
> not actually build let alone work with anything recent.

So?  Are you not capable of fixing it?  All the pointers and hooks are
there and it's just a matter of updating the code to meet the API
offered by the in-tree implementation.  As you've hopefully already seen
there is a canonical example of how it should work in usr.bin/login.

> Perhaps the problem is that all the other projects get their Kerberos
> 5 support in xdm by using either PAM or BSD Auth and so there is
> little impetus for the XFree86 developers to add direct support
> for Kerberos 5.

Perhaps, but why are you looking for blame instead of just fixing the
code?  If someone offered good clean patches that produced working
functionality on at least one platform such as NetBSD then I'm sure
they'd stand a decent chance of being accepted and included in the base
Xfree86 release.

I don't use kerberos (currently) and so I have no impetus to work on
such patches, but presumably you do.

> All of the Kerberos 5 bits in the xdm in our source tree are in
> support of kerberised X connections

Sure, OK, whatever.  The fact remain s that there's some native support
for keberos in the greeter too and if someone were to update it to
support ther krb5 APIs offered natively by NetBSD then it would be there
for everyone.

> and defining the right bits to
> get it to build will turn on all manner of broken code in the rest
> of the tree (same old API issue.)

Again, why are you looking for blame instead of just fixing the code?

> The xdm/greeter/verify.c in our source tree does not support Kerberos 5,
> only Kerberos 4.  So that leaves it supporting only half of the auth
> methods that login(1) supports.

Well, fix it then!  You said xdm didn't have "kerberos" support.  I
showed that it does.  You say well, it's not "Kerberos 5".  I say you're
whining about nothing.  Xdm can, and should, be fixed to have native
krb5 support regardless of what NetBSD does in the "auth wars".  Free
code doesn't grow on trees though and so if you're a krb5 user capable
of fixing xdm then you should get right to it!

-- 
						Greg A. Woods

+1 416 218-0098                  VE3TCP            RoboHack <woods@robohack.ca>
Planix, Inc. <woods@planix.com>          Secrets of the Weird <woods@weird.com>