In message <20030909014800.GA6733@rek.tjls.com>, Thor Lancelot Simon writes:
>Your comments are extremely rude and entirely uncalled-for.  Soda-san
>has made many important contributions to NetBSD in his long tenure as
>a developer.  He is entitled to his opinion, which many of the NetBSD
>developers happen to share.

But he keeps saying BSD Auth can be implemented over PAM, and it's been
pointed out that this doesn't actually meet the obvious goal of "compile
programs which use BSD Auth".

I dunno.  For reasons unknown, his message which Nate quoted never showed
up here.  But I do think that, until *something* happens, we'll all be
stuck with "authentication is done by crypting strings and comparing them
to p->pw_passwd".

I think that BSD Auth solves a great number of the real-world problems
that people have brought up.  It doesn't solve all of them, but nothing
solves *all* of them.  If we migrate away from "use crypt(3)" towards
"here is where authentication code goes", then we're *closer* to being
able to use PAM than we are today.  If we check in Itojun's changes, then
we all get to start playing with authentication schemes today.

The things that, as I understand it, are missing that people have a specific
use for are:
1.  AFS token stashing.
2.  "template users".

I believe we could extend the BSD Auth protocol to support both of those
with an hour's programming.  Then people who are actually trying to do these
things would be able to do them *today*.

We've had this fight over and over.  We have working code.  We don't have
consensus on whether we want BSD Auth *or* PAM, and I doubt we ever will - but
I see no reason to object to adding one of them, with the understanding that
the other will probably be added too.  With the proposed implementation,
programs that don't want to know about or use BSD Auth don't have to, and
can simply ignore it.  Programs that do want it will be able to get it.
That's progress.

-s