Aleksej Saushev <asau%inbox.ru@localhost> writes: > Hello, > > "Ignatios Souvatzis" <is%netbsd.org@localhost> writes: > >> Module Name: pkgsrc >> Committed By: is >> Date: Sun Dec 2 11:51:45 UTC 2012 >> >> Modified Files: >> pkgsrc/net/bind98: options.mk >> >> Log Message: >> PKG_OPTIONize kerberos as 'kerberos'. From: Matthias Kretschmer via PR#45823 >> with a minor edit. >> N.B.: a minority of packages uses 'gssapi' as the option name. We should >> decide on one option name and fix all packages to use the same, with >> notification of the users and a transition mechanism. (Do we support, or >> intend to support, any GSSAPI mechanisms other than Kerberos? In parallel?) > > Bringing it on proper mailing list. > > I very much doubt that continuous use of GSSAPI is realistic for anything > besides Kerberos and NTLM, where it is used for historic reasons. > NTLM is declared obsolete by Microsoft itself (you can find such statement > in their documentation), and everyone is suggested to migrate to Kerberos. > In my opinion, it is safe to assume equivalence of GSSAPI to Kerberos. I am not sure if there is anything that supports GSSAPI bindings independent of a mechanism (similar to how PAM works). I'd say that if turning on the option causes a dependency on kerberos, then the option should be kerberos. If it causes a dependency on some gssapi package that acts like pam (and can be configured for providers), call it gssapi. The hard case if it follows some GSSAPI_TYPE mk.conf variable and depends on kerberos or something else depending on that variable. But I think that's theoretical and we needn't worry about it. So I think if in each case we're actually talking about kerberos, we should use that, and use a LEGACY option definition to map gssapi to kerberos.
Attachment:
pgppRRnS6yjFp.pgp
Description: PGP signature