[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: kpasswd

At 05:50 AM 10/16/2003, Frank Swasey wrote:
>On Wed, 15 Oct 2003 at 3:49pm, Kurt D. Zeilenga wrote:
>> At 02:29 PM 10/15/2003, Paul M Fleming wrote:
>> >What specifically is broken? Do you have a list of ITSs?
>> Well, for starters, configure detection of Kerberos fails
>> because the tests select the inappropriate combination of
>> libraries.  Then, if you get pass that, the code often
>> won't compile.  Beyond that, I don't know as the claims
>> the code is otherwise broken have not been investigated.
>Funny.  RedHat has been compiling using --with-kerberos=k5only
>--enable-kpasswd and it doesn't have any trouble compiling.  It works.
>It solves a lot of problems.  Please enumerate the problems it causes.

For starters, ITS#2752 and ITS#2772.

>We've had this argument about the usefulness of {KERBEROS} password
>checking before.

Yes.  And as I noted in a previous post, the reason why the
configuration option was removed was due to the code not being
actively maintained.

>There has been NO discussion of this change anywhere.

There have been many discussions regarding whether {KERBEROS}
feature should remain or not.  The core team has repeated
said that the feature could remain as long as it maintained.

>Who made the decision to remove support for {KERBEROS}?

I did (as the 2.1 release engineer).

>> >We currently
>> >use this code but I believe the same functionality can also be achieved
>> >by using SASL/saslauthd and {SASL} or am I mistaken?
>> It's my understanding that you can get the same (mis)functionality
>> via {SASL}.
>How is it a misfunction? 

See the archives.

>How does one get this same functionality from
>SASL when the CLIENT application doesn't have SASL capabilities?
>Do I now have to go require all my application providers to support SASL?
>How does one get this functionality via SASL even if the client has SASL

Like {KERBEROS}, {SASL} does not require clients to have support
for SASL nor Kerberos.