On 1063492353 seconds since the Beginning of the UNIX epoch
"Greg A. Woods" wrote:
>

>> 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 actually use PAM (and probably
BSD Auth), you will note that the modules (or programs) will properly
allow users to log in and obtain tickets.  You may be thinking
about making kerberized network connections, but that's not what
PAM or BSD Auth are trying to do anyway.

>We have both kerberos and s/key natively supported in the base OS and I
>was under the impression that all add-on packages in pkgsrc which needed
>to be aware of at least Kerberos already had the necessary hooks to make
>them aware of the native Kerberos libraries and utilities.

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

>I'm a little less sure about how well existing packages work with
>NetBSD's s/key support.  I haven't tried s/key with Cyrus SASL lately,
>for example, though I was hoping to get a chance to do exactly that very
>soon.  It should already work if I understand the "--enable-otp"

SASL is a different beast.

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