[ On Saturday, September 13, 2003 at 20:15:55 (-0400), Roland Dowdeswell wrote: ]
> Subject: Re: BSD auth for NetBSD 
>
> >> Two things: kerberos, s/key.
> >
> > Adding either PAM or BSD Auth doesn't really make supporting either of
> > these in third party code all that much easier.  Third party developers
> > still pretty much have to be prepared to use native OS support for these
> > two mechanisms regardless of whether they also support some more generic
> > framework such as PAM and/or BSD Auth.
> 
> What??  This is incorrect.

If you had actually read any of the code for any major third-party
applications (e.g. those found in pkgsrc) you would have seen that I am
in fact 100% correct.  You should go back and read that code before you
make further blatant mistakes like that.

>  If you actually use PAM (and probably
> BSD Auth)

Fortunately portable third party applications _cannot_ assume that PAM
is available (just as they cannot assume BSD Auth is available).  (And
yes, this is a very good thing since there's no POSIX API for making
authentication requests and checks.)

> Not for accepting passwords in cases such as xlock, xscreensaver,
> gdm, kdm, etc.

In fact if you look at those programs you'll find they many of them do
have direct support for each of crypt(), krb_verify_user(),
pam_authenticate(), auth_call(), etc.  (see xdm/greeter/verify.c, for
example, which supports everything but S/Key directly it seems).

Even CVS (for its stupid pserver protocol), includes such direct support
of at least Kerberos, as well as of course crypt().

Like I say above:  read some more code!

Even a grep for the obvious function names in the obvious places would
have verified what I said initially to have been correct.

> SASL is a different beast.

SASL as a protocol serves the same needs in a different environment.

However saslauthd does all of what I say above and will continue to do
so even if NetBSD joins either OpenBSD or FreeBSD in the "auth API wars".

-- 
						Greg A. Woods

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