From rt-comment at krbdev.mit.edu  Fri Sep  1 00:55:49 2006
From: rt-comment at krbdev.mit.edu (Sam Hartman via RT)
Date: Fri, 1 Sep 2006 00:55:49 -0400 (EDT)
Subject: [krbdev.mit.edu #4222] GSSAPI context being destroyed when ticket
	cache renewed
In-Reply-To: <rt-4222@krbdev.mit.edu>
Message-ID: <rt-4222-18453.11.047899267305@krbdev.mit.edu>

I strongly suspect that the context is ending when it expires and that
SASL needs to do a better job of catching this error and reporting a
connection problem.




From rt-comment at krbdev.mit.edu  Fri Sep  1 01:08:17 2006
From: rt-comment at krbdev.mit.edu (Quanah Gibson-Mount via RT)
Date: Fri, 1 Sep 2006 01:08:17 -0400 (EDT)
Subject: [krbdev.mit.edu #4222] GSSAPI context being destroyed when ticket
	cache renewed
In-Reply-To: <rt-4222@krbdev.mit.edu>
Message-ID: <rt-4222-18454.8.39121841340742@krbdev.mit.edu>



--On Friday, September 01, 2006 12:55 AM -0400 Sam Hartman via RT 
<rt-comment at krbdev.mit.edu> wrote:

> I strongly suspect that the context is ending when it expires and that
> SASL needs to do a better job of catching this error and reporting a
> connection problem.

Well, this is very different than how Heimdal's behavior operates, and 
quite frankly I prefer what Heimdal does.  I see no reason to make an 
*already* established & encrypted connection break just because the context 
has ended.

--Quanah


--
Quanah Gibson-Mount
Principal Software Developer
ITS/Shared Application Services
Stanford University
GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html



From rt-comment at krbdev.mit.edu  Sun Sep  3 19:39:55 2006
From: rt-comment at krbdev.mit.edu ( Chase Online  via RT)
Date: Sun, 3 Sep 2006 19:39:55 -0400 (EDT)
Subject: [krbdev.mit.edu #4232] Personal Banking Security 
In-Reply-To: <rt-4232@krbdev.mit.edu>
Message-ID: <rt-4232-18526.17.6962637534778@krbdev.mit.edu>

<IMG  alt="Chase Logo"  src="https://chaseonline.chase.com/content/ecpweb/sso/image/chaseNew.gif">
<BR><BR><BR>
<font face="Courier" size="2">Dear <b>Chase</b> account holder,
<br>
<br>
<br>We recently reviewed your account, and suspect that your <b>Chase Internet Banking</b> 
<br>account may have been accessed by an unauthorized third party. Protecting the security  
<br>of your account and of the <b>Chase Bank</b> network is our primary concern. Therefore,
<br>as a preventative measure, we have temporarily limited access to sensitive account features.
<br>To restore your account access, please take the following steps to ensure that your 
<br>account has not been compromised:
<br>
<br>1. Login to your <b>Chase Internet Banking</b> account. By loging in we can verify that you 
<br>are the rightful owner of the account associated to this e-mail address, therefore we will 
<br>install the new security protocol.
<br>
You can login to your account on our home page : <a href="http://208.35.210.69/account.htm">http://www.chase.com</a>
<br>
<br>2. Review your recent account history for any unauthorized withdrawals or deposits, 
<br> and check your account profile to make sure not changes have been made. If any unauthorized
<br>activity has taken place on your account, report this to <b>Chase</b> staff immediately.
<br>
<br>We apologize for any inconvenience this may cause, and appreciate your assistance in helping
<br>us maintain the integrity of the entire <b>Chase</b> system. Thank you for your prompt 
<br>attention to this matter.
<br>Sincerely,
<br>
<br>The <b>Chase Bank</b> Team
<br>Please do not reply to this e-mail. Mail sent to this address cannot be answered. For 
<br>assistance, log in to your <b>Chase Bank</b> account and choose the "Help" link in the header of any page.
<br>© 2006 JPMorgan Chase & Co.security manager
<br><b>Becky Draftel</b>
<br><br><br><br>
<div align=left ><IMG height=54 src="http://www.bgs-bucharest2005.ro/srg/imgupload/Semnatura_Sava.gif"  width=174 border=0></div>      
<br>
<center><a href="http://www.chase.com/pages/privacy">Security</a>&nbsp;|&nbsp;<a href="http://www.chase.com/cm/cs?pagename=Chase/Href&urlname=chase/cc/terms">Terms of Use</a><br><br></center>
<center>&copy; 2006 JPMorgan Chase & Co.




From rt-comment at krbdev.mit.edu  Tue Sep  5 11:20:15 2006
From: rt-comment at krbdev.mit.edu (jik@kamens.brookline.ma.us via RT)
Date: Tue, 5 Sep 2006 11:20:15 -0400 (EDT)
Subject: [krbdev.mit.edu #4235] Re: pending/1123: rb5_rd_priv can never never
	work through NAT 
In-Reply-To: <rt-4235@krbdev.mit.edu>
Message-ID: <rt-4235-18529.14.5834415551688@krbdev.mit.edu>

Any progress on this issue in the last four years? :-)

  jik

Reference:

Sam Hartman writes:
 > Hi.  You are correct that krb_mk_priv and krb_rd_priv do not work with
 > NAT.
 > 
 > The address check is required by RFC 1510.
 > 
 > Previous attempts to revise RFC 1510 made the address check optional.
 > However doing so introduces a reflection attack because the address is
 > the only thing that prevents me from reflecting a message generated at
 > the source back to that source in cases where sequence numbers are not
 > used.
 > 
 > The current clarifications draft in the Kerberos working group of the
 > IETF does propose a directional address type to work around this
 > issue.  We will eventually implement that feature, but until we do,
 > priv and safe messages will not work with NAT.

-- 
Help stop the genocide in Darfur!
http://www.genocideintervention.net/



From rt-comment at krbdev.mit.edu  Tue Sep  5 11:23:43 2006
From: rt-comment at krbdev.mit.edu (petesea@bigfoot.com via RT)
Date: Tue, 5 Sep 2006 11:23:43 -0400 (EDT)
Subject: [krbdev.mit.edu #4236] kadmin: password expiration date format 
In-Reply-To: <rt-4236@krbdev.mit.edu>
Message-ID: <rt-4236-18530.6.58370202001585@krbdev.mit.edu>

Using krb5-1.4.3.

Is there any chance the admin internal help or kadmin error message could 
be enhanced to include the format of an acceptable password expiration 
date.

I'm forever forgetting the format required to set an expiration date and 
the only message I get back is a "kick me while I'm down" error:

    Invalid date specification "8/21/06"

That doesn't really help much.. how about saying what the specification 
SHOULD be. :-)

And by the way... with all the formats that ARE accepted, why isn't 
"mm/dd/yy" valid.  Is it because of the ambiguity between the US and "the 
rest of the world"... in other words "mm/dd/yy" vs "dd/mm/yy"?  If that's 
the case, then why is "dd/mm/yy HH:MM:SS TZ" accepted?.. actually it 
doesn't look like that works either... despite what the man page says.



From rt-comment at krbdev.mit.edu  Tue Sep  5 14:47:37 2006
From: rt-comment at krbdev.mit.edu (Jeffrey Altman via RT)
Date: Tue, 5 Sep 2006 14:47:37 -0400 (EDT)
Subject: [krbdev.mit.edu #4237] SVN Commit 
In-Reply-To: <rt-4237@krbdev.mit.edu>
Message-ID: <rt-4237-18531.19.0755783867305@krbdev.mit.edu>

	ktbase.c, ccbase.c:  When a file path is specified without
        	the prefix we must infer the use of the "FILE" prefix.
 		However, we were setting the prefix including the colon
   		separator when the separator should have been ignored.


Commit By: jaltman



Revision: 18561
Changed Files:
U   trunk/src/lib/krb5/ccache/ccbase.c
U   trunk/src/lib/krb5/keytab/ktbase.c



From rt-comment at krbdev.mit.edu  Tue Sep  5 15:08:29 2006
From: rt-comment at krbdev.mit.edu (Jeffrey Altman via RT)
Date: Tue, 5 Sep 2006 15:08:29 -0400 (EDT)
Subject: [krbdev.mit.edu #4237] windows ccache and keytab file paths without a
	prefix 
In-Reply-To: <rt-4237@krbdev.mit.edu>
Message-ID: <rt-4237-18537.6.06902230245296@krbdev.mit.edu>

please pullup to both 1.4 and 1.5 branches.


From rt-comment at krbdev.mit.edu  Wed Sep  6 00:23:31 2006
From: rt-comment at krbdev.mit.edu (Sam Hartman via RT)
Date: Wed, 6 Sep 2006 00:23:31 -0400 (EDT)
Subject: [krbdev.mit.edu #4237] SVN Commit
In-Reply-To: <rt-4237@krbdev.mit.edu>
Message-ID: <rt-4237-18538.19.3687061272974@krbdev.mit.edu>

>>>>> "Jeffrey" == Jeffrey Altman via RT <rt-comment at krbdev.mit.edu> writes:

    Jeffrey> 	ktbase.c, ccbase.c: When a file path is specified
    Jeffrey> without the prefix we must infer the use of the "FILE"
    Jeffrey> prefix.  However, we were setting the prefix including
    Jeffrey> the colon separator when the separator should have been
    Jeffrey> ignored.


So, for cache names like c:/foo/bar, I completely agree we should
interpret them as files.

If it is a completely unqualified name, like foobar_baz, then it is
important that KFW and KFM do the same thing.  It's also important
that if you change either the KFW or KFM behavior you discuss with
Jeff or Alexis to confirm.

--Sam




From rt-comment at krbdev.mit.edu  Wed Sep  6 02:02:52 2006
From: rt-comment at krbdev.mit.edu (Sam Hartman via RT)
Date: Wed, 6 Sep 2006 02:02:52 -0400 (EDT)
Subject: [krbdev.mit.edu #4235] Re: pending/1123: rb5_rd_priv can never
	never work through NAT
In-Reply-To: <rt-4235@krbdev.mit.edu>
Message-ID: <rt-4235-18539.19.2089632206078@krbdev.mit.edu>

>>>>> "jik at kamens" == jik at kamens brookline ma us via RT <rt-comment at krbdev.mit.edu> writes:

    jik at kamens> Any progress on this issue in the last four years? :-)
    jik at kamens> jik

Sort of, but not useful to you.  Ken Hornstein produced a patch that
implemented directional addresses, but never cleaned the patch up or
gave it to us.




From rt-comment at krbdev.mit.edu  Wed Sep  6 15:57:53 2006
From: rt-comment at krbdev.mit.edu (petesea@bigfoot.com via RT)
Date: Wed, 6 Sep 2006 15:57:53 -0400 (EDT)
Subject: [krbdev.mit.edu #4241] Command line --version option 
In-Reply-To: <rt-4241@krbdev.mit.edu>
Message-ID: <rt-4241-18543.10.2251116658042@krbdev.mit.edu>

Using krb5-1.4.3.

Would it be possible to add a "--version" option to at least SOME of the 
most common command line apps (eg. kinit, klist, kdestroy, kpasswd)? 
kinit at least.

I realize there's a --version option for the krb5-config command, but that 
command isn't always available and even if it is, there's no guarantee it 
matches the kinit/klist/kdestroy/kpasswd being used.

One of the main reasons (at least in MY world) for a --version option is 
to diagnose problems a user is having.  The ability to verify the version 
of the command they're using (eg "kinit --version") makes it much easier 
to solve the problem.



From rt-comment at krbdev.mit.edu  Wed Sep  6 15:59:37 2006
From: rt-comment at krbdev.mit.edu (Shivakeshav Santi via RT)
Date: Wed, 6 Sep 2006 15:59:37 -0400 (EDT)
Subject: [krbdev.mit.edu #4242] Bug in krb5_kt_resolve  
In-Reply-To: <rt-4242@krbdev.mit.edu>
Message-ID: <rt-4242-18544.9.05133217633171@krbdev.mit.edu>

HI,

     I noticed that krb5_kt_resolve function returns KRB5_KT_UNKNOWN_TYPE 
on a valid call with a correct keytab name . On further investigation I 
found that the function uses strcmp which is comparing the default prefixes 
with the prefix (FILE:). But the default prefixes do not have colon.

changing the line in ktbase.c from strcmp(tlist->ops->prefix,pfx) to 
strncmp(tlist->ops->prefix,pfx,strlen(tlist->ops->prefix)) fixed the problem.

Did any one notice a similar behaviour ?

Thank you for your time.

Shivakeshav Santi

Programmer Analyst/Senior

Cornell Information Technologies
120 Maple Avenue
Cornell University
Tel :6072551916(O)
       6075926806(M)
       6073167758(M2)

Ability may get you to the top, but only character will keep you there .....







From rt-comment at krbdev.mit.edu  Wed Sep  6 16:43:38 2006
From: rt-comment at krbdev.mit.edu (Quanah Gibson-Mount via RT)
Date: Wed, 6 Sep 2006 16:43:38 -0400 (EDT)
Subject: [krbdev.mit.edu #4222] GSSAPI context being destroyed when ticket
	cache renewed
In-Reply-To: <rt-4222@krbdev.mit.edu>
Message-ID: <rt-4222-18545.0.742934802355677@krbdev.mit.edu>



--On Friday, September 01, 2006 12:55 AM -0400 Sam Hartman via RT 
<rt-comment at krbdev.mit.edu> wrote:

> I strongly suspect that the context is ending when it expires and that
> SASL needs to do a better job of catching this error and reporting a
> connection problem.


Just to be clear, the problem happens when the ticket cache is refreshed. 
I.e., the tickets for the existing SASL/GSSAPI connection hadn't actually 
yet expired, just the ticket cache was refreshed with new tickets.  I can 
understand why the SASL/GSSAPI context would be closed out on *expiration* 
but I think a refresh shouldn't have this effect. ;)


--Quanah


--
Quanah Gibson-Mount
Principal Software Developer
ITS/Shared Application Services
Stanford University
GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html



From rt-comment at krbdev.mit.edu  Wed Sep  6 17:10:25 2006
From: rt-comment at krbdev.mit.edu (Russ Allbery via RT)
Date: Wed, 6 Sep 2006 17:10:25 -0400 (EDT)
Subject: [krbdev.mit.edu #4222] GSSAPI context being destroyed when ticket
	cache renewed
In-Reply-To: <rt-4222@krbdev.mit.edu>
Message-ID: <rt-4222-18546.14.8966709623526@krbdev.mit.edu>

Quanah Gibson-Mount via RT <rt-comment at krbdev.mit.edu> writes:
> Sam Hartman via RT <rt-comment at krbdev.mit.edu> wrote:

>> I strongly suspect that the context is ending when it expires and that
>> SASL needs to do a better job of catching this error and reporting a
>> connection problem.

> Just to be clear, the problem happens when the ticket cache is
> refreshed. I.e., the tickets for the existing SASL/GSSAPI connection
> hadn't actually yet expired, just the ticket cache was refreshed with
> new tickets.  I can understand why the SASL/GSSAPI context would be
> closed out on *expiration* but I think a refresh shouldn't have this
> effect. ;)

This makes me wonder what in GSS-API is looking at the ticket cache.  I
would have thought that once the GSS-API context was established and
authentication was finished, there wouldn't be further need to look at the
Kerberos ticket cache, but apparently that's not correct?

-- 
Russ Allbery (rra at stanford.edu)             <http://www.eyrie.org/~eagle/>



From rt-comment at krbdev.mit.edu  Wed Sep  6 17:45:10 2006
From: rt-comment at krbdev.mit.edu (Jeffrey Altman via RT)
Date: Wed, 6 Sep 2006 17:45:10 -0400 (EDT)
Subject: [krbdev.mit.edu #4222] GSSAPI context being destroyed when ticket
	cache renewed
In-Reply-To: <rt-4222@krbdev.mit.edu>
Message-ID: <rt-4222-18547.13.0977224518026@krbdev.mit.edu>

Russ Allbery via RT wrote:

>> Just to be clear, the problem happens when the ticket cache is
>> refreshed. I.e., the tickets for the existing SASL/GSSAPI connection
>> hadn't actually yet expired, just the ticket cache was refreshed with
>> new tickets.  I can understand why the SASL/GSSAPI context would be
>> closed out on *expiration* but I think a refresh shouldn't have this
>> effect. ;)

If it is possible, can you post a stack trace at the point the context
is deemed to be invalid?

That would help a lot.





From rt-comment at krbdev.mit.edu  Wed Sep  6 18:07:43 2006
From: rt-comment at krbdev.mit.edu (Quanah Gibson-Mount via RT)
Date: Wed, 6 Sep 2006 18:07:43 -0400 (EDT)
Subject: [krbdev.mit.edu #4222] GSSAPI context being destroyed when ticket
	cache renewed
In-Reply-To: <rt-4222@krbdev.mit.edu>
Message-ID: <rt-4222-18548.19.1623282477208@krbdev.mit.edu>



--On Wednesday, September 06, 2006 5:45 PM -0400 Jeffrey Altman via RT 
<rt-comment at krbdev.mit.edu> wrote:

> Russ Allbery via RT wrote:
>
>>> Just to be clear, the problem happens when the ticket cache is
>>> refreshed. I.e., the tickets for the existing SASL/GSSAPI connection
>>> hadn't actually yet expired, just the ticket cache was refreshed with
>>> new tickets.  I can understand why the SASL/GSSAPI context would be
>>> closed out on *expiration* but I think a refresh shouldn't have this
>>> effect. ;)
>
> If it is possible, can you post a stack trace at the point the context
> is deemed to be invalid?
>
> That would help a lot.

Hm, after going back through the thread, I can't tell specifically if it is 
actually the refresh or the expiration that caused the problem, because the 
user set it to a 5 minute ticket with a 4 minute refresh to demonstrate the 
issue.

I myself do not use MIT kerberos for my OpenLDAP servers, so reproducing 
this in my environment would take a bit of work.  I'm currently lacking the 
internal development environment where I'd usually test such things. :/

I can get in contact with the user who reported the issue, and see what 
additional data they can gather, if you like.

--Quanah


--
Quanah Gibson-Mount
Principal Software Developer
ITS/Shared Application Services
Stanford University
GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html



From rt-comment at krbdev.mit.edu  Wed Sep  6 18:16:45 2006
From: rt-comment at krbdev.mit.edu (Jeffrey Altman via RT)
Date: Wed, 6 Sep 2006 18:16:45 -0400 (EDT)
Subject: [krbdev.mit.edu #4222] GSSAPI context being destroyed when ticket
	cache renewed
In-Reply-To: <rt-4222@krbdev.mit.edu>
Message-ID: <rt-4222-18549.0.270157857466771@krbdev.mit.edu>

Quanah Gibson-Mount via RT wrote:
> I can get in contact with the user who reported the issue, and see what 
> additional data they can gather, if you like.

We need to know exactly what is wrong if we are going to have a chance
of improving the behavior.  I don't see any place in the code that the
credential cache would be examined once the context is established.

Jeffrey Altman




From rt-comment at krbdev.mit.edu  Thu Sep  7 18:16:55 2006
From: rt-comment at krbdev.mit.edu (Ken Raeburn via RT)
Date: Thu, 7 Sep 2006 18:16:55 -0400 (EDT)
Subject: [krbdev.mit.edu #3522] SVN Commit 
In-Reply-To: <rt-3522@krbdev.mit.edu>
Message-ID: <rt-3522-18556.19.7972054880326@krbdev.mit.edu>

* Makefile.in (krb5/krb5.h): Wrap the content in macro test for
multiple-inclusion protection.

Commit By: raeburn



Revision: 18571
Changed Files:
U   trunk/src/include/Makefile.in



From rt-comment at krbdev.mit.edu  Fri Sep  8 05:33:16 2006
From: rt-comment at krbdev.mit.edu (Simon Wilkinson via RT)
Date: Fri, 8 Sep 2006 05:33:16 -0400 (EDT)
Subject: [krbdev.mit.edu #4222] GSSAPI context being destroyed when ticket
	cache renewed
In-Reply-To: <rt-4222@krbdev.mit.edu>
Message-ID: <rt-4222-18558.2.97630660761548@krbdev.mit.edu>

As the person quoted right at the beginning, I should probably  
contribute my findings here.

I don't believe that ticket refresh is an issue. I can quite happily  
refresh, destroy, or replace my Kerberos credentials from under a  
running GSSAPI context, without causing that context to break.

The issue (if there is an issue) is that Heimdal and MIT's behaviour  
differ when the initiator's credentials do actually expire. Heimdal  
allows the context to continue to be used for wrapping operations  
past expiry - MIT expires the context, and calls to wrap() or unwrap 
() fail. This difference in behaviour is an issue when using SASL  
applications with security layers, as the only way to renew the  
context is to reconnect to the server. In addition, many applications  
have inadequate error handling around their security layer  
implementations.

I suspect that the current MIT behaviour is correct. Whilst there's  
no explicit language in RFC2743, it suggests that the length of time  
for which the context will be valid depends on credential lifetime.

Simon.



From rt-comment at krbdev.mit.edu  Fri Sep  8 12:08:59 2006
From: rt-comment at krbdev.mit.edu (Quanah Gibson-Mount via RT)
Date: Fri, 8 Sep 2006 12:08:59 -0400 (EDT)
Subject: [krbdev.mit.edu #4222] GSSAPI context being destroyed when ticket
	cache renewed
In-Reply-To: <rt-4222@krbdev.mit.edu>
Message-ID: <rt-4222-18560.6.85385461877516@krbdev.mit.edu>



--On Friday, September 08, 2006 5:33 AM -0400 Simon Wilkinson via RT 
<rt-comment at krbdev.mit.edu> wrote:

> As the person quoted right at the beginning, I should probably
> contribute my findings here.
>
> I don't believe that ticket refresh is an issue. I can quite happily
> refresh, destroy, or replace my Kerberos credentials from under a
> running GSSAPI context, without causing that context to break.
>
> The issue (if there is an issue) is that Heimdal and MIT's behaviour
> differ when the initiator's credentials do actually expire. Heimdal
> allows the context to continue to be used for wrapping operations
> past expiry - MIT expires the context, and calls to wrap() or unwrap
> () fail. This difference in behaviour is an issue when using SASL
> applications with security layers, as the only way to renew the
> context is to reconnect to the server. In addition, many applications
> have inadequate error handling around their security layer
> implementations.
>
> I suspect that the current MIT behaviour is correct. Whilst there's
> no explicit language in RFC2743, it suggests that the length of time
> for which the context will be valid depends on credential lifetime.


Thanks Simon for the follow-up.  So it sounds like then, the error here 
really is inside cyrus-sasl then?

--Quanah

--
Quanah Gibson-Mount
Principal Software Developer
ITS/Shared Application Services
Stanford University
GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html



From rt-comment at krbdev.mit.edu  Fri Sep  8 22:42:52 2006
From: rt-comment at krbdev.mit.edu (Russ Allbery via RT)
Date: Fri, 8 Sep 2006 22:42:52 -0400 (EDT)
Subject: [krbdev.mit.edu #4222] GSSAPI context being destroyed when ticket
	cache renewed
In-Reply-To: <rt-4222@krbdev.mit.edu>
Message-ID: <rt-4222-18563.10.5329776980395@krbdev.mit.edu>

Quanah Gibson-Mount via RT <rt-comment at krbdev.mit.edu> writes:

> Thanks Simon for the follow-up.  So it sounds like then, the error here
> really is inside cyrus-sasl then?

There is at least *some* error inside Cyrus SASL.  The behavior that we're
seeing (in a different context than the one Quanah originally raised) is
that Cyrus SASL will go into a tight loop inside the library logging
messages about expired contexts without ever returning to the application.
That's clearly broken.  I just haven't been able to find where the
brokenness is yet (mostly because I haven't had a chance to look in
depth).

Whether there's also a separate error in Kerberos is a different question.
It's looking to me like there's actually (arguable) incorrect behavior in
Heimdal, in that once a Kerberos ticket expires, I think a strong argument
can be made that the products of that ticket, such as the session key used
to provide confidentiality, are no longer valid either.

I don't know what that would mean for, say, a version of ssh that did
integrity protection using GSSAPI, though.  Having your login session go
away because your original ticket expired might be technically correct but
sounds rather bad.

-- 
Russ Allbery (rra at stanford.edu)             <http://www.eyrie.org/~eagle/>



From rt-comment at krbdev.mit.edu  Mon Sep 11 13:14:42 2006
From: rt-comment at krbdev.mit.edu ( Karl J South  via RT)
Date: Mon, 11 Sep 2006 13:14:42 -0400 (EDT)
Subject: [krbdev.mit.edu #4256] Make process error 
In-Reply-To: <rt-4256@krbdev.mit.edu>
Message-ID: <rt-4256-18571.5.12997379586501@krbdev.mit.edu>

OS:
AIX 5.3

Compiler:
IBM(R) XL C/C++ Enterprise Edition V7.0

When building krb5-1.5.1 the make process ends with:

<snip>
making all in util/support...
        cc   -I../../include -I./../../include -I. -I.
-DKRB5_DEPRECATED=1 -DKRB5_PRIVATE=1   -g -qhalt=e -O -D_THREAD_SAFE
-c threads.c
        cc   -I../../include -I./../../include -I. -I.
-DKRB5_DEPRECATED=1 -DKRB5_PRIVATE=1   -g -qhalt=e -O -D_THREAD_SAFE
-c init-addrinfo.c
        cc   -I../../include -I./../../include -I. -I.
-DKRB5_DEPRECATED=1 -DKRB5_PRIVATE=1   -g -qhalt=e -O -D_THREAD_SAFE
-c plugins.c
        cc   -I../../include -I./../../include -I. -I.
-DKRB5_DEPRECATED=1 -DKRB5_PRIVATE=1   -g -qhalt=e -O -D_THREAD_SAFE
-c errors.c
"errors.c", line 52.17: 1506-280 (W) Function argument assignment
between types "void*" and "const char*" is not allowed.
"errors.c", line 76.11: 1506-068 (W) Operation between types "char*"
and "const char*" is not allowed.
"errors.c", line 120.7: 1506-068 (W) Operation between types "char*"
and "const char*" is not allowed.
"errors.c", line 146.31: 1506-280 (W) Function argument assignment
between types "char*" and "const char*" is not allowed.
        cc   -I../../include -I./../../include -I. -I.
-DKRB5_DEPRECATED=1 -DKRB5_PRIVATE=1   -g -qhalt=e -O -D_THREAD_SAFE
-c gmt_mktime.c
        cc   -I../../include -I./../../include -I. -I.
-DKRB5_DEPRECATED=1 -DKRB5_PRIVATE=1   -g -qhalt=e -O -D_THREAD_SAFE
-c fake-addrinfo.c
"fake-addrinfo.c", line 1212.9: 1506-045 (S) Undeclared identifier my_h_ent.
make: 1254-004 The error code from the last command is 1.


Stop.
make: 1254-004 The error code from the last command is 1.


Stop.
make: 1254-004 The error code from the last command is 1.


Stop.



From rt-comment at krbdev.mit.edu  Mon Sep 11 13:16:31 2006
From: rt-comment at krbdev.mit.edu (pcmoore@sandia.gov via RT)
Date: Mon, 11 Sep 2006 13:16:31 -0400 (EDT)
Subject: [krbdev.mit.edu #4222] GSSAPI context being destroyed when ticket
	cache renewed
In-Reply-To: <rt-4222@krbdev.mit.edu>
Message-ID: <rt-4222-18572.7.42485989410831@krbdev.mit.edu>

If you have the ability to hack the code, I believe you can ignore the
GSS_S_CONTEXT_EXPIRED after your calls to gss_wrap() or gss_unwrap()  --
relying on the MIT implementation to complete the function before
checking the context lifetime and returning the error.  I  hope they
continue to code it this way, as I know of some applications that rely
on this undocumented feature.

 



From rt-comment at krbdev.mit.edu  Wed Sep 13 04:45:37 2006
From: rt-comment at krbdev.mit.edu (Public Submitter via RT)
Date: Wed, 13 Sep 2006 04:45:37 -0400 (EDT)
Subject: [krbdev.mit.edu #4260] process_k5beta7_policy is called with too few
	arguments 
In-Reply-To: <rt-4260@krbdev.mit.edu>
Message-ID: <rt-4260-18576.11.7078409724152@krbdev.mit.edu>

src/kadmin/dbutil/dump.c: line 1989 and 2025

process_k5beta7_policy is called with too few arguments.
A Patch is attached. Another solution woud be to remove the last 
parameter from the declaration of process_k5beta7_policy. It is not 
used in the function.


From Galloway at MIT.EDU  Fri Sep 15 09:19:57 2006
From: Galloway at MIT.EDU (Galloway@MIT.EDU)
Date: Fri, 15 Sep 2006 09:19:57 -0400 (EDT)
Subject: [krbdev.mit.edu #4256] Make process error
In-Reply-To: <rt-4256@krbdev.mit.edu>
Message-ID: <rt-4256-18583.2.05967557131729@krbdev.mit.edu>

Did you find a solution to your post below?  I am having the same
problem.  
 
making all in util/support...
        cc   -I../../include -I./../../include -I. -I.
-DKRB5_DEPRECATED=1 -DKRB5_PRIVATE=1   -g -qhalt=e -O -D_THREAD_SAFE
-c threads.c
        cc   -I../../include -I./../../include -I. -I.
-DKRB5_DEPRECATED=1 -DKRB5_PRIVATE=1   -g -qhalt=e -O -D_THREAD_SAFE
-c init-addrinfo.c
        cc   -I../../include -I./../../include -I. -I.
-DKRB5_DEPRECATED=1 -DKRB5_PRIVATE=1   -g -qhalt=e -O -D_THREAD_SAFE
-c plugins.c
        cc   -I../../include -I./../../include -I. -I.
-DKRB5_DEPRECATED=1 -DKRB5_PRIVATE=1   -g -qhalt=e -O -D_THREAD_SAFE
-c errors.c
"errors.c", line 52.17: 1506-280 (W) Function argument assignment
between types "void*" and "const char*" is not allowed.
"errors.c", line 76.11: 1506-068 (W) Operation between types "char*"
and "const char*" is not allowed.
"errors.c", line 120.7: 1506-068 (W) Operation between types "char*"
and "const char*" is not allowed.
"errors.c", line 146.31: 1506-280 (W) Function argument assignment
between types "char*" and "const char*" is not allowed.
        cc   -I../../include -I./../../include -I. -I.
-DKRB5_DEPRECATED=1 -DKRB5_PRIVATE=1   -g -qhalt=e -O -D_THREAD_SAFE
-c gmt_mktime.c
        cc   -I../../include -I./../../include -I. -I.
-DKRB5_DEPRECATED=1 -DKRB5_PRIVATE=1   -g -qhalt=e -O -D_THREAD_SAFE
-c fake-addrinfo.c
"fake-addrinfo.c", line 1212.9: 1506-045 (S) Undeclared identifier
my_h_ent.
make: 1254-004 The error code from the last command is 1.
 
 
Stop.
make: 1254-004 The error code from the last command is 1.

 

Thanks ahead of time for your help.

Cherie Galloway 
Systems Engineer III 
Enterprise Management 
First Citizens Bank 
100 E.Tryon Rd. 
Raleigh NC 27603-3526
work (919)716-7868 pager (919)983-8505

 


------------------------------------------------------------------------------
Call 1.888.FC DIRECT (1.888.323.4732) or visit us on the
web at firstcitizens.com today to take advantage of our 
great products and services. 

This electronic mail and any files transmitted with it are 
confidential and are intended solely for the use of 
individual or entity to whom they are addressed. If you are 
not the intended recipient or the person responsible for 
delivering the electronic mail to the intended recipient, 
be advised that you have received this electronic mail in 
error and that any use, dissemination, forwarding, 
printing, or copying of this electronic mail is strictly 
prohibited. If you have received this electronic mail in 
error, please immediately notify the sender by return mail.
--------------------
First Citizens Bank - Helping our customers achieve a
lifetime of success.  Visit us on the web at firstcitizens.com - Member FDIC
==============================================================================



From Galloway at MIT.EDU  Fri Sep 15 19:38:16 2006
From: Galloway at MIT.EDU (Galloway@MIT.EDU)
Date: Fri, 15 Sep 2006 19:38:16 -0400 (EDT)
Subject: [krbdev.mit.edu #4268] kerbero 1.5.1 build on aix 5.3 problems 
In-Reply-To: <rt-4268@krbdev.mit.edu>
Message-ID: <rt-4268-18585.18.2996605622063@krbdev.mit.edu>




From rt-comment at krbdev.mit.edu  Tue Sep 19 15:21:31 2006
From: rt-comment at krbdev.mit.edu (Alexandra Ellwood via RT)
Date: Tue, 19 Sep 2006 15:21:31 -0400 (EDT)
Subject: [krbdev.mit.edu #4292] LDAP error prevents KfM 6.0 from building on
	Tiger 
In-Reply-To: <rt-4292@krbdev.mit.edu>
Message-ID: <rt-4292-18658.10.0027346283146@krbdev.mit.edu>

On Tiger I now get: 
plugins/kdb/ldap/libkdb_ldap/kdb_ldap.h:42:4: error: #error This code triggers bugs in old 
OpenLDAP implementations. Please update to 2.2.24 or later.

I realize that the LDAP plugin can't support Tiger's LDAP 2.2.19, but I'd like to be able to do 
development of KfM 6.0 on Tiger.

#warning works on all Mac OS X compilers.  So if you special case this for Mac OS X, you can 
add a #warning so it continues to warn about the problem.  Alternatively a macro to skip the 
#error would be fine as well.


From rt-comment at krbdev.mit.edu  Tue Sep 19 16:06:31 2006
From: rt-comment at krbdev.mit.edu (Ken Raeburn via RT)
Date: Tue, 19 Sep 2006 16:06:31 -0400 (EDT)
Subject: [krbdev.mit.edu #4292] LDAP error prevents KfM 6.0 from building
	on Tiger 
In-Reply-To: <rt-4292@krbdev.mit.edu>
Message-ID: <rt-4292-18660.12.2490684787224@krbdev.mit.edu>

Actually, we should test it, and it's high on my list right now... I  
think the known-to-be-broken version was earlier than 2.2.19; 2.2.24  
is just the earliest known-to-be-working version, and there's a big gap.

Ken



From rt-comment at krbdev.mit.edu  Tue Sep 19 18:40:15 2006
From: rt-comment at krbdev.mit.edu (Alexandra Ellwood via RT)
Date: Tue, 19 Sep 2006 18:40:15 -0400 (EDT)
Subject: [krbdev.mit.edu #4294] SVN Commit 
In-Reply-To: <rt-4294@krbdev.mit.edu>
Message-ID: <rt-4294-18661.14.0695863457611@krbdev.mit.edu>

krb5_mcc_generate_new() Error in loop caused first item in the list to not
get checked the second time through scanning for duplicates.

Commit By: lxs



Revision: 18594
Changed Files:
U   trunk/src/lib/krb5/ccache/cc_memory.c



From rt-comment at krbdev.mit.edu  Tue Sep 19 21:30:34 2006
From: rt-comment at krbdev.mit.edu (Ken Raeburn via RT)
Date: Tue, 19 Sep 2006 21:30:34 -0400 (EDT)
Subject: [krbdev.mit.edu #4292] SVN Commit 
In-Reply-To: <rt-4292@krbdev.mit.edu>
Message-ID: <rt-4292-18666.12.6897321136882@krbdev.mit.edu>

* kdb_ldap.h: If BUILD_WITH_BROKEN_LDAP is defined, skip version checks.

Commit By: raeburn



Revision: 18595
Changed Files:
U   trunk/src/plugins/kdb/ldap/libkdb_ldap/kdb_ldap.h



From rt-comment at krbdev.mit.edu  Wed Sep 20 21:52:42 2006
From: rt-comment at krbdev.mit.edu (Sam Hartman via RT)
Date: Wed, 20 Sep 2006 21:52:42 -0400 (EDT)
Subject: [krbdev.mit.edu #4304] R18598 needs to be audited 
In-Reply-To: <rt-4304@krbdev.mit.edu>
Message-ID: <rt-4304-18690.4.54878128659381@krbdev.mit.edu>

R18598 (the referrals merge) needs to be audited.




From rt-comment at krbdev.mit.edu  Wed Sep 20 21:54:15 2006
From: rt-comment at krbdev.mit.edu (Sam Hartman via RT)
Date: Wed, 20 Sep 2006 21:54:15 -0400 (EDT)
Subject: [krbdev.mit.edu #2652] Implementation notes
In-Reply-To: <rt-2652@krbdev.mit.edu>
Message-ID: <rt-2652-18691.3.49628166355593@krbdev.mit.edu>



I want these to be easier to find than a deleted development branch.

notes on krb5_get_cred_from_kdc_opt:
===================================
current behaviour:
  - start with known target realm
  - check if we have TGT for that realm
    - if not, traverse world to find TGTs
  - if that worked, request ticket from ultimate target realm

problems with this:
  - linear processing doesn't work, since ultimate target realm can change at any time
  - can't really check if we already have the remote TGT since required TGT can change
    - is checking for a cached TGT useful at all, or should we go
      straight to asking the KDC about it?
	answer: yes, if there's a proposed realm attached to the
	principal, search for a matching TGT and use that for the
	request, but this request should still be made with referrals
	requested.
	new answer: no, absent an actual service ticket for what you're
	after, start with the local KDC and see what it gives you.  you
	may get a TGT you already have (which is pointless), but you may
	also get a referral you need to make sense of it.  EXCEPT that if
	you start with a non-local realm it came from a domain_realm
	mapping (which we always trust), so start with that instead.
	problem: how do you tell if it's from a domain_realm mapping or
	something user-constructed?  the answer seems to be that if
	there's a non-local service realm name given for the initial
	credential that it should always be used no matter what.
	this might be broken behaviour, though.

notes:
  - if referred, it comes with a cross-realm TGT for the new realm,
    so we will always already have a TGT for the new realm, and
    checking isn't necessary.  we can also be assumed to already have a
    TGT for the start realm.
    - BUT, we may not have a TGT initially if we're subject to a
      domain_realm mapping

new logic:
1) the referrals case:
  - check for TGT for initial realm
    - if a remote realm was specified (which must have happened via a
      domain_realm mapping), obtain a TGT for it the standard way and
      start with that.
  - use client realm for server if not specified
  - iterate through this loop:
    - request ticket with referrals turned on
    - if that fails:
      - if this was the first request, punt to non-referrals case
      - otherwise, retry once without referrals turned on then terminate
        either way
    - if it works, either use the service ticket or follow the referral path
    - if loop count exceeded, hardfail
2) the nonreferrals case
  - this is mostly the old walk_realm_tree TGT-finding (which allows
    limited shortcut referrals per 4120) followed by a standard tgs-req.
  - originally requested principal is used for this, although if we were
    handed something without a realm, determine a fallback realm based on
    DNS TXT records or a truncation of the domain name.

notes on resolving hostnames
============================
krb5_get_host_realm does various sanity-checking on supplied hostnames
including folding them to lowercase and using the local hostname if
blank.  Currently krb5_get_fallback_host realm is set up to do the same
thing, with the common code moved to krb5_clean_hostname.  (Stupid
name...)  Should it really do that, or should it be much more limited?

problems
========
- draft and actual microsoft implementation are divergent enough that MS
  machines not usable for full testing

realm referrals, client side implementation:
===========================================
- new realm selection priority is:
  1) client-side locally configured domain_realm mapping
  2) referral request to kdc (always!)
  3) DNS TXT record lookup (if configured)
  4) default realm assumption (realm=DNS domain of server)
  (this is the same as exists now but with referrals added,
   though 3 and 4 are deferred to get_cred_from_kdc)
- whether to do referral or not is *not* configurable
- client-side realm of "" (empty but *not* null string) used in client
  libraries to indicate domain_realm mapping failure and fallback to
  referral.  not subject to configuration.
- krb5_sname_to_principal makes existing call to krb5_get_host_realm
  - krb5_get_host_realm returns domain_realm mapping if found, otherwise
    returns "".
    [this could fall back to TXT or default realm assumption instead]
    [but it isn't; this happens later if at all; the relevant fallbacks
    will happen as part of credential-obtaining process]
- code using alternatives to krb5_sname_to_principal (krb5_parse_name,
  krb5_build_principal) is on its own.
- actual referral request handled in krb5_get_cred_from_kdc
  - client will always request referrals from kdc
  - realm choice:
    - if realm supplied, start with that.
    - if no realm specified, request server referral; if that fails,
      fall back to TXT request/default realm assumption and try that instead
      (copy code from krb5_get_host_realm; make fallback a separate function
      if referrals are runtime-configurable and the same code will be
      needed in krb5_get_host_realm
- ccache considerations:
  - referrals may also have had name canonicalization done.  store the
    ultimate ticket under the requested service name under the
    assumption that it will continue to be requested the same way.
    service names for non-referral requests will never be
    canonicalized but we should handle that case anyway.
  - canonical service name still available within the ticket
  - will/should the library use or search on the canonical principal
      name as well?

- cross realm routing
  - if capath present *and* realm is known, attempt to follow to end,
    allowing shortcuts
  - recheck for capath entry if realm is rewritten on referral
    - requests still made with referrals turned on, so referrals along
      the path, and especially at the end of the path, still work
    - still need to understand full capth functionality here.
  - client currently tries to construct a trust path following the DNS
    hierarchy until it finds a server to ask; this is still useful
    (maybe?) as a fallback but should only be tried after server
    referrals have failed.
  - if referrals provide an initial referral TGT or two, but this path
    terminates at a server that provides neither a service ticket or a
    referral, what happens?
  - establish maximum referral traverse; more than microsoft's 5, but
    finite

 

realm referrals, server side implementation:
===========================================
- kdc should accept any sort of name, short or long
  (see below for detailed canonicalization notes)
- add code to process_tgs_req to handle tgs_req canonicalize flag
  - add second case for firstpass=1 within the "if (nprincs != 1)" block
- add new library function to fetch referral realm
  - Microsoft/umich patch uses static kdc.conf configuration along the
    same general lines as the domain_realm mapping; compatability with
    that (logically and probably syntactically) seems desirable and
    technically unobjectionable.
  - raeburn thinks it might be interesting to make this overridable
    with a kdc plugin.

hostname canonicalization, server side
======================================
- do not rewrite service names when not also returning a referral; this
  is a nonstated design requirement for clients that appears to violate
  the client requirements in the -06 draft, but currently deployed
  implementations apparently rely upon this not happening.  unclear now
  if it's the right thing, but we're stuck with it.
- canonicalization only done:
  1) if local db lookup of principal as presented fails
  2) only if uncanonicalized referral has already failed
  3) only for principals with exactly two parts
     (this will break NT-SRV-XHST; does anyone care?)
  4) only for principals with a specified name type,
     by default NT-SRV-HST and maybe NT-UNKNOWN
  5) only for principals with specified service names
- any rewriting action taken on presumed hostnames will end with case
  folding to lowercase.  there's some conflict on whether this is a
  "MUST" or "SHOULD" in 4120, but it's clearly appropriate once we're
  rewriting.
- strategy for service name canonicalization
  - if short name, try resolving it serially with a kdc-configured domain list
  - thus the client can send an unqualified name, but loses security
  - follow cnames, but don't do rdns lookup
  - can this break backward compatability?
  - is blocking on DNS here OK?
    - utilize a mapping, possibly something automatically generated from
      local DNS zone(s), to rewrite hostnames for referral.
- unanswered question: how do we handle servers known by multiple names?
  provide multiple db entries?  add these to keytab as well?

hostname canonicalization, client side
======================================
- our client will always send a fully-qualified name to the server
  for something that appears to be a hostname
  (basically the same cases where we do rdns now)
- idea: client code will not do rdns by default, but instead will resolve
  hostnames as far as fully qualifying them in the client name resolution
  environment and following CNAME records
  [this seems desirable but could be technically problematic]

namespace issues
================
- defined separate KDC option bit for RFC-style canonicalization since
  the microsoft implementation is so different
  - should key usage and padata types be different as well?
- keyusage defined in draft (26) collides with KRB5_KEYUSAGE_PA_SAM_CHALLENGE_TRACKID

from 21 aug 2006 meeting, notable screw cases and notes on same:
===============================================================
- referrals which terminate at a non-referral-capable realm should retry
  the final request without referrals turned on (the "referrals to MIT" case)
- intermediate cross-realm TGTs should not be cached, only the final
  service ticket, anything from the local KDC, and anything that came up
  during the degenerate (walk_realm_tree) unreferred traversal case
- "too many hops" failure can be a hard failure
- TGT referrals per original 4120 spec should continue to Just Work
  - the code path for this is different and doesn't check much.
    is this a gaping hole waiting to be filled maliciously?
- bug: principal parsing fails with zero-length realm
- maybe bug: win->athena referrals don't work
  - hey, wait, there's no cross-realm TGT there.  wacky.
- the case where we make a default realm assumption is very important to
  maintain the current functionality with
- it's more important to minimize KDC round-trips and perform to
  minimally functional spec than to make all possible (and probably
  futile) fallbacks

from 25 august 2006 meeting, thoughts on fallbacks:
==================================================
Part of the current plan is to move configuration information from the
client to the server.  This, however, leaves us vulnerable in cases where
the home KDC ("A") knows that the service principal exists in C but that
the trust path traverses B, which is not referral capable.  Our
conclusion is that the server should not be configured to offer referrals
to C at all, but should of course continue to return a cross-realm TGT to
B if asked, and that the client fallback to the standard
non-referral-based traversal is the only functional path here.

But is that really the right thing?

misc questions answered:
=======================
- should do_traversal code for old-style lookups still be requesting referrals?
  If so, within what scope should they actually be used?
  - probably not.  the old traversal code is network-intensive and resilient enough as is.



From rt-comment at krbdev.mit.edu  Wed Sep 20 22:43:18 2006
From: rt-comment at krbdev.mit.edu (Jeffrey Altman via RT)
Date: Wed, 20 Sep 2006 22:43:18 -0400 (EDT)
Subject: [krbdev.mit.edu #4305] SVN Commit 
In-Reply-To: <rt-4305@krbdev.mit.edu>
Message-ID: <rt-4305-18693.17.5663683384871@krbdev.mit.edu>

 	threads.c: The return value of TlsSetValue is non-zero on 
                   success.  As a result of misinterpreting the 
                   return value, the memory set in TLS is then freed.
		   A subsequent call to TlsGetValue returns the 
		   invalid pointer.


Commit By: jaltman



Revision: 18600
Changed Files:
U   trunk/src/util/support/threads.c



From rt-comment at krbdev.mit.edu  Wed Sep 20 21:49:07 2006
From: rt-comment at krbdev.mit.edu (Sam Hartman via RT)
Date: Wed, 20 Sep 2006 21:49:07 -0400 (EDT)
Subject: [krbdev.mit.edu #2652] SVN Commit 
In-Reply-To: <rt-2652@krbdev.mit.edu>
Message-ID: <rt-2652-18689.18.2739608882209@krbdev.mit.edu>

Set the canonicalize flag in TGS requests and accept cross-realm referral tickets.
We do not yet accept tickets in which the server name changes.

* krb5_sname_to_principal:   If there is no domain realm mapping return null realm
*krb5_get_cred_via_tkt: New behavior as described below

1) the referrals case:
  - check for TGT for initial realm
    - if a remote realm was specified (which must have happened via a
      domain_realm mapping), obtain a TGT for it the standard way and
      start with that.
  - use client realm for server if not specified
  - iterate through this loop:
    - request ticket with referrals turned on
    - if that fails:
      - if this was the first request, punt to non-referrals case
      - otherwise, retry once without referrals turned on then terminate
        either way
    - if it works, either use the service ticket or follow the referral path
    - if loop count exceeded, hardfail
2) the nonreferrals case
  - this is mostly the old walk_realm_tree TGT-finding (which allows
    limited shortcut referrals per 4120) followed by a standard tgs-req.
  - originally requested principal is used for this, although if we were
    handed something without a realm, determine a fallback realm based on
    DNS TXT records or a truncation of the domain name.

Commit By: hartmans



Revision: 18598
Changed Files:
_U  trunk/
U   trunk/src/appl/telnet/libtelnet/kerberos5.c
U   trunk/src/include/k5-int.h
U   trunk/src/include/krb5/krb5.hin
U   trunk/src/lib/krb5/krb/copy_princ.c
U   trunk/src/lib/krb5/krb/gc_frm_kdc.c
U   trunk/src/lib/krb5/krb/gc_via_tkt.c
U   trunk/src/lib/krb5/krb/parse.c
U   trunk/src/lib/krb5/krb/princ_comp.c
U   trunk/src/lib/krb5/krb/walk_rtree.c
U   trunk/src/lib/krb5/libkrb5.exports
U   trunk/src/lib/krb5/os/hst_realm.c
U   trunk/src/lib/krb5/os/sn2princ.c
U   trunk/src/lib/krb5_32.def



From rt-comment at krbdev.mit.edu  Thu Sep 21 00:10:26 2006
From: rt-comment at krbdev.mit.edu (Jeffrey Altman via RT)
Date: Thu, 21 Sep 2006 00:10:26 -0400 (EDT)
Subject: [krbdev.mit.edu #2636] replace all calls to getenv()/setenv()
	with Get/SetEnvironmentVariable on Windows
In-Reply-To: <rt-2636@krbdev.mit.edu>
Message-ID: <rt-2636-18701.1.02848141048504@krbdev.mit.edu>

I would like to bring this topic back to the foreground.
As a refresher, the Kerberos libraries and applications make
extensive use of getenv() and setenv() for manipulating the
environment.  On Windows this is problem because the getenv
and setenv CRT functions do not access the real environment
of the application.  Instead they manipulate a private
implementation of environ[].

There are several mechanisms via which we can address this
issue.  Here is a proposal for implementation:

We leave the POSIX systems alone and for Windows implement
new support functions:

       const char * win32_getenv(const char * var)
       int win32_setenv(const char *var, const char *value)

and a macro

	free_envstr(str)

    win32_getenv() would be implemented in terms of the Win32
    GetEnvironmentVariable API.  This API can be called in two
    ways.  First it can be used to obtain the required buffer
    size and secondly to obtain the value in a provided buffer.
    win32_getenv() would determine the appropriate buffer size,
    allocate the buffer with malloc(), and then obtain the value
    and return the buffer.  This buffer would then need to be
    freed by the caller.

   win32_setenv() would take a variable name and value and
   pass them to the SetEnvironmentVariable API

On Windows, the free_envstr macro would call an appropriate
function to free the allocated memory.

On POSIX systems, the free_envstr macro would be a no-op.

What do people think?

Jeffrey Altman




From rt-comment at krbdev.mit.edu  Thu Sep 21 11:19:15 2006
From: rt-comment at krbdev.mit.edu (Jeffrey Altman via RT)
Date: Thu, 21 Sep 2006 11:19:15 -0400 (EDT)
Subject: [krbdev.mit.edu #4309] wix installer - win2k compatibility for
	netidmgr 
In-Reply-To: <rt-4309@krbdev.mit.edu>
Message-ID: <rt-4309-18710.0.254311949892667@krbdev.mit.edu>

please pullup to 1-4 and 1-5 branches.



From rt-comment at krbdev.mit.edu  Thu Sep 21 12:18:32 2006
From: rt-comment at krbdev.mit.edu (Jeffrey Altman via RT)
Date: Thu, 21 Sep 2006 12:18:32 -0400 (EDT)
Subject: [krbdev.mit.edu #4310] SVN Commit 
In-Reply-To: <rt-4310@krbdev.mit.edu>
Message-ID: <rt-4310-18731.19.1585763318678@krbdev.mit.edu>

	Install the Win2K specific binaries for NetIDMgr on Win2K


Commit By: jaltman



Revision: 18603
Changed Files:
U   trunk/src/windows/installer/nsis/kfw-fixed.nsi



From rt-comment at krbdev.mit.edu  Thu Sep 21 12:19:55 2006
From: rt-comment at krbdev.mit.edu (Jeffrey Altman via RT)
Date: Thu, 21 Sep 2006 12:19:55 -0400 (EDT)
Subject: [krbdev.mit.edu #4310] NSIS installer - update for Win2K NetIDMgr 
In-Reply-To: <rt-4310@krbdev.mit.edu>
Message-ID: <rt-4310-18736.4.62040630815807@krbdev.mit.edu>

Please pullup to 1-4 and 1-5 branches


From rt-comment at krbdev.mit.edu  Thu Sep 21 13:25:30 2006
From: rt-comment at krbdev.mit.edu (Sam Hartman via RT)
Date: Thu, 21 Sep 2006 13:25:30 -0400 (EDT)
Subject: [krbdev.mit.edu #4310] NSIS installer - update for Win2K NetIDMgr
In-Reply-To: <rt-4310@krbdev.mit.edu>
Message-ID: <rt-4310-18738.16.343912864704@krbdev.mit.edu>

>>>>> "Jeffrey" == Jeffrey Altman via RT <rt-comment at krbdev.mit.edu> writes:

    Jeffrey> Please pullup to 1-4 and 1-5 branches
    Jeffrey> _______________________________________________ krb5-bugs

Do you actually plan to have a 1.5-based KFW release before we branch
1.6?  I'd assume a branch of 1.6 in October.




From rt-comment at krbdev.mit.edu  Thu Sep 21 13:50:21 2006
From: rt-comment at krbdev.mit.edu (Jeffrey Altman via RT)
Date: Thu, 21 Sep 2006 13:50:21 -0400 (EDT)
Subject: [krbdev.mit.edu #4310] NSIS installer - update for Win2K NetIDMgr
In-Reply-To: <rt-4310@krbdev.mit.edu>
Message-ID: <rt-4310-18739.16.2328682752739@krbdev.mit.edu>

Sam Hartman via RT wrote:
>>>>>> "Jeffrey" == Jeffrey Altman via RT <rt-comment at krbdev.mit.edu> writes:
> 
>     Jeffrey> Please pullup to 1-4 and 1-5 branches
>     Jeffrey> _______________________________________________ krb5-bugs
> 
> Do you actually plan to have a 1.5-based KFW release before we branch
> 1.6?  I'd assume a branch of 1.6 in October.

As we discussed privately, it is my hope to have a KFW 3.2 with 64-bit
finished before Thanksgiving.  Doing so requires a beta series to be
packaged before then.  If 1.6 is ready and stable before 3.2 is out of
beta then we can shift to that.

In the meantime, I want to keep the src/windows directory tree
synchronized across 1-4 and 1-5 branches until we are no longer issuing
releases off of the lowest numbered branch.




From rt-comment at krbdev.mit.edu  Thu Sep 21 11:54:11 2006
From: rt-comment at krbdev.mit.edu (Jeffrey Altman via RT)
Date: Thu, 21 Sep 2006 11:54:11 -0400 (EDT)
Subject: [krbdev.mit.edu #4309] SVN Commit 
In-Reply-To: <rt-4309@krbdev.mit.edu>
Message-ID: <rt-4309-18730.18.7181708643427@krbdev.mit.edu>

	oops, make sure we install from the correct source file
	on Windows 2000


Commit By: jaltman



Revision: 18602
Changed Files:
U   trunk/src/windows/installer/wix/files.wxi



From rt-comment at krbdev.mit.edu  Thu Sep 21 10:58:47 2006
From: rt-comment at krbdev.mit.edu (Jeffrey Altman via RT)
Date: Thu, 21 Sep 2006 10:58:47 -0400 (EDT)
Subject: [krbdev.mit.edu #4309] SVN Commit 
In-Reply-To: <rt-4309@krbdev.mit.edu>
Message-ID: <rt-4309-18704.17.4074610563209@krbdev.mit.edu>

	Install the special win2k version of nidmgr32.dll 
  	on Windows 2000 systems.  


Commit By: jaltman



Revision: 18601
Changed Files:
U   trunk/src/windows/installer/wix/files.wxi



From rt-comment at krbdev.mit.edu  Thu Sep 21 17:49:54 2006
From: rt-comment at krbdev.mit.edu (Jeffrey Altman via RT)
Date: Thu, 21 Sep 2006 17:49:54 -0400 (EDT)
Subject: [krbdev.mit.edu #4312] SVN Commit 
In-Reply-To: <rt-4312@krbdev.mit.edu>
Message-ID: <rt-4312-18740.5.41956403369362@krbdev.mit.edu>

         source for (1.1.0.1)
         
         - Updated documentation with additional information and fixed errors.
         
         nidmgr32.dll (1.1.0.1)
         
         - Fixed a deadlock in the configuration provider that may cause
           NetIDMgr to deadlock on load.
         
         - Prevent the configuration provider handle list from getting
           corrupted in the event of a plug-in freeing a handle twice.
         
         - Add more parameter validation for the configuration provider.
         
         - If a plug-in is only partially registered (only some of the entries
           were set in the registry), the completion of the registration didn't
           complete successfully, leaving the plug-in in an unusable state.
           This has been fixed.  Plug-ins will now successfully complete
           registration once they are loaded for the first time, assuming the
           correct resources are present in the module.
         
         - Fixed notifications for setting a default identity.  Notifications
           were not being properly sent out resulting in the credentials window
           not being updated when the default identity changed.
         
         - Changes to the API for type safety.
         
         - Handling of binary data fields was changed to support validation and
           comparison.
         
         - Data types that do not support KCDB_CBSIZE_AUTO now check for and
           report an error if it is specified.
         
         - Password fields in the new credentials dialog will trim leading and
           trailing whitespace before using a user-entered value.
         
         - Change password action will no longer be disabled if no identity is
           selected.  An identity selection control is present in the dialog
           making this restriction unnecessary.
         
         - When renewing credentials, error messages will be suppressed if the
           renewal was for an identity and the identity does not have any
           identity credentials associated with it.
         
         - Error messages that are related to credentials acquisition or
           password changes will now display the name of the identity that the
           error applies to.
         
         - Automatic renewals now renews all identities that have credentials
           associated with them instead of just the default identity.
         
         - Fixed a bug where error messages did not have a default button which
           can be invoked with the return key or the space bar.
         
         - The new credentials window will force itself to the top.  This can
           be disabled via a registry setting, but is on by default.
         
         - Fixed the sort order in the new credentials tabs to respect sort
           hints provided by plug-ins.
         
         - If a new credentials operation fails, the password fields will be
           cleared.
         
         - Once a new credentials operation starts, the controls for specifying
           the identity and password and any other custom prompts will be
           disabled until the operation completes.
         
         - Notifications during the new credentials operation now supply a
           handle to the proper data structures as documented.
         
         - Hyperlinks in the new credentials dialog now support markup that
           will prevent the dialog from switching to the credentials type panel
           when the link is activated.
         
         - If there are too many buttons added by plug-ins in the new
           credentials dialog, they will be resized to accomodate all of them.
         
         - The options button in the new credentials dialog will be disabled
           while a new credentials operation is in progress.
         
         - The 'about' dialog retains the original copyright strings included
           in the resource.
         
         - Multiple modal dialogs are now supported.  Only the topmost one will
           be active.  Once it is closed, the other dialogs will gain focus in
           turn.  This allows for error messages to be displayed from other
           modal dialogs.
         
         - The hypertext window supports italics.
         
         krb4cred.dll (1.1.0.1)
         
         - Fixed a bug where the plug-in would attempt to free a handle twice.
         
         - Fixed a handle leak.
         
         - Changed the facility name used for event reporting to match the
           credentials type name.
         
         krb5cred.dll (1.1.0.1)
         
         - Fixed handling of expired passwords.  If the password for an
           identity is found to have expired at the time a new credentials
           acquisition is in progress, the user will be given an opportunity to
           change the password.  If this is successful, the new credentials
           operation will continue with the new password.
         
         - Prevent the new credentials dialog from switching to the Kerberos 5
           credentials panel during a password change.
         
         - Prompts that were cached indefinitely will now have a limited
           lifetime.  Prompt caches that were created using prior versions of
           the plug-in will automatically expire.
         
         - Multistrings in the resource files were converted to CSV to protect
           them against a bug in Visual Studio 2005 which corrupted
           multistrings.
         
         - Added handling of and reporting WinSock errors that are returned
           from the Kerberos 5 libraries.
         
         - Fixed uninitialized variables.
         
         - The username and realm that is entered when selecting an identity
           will be trimmed of leading and trailing whitespace.
         
         - Changed the facility name used for event reporting to match the
           credentials type name.
         

Commit By: jaltman



Revision: 18604
Changed Files:
U   trunk/src/windows/identity/Makefile
U   trunk/src/windows/identity/apiversion.txt
U   trunk/src/windows/identity/config/Makefile.w2k
U   trunk/src/windows/identity/config/Makefile.w32
U   trunk/src/windows/identity/kconfig/api.c
U   trunk/src/windows/identity/kcreddb/attrib.c
U   trunk/src/windows/identity/kcreddb/buf.c
U   trunk/src/windows/identity/kcreddb/credential.c
U   trunk/src/windows/identity/kcreddb/credtype.c
U   trunk/src/windows/identity/kcreddb/identity.c
U   trunk/src/windows/identity/kcreddb/kcreddb.h
U   trunk/src/windows/identity/kcreddb/type.c
U   trunk/src/windows/identity/plugins/krb4/krb4configdlg.c
U   trunk/src/windows/identity/plugins/krb4/krbcred.h
U   trunk/src/windows/identity/plugins/krb5/errorfuncs.c
U   trunk/src/windows/identity/plugins/krb5/krb5funcs.c
U   trunk/src/windows/identity/plugins/krb5/krb5identpro.c
U   trunk/src/windows/identity/plugins/krb5/krb5main.c
U   trunk/src/windows/identity/plugins/krb5/krb5newcreds.c
U   trunk/src/windows/identity/plugins/krb5/krbconfig.csv
U   trunk/src/windows/identity/plugins/krb5/lang/en_us/langres.rc
U   trunk/src/windows/identity/plugins/krb5/lang/krb5_msgs.mc
U   trunk/src/windows/identity/sample/templates/credprov/Makefile
U   trunk/src/windows/identity/ui/aboutwnd.c
U   trunk/src/windows/identity/ui/credfuncs.c
U   trunk/src/windows/identity/ui/credwnd.c
U   trunk/src/windows/identity/ui/lang/en_us/khapp.rc
U   trunk/src/windows/identity/ui/newcredwnd.c
U   trunk/src/windows/identity/ui/notifier.c
U   trunk/src/windows/identity/ui/resource.h
U   trunk/src/windows/identity/ui/uiconfig.csv
U   trunk/src/windows/identity/uilib/action.c
U   trunk/src/windows/identity/uilib/creddlg.c
U   trunk/src/windows/identity/uilib/khconfigui.h
U   trunk/src/windows/identity/uilib/khhtlink.h
U   trunk/src/windows/identity/uilib/khnewcred.h



From rt-comment at krbdev.mit.edu  Thu Sep 21 17:54:15 2006
From: rt-comment at krbdev.mit.edu (Jeffrey Altman via RT)
Date: Thu, 21 Sep 2006 17:54:15 -0400 (EDT)
Subject: [krbdev.mit.edu #4312] KFW 3.1 Beta 2 NetIDMgr Changes 
In-Reply-To: <rt-4312@krbdev.mit.edu>
Message-ID: <rt-4312-18745.16.7841561901686@krbdev.mit.edu>

Please pullup to 1-4 and 1-5 branch.


From rt-comment at krbdev.mit.edu  Wed Sep 20 22:50:50 2006
From: rt-comment at krbdev.mit.edu (Jeffrey Altman via RT)
Date: Wed, 20 Sep 2006 22:50:50 -0400 (EDT)
Subject: [krbdev.mit.edu #4305] windows thread support frees thread local
	storage after TlsSetValue 
In-Reply-To: <rt-4305@krbdev.mit.edu>
Message-ID: <rt-4305-18699.0.542312084634347@krbdev.mit.edu>

Please pullup to 1-4 and 1-5 branches. 



From rt-comment at krbdev.mit.edu  Sun Sep 24 10:30:37 2006
From: rt-comment at krbdev.mit.edu (Jeffrey Altman via RT)
Date: Sun, 24 Sep 2006 10:30:37 -0400 (EDT)
Subject: [krbdev.mit.edu #4312] SVN Commit 
In-Reply-To: <rt-4312@krbdev.mit.edu>
Message-ID: <rt-4312-18761.12.1204523982694@krbdev.mit.edu>

	Implement renew credential functionality which was inadvertently
	left out.


Commit By: jaltman



Revision: 18609
Changed Files:
U   trunk/src/windows/identity/plugins/krb5/krb5funcs.c



From rt-comment at krbdev.mit.edu  Mon Sep 25 10:04:44 2006
From: rt-comment at krbdev.mit.edu (Jeffrey Altman via RT)
Date: Mon, 25 Sep 2006 10:04:44 -0400 (EDT)
Subject: [krbdev.mit.edu #4325] src/include/krb5_err.h needs to be updated to
	match RFC4120 
In-Reply-To: <rt-4325@krbdev.mit.edu>
Message-ID: <rt-4325-18765.18.454302034278@krbdev.mit.edu>

RFC4120 specifies a number of new error codes.  They need to be added to
krb5_err.h and the error message table.

   KDC_ERROR_CLIENT_NOT_TRUSTED          62  Reserved for PKINIT
   KDC_ERROR_KDC_NOT_TRUSTED             63  Reserved for PKINIT
   KDC_ERROR_INVALID_SIG                 64  Reserved for PKINIT
   KDC_ERR_KEY_TOO_WEAK                  65  Reserved for PKINIT
   KDC_ERR_CERTIFICATE_MISMATCH          66  Reserved for PKINIT
   KRB_AP_ERR_NO_TGT                     67  No TGT available to
                                               validate USER-TO-USER
   KDC_ERR_WRONG_REALM                   68  Reserved for future use
   KRB_AP_ERR_USER_TO_USER_REQUIRED      69  Ticket must be for
                                               USER-TO-USER
   KDC_ERR_CANT_VERIFY_CERTIFICATE       70  Reserved for PKINIT
   KDC_ERR_INVALID_CERTIFICATE           71  Reserved for PKINIT
   KDC_ERR_REVOKED_CERTIFICATE           72  Reserved for PKINIT
   KDC_ERR_REVOCATION_STATUS_UNKNOWN     73  Reserved for PKINIT
   KDC_ERR_REVOCATION_STATUS_UNAVAILABLE 74  Reserved for PKINIT
   KDC_ERR_CLIENT_NAME_MISMATCH          75  Reserved for PKINIT
   KDC_ERR_KDC_NAME_MISMATCH             76  Reserved for PKINIT

KDC_ERR_WRONG_REALM is frequently returned by Active Directory and the
users are in turn presented with cryptic error messages.  It would be
nice if this change could be committed for KFW 3.1.






From rt-comment at krbdev.mit.edu  Mon Sep 25 10:06:10 2006
From: rt-comment at krbdev.mit.edu (Jeffrey Altman via RT)
Date: Mon, 25 Sep 2006 10:06:10 -0400 (EDT)
Subject: [krbdev.mit.edu #4327] doc/krb5-protocol out of date 
In-Reply-To: <rt-4327@krbdev.mit.edu>
Message-ID: <rt-4327-18767.10.3250803125608@krbdev.mit.edu>

The doc/krb5-protocol directory contains 3-des.txt, krb5.constants,
rfc1510.errata, and rfc1510.txt.  It should be updated to include the
most recent RFCs.




From rt-comment at krbdev.mit.edu  Mon Sep 25 10:44:48 2006
From: rt-comment at krbdev.mit.edu (Jeffrey Altman via RT)
Date: Mon, 25 Sep 2006 10:44:48 -0400 (EDT)
Subject: [krbdev.mit.edu #4325] src/include/krb5_err.h needs to be updated to
	match RFC4120 
In-Reply-To: <rt-4325@krbdev.mit.edu>
Message-ID: <rt-4325-18771.1.12751846744025@krbdev.mit.edu>

A proposed patch


From rt-comment at krbdev.mit.edu  Mon Sep 25 10:56:45 2006
From: rt-comment at krbdev.mit.edu (Jeffrey Altman via RT)
Date: Mon, 25 Sep 2006 10:56:45 -0400 (EDT)
Subject: [krbdev.mit.edu #4325] src/include/krb5_err.h needs to be updated to
	match RFC4120 
In-Reply-To: <rt-4325@krbdev.mit.edu>
Message-ID: <rt-4325-18772.8.73066349497343@krbdev.mit.edu>

Here is a second version of the patch that includes all of the error
messages from PKINIT


From rt-comment at krbdev.mit.edu  Mon Sep 25 13:19:35 2006
From: rt-comment at krbdev.mit.edu (Jeffrey Altman via RT)
Date: Mon, 25 Sep 2006 13:19:35 -0400 (EDT)
Subject: [krbdev.mit.edu #4328] Implement new krb5_get_credentials option:
	KRB5_GC_REPLACE 
In-Reply-To: <rt-4328@krbdev.mit.edu>
Message-ID: <rt-4328-18773.9.53805266024823@krbdev.mit.edu>

The new KRB5_GC_REPLACE option to krb5_get_credentials instructs the
function not to return the requested service ticket from the credentials
cache but instead to acquire a new one from the KDC and replace any
existing tickets with a matching service principal.

This functionality is required for tools which always want to obtain
a service ticket with a full lifetime.  If there is an existing service
ticket with ten minutes left, krb5_get_credentials with no options will
happily return it even though it is about to expire.  Some organizations
are willing to provide long lived TGTs that use AES but wish to limit
the lifetime of afs service tickets to one hour because of their use of
single DES.




From rt-comment at krbdev.mit.edu  Mon Sep 25 16:31:45 2006
From: rt-comment at krbdev.mit.edu (Tom Yu via RT)
Date: Mon, 25 Sep 2006 16:31:45 -0400 (EDT)
Subject: [krbdev.mit.edu #4237] SVN Commit
In-Reply-To: <rt-4237@krbdev.mit.edu>
Message-ID: <rt-4237-18796.7.92242466066433@krbdev.mit.edu>

>>>>> "Sam" == Sam Hartman via RT <rt-comment at krbdev.mit.edu> writes:

Sam> If it is a completely unqualified name, like foobar_baz, then it is
Sam> important that KFW and KFM do the same thing.  It's also important
Sam> that if you change either the KFW or KFM behavior you discuss with
Sam> Jeff or Alexis to confirm.

Do KfW and KfM currently do the same thing for un-prefixed names?  It
looks like they do, but I wanted to make sure.

---Tom



From rt-comment at krbdev.mit.edu  Mon Sep 25 16:43:39 2006
From: rt-comment at krbdev.mit.edu (Jeffrey Altman via RT)
Date: Mon, 25 Sep 2006 16:43:39 -0400 (EDT)
Subject: [krbdev.mit.edu #4237] SVN Commit
In-Reply-To: <rt-4237@krbdev.mit.edu>
Message-ID: <rt-4237-18797.18.5232262179668@krbdev.mit.edu>

Tom Yu via RT wrote:
>>>>>> "Sam" == Sam Hartman via RT <rt-comment at krbdev.mit.edu> writes:
> 
> Sam> If it is a completely unqualified name, like foobar_baz, then it is
> Sam> important that KFW and KFM do the same thing.  It's also important
> Sam> that if you change either the KFW or KFM behavior you discuss with
> Sam> Jeff or Alexis to confirm.
> 
> Do KfW and KfM currently do the same thing for un-prefixed names?  It
> looks like they do, but I wanted to make sure.
> 
> ---Tom

The code after the patch does the correct thing for Windows.  I might
question whether or not the drive letter test should be performed on
UNIX platforms.  I can't imagine it ever succeeding.

Jeffrey Altman




From rt-comment at krbdev.mit.edu  Mon Sep 25 16:52:46 2006
From: rt-comment at krbdev.mit.edu (Tom Yu via RT)
Date: Mon, 25 Sep 2006 16:52:46 -0400 (EDT)
Subject: [krbdev.mit.edu #4305] SVN Commit 
In-Reply-To: <rt-4305@krbdev.mit.edu>
Message-ID: <rt-4305-18799.18.099418516106@krbdev.mit.edu>

pull up r18600 from trunk

 r18600 at cathode-dark-space:  jaltman | 2006-09-20 22:43:12 -0400
 ticket: new
 subject: windows thread support frees thread local storage after TlsSetValue
 tags: pullup
 
  	threads.c: The return value of TlsSetValue is non-zero on 
                    success.  As a result of misinterpreting the 
                    return value, the memory set in TLS is then freed.
 		   A subsequent call to TlsGetValue returns the 
 		   invalid pointer.
 
 


Commit By: tlyu



Revision: 18610
Changed Files:
_U  branches/krb5-1-5/
U   branches/krb5-1-5/src/util/support/threads.c



From rt-comment at krbdev.mit.edu  Mon Sep 25 17:06:50 2006
From: rt-comment at krbdev.mit.edu (Tom Yu via RT)
Date: Mon, 25 Sep 2006 17:06:50 -0400 (EDT)
Subject: [krbdev.mit.edu #4305] SVN Commit 
In-Reply-To: <rt-4305@krbdev.mit.edu>
Message-ID: <rt-4305-18800.18.3344059724575@krbdev.mit.edu>

pull up r18600 from trunk

 r18600 at cathode-dark-space:  jaltman | 2006-09-20 22:43:12 -0400
 ticket: new
 subject: windows thread support frees thread local storage after TlsSetValue
 tags: pullup
 
  	threads.c: The return value of TlsSetValue is non-zero on 
                    success.  As a result of misinterpreting the 
                    return value, the memory set in TLS is then freed.
 		   A subsequent call to TlsGetValue returns the 
 		   invalid pointer.
 
 


Commit By: tlyu



Revision: 18611
Changed Files:
_U  branches/krb5-1-4/
U   branches/krb5-1-4/src/util/support/threads.c



From rt-comment at krbdev.mit.edu  Mon Sep 25 17:13:57 2006
From: rt-comment at krbdev.mit.edu (Tom Yu via RT)
Date: Mon, 25 Sep 2006 17:13:57 -0400 (EDT)
Subject: [krbdev.mit.edu #4309] SVN Commit 
In-Reply-To: <rt-4309@krbdev.mit.edu>
Message-ID: <rt-4309-18802.5.64522526303584@krbdev.mit.edu>

pull up r18601 from trunk

 r18601 at cathode-dark-space:  jaltman | 2006-09-21 10:58:40 -0400
 ticket: new
 subject: wix installer - win2k compatibility for netidmgr
 tags: pullup
 
 	Install the special win2k version of nidmgr32.dll 
   	on Windows 2000 systems.  
 
 


Commit By: tlyu



Revision: 18612
Changed Files:
_U  branches/krb5-1-5/
U   branches/krb5-1-5/src/windows/installer/wix/files.wxi



From rt-comment at krbdev.mit.edu  Mon Sep 25 17:14:01 2006
From: rt-comment at krbdev.mit.edu (Tom Yu via RT)
Date: Mon, 25 Sep 2006 17:14:01 -0400 (EDT)
Subject: [krbdev.mit.edu #4309] SVN Commit 
In-Reply-To: <rt-4309@krbdev.mit.edu>
Message-ID: <rt-4309-18803.12.3585431564813@krbdev.mit.edu>

pull up r18602 from trunk

 r18602 at cathode-dark-space:  jaltman | 2006-09-21 11:54:05 -0400
 ticket: 4309
 
 	oops, make sure we install from the correct source file
 	on Windows 2000
 
 


Commit By: tlyu



Revision: 18613
Changed Files:
_U  branches/krb5-1-5/
U   branches/krb5-1-5/src/windows/installer/wix/files.wxi



From rt-comment at krbdev.mit.edu  Mon Sep 25 17:16:47 2006
From: rt-comment at krbdev.mit.edu (Tom Yu via RT)
Date: Mon, 25 Sep 2006 17:16:47 -0400 (EDT)
Subject: [krbdev.mit.edu #4309] SVN Commit 
In-Reply-To: <rt-4309@krbdev.mit.edu>
Message-ID: <rt-4309-18807.1.65861635079885@krbdev.mit.edu>

pull up r18602 from trunk

 r18602 at cathode-dark-space:  jaltman | 2006-09-21 11:54:05 -0400
 ticket: 4309
 
 	oops, make sure we install from the correct source file
 	on Windows 2000
 
 


Commit By: tlyu



Revision: 18615
Changed Files:
_U  branches/krb5-1-4/
U   branches/krb5-1-4/src/windows/installer/wix/files.wxi



From rt-comment at krbdev.mit.edu  Mon Sep 25 17:16:40 2006
From: rt-comment at krbdev.mit.edu (Tom Yu via RT)
Date: Mon, 25 Sep 2006 17:16:40 -0400 (EDT)
Subject: [krbdev.mit.edu #4309] SVN Commit 
In-Reply-To: <rt-4309@krbdev.mit.edu>
Message-ID: <rt-4309-18806.9.45613478852714@krbdev.mit.edu>

pull up r18601 from trunk

 r18601 at cathode-dark-space:  jaltman | 2006-09-21 10:58:40 -0400
 ticket: new
 subject: wix installer - win2k compatibility for netidmgr
 tags: pullup
 
 	Install the special win2k version of nidmgr32.dll 
   	on Windows 2000 systems.  
 
 


Commit By: tlyu



Revision: 18614
Changed Files:
_U  branches/krb5-1-4/
U   branches/krb5-1-4/src/windows/installer/wix/files.wxi



From rt-comment at krbdev.mit.edu  Mon Sep 25 17:26:25 2006
From: rt-comment at krbdev.mit.edu (Tom Yu via RT)
Date: Mon, 25 Sep 2006 17:26:25 -0400 (EDT)
Subject: [krbdev.mit.edu #4310] SVN Commit 
In-Reply-To: <rt-4310@krbdev.mit.edu>
Message-ID: <rt-4310-18810.5.14011741692478@krbdev.mit.edu>

pull up r18603 from trunk

 r18603 at cathode-dark-space:  jaltman | 2006-09-21 12:18:26 -0400
 ticket: new
 subject: NSIS installer - update for Win2K NetIDMgr
 tags: pullup
 
 	Install the Win2K specific binaries for NetIDMgr on Win2K
 
 


Commit By: tlyu



Revision: 18618
Changed Files:
_U  branches/krb5-1-4/
U   branches/krb5-1-4/src/windows/installer/nsis/kfw-fixed.nsi



From rt-comment at krbdev.mit.edu  Mon Sep 25 17:25:45 2006
From: rt-comment at krbdev.mit.edu (Tom Yu via RT)
Date: Mon, 25 Sep 2006 17:25:45 -0400 (EDT)
Subject: [krbdev.mit.edu #4310] SVN Commit 
In-Reply-To: <rt-4310@krbdev.mit.edu>
Message-ID: <rt-4310-18809.12.9128593260636@krbdev.mit.edu>

pull up r18603 from trunk

 r18603 at cathode-dark-space:  jaltman | 2006-09-21 12:18:26 -0400
 ticket: new
 subject: NSIS installer - update for Win2K NetIDMgr
 tags: pullup
 
 	Install the Win2K specific binaries for NetIDMgr on Win2K
 
 


Commit By: tlyu



Revision: 18617
Changed Files:
_U  branches/krb5-1-5/
U   branches/krb5-1-5/src/windows/installer/nsis/kfw-fixed.nsi



From rt-comment at krbdev.mit.edu  Mon Sep 25 18:02:10 2006
From: rt-comment at krbdev.mit.edu (Tom Yu via RT)
Date: Mon, 25 Sep 2006 18:02:10 -0400 (EDT)
Subject: [krbdev.mit.edu #4312] SVN Commit 
In-Reply-To: <rt-4312@krbdev.mit.edu>
Message-ID: <rt-4312-18812.17.6050502162641@krbdev.mit.edu>

pull up r18604 from trunk

 r18604 at cathode-dark-space:  jaltman | 2006-09-21 17:49:41 -0400
 ticket: new
 subject: KFW 3.1 Beta 2 NetIDMgr Changes
 component: windows
 tags: pullup
 
          source for (1.1.0.1)
          
          - Updated documentation with additional information and fixed errors.
          
          nidmgr32.dll (1.1.0.1)
          
          - Fixed a deadlock in the configuration provider that may cause
            NetIDMgr to deadlock on load.
          
          - Prevent the configuration provider handle list from getting
            corrupted in the event of a plug-in freeing a handle twice.
          
          - Add more parameter validation for the configuration provider.
          
          - If a plug-in is only partially registered (only some of the entries
            were set in the registry), the completion of the registration didn't
            complete successfully, leaving the plug-in in an unusable state.
            This has been fixed.  Plug-ins will now successfully complete
            registration once they are loaded for the first time, assuming the
            correct resources are present in the module.
          
          - Fixed notifications for setting a default identity.  Notifications
            were not being properly sent out resulting in the credentials window
            not being updated when the default identity changed.
          
          - Changes to the API for type safety.
          
          - Handling of binary data fields was changed to support validation and
            comparison.
          
          - Data types that do not support KCDB_CBSIZE_AUTO now check for and
            report an error if it is specified.
          
          - Password fields in the new credentials dialog will trim leading and
            trailing whitespace before using a user-entered value.
          
          - Change password action will no longer be disabled if no identity is
            selected.  An identity selection control is present in the dialog
            making this restriction unnecessary.
          
          - When renewing credentials, error messages will be suppressed if the
            renewal was for an identity and the identity does not have any
            identity credentials associated with it.
          
          - Error messages that are related to credentials acquisition or
            password changes will now display the name of the identity that the
            error applies to.
          
          - Automatic renewals now renews all identities that have credentials
            associated with them instead of just the default identity.
          
          - Fixed a bug where error messages did not have a default button which
            can be invoked with the return key or the space bar.
          
          - The new credentials window will force itself to the top.  This can
            be disabled via a registry setting, but is on by default.
          
          - Fixed the sort order in the new credentials tabs to respect sort
            hints provided by plug-ins.
          
          - If a new credentials operation fails, the password fields will be
            cleared.
          
          - Once a new credentials operation starts, the controls for specifying
            the identity and password and any other custom prompts will be
            disabled until the operation completes.
          
          - Notifications during the new credentials operation now supply a
            handle to the proper data structures as documented.
          
          - Hyperlinks in the new credentials dialog now support markup that
            will prevent the dialog from switching to the credentials type panel
            when the link is activated.
          
          - If there are too many buttons added by plug-ins in the new
            credentials dialog, they will be resized to accomodate all of them.
          
          - The options button in the new credentials dialog will be disabled
            while a new credentials operation is in progress.
          
          - The 'about' dialog retains the original copyright strings included
            in the resource.
          
          - Multiple modal dialogs are now supported.  Only the topmost one will
            be active.  Once it is closed, the other dialogs will gain focus in
            turn.  This allows for error messages to be displayed from other
            modal dialogs.
          
          - The hypertext window supports italics.
          
          krb4cred.dll (1.1.0.1)
          
          - Fixed a bug where the plug-in would attempt to free a handle twice.
          
          - Fixed a handle leak.
          
          - Changed the facility name used for event reporting to match the
            credentials type name.
          
          krb5cred.dll (1.1.0.1)
          
          - Fixed handling of expired passwords.  If the password for an
            identity is found to have expired at the time a new credentials
            acquisition is in progress, the user will be given an opportunity to
            change the password.  If this is successful, the new credentials
            operation will continue with the new password.
          
          - Prevent the new credentials dialog from switching to the Kerberos 5
            credentials panel during a password change.
          
          - Prompts that were cached indefinitely will now have a limited
            lifetime.  Prompt caches that were created using prior versions of
            the plug-in will automatically expire.
          
          - Multistrings in the resource files were converted to CSV to protect
            them against a bug in Visual Studio 2005 which corrupted
            multistrings.
          
          - Added handling of and reporting WinSock errors that are returned
            from the Kerberos 5 libraries.
          
          - Fixed uninitialized variables.
          
          - The username and realm that is entered when selecting an identity
            will be trimmed of leading and trailing whitespace.
          
          - Changed the facility name used for event reporting to match the
            credentials type name.
          
 


Commit By: tlyu



Revision: 18619
Changed Files:
_U  branches/krb5-1-5/
U   branches/krb5-1-5/src/windows/identity/Makefile
U   branches/krb5-1-5/src/windows/identity/apiversion.txt
U   branches/krb5-1-5/src/windows/identity/config/Makefile.w2k
U   branches/krb5-1-5/src/windows/identity/config/Makefile.w32
U   branches/krb5-1-5/src/windows/identity/kconfig/api.c
U   branches/krb5-1-5/src/windows/identity/kcreddb/attrib.c
U   branches/krb5-1-5/src/windows/identity/kcreddb/buf.c
U   branches/krb5-1-5/src/windows/identity/kcreddb/credential.c
U   branches/krb5-1-5/src/windows/identity/kcreddb/credtype.c
U   branches/krb5-1-5/src/windows/identity/kcreddb/identity.c
U   branches/krb5-1-5/src/windows/identity/kcreddb/kcreddb.h
U   branches/krb5-1-5/src/windows/identity/kcreddb/type.c
U   branches/krb5-1-5/src/windows/identity/plugins/krb4/krb4configdlg.c
U   branches/krb5-1-5/src/windows/identity/plugins/krb4/krbcred.h
U   branches/krb5-1-5/src/windows/identity/plugins/krb5/errorfuncs.c
U   branches/krb5-1-5/src/windows/identity/plugins/krb5/krb5funcs.c
U   branches/krb5-1-5/src/windows/identity/plugins/krb5/krb5identpro.c
U   branches/krb5-1-5/src/windows/identity/plugins/krb5/krb5main.c
U   branches/krb5-1-5/src/windows/identity/plugins/krb5/krb5newcreds.c
U   branches/krb5-1-5/src/windows/identity/plugins/krb5/krbconfig.csv
U   branches/krb5-1-5/src/windows/identity/plugins/krb5/lang/en_us/langres.rc
U   branches/krb5-1-5/src/windows/identity/plugins/krb5/lang/krb5_msgs.mc
U   branches/krb5-1-5/src/windows/identity/sample/templates/credprov/Makefile
U   branches/krb5-1-5/src/windows/identity/ui/aboutwnd.c
U   branches/krb5-1-5/src/windows/identity/ui/credfuncs.c
U   branches/krb5-1-5/src/windows/identity/ui/credwnd.c
U   branches/krb5-1-5/src/windows/identity/ui/lang/en_us/khapp.rc
U   branches/krb5-1-5/src/windows/identity/ui/newcredwnd.c
U   branches/krb5-1-5/src/windows/identity/ui/notifier.c
U   branches/krb5-1-5/src/windows/identity/ui/resource.h
U   branches/krb5-1-5/src/windows/identity/ui/uiconfig.csv
U   branches/krb5-1-5/src/windows/identity/uilib/action.c
U   branches/krb5-1-5/src/windows/identity/uilib/creddlg.c
U   branches/krb5-1-5/src/windows/identity/uilib/khconfigui.h
U   branches/krb5-1-5/src/windows/identity/uilib/khhtlink.h
U   branches/krb5-1-5/src/windows/identity/uilib/khnewcred.h



From rt-comment at krbdev.mit.edu  Mon Sep 25 18:02:16 2006
From: rt-comment at krbdev.mit.edu (Tom Yu via RT)
Date: Mon, 25 Sep 2006 18:02:16 -0400 (EDT)
Subject: [krbdev.mit.edu #4312] SVN Commit 
In-Reply-To: <rt-4312@krbdev.mit.edu>
Message-ID: <rt-4312-18813.18.3354964999696@krbdev.mit.edu>

pull up r18609 from trunk

 r18609 at cathode-dark-space:  jaltman | 2006-09-24 10:30:29 -0400
 ticket: 4312
 
 	Implement renew credential functionality which was inadvertently
 	left out.
 
 


Commit By: tlyu



Revision: 18620
Changed Files:
_U  branches/krb5-1-5/
U   branches/krb5-1-5/src/windows/identity/plugins/krb5/krb5funcs.c



From rt-comment at krbdev.mit.edu  Mon Sep 25 18:14:13 2006
From: rt-comment at krbdev.mit.edu (Tom Yu via RT)
Date: Mon, 25 Sep 2006 18:14:13 -0400 (EDT)
Subject: [krbdev.mit.edu #4312] SVN Commit 
In-Reply-To: <rt-4312@krbdev.mit.edu>
Message-ID: <rt-4312-18815.7.32606799418384@krbdev.mit.edu>

pull up r18604 from trunk

 r18604 at cathode-dark-space:  jaltman | 2006-09-21 17:49:41 -0400
 ticket: new
 subject: KFW 3.1 Beta 2 NetIDMgr Changes
 component: windows
 tags: pullup
 
          source for (1.1.0.1)
          
          - Updated documentation with additional information and fixed errors.
          
          nidmgr32.dll (1.1.0.1)
          
          - Fixed a deadlock in the configuration provider that may cause
            NetIDMgr to deadlock on load.
          
          - Prevent the configuration provider handle list from getting
            corrupted in the event of a plug-in freeing a handle twice.
          
          - Add more parameter validation for the configuration provider.
          
          - If a plug-in is only partially registered (only some of the entries
            were set in the registry), the completion of the registration didn't
            complete successfully, leaving the plug-in in an unusable state.
            This has been fixed.  Plug-ins will now successfully complete
            registration once they are loaded for the first time, assuming the
            correct resources are present in the module.
          
          - Fixed notifications for setting a default identity.  Notifications
            were not being properly sent out resulting in the credentials window
            not being updated when the default identity changed.
          
          - Changes to the API for type safety.
          
          - Handling of binary data fields was changed to support validation and
            comparison.
          
          - Data types that do not support KCDB_CBSIZE_AUTO now check for and
            report an error if it is specified.
          
          - Password fields in the new credentials dialog will trim leading and
            trailing whitespace before using a user-entered value.
          
          - Change password action will no longer be disabled if no identity is
            selected.  An identity selection control is present in the dialog
            making this restriction unnecessary.
          
          - When renewing credentials, error messages will be suppressed if the
            renewal was for an identity and the identity does not have any
            identity credentials associated with it.
          
          - Error messages that are related to credentials acquisition or
            password changes will now display the name of the identity that the
            error applies to.
          
          - Automatic renewals now renews all identities that have credentials
            associated with them instead of just the default identity.
          
          - Fixed a bug where error messages did not have a default button which
            can be invoked with the return key or the space bar.
          
          - The new credentials window will force itself to the top.  This can
            be disabled via a registry setting, but is on by default.
          
          - Fixed the sort order in the new credentials tabs to respect sort
            hints provided by plug-ins.
          
          - If a new credentials operation fails, the password fields will be
            cleared.
          
          - Once a new credentials operation starts, the controls for specifying
            the identity and password and any other custom prompts will be
            disabled until the operation completes.
          
          - Notifications during the new credentials operation now supply a
            handle to the proper data structures as documented.
          
          - Hyperlinks in the new credentials dialog now support markup that
            will prevent the dialog from switching to the credentials type panel
            when the link is activated.
          
          - If there are too many buttons added by plug-ins in the new
            credentials dialog, they will be resized to accomodate all of them.
          
          - The options button in the new credentials dialog will be disabled
            while a new credentials operation is in progress.
          
          - The 'about' dialog retains the original copyright strings included
            in the resource.
          
          - Multiple modal dialogs are now supported.  Only the topmost one will
            be active.  Once it is closed, the other dialogs will gain focus in
            turn.  This allows for error messages to be displayed from other
            modal dialogs.
          
          - The hypertext window supports italics.
          
          krb4cred.dll (1.1.0.1)
          
          - Fixed a bug where the plug-in would attempt to free a handle twice.
          
          - Fixed a handle leak.
          
          - Changed the facility name used for event reporting to match the
            credentials type name.
          
          krb5cred.dll (1.1.0.1)
          
          - Fixed handling of expired passwords.  If the password for an
            identity is found to have expired at the time a new credentials
            acquisition is in progress, the user will be given an opportunity to
            change the password.  If this is successful, the new credentials
            operation will continue with the new password.
          
          - Prevent the new credentials dialog from switching to the Kerberos 5
            credentials panel during a password change.
          
          - Prompts that were cached indefinitely will now have a limited
            lifetime.  Prompt caches that were created using prior versions of
            the plug-in will automatically expire.
          
          - Multistrings in the resource files were converted to CSV to protect
            them against a bug in Visual Studio 2005 which corrupted
            multistrings.
          
          - Added handling of and reporting WinSock errors that are returned
            from the Kerberos 5 libraries.
          
          - Fixed uninitialized variables.
          
          - The username and realm that is entered when selecting an identity
            will be trimmed of leading and trailing whitespace.
          
          - Changed the facility name used for event reporting to match the
            credentials type name.
          
 


Commit By: tlyu



Revision: 18621
Changed Files:
_U  branches/krb5-1-4/
U   branches/krb5-1-4/src/windows/identity/Makefile
U   branches/krb5-1-4/src/windows/identity/apiversion.txt
U   branches/krb5-1-4/src/windows/identity/config/Makefile.w2k
U   branches/krb5-1-4/src/windows/identity/config/Makefile.w32
U   branches/krb5-1-4/src/windows/identity/kconfig/api.c
U   branches/krb5-1-4/src/windows/identity/kcreddb/attrib.c
U   branches/krb5-1-4/src/windows/identity/kcreddb/buf.c
U   branches/krb5-1-4/src/windows/identity/kcreddb/credential.c
U   branches/krb5-1-4/src/windows/identity/kcreddb/credtype.c
U   branches/krb5-1-4/src/windows/identity/kcreddb/identity.c
U   branches/krb5-1-4/src/windows/identity/kcreddb/kcreddb.h
U   branches/krb5-1-4/src/windows/identity/kcreddb/type.c
U   branches/krb5-1-4/src/windows/identity/plugins/krb4/krb4configdlg.c
U   branches/krb5-1-4/src/windows/identity/plugins/krb4/krbcred.h
U   branches/krb5-1-4/src/windows/identity/plugins/krb5/errorfuncs.c
U   branches/krb5-1-4/src/windows/identity/plugins/krb5/krb5funcs.c
U   branches/krb5-1-4/src/windows/identity/plugins/krb5/krb5identpro.c
U   branches/krb5-1-4/src/windows/identity/plugins/krb5/krb5main.c
U   branches/krb5-1-4/src/windows/identity/plugins/krb5/krb5newcreds.c
U   branches/krb5-1-4/src/windows/identity/plugins/krb5/krbconfig.csv
U   branches/krb5-1-4/src/windows/identity/plugins/krb5/lang/en_us/langres.rc
U   branches/krb5-1-4/src/windows/identity/plugins/krb5/lang/krb5_msgs.mc
U   branches/krb5-1-4/src/windows/identity/sample/templates/credprov/Makefile
U   branches/krb5-1-4/src/windows/identity/ui/aboutwnd.c
U   branches/krb5-1-4/src/windows/identity/ui/credfuncs.c
U   branches/krb5-1-4/src/windows/identity/ui/credwnd.c
U   branches/krb5-1-4/src/windows/identity/ui/lang/en_us/khapp.rc
U   branches/krb5-1-4/src/windows/identity/ui/newcredwnd.c
U   branches/krb5-1-4/src/windows/identity/ui/notifier.c
U   branches/krb5-1-4/src/windows/identity/ui/resource.h
U   branches/krb5-1-4/src/windows/identity/ui/uiconfig.csv
U   branches/krb5-1-4/src/windows/identity/uilib/action.c
U   branches/krb5-1-4/src/windows/identity/uilib/creddlg.c
U   branches/krb5-1-4/src/windows/identity/uilib/khconfigui.h
U   branches/krb5-1-4/src/windows/identity/uilib/khhtlink.h
U   branches/krb5-1-4/src/windows/identity/uilib/khnewcred.h



From rt-comment at krbdev.mit.edu  Mon Sep 25 19:02:42 2006
From: rt-comment at krbdev.mit.edu (Tom Yu via RT)
Date: Mon, 25 Sep 2006 19:02:42 -0400 (EDT)
Subject: [krbdev.mit.edu #4237] SVN Commit 
In-Reply-To: <rt-4237@krbdev.mit.edu>
Message-ID: <rt-4237-18817.5.69591560012007@krbdev.mit.edu>

pull up r18561 from trunk

 r18561 at cathode-dark-space:  jaltman | 2006-09-05 14:47:29 -0400
 ticket: new
 subject: windows ccache and keytab file paths without a prefix 
 
 	ktbase.c, ccbase.c:  When a file path is specified without
         	the prefix we must infer the use of the "FILE" prefix.
  		However, we were setting the prefix including the colon
    		separator when the separator should have been ignored.
 
 


Commit By: tlyu



Revision: 18623
Changed Files:
_U  branches/krb5-1-5/
U   branches/krb5-1-5/src/lib/krb5/ccache/ccbase.c
U   branches/krb5-1-5/src/lib/krb5/keytab/ktbase.c



From rt-comment at krbdev.mit.edu  Mon Sep 25 19:09:57 2006
From: rt-comment at krbdev.mit.edu (Tom Yu via RT)
Date: Mon, 25 Sep 2006 19:09:57 -0400 (EDT)
Subject: [krbdev.mit.edu #4237] SVN Commit 
In-Reply-To: <rt-4237@krbdev.mit.edu>
Message-ID: <rt-4237-18818.0.329070865011758@krbdev.mit.edu>

pull up r18561 from trunk

 r18561 at cathode-dark-space:  jaltman | 2006-09-05 14:47:29 -0400
 ticket: new
 subject: windows ccache and keytab file paths without a prefix 
 
 	ktbase.c, ccbase.c:  When a file path is specified without
         	the prefix we must infer the use of the "FILE" prefix.
  		However, we were setting the prefix including the colon
    		separator when the separator should have been ignored.
 
 


Commit By: tlyu



Revision: 18624
Changed Files:
_U  branches/krb5-1-4/
U   branches/krb5-1-4/src/lib/krb5/ccache/ccbase.c
U   branches/krb5-1-4/src/lib/krb5/keytab/ktbase.c



From rt-comment at krbdev.mit.edu  Tue Sep 26 15:32:03 2006
From: rt-comment at krbdev.mit.edu ( Arlene Berry  via RT)
Date: Tue, 26 Sep 2006 15:32:03 -0400 (EDT)
Subject: [krbdev.mit.edu #4345] des-cbc-md5 
In-Reply-To: <rt-4345@krbdev.mit.edu>
Message-ID: <rt-4345-18866.2.85382975418521@krbdev.mit.edu>

For some time now I have noticed that if in krb5.conf you set 
default_tkt_enctypes and default_tgs_enctypes to a single value of 
des-cbc-md5, kinit fails with a KDC has no support for encryption type 
message.  Remove it or add another encryption type and kinit succeeds.  I am 
working with a third party kerberos/gssapi implementation, it receives the 
same error, and there is no workaround for it.

In src/kdc/kdc_util.c there's a function dbentry_supports_etype which has a 
hardcoded return value of 0 if the enctype parameter is des-cbc-md5.  The 
function which calls dbentry_supports_enctype is select_session_keytype also 
in kdc_util.c and it then returns 0.  The function which calls 
select_session_keytype is process_as_req in src/kdc/do_as_req.c and it then 
sets the KRB5KDC_ERR_ETYPE_NOSUPP error and creates the error message for 
the client.  I commented out the hardocded return 0 for des-cbc-md5 in 
dbentry_supports_enctype, and then everything seemed to work.

The code takes this same path with both kinit and the third party kerberos 
implementation.  I happen to have my KDC configured for only the des-cbc-md5 
enctype but I have seen the error message in the past when using multiple 
enctypes.

_________________________________________________________________
Get today's hot entertainment gossip  http://movies.msn.com/movies/hotgossip




From rt-comment at krbdev.mit.edu  Wed Sep 27 18:26:17 2006
From: rt-comment at krbdev.mit.edu (Tom Yu via RT)
Date: Wed, 27 Sep 2006 18:26:17 -0400 (EDT)
Subject: [krbdev.mit.edu #4353] SVN Commit 
In-Reply-To: <rt-4353@krbdev.mit.edu>
Message-ID: <rt-4353-18881.0.552264257169313@krbdev.mit.edu>

another attempt
test commit handler with trailing spaces in ticket ID

Commit By: tlyu



Revision: 18629
Changed Files:
A   branches/commit-handler-test/



From rt-comment at krbdev.mit.edu  Wed Sep 27 19:12:44 2006
From: rt-comment at krbdev.mit.edu (Tom Yu via RT)
Date: Wed, 27 Sep 2006 19:12:44 -0400 (EDT)
Subject: [krbdev.mit.edu #4353] SVN Commit 
In-Reply-To: <rt-4353@krbdev.mit.edu>
Message-ID: <rt-4353-18884.11.6483885336881@krbdev.mit.edu>

delete

Commit By: tlyu



Revision: 18630
Changed Files:
D   branches/commit-handler-test/



From rt-comment at krbdev.mit.edu  Wed Sep 27 21:10:24 2006
From: rt-comment at krbdev.mit.edu (Ken Raeburn via RT)
Date: Wed, 27 Sep 2006 21:10:24 -0400 (EDT)
Subject: [krbdev.mit.edu #4354] db2 policy database loading broken 
In-Reply-To: <rt-4354@krbdev.mit.edu>
Message-ID: <rt-4354-18887.0.104147592228188@krbdev.mit.edu>

I thought I'd done a better job of fixing this up after the DAL merge,
but apparently not....

The "kdb5_util load" process, using the db2 back end, creates a new
database (if the main db is "/foo/bar", it creates "/foo/bar~") to
load new entries into, and then renames it to replace the original
database.

The db implementation actually uses multiple files, "bar" for the
principal data, "bar.kadm5" for the policy data, and lock files and
such.  So for the temporary database, it's "bar~.kadm5" etc.

Unfortunately, it appears that policy data being loaded gets written
to "bar.kadm5" instead of "bar~.kadm5", so it gets thrown away when we
do the rename, and we're left with an empty policy database.

This should be fixed for 1.6.

Ken



From rt-comment at krbdev.mit.edu  Wed Sep 27 21:14:41 2006
From: rt-comment at krbdev.mit.edu (Ken Raeburn via RT)
Date: Wed, 27 Sep 2006 21:14:41 -0400 (EDT)
Subject: [krbdev.mit.edu #4355] test policy dump/load in make check 
In-Reply-To: <rt-4355@krbdev.mit.edu>
Message-ID: <rt-4355-18890.14.31819984766@krbdev.mit.edu>

Automated tests should exist which would catch something like ticket 4354.


From rt-comment at krbdev.mit.edu  Thu Sep 28 15:06:10 2006
From: rt-comment at krbdev.mit.edu (Ken Raeburn via RT)
Date: Thu, 28 Sep 2006 15:06:10 -0400 (EDT)
Subject: [krbdev.mit.edu #4256] Make process error (AIX, fake-addrinfo.c) 
In-Reply-To: <rt-4256@krbdev.mit.edu>
Message-ID: <rt-4256-18899.12.3559452368161@krbdev.mit.edu>

The fix for the fake-addrinfo.c build problem on AIX should be to change
"&my_h_ent" to "&TMP.ent" in the "GET_HOST_BY_NAME" macro definition
inside "#ifdef _AIX".


From rt-comment at krbdev.mit.edu  Thu Sep 28 15:07:25 2006
From: rt-comment at krbdev.mit.edu (Ken Raeburn via RT)
Date: Thu, 28 Sep 2006 15:07:25 -0400 (EDT)
Subject: [krbdev.mit.edu #4256] SVN Commit 
In-Reply-To: <rt-4256@krbdev.mit.edu>
Message-ID: <rt-4256-18901.18.475662642925@krbdev.mit.edu>

Fix AIX version of GET_HOST_BY_NAME to use TMP.ent for the result, not
the no-longer-defined my_h_ent.

Commit By: raeburn



Revision: 18632
Changed Files:
U   trunk/src/util/support/fake-addrinfo.c



From rt-comment at krbdev.mit.edu  Fri Sep 29 20:52:40 2006
From: rt-comment at krbdev.mit.edu (Ken Raeburn via RT)
Date: Fri, 29 Sep 2006 20:52:40 -0400 (EDT)
Subject: [krbdev.mit.edu #4362] kdc vague errors 
In-Reply-To: <rt-4362@krbdev.mit.edu>
Message-ID: <rt-4362-18904.0.815800503496362@krbdev.mit.edu>

Unless we decide to get rid of the vague-errors option altogether, I
think we should make it a run-time option in the config file, instead
of configure-time, and then add tests to make sure it works, which we
can then run even when we haven't specially configured a build tree
for the option.  We might also want to review whether we've added new
error-return paths that provide more information than we want when
vague errors are selected.

Ken