tech-pkg archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: CVS commit: pkgsrc/net/bind98

Aleksej Saushev <> writes:

>   Hello,
> "Ignatios Souvatzis" <> writes:
>> Module Name: pkgsrc
>> Committed By:        is
>> Date:                Sun Dec  2 11:51:45 UTC 2012
>> Modified Files:
>>      pkgsrc/net/bind98:
>> 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

Attachment: pgppRRnS6yjFp.pgp
Description: PGP signature

Home | Main Index | Thread Index | Old Index