[ On Sunday, September 14, 2003 at 20:53:40 (-0700), Bill Studenmund wrote: ]
> Subject: Re: BSD auth for NetBSD 
>
> I started to look at such a shim API, but have not gotten very far.

Any hints as to why not?

> It
> looks like just using PAM and having a BSD Auth using module ship in the
> base system would be the best way to go.

That doesn't solve _any_ of the problems BSD Auth solves nor does it
even provide the BSD Auth client API (which, IIUC, was Peter's minimum
requirement).  I.e. it's a slam in the face of everything BSD Auth
stands for.  It's also an unfair choice since it would seem to be
ignoring all the true technical merits and be based on perceived market
share alone.  What a sham, especially for an open source system that
purports to have only the highest of technical and quality standards.
I.e. you're going backwards here again Bill, not forwards.

The only really ideal solution is to provide both APIs as a shim for
each other's framework with something like nsswitch in between them so
that the administrator can choose which framework to use in production.
If you've encountered technical stumbling blocks in trying to implement
such an API then let's hear them (though perhaps in a new thread)!

An alternate solution is to evaluate each API fairly on its technical
merits _alone and choose the best one.  That one client API can then be
used as a wrapper around both frameworks.  It would seem adapting to the
client API is much easier for applications to do than it is to force
admins and third party vendors to compromise on which framework to
choose.  I don't mind using the technically best client API (I'm a
programmer too!), so long as I am also allowed to choose to use the
authentication framework I believe to be safer and more sound for my
uses, and so long as I can continue to build static-linked systems using
BSD Auth.  This means a bit more work for pkgsrc developers, but
hopefully only for the first porting effort (which can be done over time
since of course the existing crypt() and krb5 APIs remain) and from
there the original maintainers take back the patches.  I'm obviously
hedging my bets on which API is technically superior, but that's a risk
I'm willing to take.  (Especially since it would only be a matter of
time before the other API could be added to the shim as well. :-)

I suppose one final alternate solution could be chosen as well, and it's
not much different than we have now for certain things in the tree.  It
is to provide each framework and API as separate but fully supported OS
components, with #ifdefs (or even big runtime 'if' statements and some
common configuration attribute in something like login.conf) in each
base-OS program so that it can be compiled and/or configured to use
either client API and thus either framework.  This will force third
party applications to either do the same or to choose which to use (and
thus will force admins to choose either a specific set of add-on
applications).  I think this would keep everyone happy enough, though
it's obviously less ideal than a shim API.  Someone would either have to
flip a coin as to which was distributed in binaries, but then again with
our modern fast cross-compile systems maybe a set of binaries for each
could be offered.


Note that all of these choices are possible down the road if BSD Auth is
brought into the system first, now.

-- 
						Greg A. Woods

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