[17310] in Kerberos_V5_Development
Re: Proposed Behavior change: don't fail when krb5_sname_to_principal
daemon@ATHENA.MIT.EDU (Sam Hartman)
Fri Oct 14 16:47:32 2011
From: Sam Hartman <hartmans@mit.edu>
To: Nico Williams <nico@cryptonector.com>
Date: Fri, 14 Oct 2011 16:47:28 -0400
In-Reply-To: <CAK3OfOgxWpHeEkCjzjTBmG6HOuE=ChwK+zXLS3vuwdPEB30FqA@mail.gmail.com>
(Nico Williams's message of "Fri, 14 Oct 2011 13:59:48 -0500")
Message-ID: <tsl8vonb8rj.fsf@mit.edu>
MIME-Version: 1.0
Cc: "krbdev@mit.edu" <krbdev@mit.edu>, Tom Yu <tlyu@mit.edu>
Content-Type: text/plain; charset="iso-8859-1"
Errors-To: krbdev-bounces@mit.edu
Content-Transfer-Encoding: 8bit
>>>>> "Nico" == Nico Williams <nico@cryptonector.com> writes:
Nico> On Fri, Oct 14, 2011 at 1:21 PM, Tom Yu <tlyu@mit.edu> wrote:
>> Greg Hudson <ghudson@MIT.EDU> writes:
>>> I'm not really opposed to this, although one could argue that
>>> host/foo.searchdomain is a better guess than host/foo in the
>>> absence of DNS (when foo contains no dots). But that
>>> assumes we can find out the search domain (which might be easier
>>> than we used to think, but we don't have a facility for it at
>>> the moment) and begs the question of what happens when there are
>>> multiple search domains.
Nico> Windows has an interface that allows you to find out what the
Nico> resolver's search list is. On Unix I assume that the BIND
Nico> resolver -or, in the worst case, reading resolv.conf directly-
Nico> will always be there.
I don't have a problem if someone proposes updating my patch with a
single search entry support. (It's possible to do multiple search
entries against a KDC with significantly more code restructuring.)
However it's sounding like people agree that the patch would be an
improvement and doesn't sound like it creates trouble for things we want
or might want in the future.
--Sam
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
