On 1045087881 seconds since the Beginning of the UNIX epoch
"Simon J. Gerraty" wrote:
>

>>	2.   ensure that the interface is ABI compatible with
>>	     LinuxPAM,
>
>Ok, here I get nervous.  One of the common themes from the ``PAM over my
>dead system camp'' has been the quality or lack thereof of Linux PAM.
>From the API perspective, how does LinuxPAM compare to BSD PAM 
>(as used by FreeBSD)?  I'm more familiar with that - since we 
>use it at work.  I've not looked at freebsd lately - but I 
>know Juniper contributed PAM code to freebsd and so support for 
>radius, tacplus, skey, ssh, opie and of course unix should all be there.

The APIs are almost identical.  Maintaining ABI compatibility is
just a matter of ensuring that we use the same error numbers and
whatnot, which should not be terribly difficult.

The big difference comes in the ABI because LinuxPAM and OpenPAM
use different numbers for errors and they are encoded in the headers.
So, basically, we get to choose only one of the two systems to have
ABI compatibility with and I think that it makes more sense to
choose LinuxPAM because it is more widely supported---and it is
the one of the two which is already in pkgsrc.

Keep in mind that this decision will only affect people who choose
to install a third party full PAM implementation on an existing
NetBSD box without rebuilding login(1), et al.  There will be
nothing to stop people from using OpenPAM if they are willing to
recompile the programs in basesrc which link against libpam.so.

--
    Roland Dowdeswell                      http://www.Imrryr.ORG/~elric/