Subject: Re: BSD auth for NetBSD
To: Bill Studenmund <wrstuden@netbsd.org>
From: Greg A. Woods <woods@weird.com>
List: tech-security
Date: 09/16/2003 04:03:02
[ On Tuesday, September 16, 2003 at 00:17:59 (-0700), Bill Studenmund wrote: ]
> Subject: Re: BSD auth for NetBSD 
>
> Uhm, read closer. 1) It does not solve the "no modules" desire of BSD
> Auth, but it keeps the list to one, which should be a rather
> easily-audited one.

So, NO, your proposal does _not_ solve _any_ of the of the problems that
BSD Auth solves.  It still violates _all_ of the goals of BSD Auth.

Using BSD Auth authenticators via a PAM module is a total sham and an
insult to everything BSD Auth stands for.  It will not ever fly.  Forget
it.

What I and others have suggested is a client API that would translate to
the alternate client API.  The whole point is to leave the back-end
frameworks untouched and intact.  The design of the client API is very
much secondary, at least to me and no doubt to anyone without a vested
interest in either API.  If you've actually examined both APIs closely
and looked at various real-world uses then you'll know already that
they're functionally almost identical (as one would expect given they
solve the very same problems from an application's perspective).

> And maybe if you actually listened to what people had to say, you'd hear
> how you are not correct in your above statements.

Nobody has addressed _any_ of the technical questions I or anyone else
has raised, let alone even begun to answer any of the questions related
to actual NetBSD userbase requirements.

I.e. there's been _nothing_ whatsoever to hear out in the first place.

You are still ignoring all the technical issues and are simply making a
political choice based on totally unjustified (and probably
unjustifiable) reasons.

> That's what we're suggesting. And the one wrapper API is PAM.

No, it's not what you're suggesting -- you are still ignoring the
fundamental benefits of the BSD Auth framework.

You have also totally failed to show any _technical_ justification for
the PAM API.  Where is your evaluation?  What qualities did you compare?
What existing real-world applications using each API did you compare and
what metrics did you use to compare them?

I'm not saying the PAM API is good or bad, but I'm not going to buy any
choice made without a fair assessment of the technical merits _ALONE_.

-- 
						Greg A. Woods

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