From: To: Time: Sat Mar 3 16:36:57 2007 MIt Kerberos Development Team From: To: Time: Sat Mar 3 16:37:31 2007 Test From: To: Time: Sat Mar 3 16:52:15 2007 MIt Kerberos Development Team From: To: Time: Sat Mar 3 16:52:35 2007 Testing again From: To: Time: Sun Mar 4 02:02:14 2007 MIt Kerberos Development Team From: To: Time: Sun Mar 4 02:02:14 2007 The topic has been set to: foo From: To: Time: Sun Mar 4 22:42:37 2007 test From: To: Time: Mon Mar 5 01:15:35 2007 [jaltman has set the topic to: not yet set] From: To: Time: Mon Mar 5 10:00:04 2007 Test From: To: Time: Mon Mar 5 10:00:20 2007 Sam, do you see me? From: To: Time: Mon Mar 5 10:00:56 2007 Yes. The problem was on my end From: To: Time: Mon Mar 5 13:59:40 2007 Whee! From: To: Time: Mon Mar 5 14:03:31 2007 Now that Tim has confirmed he is seeing the expected behavior perhaps Richard could get around to confirming that when he runs the tests we ask for, he sees expected results. From: To: Time: Mon Mar 5 15:44:41 2007 Is it possible that MIT's KDC uses a different key type for extremely old and more recent keys? Is there a way I can probe the key type? From: To: Time: Mon Mar 5 15:50:01 2007 Yes; it's possible that different principals have keys of different types, depending on age, if there has been some change to the default enctypes for that realm. I don't know if there's been any such change. From: To: Time: Mon Mar 5 15:51:12 2007 As to whether you can find out... well, if the KDC will issue tickets for that principal as a service, you can use kvno to get a ticket for it and examine that; IIRC klist -v will print the service key enctype. But that only tells you one type; the principal may have multiple keys. From: To: Time: Mon Mar 5 15:51:18 2007 Okay. My prototype JAAS verifier for Wildfire works for systest, but not for me. I have a very old password, and I wonder if it's a keytype support issue. I could change my password, but that would destroy the evidence, so I'd like to probe the keytypes first. From: To: Time: Mon Mar 5 15:51:59 2007 Ah, OK. Well, you _might_ be able to use kadmin to examine yourself; I don't know what the ACL's are like. From: To: Time: Mon Mar 5 15:52:46 2007 You can also do a search, running kinit multiple times with your krb5.conf set to advertise different sets of supported enctypes. From: To: Time: Mon Mar 5 15:53:27 2007 I'm assuming you don't have Kerberos admin bits, or you could just use kadmin From: To: Time: Mon Mar 5 15:55:32 2007 kadmin seems to work. From: To: Time: Mon Mar 5 15:57:00 2007 Sadly, it falsifies my theory; they both have the same types of keys. From: To: Time: Mon Mar 5 15:58:29 2007 I wonder if this is a string-to-key issue. If your password predates the conversion from krb4, then it will have an empty salt; maybe that's confusing something. It might be interesting to capture the traffic between your verifier and the KDC. From: To: Time: Mon Mar 5 15:59:10 2007 ... and compare for you vs systest, and for systest with your verifier vs kinit From: To: Time: Mon Mar 5 16:00:37 2007 Well, each principal has two keys. In each case, both keys are of type "DES cbc mode with CRC-32", and one of them is "no salt" and the other is "Version 4". From: To: Time: Mon Mar 5 16:01:06 2007 I can do a traffic capture easily enough, but will that reveal anything if the problem is string-to-key conversion on the verifier end? (Also, what can I use to analyze the traffic?) From: To: Time: Mon Mar 5 16:03:18 2007 I believe ethereal can parse Kerberos, though I doubt it can deal with the encrypted stuff. I was thinking in terms of the KDC sending you salt string information for one principal but not the other, which you'd have been able to see because it's not encrypted. From: To: Time: Mon Mar 5 16:04:00 2007 But yeah, if you have one "normal" and one v4-salted des-cbc-crc for each principal, that shouldn't be the issue. From: To: Time: Mon Mar 5 16:04:12 2007 do you know what error you're getting? From: To: Time: Mon Mar 5 16:04:49 2007 The JAAS debug message is "Integrity check on decrypted field failed (31)" From: To: Time: Mon Mar 5 16:04:58 2007 I've verified with a debugger that my password isn't getting munged or anything. From: To: Time: Mon Mar 5 16:06:32 2007 Hm. Does kadmin list the keys in the same _order_ for both principals? From: To: Time: Mon Mar 5 16:06:47 2007 No, they're in reverse order. From: To: Time: Mon Mar 5 16:07:06 2007 Version 4 is first for ghudson, last for systest. From: To: Time: Mon Mar 5 16:07:33 2007 Then that's probably your problem - for ghudson, the KDC is preferring the v4-salted key, and the verifier can't deal. From: To: Time: Mon Mar 5 16:08:11 2007 Is that a bug? Is it advertising enctypes it can't support? From: To: Time: Mon Mar 5 16:08:49 2007 No. Both keys have the same enctype; the parameters to the string-to-key operation are just different. From: To: Time: Mon Mar 5 16:09:02 2007 Hm... From: To: Time: Mon Mar 5 16:10:42 2007 There is a mechanism which allows the KDC to tell you which salt to use, but it basically involves sending a request without preauth when preauth is required. I'm pretty sure what kinit and similar programs do is "know" that there are multiple default salts, and try decrypting the response with each of them. From: To: Time: Mon Mar 5 16:11:11 2007 The java stuff probably only knows about the "normal" salt. From: To: Time: Mon Mar 5 16:13:03 2007 Oh; it appears that the KDC can also send PA-ETYPE-INFO2 in an AS-REP, so in theory it can be made to work without an extra round trip. Unfortunately, I bet you can't make changes at that level. From: To: Time: Mon Mar 5 16:13:49 2007 Examining the network traffic should tell you if that is there, too From: To: Time: Mon Mar 5 16:13:50 2007 Heh. I don't even know if I can look at the source for the relevant JAAS implementation module, much less change it. From: To: Time: Mon Mar 5 16:20:39 2007 It's probable that MIT's kdc uses a different salt type for very old passwords converted to keys, but no it should use the same enctype From: To: Time: Mon Mar 5 16:26:09 2007 Greg, if you were using a newer JDK, you'd have much better kerberos support. 1.6 for example is much better than 1.4.2. I can't remember if this particular bug is fixed in 1.6 though. Note that if your key is that old you cannot log into win.mit.edu. NIST's policy has been to tell people with keys that old to update them to log into win.mit.edu From: To: Time: Mon Mar 5 16:27:06 2007 You have a group called NIST? From: To: Time: Mon Mar 5 16:27:24 2007 I guess that goes well with our ISO From: To: Time: Mon Mar 5 16:28:49 2007 OK. Then I understand why you want to prohibit me from getting to the tgt session key or any service that uses the same key as the local machine. But why other services? From: To: Time: Mon Mar 5 16:29:33 2007 Ah, because you could get access to other computers if you are a domain admin that way From: To: Time: Mon Mar 5 16:31:42 2007 mix From: To: Time: Mon Mar 5 16:33:52 2007 I'm using JDK 1.5 at the moment, but I can probably switch to 1.6 and see if that helps. From: To: Time: Mon Mar 5 16:34:15 2007 I'm very curious whether I can look at the source for com.sun.blah.krb5login somehow, e.g. to see if there's any ticket verification support. From: To: Time: Mon Mar 5 16:34:39 2007 Have you looked at the gpled java sources? From: To: Time: Mon Mar 5 16:35:43 2007 Not yet. Let me see if I can find them. From: To: Time: Mon Mar 5 16:40:05 2007 (Wow, they're using Subversion.) From: To: Time: Mon Mar 5 16:55:07 2007 No, I don't think com.sun.blah.krb5login is part of the compiler, the hotspot JVM, or the help system. If they've open-sourced the class library, I haven't found any information about that. From: To: Time: Mon Mar 5 17:12:29 2007 Apparently December 2000 was the cutoff date for whatever compatibility problem affected Windows (http://web.mit.edu/ist/topics/windows/server/winmitedu/help.html). I last changed my password in October 1999. From: To: Time: Mon Mar 5 17:12:49 2007 I'm guessing it's the same issue for both. From: To: Time: Mon Mar 5 17:13:31 2007 the change was to re-order the enctype/salttype list for kadmind From: To: Time: Mon Mar 5 17:14:32 2007 Is there any reason you couldn't just force-change the order for all users on the KDC? From: To: Time: Mon Mar 5 17:15:04 2007 there are no interfaces for re-ordering keys for a principal From: To: Time: Mon Mar 5 17:15:24 2007 So, it could be done, but it would have required writing code? Reasonable. From: To: Time: Mon Mar 5 17:15:45 2007 either really hairy dumpfile surgery or writing a custom program using the kadm5 API From: To: Time: Mon Mar 5 17:17:45 2007 and in an ideal world, people would change their passwords more often than once every five years From: To: Time: Mon Mar 5 21:39:08 2007 Gah. The Debian ssh-krb5 transition still isn't quite right. I think this is about as good as it's going to get for etch, though, since we just ran out of time. It still doesn't enable key exchange properly if everything is commented out and one was just relying on the ssh-krb5 defaults (it does if anything is uncommented, though). From: To: Time: Mon Mar 5 21:42:27 2007 Oh, wait, never mind. ssh-krb5 installed uncommented versions. So this will work. From: To: Time: Mon Mar 5 21:43:28 2007 In what sense are we out of time? From: To: Time: Mon Mar 5 21:43:53 2007 Ah, cool. From: To: Time: Mon Mar 5 21:44:34 2007 ssh produces a udeb. Final release freeze for udebs is five days from now. From: To: Time: Mon Mar 5 21:46:08 2007 Ah. It would be nice if they'd actually send things like that to d-d-a From: To: Time: Mon Mar 5 21:46:12 2007 Yup, everything looks like it works. Sending the unblock request now. From: To: Time: Mon Mar 5 21:46:20 2007 Yeah, that's a good point. From: To: Time: Tue Mar 6 12:05:44 2007 Pandion seems to work well as a Windows Jabber client with conference room support except that when the host is disconnected from the network, Pandion doesn't seem to be able to auto-rejoin the conference room when it logs back into the Jabber server. From: To: Time: Tue Mar 6 15:36:05 2007 kind of unfortunate that the SVN RT gateway logs in a different format than the mail script... From: To: Time: Tue Mar 6 16:49:45 2007 jaltman: I have that same issue with gaim From: To: Time: Tue Mar 6 18:09:21 2007 why are there no RT tickets for svn revisions 19207 and 19208? From: To: Time: Tue Mar 6 18:10:54 2007 why were src/windows/installers/wix/{features.wxi,files.wxi} modified? From: To: Time: Tue Mar 6 18:11:05 2007 19207 didn't have RT commit headers From: To: Time: Tue Mar 6 18:11:21 2007 19208 is ticket #5458 From: To: Time: Tue Mar 6 18:12:21 2007 (sorry 19208 is ken's. I misread it as kevin's) From: To: Time: Tue Mar 6 18:16:15 2007 I understand the commit message, but I don't understand how this commit message maps to the diff. From: To: Time: Tue Mar 6 18:16:30 2007 Kevin's changes to those files are just wrong. If the decision has been made to remove Leash from the installer, then the feature and all of the associated components must be removed From: To: Time: Tue Mar 6 18:17:24 2007 Yeah. The commit message doesn't mention leash, so I don't understand how that could be right even if he thought he wanted to remove leash From: To: Time: Tue Mar 6 18:18:00 2007 And I don't see why he wants to remove krb5.ini. The commit message says he wants to pull krb5.ini from the krb5 source tree not from the extras zip, but that change does not accomplish that From: To: Time: Tue Mar 6 18:18:05 2007 I do not understand the commenting out of the configuration files. We want configuration files to be installed. My understanding from the face-to-face meeting is that we want the krb5.ini installed by KFW to be identical to the krb5.conf installed by UNIX From: To: Time: Tue Mar 6 18:18:32 2007 btw, can I invite Asanka to join this conference? From: To: Time: Tue Mar 6 18:20:39 2007 I'd back out the change because the commit message does not accurately describe it. Send Kevin (and possibly krbcore) mail noting that. From: To: Time: Tue Mar 6 18:21:19 2007 I suspect that he accidentally had local changes to work around problems he was having that he committed without intending to commit From: To: Time: Tue Mar 6 18:25:42 2007 In fact all the things in the commit message seem to be accomplished once you back out those changes From: To: Time: Tue Mar 6 18:31:41 2007 Revision 19211, RT 5461 From: To: Time: Thu Mar 8 10:53:14 2007 For those who use GNUPrivacyGuard http://securitywatch.eweek.com/flaws/dont_trust_gnupg_encrypted_and_signed_email.html From: To: Time: Thu Mar 8 10:56:26 2007 I get a 404 From: To: Time: Thu Mar 8 10:57:09 2007 the link I just posted works for me From: To: Time: Thu Mar 8 10:59:51 2007 Essentially what it says is that 99% of e-mail applications that use GNUPG do so incorrectly and allow the messages to be manipulated without detection. Instead of trying to fix the applications, GNUPG 1.4.7 has changed the semantics of the GNUPG API to address the problem. Enigmail has also been updated. From: To: Time: Thu Mar 8 11:00:03 2007 Vulnerable systems include those using: GnuPG 1.4.6 and previous versions Enigmail 0.94.2 and previous versions KMail 1.9.5 and previous versions Evolution 2.8.1 and previous versions Sylpheed 2.2.7 and previous versions Mutt 1.5.13 and previous versions GNUMail 1.1.2 and previous versions Other scripts and applications using GnuPG may be vulnerable From: To: Time: Thu Mar 8 11:01:19 2007 How do they missuse it? From: To: Time: Thu Mar 8 11:01:38 2007 that is not described in the eweek article From: To: Time: Thu Mar 8 11:02:44 2007 Ah. From: To: Time: Thu Mar 8 11:05:42 2007 1.4.6 fixed a remotely controllable function pointer issue http://lists.gnupg.org/pipermail/gnupg-announce/2006q4/000246.html And here is a description of the application misuse corrected in 1.4.7 http://lists.gnupg.org/pipermail/gnupg-announce/2007q1/000251.html From: To: Time: Thu Mar 8 11:09:12 2007 OK, so it doesn't look like this applies to pgp/mime From: To: Time: Thu Mar 8 11:09:25 2007 At least for signatures. It may for encrypted messages From: To: Time: Fri Mar 9 12:03:11 2007 Has everyone who's going to IETF registered? I remembered the early bird deadline with about 5 minutes to spare. From: To: Time: Fri Mar 9 16:14:58 2007 Does anyone who got the mail want to serve on the infinite mile committee? From: To: Time: Fri Mar 9 16:18:15 2007 hm, looks like Wilson really wants one of us to serve. From: To: Time: Fri Mar 9 16:18:34 2007 Yes. But before I pick someone I want to make sure that no one wants to volunteer From: To: Time: Fri Mar 9 16:31:13 2007 Ah. I buy the argument about bytes-to-char. I don't buy the other arguments until and unless zephyr gains charset info From: To: Time: Fri Mar 9 16:33:20 2007 mix. From: To: Time: Fri Mar 9 18:08:32 2007 is MIT going to post the new KFW installers and send out an announcement? I'm leaving for the night. From: To: Time: Sun Mar 11 03:02:23 2007 MIt Kerberos Development Team From: To: Time: Sun Mar 11 03:02:23 2007 The topic has been set to: not yet set From: To: Time: Mon Mar 12 17:12:05 2007 there's a DST-related query in the kfw-bugs moderation queue... should i let it through? From: To: Time: Mon Mar 12 17:15:31 2007 The problem with MSLSA on Vista under UAC and filtering on the content of the session key is this: * when enumerating the tickets in the MSLSA for klist or NIM, we do not use the API that reads the tickets. Therefore, we do not know that the enctype or key value might be bad. * we can't probe the MSLSA for the tickets themselves all of the time without causing the MSLSA to go fetch new tickets from the KDC. I need to filter based upon the current process account, the membership of the account in the Administrators group, and the lack of Administrators groups in the current process token. From: To: Time: Mon Mar 12 17:15:52 2007 the DST related bug in the kfw-bugs queue is a helpdesk question. From: To: Time: Mon Mar 12 17:15:59 2007 it should not be going to kfw-bugs From: To: Time: Mon Mar 12 17:16:36 2007 ok i'll reject it with a note to send mail to computing-help From: To: Time: Mon Mar 12 17:16:42 2007 thanks From: To: Time: Mon Mar 12 17:23:21 2007 KFW really should have skipped major version 3. From: To: Time: Mon Mar 12 17:23:40 2007 why? From: To: Time: Mon Mar 12 17:23:55 2007 Oh, but I've got friends so looking forward to Kerberos For Windows 3.11 From: To: Time: Mon Mar 12 17:24:09 2007 3.1.1 already shipped From: To: Time: Mon Mar 12 17:24:14 2007 Yeah, I mis-parse it that way half te time, still. From: To: Time: Mon Mar 12 17:24:19 2007 s/te/the/ From: To: Time: Mon Mar 12 17:25:55 2007 Yes; I saw Tom's mail from over the weekend. But ==asedeno's-friends From: To: Time: Mon Mar 12 17:26:19 2007 I don't really care From: To: Time: Mon Mar 12 17:27:02 2007 Hm. Lack of instances is annoying. From: To: Time: Mon Mar 12 17:28:11 2007 lack of instances is the primary reason I still prefer Zephyr over Jabber From: To: Time: Mon Mar 12 17:28:50 2007 is zephyr peculiar among IM systems for the concept of instances? From: To: Time: Mon Mar 12 17:28:57 2007 Are folks using barnowl for Jabber actively? I need to look at that, since the gaim interface really is obnoxious. From: To: Time: Mon Mar 12 17:29:15 2007 > My name is Navarut A. Now, I'm find out information about Kerberos for my > Project but I don't sure how many bits that used in Kerberos (32 bits or not) Oh; Kerberos uses many bits. Most tickets are thousands of bits long. From: To: Time: Mon Mar 12 17:29:33 2007 I think so. I've not seen anything else that lets you create new conversations on the fly quite as easy as Zephyr does. IRC comes closer, but creating a channel is still heavier-weight than Zephyr instances. From: To: Time: Mon Mar 12 17:29:34 2007 Yeah. "Not 32. Way more." From: To: Time: Mon Mar 12 17:29:38 2007 Yes, zephyr is peculiar in that way. From: To: Time: Mon Mar 12 17:31:09 2007 And yes, people do use barnowl for jabber, though I don't know if anyone uses it exclusively. I expect to have transitioned by the end of the week, modulo the owl in my office that logs zephyr for me. From: To: Time: Mon Mar 12 17:32:18 2007 Using gaim for some fora and owl for others is really not doing it for me, and I refuse to use gaim's zephyr From: To: Time: Mon Mar 12 17:34:05 2007 Gaim's Zephyr is gross. From: To: Time: Mon Mar 12 17:35:14 2007 I find the Adium (libgaim) Zephyr support to be a bit annoying, but not completely sucky. Well, unless you count (1) the Kerberos bug that means there's a strong chance of crashing Adium when my tickets get renewed, and (2) the excessive CPU usage of Adium and CCacheServer that Zephyr triggers. But then, I haven't tried owl yet... From: To: Time: Mon Mar 12 17:38:31 2007 i still can't figure out how to set topics or query usernames in chatrooms in adium From: To: Time: Mon Mar 12 17:39:06 2007 [raeburn@mit.edu has set the topic to: use /topic] From: To: Time: Mon Mar 12 17:42:20 2007 and where is this documented? or does the conference server handle it? From: To: Time: Mon Mar 12 17:45:41 2007 I'm not sure what you mean by "query usernames". From: To: Time: Mon Mar 12 17:45:57 2007 discover the actual Jabber IDs of people in the room From: To: Time: Mon Mar 12 17:46:05 2007 for rooms which support that From: To: Time: Mon Mar 12 17:46:31 2007 The client interprets the /topic command and sends an xmpp message to the conference with a subject tag and no body. From: To: Time: Mon Mar 12 17:48:04 2007 I don't think you get to do that. At least, I've never seen a room support it. From: To: Time: Mon Mar 12 17:48:18 2007 yay, the securID thing works and reproduces both bugs filed against KfM about it From: To: Time: Mon Mar 12 17:48:46 2007 yay From: To: Time: Mon Mar 12 17:49:23 2007 now to go lose my mind somewhere deep inside the init creds code ;-) From: To: Time: Mon Mar 12 17:50:45 2007 Well, Adium shows me "Russ" in this conference room, and iChat shows me "rra@jabber.org"... From: To: Time: Mon Mar 12 17:51:05 2007 Poor lxs... :-( From: To: Time: Mon Mar 12 17:51:28 2007 i need to thwack the init_creds code hard a few more times From: To: Time: Mon Mar 12 17:51:31 2007 Interesting; gaim does not make that visible to me. From: To: Time: Mon Mar 12 17:52:41 2007 Heh. And in iChat, apparently it's configured to display icons instead of names. Which means anything not attributed to me (or jaltman, who has left) is attributed to a light bulb. From: To: Time: Mon Mar 12 17:52:44 2007 In gaim, I can right-click on the people in the list of conference members and get info. From: To: Time: Mon Mar 12 17:53:26 2007 in adium i can't do that From: To: Time: Mon Mar 12 17:53:37 2007 or rather the account info is empty for most people From: To: Time: Mon Mar 12 17:54:03 2007 Ah, yes, that's largely true for me as well. I get an account address that's actually at the conference server. How weird. From: To: Time: Mon Mar 12 17:54:43 2007 Tom: Really? So far, I haven't found anyone the account info *isn't* empty for, including people in my contact list... From: To: Time: Mon Mar 12 17:55:22 2007 Oh, if the addresses are bogus, yeah, Adium wouldn't have anything on them. But the info iChat shows ought to be available... From: To: Time: Mon Mar 12 17:58:38 2007 which codepath does the securID stuff go through? From: To: Time: Mon Mar 12 17:58:47 2007 (ie: which prompter invocation?) From: To: Time: Mon Mar 12 17:59:15 2007 probably deep in preauth2.c but i'd have to check From: To: Time: Mon Mar 12 17:59:29 2007 (I'm running a build so I'll have debugging code in ~10 mins, I just wanted to start at code while I wait) From: To: Time: Mon Mar 12 17:59:44 2007 s/start/stare/ From: To: Time: Mon Mar 12 18:00:57 2007 krb5_do_preauth dispatches through the table pa_types which has a reference to the static function pa_sam From: To: Time: Mon Mar 12 18:01:45 2007 so it's pa_sam and not pa_sam_2? From: To: Time: Mon Mar 12 18:02:15 2007 not actually sure... From: To: Time: Mon Mar 12 18:02:29 2007 pa_sam_2 appears to get called 1st From: To: Time: Mon Mar 12 18:02:39 2007 what patype numbers are being sent? From: To: Time: Mon Mar 12 18:03:20 2007 I'd know that if I hadn't been foolish enough to upgrade to wireshark From: To: Time: Mon Mar 12 18:03:42 2007 I'll just wait for debuggery goodness From: To: Time: Mon Mar 12 18:03:43 2007 oh From: To: Time: Mon Mar 12 18:04:04 2007 so pa_sam2 should get called if the patype is PADATA_SAM_CHALLENGE_2 i think From: To: Time: Mon Mar 12 18:04:22 2007 you can't have wireshark and ethereal installed simultaneously and wireshark is cranky on my machine From: To: Time: Mon Mar 12 18:40:48 2007 still not quite sure what all adium supports for MUC but it looks like it only supports a very limited subset of functionality From: To: Time: Mon Mar 12 18:49:40 2007 oh heh, I wonder when that code disappeared out of the krb5 tree From: To: Time: Mon Mar 12 18:49:48 2007 well that explains it From: To: Time: Mon Mar 12 18:49:59 2007 disappeared? From: To: Time: Mon Mar 12 18:50:25 2007 krb5_get_init_creds_password() lost its knowledge of the magic Mac error code for user cancelled From: To: Time: Mon Mar 12 18:50:35 2007 oh, weird From: To: Time: Mon Mar 12 18:50:50 2007 probably a very long time ago and I never noticed From: To: Time: Mon Mar 12 18:50:57 2007 are you sure it wasn't in get_in_tkt and we just didn't port it to get_init_creds? From: To: Time: Mon Mar 12 18:51:33 2007 oh hm possibly From: To: Time: Mon Mar 12 18:53:44 2007 well what's weird is that krb5_get_init_creds_password is the only place where KRB5_LIBOS_PWDINTR is special cased, though I'm clearly getting caught in the MAX_IN_TKT_LOOPS loop (I get KRB5_GET_IN_TKT_LOOP sometimes) From: To: Time: Mon Mar 12 18:54:21 2007 more debugging is required, but switching the KLL prompters to use KRB5_LIBOS_PWDINTR seems to make the behavior much better From: To: Time: Mon Mar 12 18:55:20 2007 (well other than that I had to move "is this a user cancelled error" into a function so I didn't check the same 2 error codes in 20 places ;-) From: To: Time: Mon Mar 12 18:55:37 2007 sounds like a good plan... From: To: Time: Mon Mar 12 18:55:58 2007 well it causes a bunch of KLL functions to violate their APIs From: To: Time: Mon Mar 12 18:56:06 2007 they now return the wrong error From: To: Time: Mon Mar 12 18:56:35 2007 do you need to do error code translations? From: To: Time: Mon Mar 12 18:56:39 2007 it's not a good permanent solution, just using it to check to see if I understand most of the problem From: To: Time: Mon Mar 12 18:57:26 2007 I need the krb5 libraries to understand klUserCanceledErr as the same as KRB5_LIBOS_PWDINTR From: To: Time: Mon Mar 12 18:58:13 2007 can you make a wrapper around the KLL function that does translation into the krb5 error code? From: To: Time: Mon Mar 12 18:58:56 2007 Not really because the KLL exports its own prompter that is documented to both be safe to use as a krb5 prompter and documented to return klUserCanceledErr :-) From: To: Time: Mon Mar 12 18:59:31 2007 oh KLL passes its prompter function when it calls get_init_creds? From: To: Time: Mon Mar 12 18:59:50 2007 yes because there's no way to provide the prompts ahead of time From: To: Time: Mon Mar 12 19:00:05 2007 and I need to display a graphical sheet to collect the information. From: To: Time: Mon Mar 12 19:00:28 2007 how about making a private function wrapper in KLL which is what actually gets passed to get_init_creds? From: To: Time: Mon Mar 12 19:00:51 2007 Because callers can also pass the external API into get_init_creds From: To: Time: Mon Mar 12 19:02:51 2007 Looking a little closer it appears that enough of the APIs may be private that I can work around it. I'm not sure. I'll just have to stare at it. The problem is that the KLL uses klUserCanceledErr all over the place and there are also two prompter implementations and several places where the prompter gets passed in. Anything I do is going to be a house of cards From: To: Time: Mon Mar 12 19:02:52 2007 i'm just trying to figure out a way to avoid putting more platform-specific stuff into the krb5 library From: To: Time: Mon Mar 12 19:03:31 2007 This will be improved by having KIM around because we can just use its headers From: To: Time: Mon Mar 12 19:04:01 2007 I'll just kludge something for the KLL From: To: Time: Mon Mar 12 20:06:23 2007 is sizeof(enum) a constant for all enums or is it dependent on the number of entries in the enum? From: To: Time: Mon Mar 12 20:06:39 2007 you sooo do not want to go there From: To: Time: Mon Mar 12 20:06:49 2007 ABI-dependent. gcc even has options for it. From: To: Time: Mon Mar 12 20:06:50 2007 many many things about enums are implementation-defined From: To: Time: Mon Mar 12 20:07:06 2007 this is windows specific code. From: To: Time: Mon Mar 12 20:07:07 2007 different enum types are allowed to have different sizes in the same implementation From: To: Time: Mon Mar 12 20:07:41 2007 Then it's up to the compiler on Windows. I wouldn't suggest relying on it being consistent at all... From: To: Time: Mon Mar 12 20:08:06 2007 don't use enums for anything that has to be a stable ABI, really From: To: Time: Mon Mar 12 20:08:32 2007 Well, not enum types, anyways. They might be okay for defining constants? From: To: Time: Mon Mar 12 20:08:33 2007 the microsoft example code is of the form enum FOO foo; API(&foo, sizeof(foo)); From: To: Time: Mon Mar 12 20:08:37 2007 Eww. From: To: Time: Mon Mar 12 20:08:48 2007 jis set me up the SecurID... seems to work ok so far From: To: Time: Mon Mar 12 20:08:57 2007 i second the eww From: To: Time: Mon Mar 12 20:09:01 2007 Gotta get me one of them, too. From: To: Time: Mon Mar 12 20:09:17 2007 you need a cryptocard From: To: Time: Mon Mar 12 20:09:41 2007 not sure they've got support for that on the ATHENA.MIT.EDU KDCs yet From: To: Time: Mon Mar 12 20:09:42 2007 I have the 0th eww. From: To: Time: Mon Mar 12 20:10:00 2007 but what am I going to do about it From: To: Time: Mon Mar 12 20:10:14 2007 i think enum constants are supposed to be compatible with int... have to check though From: To: Time: Mon Mar 12 20:10:16 2007 Jeff told me they're actually using it for access to certain servers. From: To: Time: Mon Mar 12 20:10:21 2007 I can't actually use the enum type because I don't want a dependency on the header its defined in From: To: Time: Mon Mar 12 20:10:36 2007 could you describe the enum situation in more detail? From: To: Time: Mon Mar 12 20:12:38 2007 I need to obtain the value of a property from a Win32 API. The API takes a VOID * as input for the buffer to be written to and a DWORD for the size of the buffer. It also takes a parameter that indicates which value I want returned. The buffer that is passed in is usually a data structure but in this case is the size of an enum. From: To: Time: Mon Mar 12 20:12:40 2007 Enumeration constants are type int, but an enumerator type "shall be compatible with char, a signed integer type, or an unsigned integer type". From: To: Time: Mon Mar 12 20:13:16 2007 and the declaration of the enum type is not anywhere accessible to you? From: To: Time: Mon Mar 12 20:13:25 2007 not in the SDK we want to use From: To: Time: Mon Mar 12 20:13:26 2007 Presumably the implementation knows what sizes can be chosen by the compiler and will DTRT. From: To: Time: Mon Mar 12 20:13:51 2007 Uh. Oh, if the enum type declaration isn't available, you lose. From: To: Time: Mon Mar 12 20:13:52 2007 i guess in that case you get to look up what the ABI specs say about enums From: To: Time: Mon Mar 12 20:14:08 2007 if you're lucky they'll be a consistent size regardless of the enum declaration From: To: Time: Mon Mar 12 20:14:11 2007 Well, under ISO C. Windows may guarantee a specific size. From: To: Time: Mon Mar 12 20:14:29 2007 let me run a simple test and see what I get From: To: Time: Mon Mar 12 20:16:06 2007 also the compiler shouldn't let you take the sizeof on an incomplete type From: To: Time: Mon Mar 12 20:16:39 2007 I don't want to use the type. I want to pass the correct sized integer value in its place From: To: Time: Mon Mar 12 20:18:40 2007 an enum with one value is sizeof(4) == sizeof(DWORD) From: To: Time: Mon Mar 12 20:18:42 2007 I think sizeof(int) is a pretty good bet. Enumeration constants can be that big, and can't be bigger. So while some enumerator types may fit in smaller storage, some won't. If enumerated types are all the same size, they can't be smaller than int, and shouldn't need to be any larger. From: To: Time: Mon Mar 12 20:19:14 2007 well then, the UAC test is going to be trivial to write. From: To: Time: Mon Mar 12 20:21:34 2007 ah, i just reread that bit of c99 and my interpretation agrees with Ken's From: To: Time: Mon Mar 12 20:24:27 2007 the test is: 1. obtain process token 2. query elevation level 3. if level == 3 then we are uac limited in which case mslsa always will report no tickets From: To: Time: Mon Mar 12 20:28:14 2007 How annoying would it be to make it a compile-time error to not be able to figure out the native byte order? I'm tweaking the nonce generation code, changing it from timestamp to random, and lacking a "get random 32-bit integer", I'm fetching 4 random bytes, and want to read them in native order for speed. Overlaying with a union has, at least in theory, some problems with trap representations etc. (But in practice is probably safe on anything we care about.) From: To: Time: Mon Mar 12 20:34:10 2007 do you actually care about the byte order in that case? From: To: Time: Mon Mar 12 20:34:45 2007 the exact-sized integer types (at least _8, _16, _32, and maybe _64) are guaranteed to have no padding bits and be twos complement i think From: To: Time: Mon Mar 12 20:34:49 2007 Not a lot. It just seems silly to reverse the byte order of four random bytes. From: To: Time: Mon Mar 12 20:36:13 2007 ok 7.18.1.1 says all exact-width integer types are required to have no padding and if signed be two's complement From: To: Time: Mon Mar 12 20:36:37 2007 Ah, that's right! Okay, I win. Um, except for Windows, I think. The comments in k5-platform.h indicate it doesn't have uint##_t. From: To: Time: Mon Mar 12 20:37:06 2007 it doesn't? From: To: Time: Mon Mar 12 20:37:40 2007 I don't have a box to check on, but that's what the comment said. From: To: Time: Mon Mar 12 20:38:19 2007 oh look the _WIN32 case in k5-platform.h seems to reference things like __int64 From: To: Time: Mon Mar 12 20:38:28 2007 looks like they're doing namespace cleanliness sort of From: To: Time: Mon Mar 12 21:48:23 2007 uac test implemented From: To: Time: Mon Mar 12 21:48:45 2007 now when UAC is limiting a process MSLSA: returns nothing From: To: Time: Mon Mar 12 21:48:57 2007 That is how it will be for KFW 3.2 From: To: Time: Mon Mar 12 21:50:23 2007 now the auto-import of tickets from the network provider is proving more difficult than expected From: To: Time: Mon Mar 12 21:51:16 2007 the network provider is receiving a decrypt integrity check error when trying to kinit for UAC restricted accounts From: To: Time: Mon Mar 12 21:51:31 2007 I have a feeling I'm not getting the correct password From: To: Time: Tue Mar 13 02:31:12 2007 now this is a problem. I finally get the Vista Integrated Logon to work but I can't commit to the repository. From: To: Time: Tue Mar 13 02:35:33 2007 apparenlty if you do not have forwardable tickets, then svn fails with less than obvious errors. From: To: Time: Tue Mar 13 10:31:31 2007 Well, the repository is in AFS, so that should not be surprising. From: To: Time: Tue Mar 13 15:48:28 2007 the postcommit script does things which require tickets From: To: Time: Tue Mar 13 16:36:52 2007 For hardware preauth, if someone typoes the PIN is it correct that it prompts again rather than returning an error? From: To: Time: Tue Mar 13 16:38:11 2007 (this happens on KfM with the GUI but not the command line, though I don't understand why yet) From: To: Time: Tue Mar 13 16:38:28 2007 Hm; good question. What happens if you are getting tickets with a password? Does an incorrect password result in an error or another prompt? From: To: Time: Tue Mar 13 16:39:05 2007 Oh, hm. At the UI level, KIM should probably give the user more than one chance to enter the PIN. From: To: Time: Tue Mar 13 16:39:27 2007 yeah but it doesn't explain why it is prompting again From: To: Time: Tue Mar 13 16:39:55 2007 also on both the command line and GUI a bad password still results in a prompt for the PIN, even though it is doomed to failure From: To: Time: Tue Mar 13 16:40:30 2007 That's clearly undesirable From: To: Time: Tue Mar 13 16:40:57 2007 Lemme try to figure out why it reprompts on the GUI but not the command line From: To: Time: Tue Mar 13 16:41:39 2007 undesirable, but also unavoidable - you don't know the password is bad until you get a reply to an AS-REQ with correct preauth, which means you need the PIN to know the password is bad. From: To: Time: Tue Mar 13 16:41:50 2007 And actually, it's not clear that it is undesirable. From: To: Time: Tue Mar 13 16:41:52 2007 ah well From: To: Time: Tue Mar 13 16:42:11 2007 well it's undesirable from the user's perspective, probably not from a security standpoint From: To: Time: Tue Mar 13 16:57:12 2007 Okay I understand why I get prompted twice. I'm getting KRB5KDC_ERR_PREAUTH_FAILED from the KDC and the code only breaks out of the loop for KRB5_PREAUTH_FAILED From: To: Time: Tue Mar 13 16:58:07 2007 need to figure out why that doesn't happen for the command line code. it's nearly the same code path on the mac... From: To: Time: Tue Mar 13 17:01:14 2007 Hm. I don't know what generatees KRB5_PREAUTH_FAILED, but the KDC never should - KRB5KDC_ERR_PREAUTH_FAILED is the one that corresponds to the protocol error for that. From: To: Time: Tue Mar 13 17:02:15 2007 (in my library, KRB5KDC_ERR_PREAUTH_FAILED is krb5.24, and KRB5_PREAUTH_FAILED is krb5.209, but yours may be different - Heimdal and MIT kerberos do not fully agree on codes in the krb5.* space that do not correspond to standardized protocol errors) From: To: Time: Tue Mar 13 17:14:52 2007 So if the password was bad I see KRB5KRB_AP_ERR_BAD_INTEGRITY and if the PIN was bad I see KRB5KDC_ERR_PREAUTH_FAILED. From: To: Time: Tue Mar 13 17:15:24 2007 Neither error is checked by the use_master loop so in both cases I get prompted twice for the securID pin From: To: Time: Tue Mar 13 17:31:54 2007 Well, those are the errors I would expect to get from the KDC in those cases. From: To: Time: Tue Mar 13 17:32:31 2007 Rather, KRB5KDC_ERR_PREAUTH_FAILED is from the KDC; the other is actually generated locally, when the EncKdcRepPart fails to decrypt From: To: Time: Tue Mar 13 17:43:14 2007 anyone seen sam lately? From: To: Time: Tue Mar 13 20:08:26 2007 anyone with a securid principal on? From: To: Time: Tue Mar 13 20:09:26 2007 I think you are the only one From: To: Time: Tue Mar 13 20:09:39 2007 ah I thought tom and ken got them From: To: Time: Tue Mar 13 20:10:01 2007 I talked to Jeff about their use of them a while back, but I haven't gotten one. From: To: Time: Tue Mar 13 20:11:24 2007 Mine stopped working and I'm wondering if I managed to lock myself out with too many bad attempts From: To: Time: Tue Mar 13 20:12:05 2007 Wait 10 min or so From: To: Time: Tue Mar 13 20:13:05 2007 ah that's annoying. I'm debugging the "bad password" case From: To: Time: Tue Mar 13 20:14:12 2007 also I seem to have a kinit that behaves differently depending on whether it is built with optimization turned on. From: To: Time: Tue Mar 13 20:14:43 2007 even though the code that behaves differently isn't in the kinit but in a framework that doesn't change in the two cases From: To: Time: Tue Mar 13 20:18:00 2007 maybe there's uninitialized stuff somewhere From: To: Time: Tue Mar 13 20:18:03 2007 stack content or stack pointer dependent? sounds like a good case for valgrind or similar. From: To: Time: Tue Mar 13 20:19:13 2007 what's different is that the "master kdc" loop doesn't get run the second time for the optimized version (although it does run for the optimized version of KerberosAgent From: To: Time: Tue Mar 13 20:19:15 2007 i got a SecurID for my root instance. it works. From: To: Time: Tue Mar 13 20:21:00 2007 lxs, maybe instead of a real securid, you want a KDC hacked up to behave like you have one From: To: Time: Tue Mar 13 20:21:52 2007 I can loop on trying the bad password case even if I'm locked out. I was just wondering if lockout can happen From: To: Time: Tue Mar 13 20:22:25 2007 also, lukeh's get_init_creds error handling stuff i was talking about is in ticket #3334 From: To: Time: Tue Mar 13 20:22:41 2007 the grail stuff does not reproduce any of these bugs, which is why I'm using this From: To: Time: Tue Mar 13 20:22:55 2007 BTW, is this sam2 or sam From: To: Time: Tue Mar 13 20:23:02 2007 sam2 I think From: To: Time: Tue Mar 13 20:31:50 2007 hmm waiting 10 minutes did not fix it From: To: Time: Tue Mar 13 20:32:11 2007 what errors? From: To: Time: Tue Mar 13 20:32:24 2007 kinit(v5): Preauthentication failed while getting initial credentials From: To: Time: Tue Mar 13 20:33:09 2007 hm, perhaps it does have a lockout. From: To: Time: Tue Mar 13 20:33:44 2007 but i need to leave now From: To: Time: Tue Mar 13 20:34:05 2007 I guess I'll try tomorrow. this stupid thing is bugs all the way down From: To: Time: Wed Mar 14 01:38:00 2007 Since it's possible not everyone reads the other place... /afs/cs.cmu.edu/misc/aaa/src/aaa-head/tests/kdcfake.c is source for an LD_PRELOAD object which simulates an attacker out on the network who has a fake KDC that always gets to answer before the real one (in fact, it currently never even sends the request to the real one, though that could be changed). From: To: Time: Wed Mar 14 01:38:42 2007 It is intended for use in testing things that do initial authentication for the purpose of validating a password, such as login. From: To: Time: Wed Mar 14 01:43:04 2007 It currently depends on heimdal's libraries and should only be expected to work if loaded into a program that is using the same libraries as it. But both of those could be fixed, by someone with sufficient motivation. In any case, the license is quite permissive, so do what you will with it, but I'll be disappointed if someone makes improvements and doesn't contribute them back. From: To: Time: Wed Mar 14 10:15:28 2007 I'd expect that with the Debian libraries it really ought to already work in a mixed implementation environment From: To: Time: Wed Mar 14 10:48:44 2007 You'd have to build it in such a way that the krb5 library it loads doesn't poison the app's namespace. From: To: Time: Wed Mar 14 10:49:04 2007 loading with RTLD_GROUP isn't enough? From: To: Time: Wed Mar 14 10:49:13 2007 Oh, also, it only does udp-over-IPv4 From: To: Time: Wed Mar 14 10:49:52 2007 When setting LD_PRELOAD, exactly how does one tell the dynamic loader that the library in question should be loaded with RTLD_GROUP? From: To: Time: Wed Mar 14 10:50:15 2007 oh right From: To: Time: Wed Mar 14 10:51:01 2007 though if you wanted to be really kludgey you could LD_PRELOAD a module which dlopen the actual object with RTLD_GROUP From: To: Time: Wed Mar 14 10:51:31 2007 Actually, does Linux even support RTLD_GROUP? I can't find evidence of such in the dlopen man page, but of course that could be because libc is GNU software and the GNU project doesn't believe in maintaining man pages From: To: Time: Wed Mar 14 10:51:59 2007 Yes, and in fact I've been considering that technique for PAM and NSS modules on platforms where the framework is lame. From: To: Time: Wed Mar 14 11:03:31 2007 Debian has symbol versions for all of its krb5 libs. From: To: Time: Wed Mar 14 11:04:29 2007 I thought there was an elf header bit similar to rtld_group as well From: To: Time: Wed Mar 14 11:04:42 2007 yeah i think so... From: To: Time: Wed Mar 14 11:05:01 2007 but i poked a little bit at glibc sources and didn't see anything that obviously implemented RTLD_GROUP From: To: Time: Wed Mar 14 12:46:08 2007 Oh, yes, symbol versions should do the trick. From: To: Time: Wed Mar 14 14:53:13 2007 I don't have delegate access to North Station again so I can't fix the meeting From: To: Time: Wed Mar 14 14:54:30 2007 oh what's even cuter is that the bogus meeting tomorrow conflicts with another meeting ;-) From: To: Time: Wed Mar 14 14:59:45 2007 wait what happened? From: To: Time: Wed Mar 14 15:01:25 2007 ok, fixed From: To: Time: Wed Mar 14 15:02:16 2007 also adium showed lxs's messages an hour ahead From: To: Time: Wed Mar 14 15:05:50 2007 weird, my messages look normal to me From: To: Time: Wed Mar 14 15:08:18 2007 okay I suck. where is north station? From: To: Time: Wed Mar 14 19:15:40 2007 Ick. Key stash files are byte order specific. From: To: Time: Wed Mar 14 19:16:15 2007 isn't it a bug that they're not just keytabs, anyway? From: To: Time: Wed Mar 14 19:16:35 2007 Well, there's that too, yeah. From: To: Time: Wed Mar 14 19:16:46 2007 (they also don't have key type info, right? which bit me on a recent upgrade) From: To: Time: Wed Mar 14 19:18:49 2007 Actually, the enctype field does appear to be stored, and is part of the reason it's byte order specific. We store a krb5_ui_2 and then an unsigned int. From: To: Time: Wed Mar 14 19:21:35 2007 The keytab files do have magic numbers that don't correspond to any (existing) enctpes, though. From: To: Time: Thu Mar 15 09:17:21 2007 svn ls From: To: Time: Thu Mar 15 09:18:19 2007 Oops. I'm trying to create /users/kpkoch in svn. But all svn ls shows from my klrb5 directory is doc and src. Wher is users? From: To: Time: Thu Mar 15 09:20:04 2007 same level as trunk. From: To: Time: Thu Mar 15 09:20:19 2007 You can go to anonsvn.mit.edu (the website) to look at the repository. From: To: Time: Thu Mar 15 09:21:02 2007 So something like svn mkdir svn+ssh://svn.mit.edu/krb5/users/kpkoch From: To: Time: Thu Mar 15 09:48:16 2007 svn mkdir svn+ssh://kpkoch@svn.mit.edu/krb5/users/kpkoch worked. Thanks. svn ls still doesn't show users. Why was the URL required for svn mkdir but not for svn ls? anonsvn.mit.edu/krb5 shows HTTP 404. anonsvn.mit.edu shows "Parent Directory" and nothing else. From: To: Time: Thu Mar 15 09:50:06 2007 http://anonsvn.mit.edu/svn/krb5 From: To: Time: Thu Mar 15 09:52:46 2007 svn co -? From: To: Time: Thu Mar 15 09:54:11 2007 I don't understand From: To: Time: Thu Mar 15 10:02:38 2007 I have to make sure the window I'm looking at is the one with focus. From: To: Time: Thu Mar 15 15:25:24 2007 sin_zero isn't guaranteed to be zero on all platforms is it? From: To: Time: Thu Mar 15 15:25:38 2007 (in struct sockaddr_in) From: To: Time: Sun Mar 18 02:02:17 2007 MIt Kerberos Development Team From: To: Time: Sun Mar 18 02:02:18 2007 raeburn@mit.edu has set the topic to: use /topic From: To: Time: Tue Mar 20 03:27:32 2007 any idea if ticket 5446 will be addressed before the end of the week? From: To: Time: Tue Mar 20 05:01:46 2007 Yay, I got the Adium patch from lxs working. Though I don't see how I can tell it *which* Jabber account to use. From: To: Time: Wed Mar 21 11:09:59 2007 you know, if you don't trust your users to not misbehave with their root access, maybe you shouldn't give them root access... From: To: Time: Wed Mar 21 11:20:16 2007 Can anyone else see https://krbdev.mit.edu/rt/Ticket/Display.html?id=5446? I get "Cannot find server or DNS Error." From: To: Time: Wed Mar 21 12:04:39 2007 interesting From: To: Time: Wed Mar 21 12:04:42 2007 checking From: To: Time: Wed Mar 21 12:06:10 2007 krbdev is refusing connections on port 22 as well From: To: Time: Wed Mar 21 12:07:43 2007 Can we ask Alexis to reboot when she gets in? From: To: Time: Wed Mar 21 12:08:21 2007 was there a power failure perhaps? From: To: Time: Wed Mar 21 12:18:16 2007 last successful mail from krbdev was ticket #5480 around 00:14 this morning From: To: Time: Wed Mar 21 12:35:40 2007 no answer on finger either. probably panicked or something. From: To: Time: Wed Mar 21 12:35:50 2007 or is sitting waiting for manual fsck From: To: Time: Wed Mar 21 13:18:16 2007 krbdev needs rebootings? From: To: Time: Wed Mar 21 13:18:43 2007 not sure From: To: Time: Wed Mar 21 13:18:55 2007 looks like it may be in a very bad state From: To: Time: Wed Mar 21 13:19:08 2007 how do you look at its console? From: To: Time: Wed Mar 21 13:19:22 2007 pinging but not responding to tcp connections at all From: To: Time: Wed Mar 21 13:19:25 2007 serial console From: To: Time: Wed Mar 21 13:20:03 2007 is it on the main serial console for the machine room or do I need a console on a cart? From: To: Time: Wed Mar 21 13:20:23 2007 you need the console on the cart From: To: Time: Wed Mar 21 13:20:33 2007 and you may need to mess with null modems From: To: Time: Wed Mar 21 13:20:51 2007 bleh, okay I can try to get it hooked up From: To: Time: Wed Mar 21 13:21:11 2007 i think you need one null modem and maybe a gender changer From: To: Time: Wed Mar 21 13:21:20 2007 going offline to change location From: To: Time: Wed Mar 21 13:21:22 2007 I'll go try now and see what I can do and come back and report From: To: Time: Wed Mar 21 13:40:25 2007 FYI it was probably up at 06:34 today because it successfully wrote the backup dump to AFS From: To: Time: Wed Mar 21 13:41:15 2007 re generalstring: "never ask that question!" From: To: Time: Wed Mar 21 13:44:31 2007 oh. jweiss says krbdev logged disk errorrs From: To: Time: Wed Mar 21 13:45:54 2007 So, Kevin how critical is this for you? This may be hard to fix while we're in Prague. From: To: Time: Wed Mar 21 13:47:46 2007 if we can get an inter-rack serial patch going somehow, i might be able to deal remotely From: To: Time: Wed Mar 21 13:48:02 2007 Well, not if it actually has a dead disk From: To: Time: Wed Mar 21 13:48:11 2007 depends on how dead From: To: Time: Wed Mar 21 13:51:08 2007 trying to extract dying gasps from jweiss From: To: Time: Wed Mar 21 13:51:17 2007 wait, that didn't sound quite right From: To: Time: Wed Mar 21 13:51:27 2007 Anyone in Prague interested in dinner? From: To: Time: Wed Mar 21 13:51:39 2007 Why would jweiss be emitting dying gasps? From: To: Time: Wed Mar 21 13:51:47 2007 he wouldn't From: To: Time: Wed Mar 21 13:51:58 2007 he caught the dying gasps of krbdev.mit.edu via remote syslog From: To: Time: Wed Mar 21 13:52:13 2007 Ah. From: To: Time: Wed Mar 21 13:56:24 2007 at least we have a recent-ish dump of the database From: To: Time: Wed Mar 21 13:59:00 2007 krbdev is really sad. it's not responding to the console. Garry is going to help me look at it in about an hour. If it needs a new disk, what do I restore from? From: To: Time: Wed Mar 21 13:59:25 2007 not easily From: To: Time: Wed Mar 21 13:59:28 2007 we have a dump From: To: Time: Wed Mar 21 13:59:35 2007 restoring the software will be a little more tricky From: To: Time: Wed Mar 21 13:59:47 2007 why was the machine not backed up? From: To: Time: Wed Mar 21 14:00:21 2007 (and more importantly how do we change that so we don't go through this again) From: To: Time: Wed Mar 21 14:00:34 2007 we have a mkserv which in theory works From: To: Time: Wed Mar 21 14:00:38 2007 i don't think we've ever tested it From: To: Time: Wed Mar 21 14:00:56 2007 also, i'm not sure we can install the version of athena that's running on krbdev anymore, so that will complicate matters From: To: Time: Wed Mar 21 14:00:58 2007 Trial by fire is always good. From: To: Time: Wed Mar 21 14:01:30 2007 could we bring it up on krbdev-new? From: To: Time: Wed Mar 21 14:01:47 2007 different OS version From: To: Time: Wed Mar 21 14:01:59 2007 i can try to re-do the RT install on krbdev-new From: To: Time: Wed Mar 21 14:02:29 2007 getting a serial console cross-wired to something that's alive would be useful From: To: Time: Wed Mar 21 14:02:53 2007 it doesn't respond to any of the break commands. having a serial console isn't helpful in its current state From: To: Time: Wed Mar 21 14:03:04 2007 how is it wired up? From: To: Time: Wed Mar 21 14:03:07 2007 I get character echo and that's it From: To: Time: Wed Mar 21 14:03:18 2007 oh it echoes? From: To: Time: Wed Mar 21 14:03:20 2007 yeah From: To: Time: Wed Mar 21 14:03:44 2007 what break commands did you try? From: To: Time: Wed Mar 21 14:05:05 2007 C-\ b and ~ C-b From: To: Time: Wed Mar 21 14:05:16 2007 which was what garry suggested From: To: Time: Wed Mar 21 14:05:18 2007 Hm. krbdev is supposedly a 220R; doesn't that mean it has the old-style LOM? From: To: Time: Wed Mar 21 14:05:51 2007 are you on the vt220? From: To: Time: Wed Mar 21 14:05:54 2007 yes From: To: Time: Wed Mar 21 14:06:06 2007 Why not pull power and reapply. From: To: Time: Wed Mar 21 14:06:07 2007 oh, you want to hit something like F4, i think From: To: Time: Wed Mar 21 14:06:12 2007 well not now. I went back to my office when garry offered to help in a bit From: To: Time: Wed Mar 21 14:06:24 2007 F4 for serial line break From: To: Time: Wed Mar 21 14:06:32 2007 okay I can try that From: To: Time: Wed Mar 21 14:07:12 2007 it might be one of the other low-numbered F keys. i don't remember From: To: Time: Wed Mar 21 14:07:47 2007 oh, F5 From: To: Time: Wed Mar 21 14:07:56 2007 I thought it was F5. It's certainly one of the first 5. On some keyboards it will be labelled. From: To: Time: Wed Mar 21 14:09:27 2007 i think it's not labeled on a vt220 From: To: Time: Wed Mar 21 14:09:51 2007 though it might depend on which f-key insert you have From: To: Time: Wed Mar 21 14:10:22 2007 It depends. I have used vt220's where it was labelled. From: To: Time: Wed Mar 21 14:10:33 2007 Of course, the keyboards of that era were all interchangeable... From: To: Time: Wed Mar 21 14:13:04 2007 I got an ok prompt From: To: Time: Wed Mar 21 14:14:18 2007 "go" just sends me back into the unresponsive state From: To: Time: Wed Mar 21 14:14:21 2007 good... so it's listening From: To: Time: Wed Mar 21 14:14:31 2007 Oh, excellent. From: To: Time: Wed Mar 21 14:14:32 2007 type "boot" at the "ok" prompt From: To: Time: Wed Mar 21 14:14:37 2007 okay From: To: Time: Wed Mar 21 14:14:49 2007 I don't have jabber in there so this will take a bit From: To: Time: Wed Mar 21 14:15:10 2007 Well, there's always zephyr. :-) From: To: Time: Wed Mar 21 14:18:02 2007 okay so that was an unmitigated failure. it logged several pages of read errors followed by a panic and ok prompt From: To: Time: Wed Mar 21 14:18:24 2007 the good news is that it's memory is okay ;-) From: To: Time: Wed Mar 21 14:18:47 2007 it needs a new disk From: To: Time: Wed Mar 21 14:19:01 2007 oh so it panicked before it finished booting? From: To: Time: Wed Mar 21 14:19:14 2007 it didn't boot so much as log errors From: To: Time: Wed Mar 21 14:19:19 2007 how far did it get before it started getting disk errors? From: To: Time: Wed Mar 21 14:19:29 2007 the memory check passed. then disk errors From: To: Time: Wed Mar 21 14:19:47 2007 Short read. 0x2000 bytes read. From: To: Time: Wed Mar 21 14:19:54 2007 ok, so something blew a hole in the kernel, or the filesystem is hosed so badly the kernel can't load From: To: Time: Wed Mar 21 14:20:32 2007 I'm guessing based on: Mar 21 06:36:31 KRBDEV.MIT.EDU scsi: [ID 107833 kern.warning] WARNING: /pci@1f,4000/scsi@3/sd@0,0 (sd0): Mar 21 06:36:31 KRBDEV.MIT.EDU Error for Command: read Error Level: Fatal that it's the disk From: To: Time: Wed Mar 21 14:20:40 2007 at this point hard power cycle giving it a few minutes to cool may or may not improve matters but it's hard to make things worse at this stage From: To: Time: Wed Mar 21 14:20:54 2007 which is what urania logged before it crapped itself From: To: Time: Wed Mar 21 14:20:59 2007 That's not enough information to guess that. From: To: Time: Wed Mar 21 14:21:33 2007 ah okay on a Mac that sort of thing would be a disk thing. Then again on a Mac I'd have it in firewire target disk mode by now From: To: Time: Wed Mar 21 14:21:37 2007 From what I saw in the log Tom showed me, there could be something wrong with the disk, or you could be seeing transient read errors resulting from things like a bad disk power supply. From: To: Time: Wed Mar 21 14:22:02 2007 it has two power supplies based on the # of power cords coming out of it From: To: Time: Wed Mar 21 14:22:06 2007 Oh, it's certainly some kind of disk access error. But you didn't actually quote enough lines to tell the difference between a problem with the disk and a problem with the host controller or cabling. From: To: Time: Wed Mar 21 14:22:21 2007 Mar 21 06:36:31 KRBDEV.MIT.EDU scsi: [ID 107833 kern.warning] WARNING: /pci@1f,4000/scsi@3/sd@0,0 (sd0): Mar 21 06:36:31 KRBDEV.MIT.EDU Error for Command: read Error Level: Fatal Mar 21 06:36:31 KRBDEV.MIT.EDU scsi: [ID 107833 kern.notice] Requested Block: 27760 Error Block: 27768 Mar 21 06:36:31 KRBDEV.MIT.EDU scsi: [ID 107833 kern.notice] Vendor: IBM Serial Number: 0122150481 Mar 21 06:36:31 KRBDEV.MIT.EDU scsi: [ID 107833 kern.notice] Sense Key: Media Error Mar 21 06:36:31 KRBDEV.MIT.EDU scsi: [ID 107833 kern.notice] ASC: 0x11 (unrecovered read error), ASCQ: 0x0, FRU: 0x0 is what garry sent me From: To: Time: Wed Mar 21 14:22:39 2007 sorry I missed the media error line. From: To: Time: Wed Mar 21 14:22:41 2007 the logs jweiss quoted included another block number too From: To: Time: Wed Mar 21 14:23:06 2007 use the front panel power button? From: To: Time: Wed Mar 21 14:23:17 2007 Yeah, so that means the disk actually detected a media error. Which _probably_ means there really is something wrong with the media. But it could be a problem that will go away if new data is written onto that block -- that is, it may be that the disk itself is salvageable, and it's just the contents that are gone. From: To: Time: Wed Mar 21 14:23:57 2007 I can try powering it off and on but I don't want to keep rebooting it until it trashes the disk more and I don't know much about suns at all From: To: Time: Wed Mar 21 14:24:11 2007 it'll sit at a manual fsck prompt if it's that badly hosed From: To: Time: Wed Mar 21 14:24:14 2007 I don't think you need to worry about that. From: To: Time: Wed Mar 21 14:24:24 2007 oh is it multiple partitions? From: To: Time: Wed Mar 21 14:24:54 2007 well either it boots far enough to run fsck or it doesn't... From: To: Time: Wed Mar 21 14:25:35 2007 it didn't boot much at all the one time I tried. The /-\-/ sequence rotated maybe twice and then it was all read errors From: To: Time: Wed Mar 21 14:26:23 2007 I think there was one other log message but it scrolled away before I could memorize it. Too many read errors From: To: Time: Wed Mar 21 14:26:46 2007 yeah... the power cycle is to see if cooling off and resetting hard will help the hardware From: To: Time: Wed Mar 21 14:26:55 2007 okay I'll power it off From: To: Time: Wed Mar 21 14:29:42 2007 I powered it off and it's resting now. I also missed the error before it paniced when I tried to boot it. that error was: krtld: error during initial load/link phase From: To: Time: Wed Mar 21 14:29:52 2007 or something like that From: To: Time: Wed Mar 21 14:30:25 2007 then I get a panic message From: To: Time: Wed Mar 21 14:30:26 2007 yeah, that sounds very sad From: To: Time: Wed Mar 21 14:57:31 2007 heading dinner-wards... back later From: To: Time: Wed Mar 21 15:02:27 2007 anyone here who knows where the RT database is on krbdev? is it in /var/postgres? From: To: Time: Wed Mar 21 15:03:44 2007 because if it is I think we may be able to get back, oh, 2/3rds of it. I'm not sure if that's useful but we'll try From: To: Time: Wed Mar 21 15:04:07 2007 anyway back to machine room From: To: Time: Wed Mar 21 15:37:55 2007 For those who care I have a blank disk in krbdev which I am installing Athena onto. The dead disk is mountable and a sizable portion of the data gives I/O errors when you try to read it. Once the new disk/OS is ready I'll set up login access and folks can try to recover as much of the data as possible From: To: Time: Wed Mar 21 18:02:18 2007 when was the last backup? From: To: Time: Wed Mar 21 18:03:58 2007 I don't know. gotta go but I'll be online later From: To: Time: Wed Mar 21 18:14:15 2007 sorry, dinner took quite a bit longer than expected From: To: Time: Wed Mar 21 18:15:27 2007 we have a dump from this morning that postdates any modifications that sent mail, i think From: To: Time: Wed Mar 21 18:16:15 2007 at least we didn't lose anything then From: To: Time: Wed Mar 21 18:16:31 2007 there may have been edits which didn't send mail but i doubt it From: To: Time: Wed Mar 21 18:39:47 2007 were you able to get into the new krbdev? From: To: Time: Wed Mar 21 18:40:56 2007 yeah, i'm in From: To: Time: Wed Mar 21 18:41:00 2007 thanks for dealing From: To: Time: Wed Mar 21 18:41:10 2007 i'm running fsck -n on the mounted /saddisk From: To: Time: Wed Mar 21 18:41:34 2007 not a problem. Note that stating files on the sad disk produces media errors From: To: Time: Wed Mar 21 18:41:41 2007 ur statting that is From: To: Time: Wed Mar 21 18:41:55 2007 so your fsck may fail From: To: Time: Wed Mar 21 18:42:26 2007 i'm sure it'll fail. i'm just wondering if metadata is hoz3d From: To: Time: Wed Mar 21 18:44:06 2007 ok, fsck -n doesn't get very far at all From: To: Time: Wed Mar 21 18:45:01 2007 wait, how did this mount at all? From: To: Time: Wed Mar 21 18:45:27 2007 krbdev.mit.edu# prtvtoc /dev/rdsk/c0t1d0s2 prtvtoc: /dev/rdsk/c0t1d0s2: Unable to read Disk geometry errno = 0x5 From: To: Time: Wed Mar 21 18:45:51 2007 do not look into disk with remaining eye ;-) From: To: Time: Wed Mar 21 18:46:01 2007 yeah From: To: Time: Wed Mar 21 18:46:22 2007 I'd just try to get config files and scripts off. Anything that might not be backed up From: To: Time: Wed Mar 21 18:46:49 2007 this looks kinda not-good: From: To: Time: Wed Mar 21 18:46:51 2007 krbdev.mit.edu# dd if=/dev/rdsk/c0t1d0s2 count=8 of=/dev/null dd: /dev/rdsk/c0t1d0s2: open: I/O error From: To: Time: Wed Mar 21 18:46:56 2007 how recent was the last dump of the database? maybe the data on the disk isn't worth trying to salvage From: To: Time: Wed Mar 21 18:47:16 2007 last dump was 06:00-ish this morning From: To: Time: Wed Mar 21 18:47:19 2007 the I/O errors are spread out over the disk, you can read some files but not others. I would not try to use dd From: To: Time: Wed Mar 21 18:47:38 2007 i might just try to rebuild onto krbdev-new From: To: Time: Wed Mar 21 18:47:54 2007 krbdev-new has mirrored disks, too From: To: Time: Wed Mar 21 18:48:21 2007 Garry offered us mirrored disks for the old machine once we were done trying to salvage the dead disk From: To: Time: Wed Mar 21 18:48:41 2007 but the new machine would be better since it's newer and we were supposed to upgrade to it anyway. From: To: Time: Wed Mar 21 18:48:45 2007 true From: To: Time: Wed Mar 21 18:49:40 2007 not that krbdev-new is really all that new anymore From: To: Time: Wed Mar 21 18:49:43 2007 ;-) From: To: Time: Wed Mar 21 18:49:54 2007 details... From: To: Time: Wed Mar 21 18:50:02 2007 we're supposed to get this shiny new virtual server right? From: To: Time: Wed Mar 21 18:50:14 2007 I think so From: To: Time: Wed Mar 21 18:51:18 2007 hm is the last dump late enough that it would have caught the disk errors? It looks like the disk errors started logging right around that time. We may need the previous day's dump as well From: To: Time: Wed Mar 21 18:51:53 2007 yeah, we've got those From: To: Time: Wed Mar 21 18:51:58 2007 cool From: To: Time: Wed Mar 21 18:52:10 2007 i think there are a few scripts and config files here and there that were not backed up From: To: Time: Wed Mar 21 18:52:48 2007 you might be able to get those off the dead disk if you're careful From: To: Time: Wed Mar 21 18:53:13 2007 and lucky ;-) From: To: Time: Wed Mar 21 18:57:57 2007 wow it doesn't even want to read the first block now From: To: Time: Wed Mar 21 18:58:24 2007 i think garry got lucky and mounted the disk before it stopped reading and the only we can get to was the stuff that got sucked into buffer cache From: To: Time: Wed Mar 21 19:06:36 2007 ah well From: To: Time: Wed Mar 21 19:07:00 2007 we actually had it mounted for a while and statted a large portion of the stuff in /var. From: To: Time: Wed Mar 21 19:07:50 2007 now if solaris only had some commands to issue power-on and power-off commands to scsi devices... From: To: Time: Wed Mar 21 19:09:37 2007 oh, this cfgadm thing might help From: To: Time: Thu Mar 22 06:36:07 2007 Anyone in Prague interested in lunch? From: To: Time: Thu Mar 22 08:28:36 2007 [raeburn has set the topic to: Kerberos] From: To: Time: Thu Mar 22 11:19:15 2007 if the timestamps are to believed, the dump succeeded a few minutes before the disk errors were logged From: To: Time: Thu Mar 22 11:27:44 2007 still not reading anything at all successfully from the dead disk. i'm going ahead and rebuilding stuff on krbdev-new From: To: Time: Thu Mar 22 12:16:10 2007 do we have a decision yet on whether or not Leash is being pulled? If it is I want to disable the building of the AFS functionality in the leashw32.dll library. From: To: Time: Thu Mar 22 12:23:16 2007 We're disabling afs. Kevin believes he has patches to check in pending krbdev Fell free to ask for them from him if you want to review them From: To: Time: Thu Mar 22 12:24:51 2007 disabling AFS is as easy as not building with "MIT_ONLY" defined From: To: Time: Thu Mar 22 12:24:58 2007 what are his patches? From: To: Time: Thu Mar 22 12:25:26 2007 Not including MIT_ONLY Dropping the sources for afscompat from what we put into the sdk zip From: To: Time: Thu Mar 22 12:26:40 2007 we never distributed those files so I'm not concerned. the question really was "is Leash32.exe going to be distributed at MIT or not?" because MIT has required the AFS functionality in the past. From: To: Time: Thu Mar 22 12:27:24 2007 leash_32 is probably going to be distributed. However SWRT has been told they are not getting AFS and has said they do not care. From: To: Time: Thu Mar 22 12:28:05 2007 Right, but it's critical that we not distribute those files, and so Kevin either needed to write some code so that the source zip was different from the build tree or we need to drop those from the sources we use for building From: To: Time: Thu Mar 22 12:30:18 2007 I agree that is something Kevin had to do. I was concerned that you were describing changes to the Leash sources that he was going to check in From: To: Time: Thu Mar 22 12:49:21 2007 Look for "Prunes" in ...\krb5\src\windows\build\bkwconfig.xml. afsauth, aklog and vs are removed from the source tree before building. From: To: Time: Thu Mar 22 12:52:41 2007 I really should have added a operating system version check into the 3.1.1 installers to prevent them from installing on Vista From: To: Time: Thu Mar 22 12:56:56 2007 Why? From: To: Time: Thu Mar 22 12:57:32 2007 because of all the bug reports From: To: Time: Thu Mar 22 13:00:18 2007 kfw 3.1.x doesn't work well on vista. we know that. it also doesn't help that at least one of the Microsoft LSA calls corrupt our process. LsaGetLogonSecurityData cannot be called on Vista without doing bad things to the caller. I've filed a bug report with Microsoft. From: To: Time: Thu Mar 22 13:01:40 2007 KfW 3.x regresses wrt 2.6.5 on XP also. SecureCRT and svn don't work because plink fails. From: To: Time: Thu Mar 22 13:02:23 2007 have you tested the current code? From: To: Time: Thu Mar 22 13:02:36 2007 and why does plink fail? From: To: Time: Thu Mar 22 13:03:42 2007 does plink fail because the correct ccache name does not get returned to the gssapi by leashw32? If so, that was fixed. From: To: Time: Thu Mar 22 13:06:13 2007 Yes. I have tested a build based on yesterday's code. From: To: Time: Thu Mar 22 13:06:28 2007 The console output is 'plink.exe': Loaded 'C:\Program Files\MIT\Kerberos\bin\krbv4w32.dll', Symbols loaded. SecureClient::SecureClient: Cannot open thread token (1008) INIT: Running on Windows NT using secure mode SecureClient::SecureClient: Cannot open thread token (1008) From: To: Time: Thu Mar 22 13:07:21 2007 followed by a lot of those 'Cannot open thread token' messages. Finally, after some timeout, it says the connection closed unexpectedly. From: To: Time: Thu Mar 22 13:08:37 2007 you do realize of course that plink is used by Windows svn in order for me to commit code to repository. so I know that it works. From: To: Time: Thu Mar 22 13:08:59 2007 So, you want to break on gss_init_sec_ctx and see why it is failing From: To: Time: Thu Mar 22 13:09:29 2007 those messages you are quoting are debug output strings from the RPC communications between the client krbcc32.dll and krbcc32s.exe From: To: Time: Thu Mar 22 13:09:31 2007 And Secure CRT has nothing to do with plink From: To: Time: Thu Mar 22 13:09:33 2007 I have not been able to commit when 3.2 is installed. From: To: Time: Thu Mar 22 13:10:33 2007 that is probably because you are using a version of putty.exe and plink.exe that are broken with regards to calling gss_release_buffer() on a buffer that was not allocated by gss From: To: Time: Thu Mar 22 13:10:52 2007 it is not kfw that is broken From: To: Time: Thu Mar 22 13:11:16 2007 krb5 1.6 no longer has the code in gss_release_buffer to avoid freeing memory that was not allocated by it. From: To: Time: Thu Mar 22 13:11:51 2007 Jeff, I don't think that is true. I think a check was added back but you'd need to confirm with Tom From: To: Time: Thu Mar 22 13:12:09 2007 was there ever a check of that sort for release_buffer? From: To: Time: Thu Mar 22 13:12:40 2007 O, no. From: To: Time: Thu Mar 22 13:13:10 2007 i didn't think there was. we may want to add one though. From: To: Time: Thu Mar 22 13:13:13 2007 a while back Ken and I added a check on the magic value. if the magic value didn't match we didn't free the memory and simply returned success. it results in a memory leak but oh well From: To: Time: Thu Mar 22 13:13:24 2007 on the other hand, mechglue makes that much more difficult. From: To: Time: Thu Mar 22 13:14:29 2007 apple found a large number of bugs in their gss application code when the mechglue was added From: To: Time: Thu Mar 22 13:15:08 2007 Hey, those are the messages that come out when I run plink. [SecureClient] I had the problems when using the plink pulled from http://stuff.mit.edu/afs/athena.mit.edu/user/j/a/jaltman/Public/??. I can't find it there right now. I made a debug build of some other plink sources to be able to debug. From: To: Time: Thu Mar 22 13:15:46 2007 You should not need a debug build of plink; only krb5 From: To: Time: Thu Mar 22 13:16:24 2007 Well, not knowing offhand how plink gets into krb5, I started with plink. From: To: Time: Thu Mar 22 13:16:39 2007 well you might want a debugging version of the calling application if you are not familiar with the GSSAPI. I certainly needed to see the calling application the first time I debugged GSAPI apps From: To: Time: Thu Mar 22 13:17:02 2007 See RFC 4556 for the protocol plink is using and for what gssapi clls it makes From: To: Time: Thu Mar 22 13:17:11 2007 otherwise you have to painstakingly record the addresses of all the inputs to figure out what is going on because you don't just know what objects get reused From: To: Time: Thu Mar 22 13:18:42 2007 *shrug* I learn much better from example code than RFCs, especially when the code doesn't actually obey the RFC (something which occurs far too often) From: To: Time: Thu Mar 22 13:18:49 2007 ymmv though From: To: Time: Thu Mar 22 13:20:36 2007 WRT gss_init_sec_ctx: The breakpoint will not currently be hit. Native engine does not support expressions in this language. What language is it written in?? From: To: Time: Thu Mar 22 13:20:51 2007 C From: To: Time: Thu Mar 22 13:27:09 2007 Another thing about plink. Changing which kfw is installed changes whether or not plink works. From: To: Time: Thu Mar 22 13:31:00 2007 you should not even need a debug build of krb5 From: To: Time: Thu Mar 22 13:31:18 2007 we build symbols for release builds. they are all you need From: To: Time: Thu Mar 22 13:32:23 2007 load plink.exe into visual studio. load the source file you want to place a breakpoint in. go to the line you want the breakpoint to be placed at. Press F9 to add the breakpoint. Run the process and when the module is loaded that matches the breakpoint it will become active. From: To: Time: Thu Mar 22 13:38:02 2007 I think you are looking for /afs/athena.mit.edu/user/j/a/jaltman/Public/putty-with-gssapi/ which contains builds of putty plus the symbol files you will need From: To: Time: Thu Mar 22 13:38:19 2007 it was last updated on 2/25/2007 From: To: Time: Thu Mar 22 13:59:12 2007 Tom, could we disable the script on svn and just run all the commit logs by hand after you get things set up to create tickets From: To: Time: Thu Mar 22 13:59:52 2007 better would be if you modified the commit script to journal the info somewhere :-) From: To: Time: Thu Mar 22 14:00:12 2007 How is krbdev.mit.edu coming along? From: To: Time: Thu Mar 22 14:00:18 2007 The script talks to RT directly rather than via email, right? From: To: Time: Thu Mar 22 14:01:22 2007 The script talks to rt, but the info is journaled in the log. I'm going to turn off the script and we can rerun it when we get things later From: To: Time: Thu Mar 22 14:01:25 2007 still building stuff... about to try actually doing the RT perl module hell From: To: Time: Thu Mar 22 14:01:46 2007 Sam, you want to turn off only the RT part of the script not the whole thing right? From: To: Time: Thu Mar 22 14:02:17 2007 I'm curious because I'd like to put out a release From: To: Time: Thu Mar 22 14:02:32 2007 I was going to do it all later, but I could turn off only rt. From: To: Time: Thu Mar 22 14:04:24 2007 OK, I think it safe to check in now; we can do the rt actions later. From: To: Time: Thu Mar 22 14:08:11 2007 Hmm not having a bug database is going to make it hard to refer to bug numbers in the version history and release notes From: To: Time: Thu Mar 22 14:08:37 2007 do you have mail from tickets? From: To: Time: Thu Mar 22 14:09:08 2007 I won't have mail for the ticket I am about to create ;-) From: To: Time: Thu Mar 22 14:09:22 2007 right From: To: Time: Thu Mar 22 14:10:01 2007 Also I seem to have last gotten commit message mail about tickets mid-January, so no. From: To: Time: Thu Mar 22 14:10:23 2007 weird; did you fall off the list? From: To: Time: Thu Mar 22 14:10:27 2007 I have copies of all of the commit message mail From: To: Time: Thu Mar 22 14:10:30 2007 I never use the email interfaces so I didn't notice it had stopped sending me mail From: To: Time: Thu Mar 22 14:10:41 2007 there's also the discuss meeting From: To: Time: Thu Mar 22 14:10:58 2007 do kfm bugs appear there? From: To: Time: Thu Mar 22 14:11:04 2007 because that's what I care about From: To: Time: Thu Mar 22 14:11:21 2007 no they don't... i don't know if the kfm queue was set up to do that From: To: Time: Thu Mar 22 14:11:31 2007 I don't have kfm From: To: Time: Thu Mar 22 14:12:47 2007 well it doesn't matter since most of the tickets I care about were created within a few hours of the disk failing. Assuming the 6am backup is horked they'll need to be rerun anyway and might not have the same bug numbers From: To: Time: Thu Mar 22 14:13:55 2007 oh. when were those commits exactly? From: To: Time: Thu Mar 22 14:14:28 2007 we have: From: To: Time: Thu Mar 22 14:14:44 2007 -rw-r--r-- 1 38160 other 26622427 Mar 19 06:34 rt.dump.2007.03.19.gz -rw-r--r-- 1 38160 other 26628603 Mar 20 06:34 rt.dump.2007.03.20.gz -rw-r--r-- 1 38160 other 26631086 Mar 21 06:34 rt.dump.2007.03.21.gz From: To: Time: Thu Mar 22 14:15:44 2007 one sec, svn log is not being my friend From: To: Time: Thu Mar 22 14:16:29 2007 actual dump may have happened a few minutes before due to gzip run time From: To: Time: Thu Mar 22 14:16:38 2007 Looks like 2007-03-20 23:23:11 -0400 (Tue, 20 Mar 2007) From: To: Time: Thu Mar 22 14:16:54 2007 or at least that's one of them. there were a series of them around that time From: To: Time: Thu Mar 22 14:18:56 2007 Last one was apparently 2007-03-20 23:27:41 -0400 (Tue, 20 Mar 2007) From: To: Time: Thu Mar 22 14:19:36 2007 ok, you might be in luck if the dump is intact. gzcatting the most recent dump seems to look ok. From: To: Time: Thu Mar 22 14:19:42 2007 I'm just worried that the disk errors coincide with the creation of rt.dump.2007.03.21.gz so it may be hosed From: To: Time: Thu Mar 22 14:20:19 2007 if timestamps are to be believed, the disk errors happened shortly after the dump From: To: Time: Thu Mar 22 14:20:46 2007 the dump runs out of a daily script fired off from cron; there is a vacuum analyze that runs after the dump, if i remember the ordering correctly. From: To: Time: Thu Mar 22 14:21:07 2007 That happened to me with a laptop once. Backups ran and the disk immediately died. That backup was complete trash when I restored it From: To: Time: Thu Mar 22 14:21:41 2007 ah maybe the vacuum triggered it. That would make things easier From: To: Time: Thu Mar 22 14:22:04 2007 that's what i'm hoping From: To: Time: Thu Mar 22 14:22:18 2007 i think the daily script is one of the things i don't have a recent backup of, so i can't check easily. From: To: Time: Thu Mar 22 14:23:10 2007 I'm going to put off committing these last patches until tomorrow and work on my performance review. Maybe that will give you enough time to get RT working again. It would make the release a lot more sane From: To: Time: Thu Mar 22 14:23:37 2007 i'm diffing dumpfiles. i feel dirty. From: To: Time: Thu Mar 22 14:23:53 2007 hehe From: To: Time: Thu Mar 22 14:24:14 2007 were you not able to get the scripts off the dying disk? From: To: Time: Thu Mar 22 14:25:05 2007 no. it refused to respond to any commands basically. it probably wants to cool again. From: To: Time: Thu Mar 22 14:25:17 2007 if you unmount it I can yank it From: To: Time: Thu Mar 22 14:26:08 2007 -SELECT setval ('"tickets_id_seq"', 5477, true); +SELECT setval ('"tickets_id_seq"', 5480, true); From: To: Time: Thu Mar 22 14:26:16 2007 looks like we got up to ticket #5480 From: To: Time: Thu Mar 22 14:26:31 2007 are those disks hot-pluggable? From: To: Time: Thu Mar 22 14:27:07 2007 5479 was my last ticket I believe. Maybe 5480 was mine too though I don't remember it From: To: Time: Thu Mar 22 14:27:21 2007 yeah the disks are hot pluggable From: To: Time: Thu Mar 22 14:37:58 2007 eh, i can just power it off and have someone power it on later From: To: Time: Thu Mar 22 14:38:06 2007 the whole machine, that is From: To: Time: Thu Mar 22 15:25:45 2007 5478 was my ticket. 5479 is lxs and 5480 is Ken's From: To: Time: Thu Mar 22 15:26:00 2007 after Ken's commit I made an additional commit against 5469 From: To: Time: Thu Mar 22 15:26:10 2007 svn rev #19241 From: To: Time: Thu Mar 22 15:26:21 2007 that was the last activity I saw From: To: Time: Fri Mar 23 00:27:07 2007 Novell has announced Desktop Services for Windows (aka MIT Kerberos 1.6 in e-Directory) http://jacksonshaw.blogspot.com/ From: To: Time: Fri Mar 23 08:39:00 2007 gah. finally got something up on krbdev-new; don't make any changes yet, though! i'm still hacking. From: To: Time: Fri Mar 23 09:09:22 2007 Kevin: I get the impression that you are attempting to install multiple versions of KFW on the same machine and mix and match the krbcc32.dll and krbcc32s.exe implementations between versions. This is not supported. From: To: Time: Fri Mar 23 09:10:15 2007 The "SecureClient" messages in the output window of the debugger come from krbcc32.dll From: To: Time: Fri Mar 23 09:44:14 2007 attempting to view ticket 5480 results in: Invalid <%args> section line at /var/rt2/WebRT/html/Elements/ListActions line 13 Stack: [/var/rt2/perl5/lib/HTML/Mason/Lexer.pm:331] [/var/rt2/perl5/lib/HTML/Mason/Lexer.pm:267] [/var/rt2/perl5/lib/HTML/Mason/Lexer.pm:173] [/var/rt2/perl5/lib/HTML/Mason/Lexer.pm:121] [/var/rt2/perl5/lib/HTML/Mason/Lexer.pm:99] [/var/rt2/perl5/lib/HTML/Mason/Compiler.pm:214] [/var/rt2/perl5/lib/HTML/Mason/Compiler/ToObject.pm:75] [/var/rt2/perl5/lib/HTML/Mason/Compiler/ToObject.pm:114] [/var/rt2/perl5/lib/HTML/Mason/Interp.pm:440] [/var/rt2/perl5/lib/HTML/Mason/Request.pm:1087] [/var/rt2/perl5/lib/HTML/Mason/Request.pm:1001] [/var/rt2/perl5/lib/HTML/Mason/Request.pm:1198] [/var/rt2/WebRT/html/Ticket/Display.html:7] [/var/rt2/WebRT/html/autohandler:69] From: To: Time: Fri Mar 23 09:45:00 2007 actually, any "Goto" operation has that result From: To: Time: Fri Mar 23 09:46:37 2007 tom is not logged in, sent to him via e-mail. From: To: Time: Fri Mar 23 09:48:38 2007 Jeff, everything you have said about installing KfW on my PC is correct. There is one little piece you may be unaware of, though. One is in a VMware session and one is the OS running on the bare metal. So the installations are independent of each other. From: To: Time: Fri Mar 23 09:49:06 2007 then they are not on the same machine. From: To: Time: Fri Mar 23 09:54:21 2007 When the krbcc32.dll cannot communicate with krbcc32s.exe it is because the client and the server portions of the RPC were built differently. The most common cause of that would be two different versions of KFW. In particular, 2.6.5 and 3.0 because 3.0 changed the RPC mechanism so that both 32-bit and 64-bit clients on the same machine could talk to the same RPC server. From: To: Time: Fri Mar 23 10:34:27 2007 My builds of KFW 3.2 Alpha are available at http://www.secure-endpoints.com/private.htm From: To: Time: Fri Mar 23 10:55:57 2007 basic ticket display works now From: To: Time: Fri Mar 23 10:58:24 2007 the content for the last three commits that I am aware of look fine From: To: Time: Fri Mar 23 10:58:40 2007 ok From: To: Time: Fri Mar 23 10:58:57 2007 there may be other Mason components that need tweaking... i'll try to hunt them down From: To: Time: Fri Mar 23 11:00:09 2007 Mason got pickier about $var => defvalue vs $var = defvalue From: To: Time: Fri Mar 23 11:08:08 2007 If I remove KfW, reboot and install (such as I just did with your 3.2 Alpha), you would think that krbcc32s.exe and krbcc32.dll would be consistent with each other. But plink continues to timeout and fail. From: To: Time: Fri Mar 23 11:15:41 2007 Since you continue to examine the problem as a black box, there isn't much I can do for you. You are a developer. You have source code, symbols, binaries, and a debugger. You control both the RPC client and the RPC server (assuming that is the problem). You can try using a FILE: ccache instead of an API: ccache to remove that code path. This code works on at least 50 machines that I know about at seven institutions. If NIM works and klist and kinit work with an API ccache, then the problem isn't the RPCs. In which case you need to debug plink. From: To: Time: Fri Mar 23 11:17:04 2007 hm, maybe i'll try swapping IP addresses, so the rebuilt krbdev is on its proper IP From: To: Time: Fri Mar 23 11:25:53 2007 crossing fingers... From: To: Time: Fri Mar 23 11:28:18 2007 holding thumbs From: To: Time: Fri Mar 23 11:29:37 2007 I can see ticket 5446 in krbdev-new. To answer an earlier question, there isn't an ETA for this issue. The 'plink problem' supercedes it, since KfW at MIT has regressed between 2.6.5 and 3.x, as shown by plink. SWRT considers bugs that depend on plink to be critical [SecureCRT, SecureFX]. From: To: Time: Fri Mar 23 11:30:41 2007 SecureCRT doesn't use plink From: To: Time: Fri Mar 23 11:33:16 2007 oops, forgot to swap server certs; done now From: To: Time: Fri Mar 23 11:33:40 2007 at what version did things break? From: To: Time: Fri Mar 23 11:33:56 2007 the old krbdev is now krbdev-new, and powered off :-) From: To: Time: Fri Mar 23 11:34:49 2007 and the old krbdev-new is now krbdev. now to continue the tweaking... From: To: Time: Fri Mar 23 11:40:42 2007 i think i've fixed all of the Mason glitches now. i hope. From: To: Time: Fri Mar 23 11:40:46 2007 Here is the output of the plink in ~jaltman/Public/putty-with-gssapi against drugstore.mit.edu [J:\Public\putty-with-gssapi]plink -ssh -g drugstore.mit.edu -v -l jaltman Server version: SSH-1.99-OpenSSH_4.2 We claim version: SSH-2.0-PuTTY_Local:_Feb_25_2007_09:59:08 Using SSH protocol version 2 Doing Diffie-Hellman group exchange Doing Diffie-Hellman key exchange Host key fingerprint is: ssh-rsa 1024 09:a1:f6:3d:2a:f5:74:9d:69:03:eb:1d:0e:7a:aa:de Initialised AES-256 client->server encryption Initialised HMAC-SHA1 client->server MAC algorithm Initialised AES-256 server->client encryption Initialised HMAC-SHA1 server->client MAC algorithm Using username "jaltman". Server methods: gssapi-keyex,gssapi-with-mic,gssapi,password GSSAPI: trying GSSAPI auth GSSAPI: ssh_gss_acquire_cred GSSAPI: ssh_gss_init_sec_context GSSAPI: delegating credentials GSSAPI: ssh_gss_init_sec_context GSSAPI: delegating credentials sending mic Access granted Opened channel for session Allocated pty (ospeed 38400bps, ispeed 38400bps) Started a shell/command Last login: Fri Mar 23 11:38:43 2007 from cpe-24-193-47-9 Athena Server (sun4) Version 9.1.27 Wed Mar 17 15:40:22 EST 2004 ( success ( 1 2 ( ANONYMOUS EXTERNAL ) ( edit-pipeline ) ) ) From: To: Time: Fri Mar 23 11:41:07 2007 This using KFW 3.2 Alpha From: To: Time: Fri Mar 23 11:43:24 2007 and here it is being used to login to athena.dialup.mit.edu [J:\Public\putty-with-gssapi]plink -ssh -g athena.dialup.mit.edu -v -l jaltman Server version: SSH-1.99-OpenSSH_4.2 We claim version: SSH-2.0-PuTTY_Local:_Feb_25_2007_09:59:08 Using SSH protocol version 2 Doing Diffie-Hellman group exchange Doing Diffie-Hellman key exchange The server's host key is not cached in the registry. You have no guarantee that the server is the computer you think it is. The server's rsa2 key fingerprint is: ssh-rsa 1024 99:d8:44:46:3a:e8:ce:19:af:0a:cc:58:d1:b3:71:c2 If you trust this host, enter "y" to add the key to PuTTY's cache and carry on connecting. If you want to carry on connecting just once, without adding the key to the cache, enter "n". If you do not trust this host, press Return to abandon the connection. Store key in cache? (y/n) y Host key fingerprint is: ssh-rsa 1024 99:d8:44:46:3a:e8:ce:19:af:0a:cc:58:d1:b3:71:c2 Initialised AES-256 client->server encryption Initialised HMAC-SHA1 client->server MAC algorithm Initialised AES-256 server->client encryption Initialised HMAC-SHA1 server->client MAC algorithm Using username "jaltman". Server methods: gssapi-keyx,gssapi-with-mic,gssapi,password GSSAPI: trying GSSAPI auth GSSAPI: ssh_gss_acquire_cred GSSAPI: ssh_gss_init_sec_context GSSAPI: delegating credentials GSSAPI: ssh_gss_init_sec_context GSSAPI: delegating credentials sending mic Access granted Opened channel for session Allocated pty (ospeed 38400bps, ispeed 38400bps) Started a shell/command Athena Server (sun4) Version 9.4.36 Wed Jan 31 17:45:27 EST 2007 *** Welcome to X.dialup.mit.edu *** The dialups are now running the new Athena release (9.4). For more information about this, see http://web.mit.edu/olh/Release/9.4/ If you are having trouble using the dialup service, please contact an Athena User Consultant at 253-4435 or use OLC. When reporting your problem, please include the hostname of the machine. ** This machine is not intended for computationally intensive work. ** If you need to run computationally intensive jobs, please come to campus and log in. Running standard startup activities ... zwgc: Unable to open X display -- disabling X driver. zwgc: To receive Zephyrgrams, (type `zwgc -ttymode'). The following clusters will be closed from 8pm on the day given, until 8am the following morning: 1-142 Monday 3/29 66-080 Tuesday 3/27 E51-075 Wednesday 3/28 athena% From: To: Time: Fri Mar 23 12:19:52 2007 Since you are new to athena you are probably unaware that in order to log into an athena machine using SSH gssapi or gssapi-with-mic that you must be able to delegate credentials. If the SSH client cannot delegate credentials then it cannot access the AFS file system. It can't access AFS because it doesn't have Kerberos credentials to use to obtain a service ticket, afs/athena.mit.edu@ATHENA.MIT.EDU. SSH cannot delegate credentials unless the users TGT is forwardable. Acquiring forwardable tickets is off by default and is set on a per-Identity basis. Perhaps your problem is that you don't have a forwardable TGT. From: To: Time: Fri Mar 23 12:46:12 2007 about to frob the commit hooks for krb5 repository From: To: Time: Fri Mar 23 13:29:23 2007 ssh is not happy with the commit hook From: To: Time: Fri Mar 23 13:34:01 2007 apparently the ssh binary on drugstore is recent enough to refuse to use a group-readable private key From: To: Time: Fri Mar 23 13:43:43 2007 Here's what I see with 3.2.0 Alpha: ... sending mic Server unexpectedly closed network connection FATAL ERROR: Server unexpectedly closed network connection does that suggest anything to you? From: To: Time: Fri Mar 23 13:44:07 2007 and what does it say above that? From: To: Time: Fri Mar 23 13:44:42 2007 you don't have forwardable tickets. configure your identity for forward tickets, get new ones, and then athena will let you in. From: To: Time: Fri Mar 23 13:44:56 2007 compare your output to what I posted earlier From: To: Time: Fri Mar 23 13:45:05 2007 C:\Projects\putty-0.58-gssapi\windows>.\plink.exe kpkoch@svn.mit.edu -v Server version: SSH-1.99-OpenSSH_4.2 We claim version: SSH-2.0-PuTTY_Local:_Mar_21_2007_16:24:48 Using SSH protocol version 2 Doing Diffie-Hellman group exchange Doing Diffie-Hellman key exchange Host key fingerprint is: ssh-rsa 1024 09:a1:f6:3d:2a:f5:74:9d:69:03:eb:1d:0e:7a:aa:de Initialised AES-256 client->server encryption Initialised HMAC-SHA1 client->server MAC algorithm Initialised AES-256 server->client encryption Initialised HMAC-SHA1 server->client MAC algorithm Using username "kpkoch". Server methods: gssapi-keyex,gssapi-with-mic,gssapi,password GSSAPI: trying GSSAPI auth GSSAPI: ssh_gss_acquire_cred GSSAPI: ssh_gss_init_sec_context GSSAPI: delegating credentials GSSAPI: ssh_gss_init_sec_context GSSAPI: delegating credentials sending mic Server unexpectedly closed network connection FATAL ERROR: Server unexpectedly closed network connection From: To: Time: Fri Mar 23 13:48:07 2007 Far out. What made you think of that? From: To: Time: Fri Mar 23 13:51:06 2007 ok, this is getting really annoying. the commit handler can't ssh to krbdev from drugstore. From: To: Time: Fri Mar 23 13:51:54 2007 why not? From: To: Time: Fri Mar 23 13:52:15 2007 or is that what you're trying to figure out? ;) From: To: Time: Fri Mar 23 13:53:09 2007 that's what i'm trying to figure out. i've got debugging zwrites crammed into the commit hook and it's not helping. the klist output seems to be truncated at the beginning. From: To: Time: Fri Mar 23 13:53:30 2007 and RSA key authentication isn't working either because the krbsnap key is group-readable From: To: Time: Fri Mar 23 13:56:08 2007 meanwhile i'm going to annoy everyone on cvs-krb5.... From: To: Time: Fri Mar 23 13:56:20 2007 kevin: because I looked at the debug output of plink and it said "delegating credentials" and because I don't believe you when you make the blanket statement that the problem is with KFW From: To: Time: Fri Mar 23 14:18:49 2007 w00t From: To: Time: Fri Mar 23 14:18:52 2007 one finally got through From: To: Time: Fri Mar 23 14:19:35 2007 are the commit handlers working now or was that just a fluke? From: To: Time: Fri Mar 23 14:19:47 2007 so the commit hook now _copies_ the group-readable RSA key into a private directory and chmods it to be private, so ssh doesn't have a cow about its permissions From: To: Time: Fri Mar 23 14:20:05 2007 you should try committing something in krb5/branches/commit-handler-test From: To: Time: Fri Mar 23 14:21:27 2007 ticket #5481 was me manually running rt-cvsgate on krbdev without actually committing anything, just to sanity-check stuff. ticket #5482 is the real deal. From: To: Time: Fri Mar 23 14:25:10 2007 I'm checking out the branch now. From: To: Time: Fri Mar 23 14:25:27 2007 you can commit directly to a URL too From: To: Time: Fri Mar 23 14:26:27 2007 I'm adding it to ticket 5481 From: To: Time: Fri Mar 23 14:26:49 2007 transmitting data .... From: To: Time: Fri Mar 23 14:26:56 2007 revision 19256 From: To: Time: Fri Mar 23 14:29:08 2007 ok, this is looking promising From: To: Time: Fri Mar 23 14:29:44 2007 i'm not going to set up incoming mail yet though, but hopefully will be able to soon. From: To: Time: Fri Mar 23 14:30:10 2007 I didn't receive an e-mail yet for the RT change but I did for the svn revision From: To: Time: Fri Mar 23 14:31:09 2007 probably because it hits the barracudas From: To: Time: Fri Mar 23 14:31:29 2007 Mar 23 14:26:41 drugstore.mit.edu sendmail[24517]: [ID 801593 mail.info] OAA24517: from=jaltman, size=216, class=0, pri=30216, nrcpts=1, msgid=<200703231826.OAA24517@drugstore.mit.edu>, relay=jaltman@localhost Mar 23 14:26:41 drugstore.mit.edu sendmail[24521]: [ID 801593 mail.info] OAA24517: to=cvs-krb5@mit.edu, delay=00:00:00, xdelay=00:00:00, mailer=smtp, relay=w92-130-barracuda-2.mit.edu. [18.7.21.223], stat=Sent (Ok: queued as 972E716F3E5) From: To: Time: Fri Mar 23 14:31:47 2007 oops wrong machine From: To: Time: Fri Mar 23 14:32:04 2007 https://krbdev.mit.edu/rt/Ticket/Display.html?id=5483 worked From: To: Time: Fri Mar 23 14:32:37 2007 should i go ahead and re-enable kfm's hook as well? From: To: Time: Fri Mar 23 14:32:49 2007 uh that used the kfm hook ;-) From: To: Time: Fri Mar 23 14:33:04 2007 Kevin: Please do not include me on internal MIT communications outside of the kerberos team. I am not a contractor for MIT anymore. It is not appropriate to draw me into the discussions. Doing so puts me in an awkward position of pointing out obvious things that SWRT needs to do as part of any KFW deployment which obviously have not been done so far. From: To: Time: Fri Mar 23 14:33:07 2007 oh nevermind it didn't From: To: Time: Fri Mar 23 14:33:19 2007 yeah I'd like kfm's hook on as well From: To: Time: Fri Mar 23 14:33:30 2007 I received the e-mail from my commit From: To: Time: Fri Mar 23 14:34:03 2007 Jeff -- that CC was in the sprit of giving credit where credit is due. From: To: Time: Fri Mar 23 14:35:12 2007 kfm hook should be back on.... and i've taken the debug zwrites out so i won't be inundated. From: To: Time: Fri Mar 23 14:36:10 2007 that might have been the case with this e-mail but you have also been including me on others. please stop. if you just want to let me know that you have given credit you can forward me a private copy of the e-mail you sent, or you can bcc me. From: To: Time: Fri Mar 23 14:53:51 2007 hm, i just noticed that the commit handler doesn't identify which repository, or so it seems. From: To: Time: Fri Mar 23 15:03:18 2007 yeah I always have to specify queue: kfm and status: open for kfm tickets, which is annoying From: To: Time: Fri Mar 23 15:03:50 2007 I'd love if I got an implicit: queue: kfm status: open resolution: fixed on all commits to the kfm repository From: To: Time: Fri Mar 23 15:03:52 2007 thus your krb5 repository commit showed up in the kfm queue with no indication it was actually a krb5 respository commit. i suppose we should fix that eventually From: To: Time: Fri Mar 23 15:04:21 2007 you use status and resolution separately? From: To: Time: Fri Mar 23 15:04:40 2007 yes, I close bugs when they are fixed in a release which has gone to Apple From: To: Time: Fri Mar 23 15:04:50 2007 because we don't have states for integrate and build From: To: Time: Fri Mar 23 15:05:17 2007 if we had integrate and build states I'd stop using the resolution stuff From: To: Time: Fri Mar 23 15:08:38 2007 "integrate" meaning "checked into trunk and ready for release engineer" and "build" meaning "release engineer has pulled it up to the branch". Then "resolved" means "shipped in release" From: To: Time: Fri Mar 23 15:10:08 2007 Radar uses those states (as well as "verify" which comes between "build" and "resolved" since they require the originator confirm the fix) and it's much easier to figure out what state our code is in their build system from them From: To: Time: Fri Mar 23 15:10:57 2007 the other nice thing about it is that the person filing the bug doesn't need to know what release it is for since the target version is set by the release engineer when it is moved from integrate to build From: To: Time: Fri Mar 23 15:11:11 2007 ur s/filing/commiting patches for/ From: To: Time: Fri Mar 23 16:14:53 2007 is the new machine being backed up at this point? is it safe to resume commits? From: To: Time: Fri Mar 23 17:26:46 2007 Sounds like something could be "shipped in release" without confirmation from the originator. Is that "verify" or "resolved"? From: To: Time: Fri Mar 23 17:33:03 2007 If something in Radar ships in a release or seed it goes to "Verify" before "Closed" From: To: Time: Fri Mar 23 17:33:50 2007 I don't strictly need the Verify state since we don't tend to have formal originator verification, but the integrate and build states would be really useful From: To: Time: Fri Mar 23 18:46:42 2007 FYI backups not happening just yet.... read mail sent to krbwrite From: To: Time: Fri Mar 23 18:54:02 2007 oops jaltman left already From: To: Time: Fri Mar 23 19:59:26 2007 I'm going to hold off making any additional commits until after backups are running on krbdev From: To: Time: Fri Mar 23 19:59:42 2007 there is nothing that I can't commit on monday From: To: Time: Sun Mar 25 02:02:24 2007 MIt Kerberos Development Team From: To: Time: Sun Mar 25 02:02:25 2007 raeburn has set the topic to: Kerberos From: To: Time: Sun Mar 25 14:53:29 2007 hm, people are hammering on krbdev looking for /nightly From: To: Time: Sun Mar 25 15:15:14 2007 manual dump done Friday night; 06:00 daily cron job to do backups re-enabled. we'll see if it fires tonight. From: To: Time: Sun Mar 25 23:19:03 2007 ok, perhaps incoming mail works now From: To: Time: Mon Mar 26 12:11:42 2007 Why did krbdev.mit.edu/rt say my comments were added to a ticket but I couldn't see them, even after opening a new browser? From: To: Time: Mon Mar 26 13:27:31 2007 which ticket was this? From: To: Time: Mon Mar 26 13:44:45 2007 oh i see. i can reproduce the problem. debugging... From: To: Time: Mon Mar 26 14:09:06 2007 oddly enough, going through the "Jumbo" update doesn't produce this problem. From: To: Time: Mon Mar 26 14:28:34 2007 RT::Attachment->Create couldn't, as you didn't specify a transaction argh From: To: Time: Mon Mar 26 14:32:10 2007 for now, going through the "Jumbo" update page seems to work From: To: Time: Mon Mar 26 14:49:48 2007 .... though it also seems to have issues with sending mail From: To: Time: Mon Mar 26 18:49:13 2007 Random people might be interested in how Jeremy Allison is adding confidentiality and integrity protection to CIFS using GSS http://lists.samba.org/archive/samba-technical/2007-March/052392.html From: To: Time: Mon Mar 26 21:55:42 2007 Are things clear on the commit handler front, making it safe to commit things again? (Not that I'll probably get to the code I was going to commit tonight, but I wanted to check in case I do.) From: To: Time: Mon Mar 26 21:56:42 2007 Yes. Also, if it screws up, cleaning up the mess is relatively easy From: To: Time: Mon Mar 26 22:03:05 2007 the remaining damage appears to be the Ticket/Update.html screen; using the "Jumbo" update links should be ok. still debugging that. From: To: Time: Mon Mar 26 22:04:15 2007 it appears that the culprit may be the TimeWorked field being set to an empty string instead of an integer and making postgres unhappy. From: To: Time: Mon Mar 26 22:22:02 2007 yeah, that was it From: To: Time: Mon Mar 26 22:33:59 2007 interesting. looks like a possible reason that messages from RT are getting through slowly is the "Precedence: bulk" From: To: Time: Tue Mar 27 13:59:20 2007 I just came across another private addition to MIT krb5 API that has made it out into the wild: int krb5_appdefault_addrmatch(krb5_context, char * service, krb5_data * realm, char * value, void * addr, char * output_string): This function looks in the appdefaults section of the profile for the combination of realm, value and ip-address and returns the matching data if it exists. It is being used for things such as specifying the maxiumum age that an authenticator is permitted to be when received from the specified ip-address. From: To: Time: Tue Mar 27 14:56:07 2007 ticket: 5490 I don't think that having a hard coded path to the location of plink is a good idea From: To: Time: Tue Mar 27 14:56:43 2007 you can require that plink.exe be in the PATH. From: To: Time: Tue Mar 27 14:57:50 2007 Don't we want to just require plink be in the path? Or better yet require that you've set things up so that svn+ssh uris just work? From: To: Time: Tue Mar 27 14:57:50 2007 the build script should auto-generate the site-local configuration files for the installers From: To: Time: Tue Mar 27 14:58:26 2007 I believe that having plink.exe and svn.exe in the path is sufficient. From: To: Time: Tue Mar 27 14:58:42 2007 As do I re: path. I also agree about site local files From: To: Time: Tue Mar 27 14:58:42 2007 Kevin's script has a hard coded plink.exe path name From: To: Time: Tue Mar 27 14:59:59 2007 there is also a hardcoded KERBEROS_ID name="kpkoch" From: To: Time: Tue Mar 27 15:01:04 2007 Which of Tom or Ken wants to go do pkinit testing with us. From: To: Time: Tue Mar 27 15:04:41 2007 I'm not sure I understand why plink is listed here at all. svn will just do the right thing. I do not believe that svn requires that the kerberos id be prepended as a user name to the url string From: To: Time: Tue Mar 27 15:05:43 2007 certainly, this script is going to fail is I try to authenticate as kpkoch From: To: Time: Tue Mar 27 15:06:02 2007 It does if plink's idea of local user is not the same as the account you're logging into From: To: Time: Tue Mar 27 15:09:08 2007 local user can be provided to plink outside of the URL From: To: Time: Tue Mar 27 15:11:26 2007 if it is going to be provided as part of the URL, can it be provided in some manner other than in the configuration file for the build that is checked into the repository? From: To: Time: Tue Mar 27 15:13:49 2007 Obviously. Let me go see if Kevin is around From: To: Time: Tue Mar 27 15:17:43 2007 He is; I asked him to take a look here. From: To: Time: Tue Mar 27 15:18:52 2007 When's the pkinit testing? From: To: Time: Tue Mar 27 15:19:11 2007 We've not decided that yet. I wanted to know who needed to be involved in scheduling. From: To: Time: Tue Mar 27 15:20:02 2007 For some reason, GAIM didn't play a sound when this activity started. It would make sense to require that plink be in the path. Then SVN_SSH could be set to "plink.exe" and it would work. This is how I run. There is a comment somewhere in the script or xml config file that site_local could be generated, but I chose not to do that. It can certainly be done. The kerberos id obviously can't be hardwired to me. But short of the non-existant schema file, I had to show what elements are required. A command line switch needs to be added so the kerberos id can be supplied at run time. From: To: Time: Tue Mar 27 15:21:50 2007 Ah, okay. Well, I can go, though I'm not jumping-up-and-down excited about it, if Tom really wants to go. And I haven't looked at any pkinit code so far. From: To: Time: Tue Mar 27 15:23:30 2007 Jeff, you said that the ID can be passed to plink outside the uri; how? Kevin, how does the decision to generate the site local config for the installers impact our goal of having consistent reproducible builds independent of what machine they are on? From: To: Time: Tue Mar 27 15:23:43 2007 the kerberos id, build directories, signing certificates, etc. are site specific data that should be provided by some means outside of the committed scripts. This could be an additional XML file or command line parameters or environment variables. From: To: Time: Tue Mar 27 15:23:55 2007 plink supports a "-l username" parameter From: To: Time: Tue Mar 27 15:24:42 2007 Why should the build directories be locally supplied? From: To: Time: Tue Mar 27 15:24:55 2007 Or rather why should more than one directory be supplied? From: To: Time: Tue Mar 27 15:25:22 2007 there is only need for one directory From: To: Time: Tue Mar 27 15:25:47 2007 I think substituting in a kerberos id from a command line or environment variable to the URI is easier than making svn pass -l From: To: Time: Tue Mar 27 15:26:40 2007 That one directory is src in the xml config. It can be set from the command line. From: To: Time: Tue Mar 27 15:28:19 2007 there are a number of parameters that need to be provided. is this a pre-release, official, or private build? version numbers? From: To: Time: Tue Mar 27 15:29:03 2007 No, version numbers come from the committed sources. From: To: Time: Tue Mar 27 15:29:53 2007 I think Jeff is talking about the 3, 2 and 0? From: To: Time: Tue Mar 27 15:30:12 2007 the current build script does not parse the version number string. From: To: Time: Tue Mar 27 15:30:23 2007 Right. We commit changes to the version.rc files for that. From: To: Time: Tue Mar 27 15:30:59 2007 What does it do? From: To: Time: Tue Mar 27 15:31:34 2007 If site-local were generated, then the xml would have the 3, 2 and 0 and would put together things like 'kfw-3-2-0.' Am I answering the right question? From: To: Time: Tue Mar 27 15:32:18 2007 Ah, so currently the build script assumes that you have some config file on the local machine including the version number? From: To: Time: Tue Mar 27 15:33:00 2007 the current KFW version number is independent of the krb5 file version numbers. the KFW version number comes from pismere athena/include/kerberos.ver From: To: Time: Tue Mar 27 15:33:03 2007 'kfw-3-2-0' is in the xml config. Are the components of that in version.rc? Is that the ultimate source of the info? From: To: Time: Tue Mar 27 15:33:15 2007 No, I'm basically asking for an explanation of how the current arrangement meets the design goal of the script or an explanation of what went wrong and a plan to fix. From: To: Time: Tue Mar 27 15:33:58 2007 No, Jeff is right. The version.rc is for the file version numbers; Jeff pointed you at the kfw version number From: To: Time: Tue Mar 27 15:35:20 2007 based upon whether or not there is a BETA value specified in athena/include/kerberos.ver, the appropriate beta tags should be generated for the configuration files for NSIS and WIX From: To: Time: Tue Mar 27 15:39:23 2007 Well, you learn something new every day [kerberos.ver]. As implemented, the xml specifies the filename and doesn't have any idea of versions. It sounds like the script needs to get the info from kerberos.ver. Where do we want to specify the 'kfw' part of the filenames? I should create or update site-local.wxi. Anything else? From: To: Time: Tue Mar 27 15:40:08 2007 That is, in addition to the krb id as already discussed. From: To: Time: Tue Mar 27 15:40:10 2007 and the NSIS installer From: To: Time: Tue Mar 27 15:40:19 2007 site-local.nsi From: To: Time: Tue Mar 27 15:41:05 2007 I think hard coding the string kfw is fine (in the script not the xml) From: To: Time: Tue Mar 27 15:41:21 2007 I haven't looked, but did you add functionality for signing the binaries (.exe, .dll, .cpl [when we have one]) as well as the installers? From: To: Time: Tue Mar 27 15:41:51 2007 No signing. You'll have to show me how you do it. From: To: Time: Tue Mar 27 15:42:23 2007 I'll need an example of how you want alpha, beta or other filename decorations formatted. From: To: Time: Tue Mar 27 15:42:56 2007 signtool.exe sign /a /d "MIT Kerberos for Windows" /du "http://web.mit.edu/kerberos" /t [filenames ...] From: To: Time: Tue Mar 27 15:43:11 2007 where signtool is part of the platform sdk From: To: Time: Tue Mar 27 15:51:30 2007 -KERBEROS_ID is already in the build script. From: To: Time: Tue Mar 27 15:52:43 2007 then I suggest you remove "kpkoch" from the XML file From: To: Time: Tue Mar 27 15:55:37 2007 approach the problem from the perspective that there are no special shortcuts for special people. if there is a reason to optimize configuration, do so in a way that optimizes it for everyone. From: To: Time: Tue Mar 27 15:58:17 2007 I already said that in the absence of a schema file, I put placeholders in the xml. From: To: Time: Tue Mar 27 15:59:57 2007 using "kpkoch" as a place holder means that when you test the build process things will work differently than for other people. if you must have a placeholder use the empty string or "svn-username" or something. From: To: Time: Tue Mar 27 16:02:06 2007 Off to a meeting. Kevin, if you need to pull me out of the meeting Im' in 225. I consider getting the build script to perform well enough that we can release betas without depending on local state on the machine critical. From: To: Time: Tue Mar 27 16:02:08 2007 You might want to consider that the KERBEROS_ID and the svn-name might not have to be the same. When I think kerberos id I think Kerberos principal as in jaltman@ATHENA.MIT.EDU. What you require is the username to be used for logging into the remote machine. From: To: Time: Tue Mar 27 16:03:20 2007 the first component of a Kerberos principal name does not have to match the login name for the service. From: To: Time: Tue Mar 27 16:12:07 2007 Its now /kerberos_username or /u. From: To: Time: Tue Mar 27 16:21:08 2007 I think you missed the point. the username is independent of kerberos From: To: Time: Tue Mar 27 16:32:57 2007 I will make one more guess. /USERNAME. If you don't like that, then you tell me what the switch should be. From: To: Time: Tue Mar 27 17:18:46 2007 /username is appropriate. From: To: Time: Tue Mar 27 17:19:48 2007 If the username on drugstore.mit.edu is configured to be different from the user's kerberos principal first component, the user won't be confused. From: To: Time: Tue Mar 27 17:58:04 2007 I think daemon@krbdev mail needs to get thrown away eventually. It gets bounces every time rt@krbdev gets spam. (RT generates a reply complaining "no ticket id specified".) From: To: Time: Tue Mar 27 17:58:46 2007 If only our RT hook could trigger SMTP-time rejection... From: To: Time: Tue Mar 27 22:14:11 2007 i think certain "prog" mailers can issue return statuses which affect whether sendmail does rejection From: To: Time: Wed Mar 28 10:43:52 2007 But people usually get annoyed when I run around creating "prog" mailers. :-) And I don't think it'll help if a spammer hits rt@krbdev and rt-comment@krbdev at the same time, since it can't sent per-recipient errors. Still, unless we can configure a milter for the machine, it might be worth exploring. From: To: Time: Wed Mar 28 10:45:53 2007 we could make a check_data ruleset but that starts to get hairy From: To: Time: Wed Mar 28 10:47:30 2007 or check_eoh From: To: Time: Wed Mar 28 10:50:37 2007 I think that'll work. We'd have to conditionalize things on both recipients and subject pattern; rt@ and rt-comment@ require the pattern, new incoming bug reports don't... From: To: Time: Wed Mar 28 10:51:51 2007 But it looks do-able. From: To: Time: Wed Mar 28 10:54:23 2007 Hm, I'll experiment with it a bit. From: To: Time: Wed Mar 28 10:55:03 2007 do it with a scratch config and queue in case things go horribly wrong From: To: Time: Wed Mar 28 10:55:24 2007 Definitely. From: To: Time: Wed Mar 28 11:02:09 2007 so nobody has any rights on the "spam" queue? From: To: Time: Wed Mar 28 11:06:03 2007 Right. Well, the idea is no one can submit by email. Doesn't matter much if one can read it, I suppose. From: To: Time: Wed Mar 28 11:08:14 2007 well nobody has "create" privileges so we always generate a "permission denied" message From: To: Time: Wed Mar 28 11:09:07 2007 you know, we might as well point MAILER-DAEMON and daemon to /dev/null From: To: Time: Wed Mar 28 11:09:40 2007 i guess there's a small chance that we might want to see error mail produced from the send-pr-gate From: To: Time: Wed Mar 28 11:12:05 2007 ok, frobbed aliases file From: To: Time: Wed Mar 28 11:23:44 2007 there appears to be two problems with kfw and non-interactive logons that I want to address before a beta goes out. (1) on XP/2003 the logon event handlers do not get triggered. this leaves behind ccache files that will not be deleted (2) on all platforms, each non-interactive process started as part of a scheduled task or via at.exe runs in a unique session. If krb5_32.dll is loaded that triggers the launch of a krbc32s.exe process for that session. When the scheduled task completes, there is still a krbc32s.exe running in the session and so the session is not closed. There is no logoff event so the krbc32s.exe is never told to terminate. I doubt there is anything that can be done other than providing a command line tool to instruct krbc32s.exe to shutdown. However, I want to take a look. From: To: Time: Wed Mar 28 11:43:31 2007 If/when we get check_eoh rules installed, then paying attention to (mailer-)daemon mail might be wise. For now, it's mostly junk. From: To: Time: Wed Mar 28 12:11:29 2007 to reproduce (2) on XP, do not use the AT service. Instead use "Scheduled Tasks" and schedule "klist.exe" to execute using an account and password that is not currently logged onto the machine. From: To: Time: Wed Mar 28 12:11:57 2007 if you use an account that is logged on, the command will execute within the account's active logon session From: To: Time: Wed Mar 28 12:46:00 2007 Logon Scripts do not execute for non-interactive logons. I don't see much choice but to disable ticket acquisition for non-interactive logons From: To: Time: Wed Mar 28 14:46:38 2007 kevin: thank you. I will test the changes after I finish addressing the non-interactive logon issues From: To: Time: Wed Mar 28 16:00:57 2007 Jeff -- your comment was hard to pick out ... you're welcome. Let me know how you like it. From: To: Time: Wed Mar 28 16:23:57 2007 so... were any of our not.ms.mit.edu machines a win2k machine? it may be we didn't get the test coverage because we didn't have a setup for win2k. From: To: Time: Wed Mar 28 16:45:50 2007 none of the not.ms machines were win2k. The top level domain was win2003 From: To: Time: Wed Mar 28 16:46:09 2007 temple-of-doom of course died From: To: Time: Wed Mar 28 16:48:34 2007 the scheduled tasks leaves krbcc32s.exe problem is going to be hard to solve. There is no event to trigger the shutdown of this process because non-interactive sessions only terminate when all of the processes within the session terminate. Scheduled Tasks do have a kill this task after X time. I wonder it it will terminate processes that were started within the session by the original task if the original process has already quit From: To: Time: Wed Mar 28 16:51:15 2007 and sadly the answer is 'no' From: To: Time: Fri Mar 30 11:48:25 2007 I'm adding signing to the KfW build script. Any comments on ... Config XML: Script: > bkw.pl -config bkwconfig.xml -sign Sample Windows command that will be executed: signtool sign /a /d "MIT Kerberos for Windows" /du "http://web.mit.edu/kerberos" /t TIMESTAMPSERVERGOESHERE C:\projects\Autobuild\public\ziptemp/kfw-3-2-0-final/bin/i386/wshelp32.dll From: To: Time: Fri Mar 30 11:52:25 2007 Why does this need to go in the config. Why can't you hard code it? When would you ever change it? From: To: Time: Fri Mar 30 11:53:22 2007 Jeff's and our time stamp server will be different. From: To: Time: Fri Mar 30 11:53:31 2007 you will change it if you change the location of the web page you want referenced for support you will change it the timestamp server if you change certificate providers From: To: Time: Fri Mar 30 11:56:44 2007 *sigh* One of the things we'll eventually have to negotiate with Jeff is what changes are appropriate to make in builds he makes while still calling it KFW. I think for now I'll continue to ignore the issue because it's going to be incredibly tedious and we basically have good ideas of what is going on. And there is basically no positive value to come out of the discussion. So, yeah, stick it in the config. From: To: Time: Fri Mar 30 11:58:21 2007 I'm expecting that MIT is going to want to change the web site at some point so that Windows users looking for support for this thing that is installed on their machine will go to a KFW focused page instead of the top-level Kerberos page From: To: Time: Fri Mar 30 11:58:53 2007 MIT for internal use will probably want the support link to point to an internal helpdesk page From: To: Time: Fri Mar 30 12:01:47 2007 Our agreement was that the product I distribute to my clients would be called "MIT Kerberos for Windows" provided that the binaries that MIT and SEI distribute are the same for a given release except that the digital signatures may be different. I may have them and MIT does not for example. From: To: Time: Fri Mar 30 12:05:30 2007 Yeah. But I suspect that agreement if interpreted too strictly may be problematic for you. From: To: Time: Fri Mar 30 12:08:32 2007 it will be problematic if MIT and SEI are both distributing krb5_32.dll as file version 1.6.1.0 if the binaries are not actually the same binary. if that happens, crash reports will be filed and there will be no mechanism to determine which symbol files or sources go with them. We really must ship the same files. MIT really must ship the same files for the external builds and internal builds. They can be packaged differently but the binaries need to be the same. From: To: Time: Fri Mar 30 14:40:02 2007 The NSIS installer copied to the build products are is called kfw-3-2-0.exe. But NSIS built MITKerberosForWindows.exe, which is what is in kfw-3-2-0-sdk.zip. Should I rename it to kfw-3-2-0.exe? From: To: Time: Fri Mar 30 14:40:36 2007 you can rename it From: To: Time: Fri Mar 30 16:54:53 2007 Kevin to clarify. The installer sources are part of the zip file. The product of running the installer scripts is not. From: To: Time: Fri Mar 30 16:55:36 2007 you should look at the zip files that are being distributed from web.mit.edu/kerberos/ From: To: Time: Fri Mar 30 17:19:14 2007 sdkfiles.xml copies *.* from the installer areas. Now the sdk step deletes *.exe and *.msi before zipping. From: To: Time: Fri Mar 30 17:21:28 2007 make sure that only the sources are zipped and not any of the intermediate build files From: To: Time: Fri Mar 30 17:22:45 2007 I intentionally executable the installer builds from a location other than the destination tree so that intermediate build files are not accidentally packaged by a recursive zip From: To: Time: Fri Mar 30 17:27:10 2007 Right. The copy of *.* is from the staging area wix & nsis areas, not from pismere/athena/auth/krb5/src/windows/installer/... From: To: Time: Fri Mar 30 17:31:30 2007 There are three area -- pismere/athena/..., pismere/staging and pismere/public. staging is populated by copying from athena, using copyfiles.xml, which isthe old copysdk.bat reformatted. There is a cleaning step done on staging before the installer builders run. public/ziptemp is created and populated for each zip file. Files can be copied from athena or staging, according to the xml files for each zip. Then there is a cleaning step before the zip is made. From: To: Time: Fri Mar 30 17:32:48 2007 if you are copying files to the staging area, why not just copy the files that are supposed to be zipped instead of copying everything and then cleaning? From: To: Time: Fri Mar 30 17:34:26 2007 Copying *.whatever will catch new things that are added. Copying individual files is more of a maintenance challenge - the xml had to be sure to track the directory contents. From: To: Time: Fri Mar 30 17:35:44 2007 copy *.whatever is more likely to copy a new generated file into the releases. If a new file is added to the distribution, updating the installers and the build script is the maintenance that must be done to accomplish that. From: To: Time: Fri Mar 30 17:37:17 2007 It comes down to which process is less error prone. I chose what I think is more foolproof. From: To: Time: Fri Mar 30 17:37:35 2007 it is more likely that someone will forget to maintain the list of things to be cleaned than the list of things to be published. From: To: Time: Fri Mar 30 17:40:09 2007 think of it this way. If a new version of makensis.exe (or some other tool) comes out and it generates a new intermediate file in the process of building the installer, are you going to notice that and update the build scripts? Or is that intermediate file going to be distributed to end users? From: To: Time: Sat Mar 31 15:02:50 2007 There are still at least two problems with the build scripts: (1) the signing of the binaries occurs after the installers and the zip files are built. this means that the binaries that are given to the user are unsigned. Both the binaries and the installers must be signed. (2) specifying both the /r and /o options to bkw.pl results in copy failures after building the installers [07/03/31 15:01:00] Fatal -- Copy of c:\temp\buildkfw\pismere\staging\doc\leash_userdoc.pdf to c:\temp\buildkfw\c:\temp\kfwout\ziptemp\kfw-3-2-0-final\doc\leash_userdoc.pdf failed at copyfiles.pl line 127. Notice that the destination concatenated both the source and the output directory paths. From: To: Time: Sat Mar 31 17:19:04 2007 Are you sure about the order of signing? makeZip.pl says if ($switches[0]->{sign}->{value}) { signFiles($zip->{Config}->{Signing}, $config); } local $zipfile = Archive::Zip->new(); ... $zipfile->addTree('.', $topdir); $zipfile->writeToFileNamed($zipname); Then there is another signing step after the zips have been made. This one signs the .exe and .msi. Ar you sure you didn't see that step and not notice signing before the zips were made? I'll look at the file copy issue ... From: To: Time: Sat Mar 31 17:20:15 2007 I'm looking at the binaries in the staging area after the installers are built. they aren't signed. From: To: Time: Sat Mar 31 17:20:28 2007 that means the binaries in the installers are not signed From: To: Time: Sat Mar 31 17:21:43 2007 * build the binaries * sign the binaries * package the binaries * sign the installers From: To: Time: Sat Mar 31 17:46:14 2007 Please email me the log while I fix the /o problem. From: To: Time: Sat Mar 31 17:46:44 2007 you should start using afs From: To: Time: Sat Mar 31 17:47:42 2007 http://web.mit.edu/jaltman/Public/KFW/bkw.pl.log From: To: Time: Sat Mar 31 18:10:11 2007 The /o problem is fixed. Your log doesn't demonstrate the signing issue; I'll wait for a new log. From: To: Time: Sat Mar 31 18:11:20 2007 Are you seeing a kfw.exe that is 8X the size of the /msi? From: To: Time: Sat Mar 31 18:11:32 2007 .msi From: To: Time: Sat Mar 31 18:11:44 2007 how could it demonstrate the signing issue? it never signed anything From: To: Time: Sat Mar 31 18:12:45 2007 each built binary should be signed once. the same binary should be included in the EXE installer, the MSI installer and the ZIP files. From: To: Time: Sat Mar 31 18:14:49 2007 You said there is a signing problem. You said you looked at files and they weren't signed. So you ran thescript. There should be a log. From: To: Time: Sat Mar 31 18:15:30 2007 I ran the script, the script didn't sign anything. It never attempted to. Why would it log something it never attempted? From: To: Time: Sat Mar 31 18:16:55 2007 As far as I can tell by reading the Perl, the only things you sign are the binaries that are copied and then zipped, and the binaries after they are zipped. Since the zipping failed due to the /o problem, there never was any signing. Since the script doesn't sign the binaries prior to the installer construction, the contents of the installers are not signed From: To: Time: Sat Mar 31 18:17:04 2007 Then what does (15:02:50) jaltman: There are still at least two problems with the build scripts: (1) the signing of the binaries occurs after the installers and the zip files are built. this means that the binaries that are given to the user are unsigned. Both the binaries and the installers must be signed. and (17:20:16) jaltman: I'm looking at the binaries in the staging area after the installers are built. they aren't signed. (17:20:28) jaltman: that means the binaries in the installers are not signed mean? From: To: Time: Sat Mar 31 18:18:23 2007 I've made it very clear. The script does not handle signing properly. The script does this: * build binaries * build installers * copy binaries * sign binaries * zip binaries * sign binaries From: To: Time: Sat Mar 31 18:19:02 2007 the script should be * build binaries * sign binaries in staging area * build installers * zip binaries * sign installers From: To: Time: Sat Mar 31 18:20:08 2007 Light dawns on Marblehead (a city in MA, not me ;-) ) While the script signs all the binaries before zipping them, and all the .exes in /OUTDIR, that is after the installers are built. The installers have insigned binaries in them. Wait one sec ... From: To: Time: Sat Mar 31 18:33:14 2007 Iterate, iterate, iterate. Signing added after copyfiles to the staging area. Note that if the installers are ill-behaved, they could reach into the build area and take unsigned files. Signing in XMLs still required, since corebinaryfile.xml does precisely that. From: To: Time: Sat Mar 31 18:34:05 2007 the installers don't reach into the build area. they are pointed at a single directory tree. From: To: Time: Sat Mar 31 18:34:53 2007 the whole reason for the copysdk.bat file is to construct the staging area that the installer scripts are pointed at From: To: Time: Sat Mar 31 19:02:01 2007 New log http://web.mit.edu/Public/KFW/bkw.pl.log errors gallore. [07/03/31 18:55:21] Access denied - . [07/03/31 18:55:21] File not found - -INAME [07/03/31 18:55:21] Access denied - . [07/03/31 18:55:21] File not found - -INAME [07/03/31 18:55:22] Access denied - . [07/03/31 18:55:22] File not found - -INAME [07/03/31 18:55:22] Access denied - . [07/03/31 18:55:22] File not found - -INAME [07/03/31 18:55:22] Access denied - . [07/03/31 18:55:22] File not found - -INAME [07/03/31 18:55:22] Access denied - . [07/03/31 18:55:22] File not found - -INAME [07/03/31 18:55:22] Access denied - . [07/03/31 18:55:22] File not found - -INAME [07/03/31 18:55:22] Access denied - . [07/03/31 18:55:22] File not found - -INAME No signatures. This output is not correct: 3/31/2007 18:58 61,836,553 kfw-3-2-0-sdk.zip 3/31/2007 18:57 53,432,978 kfw-3-2-0.exe 3/31/2007 18:55 8,507,392 kfw-3-2-0.msi 3/31/2007 18:57 6,275,544 kfw-3-2-0.zip 7/21/2006 9:48 27,951 msi-deployment-guide.txt 1/27/2006 14:59 1,345,437 netidmgr_userdoc.pdf You need to test and verify your scripts. That means you have to test your scripts and verify that the output matches the contents of the installers and zip files that can be downloaded from the MIT Kerberos web site. Let me know when you have the problems solved. From: To: Time: Sat Mar 31 19:08:33 2007 http://web.mit.edu/Public/jaltman/KFW/bkw.pl.log (your link with jaltman added) gives a HTTP 404. Which is odd, because it looks like the same URL as the link at 19:02, which still points to the old log. From: To: Time: Sat Mar 31 19:11:36 2007 [J:\Public\KFW]dir bkw.pl.log Volume in drive J is AFS Serial number is 0000:04d2 Directory of J:\Public\KFW\bkw.pl.log 3/31/2007 18:58 306,130 bkw.pl.log From: To: Time: Sat Mar 31 19:11:52 2007 http://web.mit.edu/jaltman/Public/KFW/bkw.pl.log From: To: Time: Sat Mar 31 19:12:24 2007 In the future, please use /VERBOSE. From: To: Time: Sat Mar 31 19:12:48 2007 I did. [J:\Public\KFW]perl bkw.pl /config BKWconfig.xml /u jaltman /r c:\temp\buildkfw /o c:\temp\kfwout /sign http://timestamp.verisign.com/scripts/timestamp.dll /v /repository checkout From: To: Time: Sat Mar 31 19:13:08 2007 Now I'm done with debugging your scripts. I'm not spending my time on it any longer. From: To: Time: Sat Mar 31 19:14:14 2007 I can't debug signing. From: To: Time: Sat Mar 31 19:21:02 2007 I suspect you don't have UNIXFIND set correctly, because your find command upcased -iname. From: To: Time: Sat Mar 31 19:22:31 2007 There is a tweak that makes sure -v works in place of -verbose. From: To: Time: Sat Mar 31 19:32:07 2007 Read the usage. /SIGN doesn't take a time stamp server. You have to put it in bkwconfig.xml in Stages/PostPackage/Config/Signing/CommandTamplate. From: To: Time: Sat Mar 31 19:33:13 2007 What happens if you try to sign a file that was already signed? Files signed in the staging area and then included in a zip will be signed again. From: To: Time: Sat Mar 31 21:45:45 2007 > I can't debug signing. You absolutely can. You don't need to sign a file in order to test your script. I told you how to debug it last week. Create a command to use in place of signtool.exe. Demonstrate that the command is executed on each file by having it write output that will be logged. > you don't have UNIXFIND set correctly quite possibly. Every other parameter can be set from the command line. Each time I have to update the XML files from Subversion I lose the configuration file. > /SIGN doesn't take a time stamp server The configuration file says otherwise: . >What happens if you try to sign a file that was already signed? Then the signature on the file is replaced and the files in the installer and the zip file will not match. You must sign the files once in the staging area. Not multiple times as you build each package. From: To: Time: Sat Mar 31 21:47:37 2007 The reason that your NSIS installer is so large is that you are building it within the staging area. By doing so you are incorporating the previous installer, the Wix installer, and all of the intermediary build files in the installer. Each time you run your script the next installer gets larger. You must run the installer scripts from a location other than the staging area. Once the binaries are signed, the staging area should be read-only. From: To: Time: Sat Mar 31 21:48:48 2007 My understanding is that the staging area is supposed to deleted for each run and built from scratch. Obviously the script is not doing so. From: To: Time: Sat Mar 31 22:20:03 2007 I suspect you would also agree that these paths in the zip files are wrong: 0 03-31-07 18:58 kfw-3-2-0-final/kfw-3-2-0-final/install/wix/ 5511 08-22-06 22:28 kfw-3-2-0-final/kfw-3-2-0-final/install/wix/config.wxi 12725 03-06-07 19:30 kfw-3-2-0-final/kfw-3-2-0-final/install/wix/features.wxi 96895 03-31-07 18:55 kfw-3-2-0-final/kfw-3-2-0-final/install/wix/files.wxi 8507392 03-31-07 18:55 kfw-3-2-0-final/kfw-3-2-0-final/install/wix/kfw.msi 548214 03-31-07 18:55 kfw-3-2-0-final/kfw-3-2-0-final/install/wix/kfw.wixobj 10138 01-20-07 01:50 kfw-3-2-0-final/kfw-3-2-0-final/install/wix/kfw.wxs From: To: Time: Sat Mar 31 22:20:43 2007 notice the doubling of "kfw-3-2-0-final" and the inclusion of kfw.msi and kfw.wixobj which are the installer and an intermediary build file From: To: Time: Sat Mar 31 22:22:03 2007 another bug: the release notes do not get copied to the output directory. I haven't verified whether or not they are in the documentation directory or not. From: To: Time: Sat Mar 31 22:26:17 2007 Why does the directory have to be removed? [07/03/31 22:25:04] rm: cannot remove directory `c:\\temp\\kfwout': Device or resource busy [07/03/31 22:25:04] Fatal -- Couldn't remove c:\temp\kfwout. at bkw.pl line 554. From: To: Time: Sat Mar 31 22:26:50 2007 I would expect the contents should be emptied when the build starts. From: To: Time: Sat Mar 31 22:59:33 2007 I 'tested' signing already by sticking an 'echo' in front of the signtool command. I have to see if every file in corebinaries.xml (in pismere/target) is also copied into staging by copyfiles.xml. If so, I will only have to zip the staging area and change corebinaries.xml to pull from the staging area. Losing changes to your config files sounds like a good reason to put the timestamp server on the command line. Let's see if Sam agrees. From: To: Time: Sat Mar 31 23:01:39 2007 you would need to provide a command line option for the unixfind as well . From: To: Time: Sat Mar 31 23:31:50 2007 That the directory is busy usually means you have a file open. Maybe you had a zip open? I forgot to add to the most recent commit msg that relnotes.html was added to the final copy into . From: To: Time: Sat Mar 31 23:32:17 2007 I had explorer open so I could watch the build process From: To: Time: Sat Mar 31 23:35:59 2007 if you forgot to mention something in a commit message, update the ticket to include the missing information From: To: Time: Sat Mar 31 23:39:44 2007 Except for resigning files, which will be fixed soon, the rest of the process should work now. From: To: Time: Sat Mar 31 23:54:03 2007 have you tested building specific tagged versions yet? From: To: Time: Sun Apr 1 00:01:48 2007 the most recent script fails. [07/04/01 00:01:33] [07/04/01 00:01:33] Info -- *** End build. [07/04/01 00:01:33] Info -- *** Begin prepackage. [07/04/01 00:01:33] Info -- chdir to c:\temp\buildkfw\pismere [07/04/01 00:01:33] [07/04/01 00:01:33] rmdir: c:\temp\buildkfw\pismere\staging: No such file or directory [07/04/01 00:01:33] Fatal -- Couldn't remove c:\temp\buildkfw\pismere\staging. at bkw.pl line 471. [C:\src\kerberos\mit-cvs\pismere\athena\auth\krb5\src\windows\build]dir c:\temp\buildkfw\pismere\staging Volume in drive C is IBM_PRELOAD Serial number is c827:bf77 4NT: (Sys) The system cannot find the file specified. "C:\temp\buildkfw\pismere\staging" 0 bytes in 0 files and 0 dirs 8,873,103,360 bytes free [C:\src\kerberos\mit-cvs\pismere\athena\auth\krb5\src\windows\build]dir c:\temp\buildkfw\pismere Volume in drive C is IBM_PRELOAD Serial number is c827:bf77 Directory of C:\temp\buildkfw\pismere\* 3/31/2007 23:37 . 3/31/2007 23:37 .. 3/31/2007 23:36 athena 3/31/2007 23:36 CVS 3/31/2007 23:35 doc 3/31/2007 23:36 scripts 3/31/2007 23:38 target 0 bytes in 0 files and 7 dirs 8,873,103,360 bytes free From: To: Time: Sun Apr 1 02:02:20 2007 MIt Kerberos Development Team From: To: Time: Sun Apr 1 02:02:21 2007 raeburn has set the topic to: Kerberos From: To: Time: Sun Apr 1 07:56:48 2007 The script still does not clean the output directory at script start. If I didn't notice that the script failed I might think the contents of the output directory are valid From: To: Time: Sun Apr 1 14:29:59 2007 No, I think having a command line switch for unixfind is wrong Better options seme to include not using it, having a convention for where we as KFW developers will install it From: To: Time: Sun Apr 1 14:50:37 2007 the path that I have used for years to install of my tools is c:\tools. The cygwin binaries are under c:\tools\cygwin From: To: Time: Sun Apr 1 14:54:32 2007 I'd have no problem standardizing on that. From: To: Time: Sun Apr 1 14:54:37 2007 the tools directory also includes any tools that can be installed without a full Windows installer or which do not handle spaces in the path name particulary well. jave, masm, nant, putty, sourcer, stuffit, sysinternals, wix, kermit, cvs, gnupg, ... When building new machines the tools directory can simply be copied from machine to machine. From: To: Time: Sun Apr 1 18:07:44 2007 Jeff, I checked in updates that address the issues raised in the last iteration. Have you had a chance to test them? From: To: Time: Sun Apr 1 18:08:58 2007 Do you mean c:\tools\cygwin\bin? My installation is in c:\cygwin and the binaries are in c:\cygwin\bin. From: To: Time: Sun Apr 1 18:13:07 2007 Jeff said that he would not test again until you had confirmed that the contents of the generated zips and installers match what is happening with KFW 3.1. From: To: Time: Sun Apr 1 18:14:38 2007 Then that's what I'll do next. From: To: Time: Sun Apr 1 20:57:58 2007 I wonder if these two differences in SDK files are correct: KfW 3.2.0 includes these two files that 3.1.0 does not. Why shouldn't they be in the SDK? wix/lang/license.rtf. nsis/licenses.rtf is in both. nsi-includes.nsi. An oversight in 3.1? From: To: Time: Sun Apr 1 21:20:12 2007 the contents of licenses.rtf used to be incorporated into other files. they were broken out so that it would be easier to maintain them. nsi-includes.nsi belongs in 3.2 From: To: Time: Sun Apr 1 22:07:19 2007 So does wix/lang/license.rtf belong or not? Is is one of the broken out parts? From: To: Time: Sun Apr 1 22:07:44 2007 they both belong From: To: Time: Sun Apr 1 22:10:28 2007 In the source zip, what is wash? From: To: Time: Sun Apr 1 22:11:14 2007 you mean pismere/scripts/wash ? From: To: Time: Sun Apr 1 22:14:48 2007 Yes. From: To: Time: Sun Apr 1 22:15:26 2007 scripts for the wash machine From: To: Time: Sun Apr 1 22:16:26 2007 wash isn't in 3.1. From: To: Time: Sun Apr 1 22:16:44 2007 the wash machine is private to mit and is not distributed with kfw From: To: Time: Sun Apr 1 22:17:48 2007 Is my assumption correct that .cvsignore should be omittted? From: To: Time: Sun Apr 1 22:18:08 2007 .cvsignore should be omitted From: To: Time: Sun Apr 1 22:23:05 2007 There arealso differences in Makefile.dir, Makefile.src. Ignore them? From: To: Time: Sun Apr 1 22:23:35 2007 yes From: To: Time: Sun Apr 1 22:26:07 2007 What is krb5/src/windows/wintel/.Sanitize? From: To: Time: Sun Apr 1 22:28:14 2007 they were removed from the repository From: To: Time: Sun Apr 1 22:28:32 2007 as were the ChangeLog files From: To: Time: Sun Apr 1 22:32:44 2007 Note that for things like scripts/wash, you should not check them out in the first place. I can see an argument for deleting the .CVSIGNORE files but you should get the set of things you are deleting down to a set where hard coding them is reasonable. I.E. exposing a config file option seems harmful in this instance because someone might use it. From: To: Time: Sun Apr 1 22:39:38 2007 What's the svn equivalent of cvs CVSROOT/modules? From: To: Time: Sun Apr 1 22:40:03 2007 Or, how can I say to not check it out? From: To: Time: Sun Apr 1 22:40:50 2007 There should not be anything in svn we don't want to ship. What do you believe we don't want to ship from the svn tree? From: To: Time: Sun Apr 1 22:43:47 2007 Cockpit error. From: To: Time: Sun Apr 1 22:54:16 2007 krb5/src/util/pty has been removed? From: To: Time: Sun Apr 1 22:58:32 2007 No, moved to krb5/src/appl From: To: Time: Sun Apr 1 23:27:15 2007 Was krb5/src/util/db2 moved or removed? From: To: Time: Sun Apr 1 23:27:59 2007 moved to src/plugins/kdb/db2 or something like that From: To: Time: Sun Apr 1 23:49:53 2007 Do we include krb5/src/windows/build? From: To: Time: Sun Apr 1 23:50:04 2007 yes From: To: Time: Sun Apr 1 23:50:37 2007 Yes From: To: Time: Sun Apr 1 23:51:18 2007 src/windows/README must be updated with text describing how to use the build scripts to build the source distribution provided in the zip file. From: To: Time: Mon Apr 2 11:34:02 2007 loadfuncs/loadfuncs.c has been removed from inc/loadfuncs in the KfW 3.2 SDK. I assume it was a mistake for a .c to be in the includes area? From: To: Time: Mon Apr 2 11:34:18 2007 no it wasn't From: To: Time: Mon Apr 2 11:36:55 2007 OK, is it correct for loadfuncs.c to not be in the 3.2 SDK inc/loadfuncs area? From: To: Time: Mon Apr 2 11:37:16 2007 loadfuncs.c is where it is. do not remove it From: To: Time: Mon Apr 2 11:37:48 2007 it might not be the best place for it, but it needs to be somewhere that it can be looked at by developers that want to use the loadfuncs headers From: To: Time: Mon Apr 2 11:41:43 2007 Thanks for the explanation. From: To: Time: Mon Apr 2 12:15:51 2007 src/windows/README talks about building krb5. It looks like it was written before NIM. It looks like I should add a section for building all the windows products. Not change anything that's there. From: To: Time: Mon Apr 2 12:18:51 2007 src/windows/README describes how to build the krb5 distribution on its own. however, doing so results in many missing pieces. no API ccache support, no ticket manager, etc. Perhaps the text on your build script should go into the pismere/doc/kerberos/README.html From: To: Time: Mon Apr 2 12:22:22 2007 That's a pointer to pismere/doc/kerberos/relnotes.html. I'll add something there. From: To: Time: Mon Apr 2 12:22:43 2007 right, that file From: To: Time: Mon Apr 2 12:23:18 2007 I haven't touched it yet. All of the changes I posted to krbcore last week in the status report have to be added to it. From: To: Time: Mon Apr 2 12:23:31 2007 I'm still working on the NIM documentation updates From: To: Time: Mon Apr 2 12:23:49 2007 the PDF documentation is done but the htmlhelp needs work From: To: Time: Mon Apr 2 12:27:46 2007 The SDK and core binary zips have been verified. The source zip should be perfect, as it is a snapshot right after the checkout. From: To: Time: Mon Apr 2 12:28:08 2007 have you tested with cvs and svn tags? From: To: Time: Mon Apr 2 12:29:44 2007 No. Can you give me some example tags? From: To: Time: Mon Apr 2 12:30:44 2007 look in the repositories and pull out the tags for kfw 3.1.0 final From: To: Time: Mon Apr 2 12:34:02 2007 or apply a test an alpha tag to the pismere repository for the sources that are used by the build script and use the 1-6 branch tag on the krb5 repository From: To: Time: Mon Apr 2 12:37:26 2007 I would not expect Kevin's copyfiles to dtrt for 3.1.. I recommend Jeff's second suggestion From: To: Time: Mon Apr 2 13:11:44 2007 Why does cvs history -a -T show no tags since 2001? From: To: Time: Mon Apr 2 14:10:49 2007 the history file may be in a weird state... i don't remember From: To: Time: Mon Apr 2 14:32:59 2007 one more thing that needs to be tested for the script. In order for MIT and SEI to distribute binaries from the same build but with different signatures it must be possible to run the packaging step without a recompile and when the /sign option is given the binaries must be signed once before the installers and the zip files are built. From: To: Time: Mon Apr 2 14:35:28 2007 Jeff, that sounds like a new requirement. Or at least you didn't bring up that requirement when Kevin posted his original usage discussion to krbcore. From: To: Time: Mon Apr 2 14:36:03 2007 Although I agree with you that it is a requirement From: To: Time: Mon Apr 2 14:36:29 2007 that is not a new requirement. I've been talking about it all weekend. I have been saying that it is crucial that the binaries be the same. From: To: Time: Mon Apr 2 14:36:50 2007 the command-line switches are there for this functionality. I just don't know that it has been tested. From: To: Time: Mon Apr 2 14:38:24 2007 I think it is a new requirement as of this weekend. From: To: Time: Mon Apr 2 14:38:30 2007 I'm not sure about that From: To: Time: Mon Apr 2 14:39:56 2007 But anyway, we both agree it is a requirement and must be tested From: To: Time: Mon Apr 2 14:40:37 2007 agreed From: To: Time: Mon Apr 2 14:44:43 2007 If you mean the binaries that are incorporated into the installers and corebinaries zip, that may not be a problem. I'll have to see if the signing is skipped with /NOMAKE, If not, it might be as simple as moving the signing into thr end of the make step. From: To: Time: Mon Apr 2 14:45:47 2007 In my opinion, signing is part of the packaging process. From: To: Time: Mon Apr 2 14:46:36 2007 WRT cvs question. Why, after cvs tag -R kfw-3-2-0-alpha, does cvs history -a -T not show my new tag? Even though cvs checkout -r kfw-3-2-0-alpha krb succeeds? From: To: Time: Mon Apr 2 14:47:21 2007 If /nopackaging is specified, signing should not be done. > cvs question I don't know. From: To: Time: Mon Apr 2 14:48:50 2007 WRT signing, maybe the way it is now is ok. Run with /NOMAKE and the binaries won't be rebuilt. Signing happens right before building the installers. Is that the behavior you want? From: To: Time: Mon Apr 2 14:49:01 2007 yes From: To: Time: Mon Apr 2 14:49:27 2007 I thought the functionality was there From: To: Time: Mon Apr 2 14:58:12 2007 which CVSROOT? From: To: Time: Mon Apr 2 14:58:23 2007 I assume pismere From: To: Time: Mon Apr 2 14:58:23 2007 it may have to do with the silly val-tags file From: To: Time: Mon Apr 2 14:59:39 2007 easier to do a cvs status -v on some file which you know has been subjected to the tags you're interested in From: To: Time: Mon Apr 2 15:02:25 2007 about to poke at webrt. there may be a disturbance in the Force. From: To: Time: Mon Apr 2 15:05:35 2007 done. now there is https/http isolation for webrt cookies From: To: Time: Mon Apr 2 15:07:19 2007 With http://krbdev.mit.edu/rt/ Can't call method "Id" on an undefined value at /var/rt2/WebRT/html/autohandler line 58, line 2. Stack: [/var/rt2/WebRT/html/autohandler:58] From: To: Time: Mon Apr 2 15:08:07 2007 and with https://krbdev.mit.edu/rt/ I'm not getting a successful access to a page which I suspect is an authentication problem. From: To: Time: Mon Apr 2 15:08:19 2007 hm, are you using certificates? From: To: Time: Mon Apr 2 15:08:22 2007 yes From: To: Time: Mon Apr 2 15:09:04 2007 what are you getting at https://krbdev.mit.edu/rt/? From: To: Time: Mon Apr 2 15:10:04 2007 firefox just says "Connecting to krbdev.mit.edu ..." and then times out after a long wait From: To: Time: Mon Apr 2 15:10:21 2007 that was a debugging hook on the http url From: To: Time: Mon Apr 2 15:10:38 2007 Any idea why a cvs checkout doesn't create a CVS/Repository? Subsequent cvs updates fail. From: To: Time: Mon Apr 2 15:10:56 2007 what was your checkout command? From: To: Time: Mon Apr 2 15:11:28 2007 shutting down firefox and restarting permits access. weird. I wonder if it was a cookie thing From: To: Time: Mon Apr 2 15:11:33 2007 Info -- cvs command: cvs checkout krb From: To: Time: Mon Apr 2 15:11:38 2007 may have been a cookie thing From: To: Time: Mon Apr 2 15:12:05 2007 How would I fix that? From: To: Time: Mon Apr 2 15:12:09 2007 "krb" not "krb5"? From: To: Time: Mon Apr 2 15:12:15 2007 which repository? From: To: Time: Mon Apr 2 15:13:38 2007 :kserver:cvs.mit.edu:/cvs/pismere From: To: Time: Mon Apr 2 15:14:16 2007 looks like "krb" is a module def in the pismere repository From: To: Time: Mon Apr 2 15:14:50 2007 The krb5 stuff is in svn. From: To: Time: Mon Apr 2 15:15:41 2007 did you try running cvs from the directories it created? From: To: Time: Mon Apr 2 15:15:50 2007 cvs checkout worked until recently. What is the cookie thing you mentioned? From: To: Time: Mon Apr 2 15:16:07 2007 the cookie has to do with firefox From: To: Time: Mon Apr 2 16:57:06 2007 i believe i've pull up the last of the build script changes in ticket #5490 From: To: Time: Mon Apr 2 17:06:41 2007 hm, looks like Kevin just made another commit From: To: Time: Mon Apr 2 17:07:04 2007 I suspect that Kevin has not finished testing yet From: To: Time: Mon Apr 2 17:07:23 2007 Tom, you should coordinate with Kevin and make sure at this point he's using tickets and pullup requests From: To: Time: Mon Apr 2 17:07:31 2007 I disappear for a bit. From: To: Time: Mon Apr 2 17:07:49 2007 he's been committing to ticket #5490 From: To: Time: Mon Apr 2 17:08:09 2007 if we need a stable point, i can ask him to make future build system commits to different tickets From: To: Time: Mon Apr 2 17:08:25 2007 I'm hoping he is close to finishing From: To: Time: Mon Apr 2 17:08:58 2007 Let me know what the deadline is for tagging and getting a build done for tonight. If the script isn't ready, I will build by hand From: To: Time: Mon Apr 2 17:09:38 2007 Try now. From: To: Time: Mon Apr 2 17:09:54 2007 what should I try? From: To: Time: Mon Apr 2 17:12:07 2007 Try your build. I checked the zips as mentioned earlier and tested tags and svn branches. From: To: Time: Mon Apr 2 17:14:24 2007 I'm going to test with your kfw-3-2-0-alpha pismere tag and the 1.6 krb5 branch. can you update pismere/doc/kerberos/relnotes.html to include the new build procedures while I test? From: To: Time: Mon Apr 2 17:16:27 2007 Does that have to be done tonight? From: To: Time: Mon Apr 2 17:17:27 2007 if it is going to make it into beta 1 yes. If you want third parties to test the build scripts it should be done. Otherwise, it will go into the next build. I'm hoping there won't be a beta 2. From: To: Time: Mon Apr 2 17:18:04 2007 I suspect it should be a cut and paste from the docs you have already written From: To: Time: Mon Apr 2 17:18:31 2007 All right, I'll do that instead of work on taxes tonight. I will be driving home soon, with laptop. From: To: Time: Mon Apr 2 17:19:31 2007 thanks From: To: Time: Mon Apr 2 17:20:20 2007 is there a conflict that both /cvstag and /config have /c as the shortcut? From: To: Time: Mon Apr 2 17:21:50 2007 Yep. From: To: Time: Mon Apr 2 17:23:27 2007 If I'm right, the following commands should do the right thing: perl bkw.pl /config BKWconfig.xml /u jaltman /r c:\temp\buildkfw /o c:\temp\kfwout\mit /nosign /v /repository checkout /cvstag kfw-3-2-0-alpha /svnbranch krb5-1-6 perl bkw.pl /config BKWconfig.xml /u jaltman /r c:\temp\buildkfw /o c:\temp\kfwout \sei /sign /v /repository skip /nomake do you agree? From: To: Time: Mon Apr 2 17:23:29 2007 The problem is in the usage. The implementation uses -f for the config File. From: To: Time: Mon Apr 2 17:25:20 2007 Those look like reasonable command lines. From: To: Time: Mon Apr 2 17:25:45 2007 should the first one contain /clean and the second one leave it out? From: To: Time: Mon Apr 2 17:26:49 2007 CHECKOUT deletes SRCDIR. From: To: Time: Mon Apr 2 17:27:08 2007 the docs say /clean cleans the target directory From: To: Time: Mon Apr 2 17:27:49 2007 And so it does. Try checking out when the srcdir exists. From: To: Time: Mon Apr 2 17:28:16 2007 if I'm reading you correctly, since target is a subdir of SRCDIR it will be cleaned without /clean when /repository checkout is specified From: To: Time: Mon Apr 2 17:28:31 2007 Correct. From: To: Time: Mon Apr 2 17:28:48 2007 /clean would only be used in combination with /repository skip or /repository update From: To: Time: Mon Apr 2 17:29:00 2007 Correct. From: To: Time: Mon Apr 2 17:29:22 2007 well, here goes. From: To: Time: Mon Apr 2 17:30:36 2007 Sam, did you want to update the meeting rooms for the apple conference call? From: To: Time: Mon Apr 2 17:50:44 2007 I have a multiprocessor system. why when building under the perl script is 78% of my cpu power idle? Because everything is blocking on stdio output. I guess I just have to wait. From: To: Time: Mon Apr 2 17:52:21 2007 What stage is the build in? From: To: Time: Mon Apr 2 17:52:37 2007 krb5 From: To: Time: Mon Apr 2 17:52:49 2007 krb5/windows/identity From: To: Time: Mon Apr 2 17:53:01 2007 probably another 6 or 8 minutes From: To: Time: Mon Apr 2 17:53:19 2007 So it has already generated the src.zip. From: To: Time: Mon Apr 2 17:53:32 2007 yes, it generated that awhile ago From: To: Time: Mon Apr 2 17:53:42 2007 Or is it still fetching? Fetching or building? From: To: Time: Mon Apr 2 17:53:58 2007 it is building. From: To: Time: Mon Apr 2 17:54:28 2007 Where would you suggest I put relnotes.html so you can give feedback without me having to check it in a bunch of times? From: To: Time: Mon Apr 2 17:54:48 2007 there is a kfwout\mit\kfw-3-1-0-src.zip file. hmm, why is it 3.1.0? From: To: Time: Mon Apr 2 17:54:59 2007 the best place to put stuff would be afs From: To: Time: Mon Apr 2 17:55:17 2007 What is kerberos.ver? From: To: Time: Mon Apr 2 17:55:38 2007 I don't have afs yet, so suggest something else. From: To: Time: Mon Apr 2 17:55:40 2007 you have an afs directory which you can access if you install the openafs client From: To: Time: Mon Apr 2 17:56:15 2007 the path will be \\afs\athena.mit.edu\user\k\p\kpkoch\ From: To: Time: Mon Apr 2 17:57:10 2007 otherwise, what can you write to? From: To: Time: Mon Apr 2 18:00:16 2007 With secureFX, I can write to athena.mit.edu\user\k\p\kpkoch\. Can you see public/relnotes.html? From: To: Time: Mon Apr 2 18:00:37 2007 Search for KPK to find the section I'm working on. From: To: Time: Mon Apr 2 18:00:53 2007 I'm going to drive home now. From: To: Time: Mon Apr 2 18:01:16 2007 the kerberos.ver says 3.1.0. you didn't cvs up before applying the krb-3-2-alpha tag so you tagged the 3-1-0 version From: To: Time: Mon Apr 2 18:01:52 2007 I just updated the tag From: To: Time: Mon Apr 2 18:02:02 2007 the build failed. let me see what the logs say From: To: Time: Mon Apr 2 18:03:10 2007 guiwrap.exe could not be found From: To: Time: Mon Apr 2 18:04:31 2007 you might want to log the command line that bkw.pl is started with From: To: Time: Mon Apr 2 18:07:37 2007 http://web.mit.edu/jaltman/Public/KFW/bkw-pass1.log is the failed build From: To: Time: Mon Apr 2 18:08:28 2007 I think the section you want to update is entitled "Building from Sources" From: To: Time: Mon Apr 2 18:09:08 2007 Replaced the text starting with "Then, go into the athena directory and type" From: To: Time: Mon Apr 2 18:10:35 2007 restarting the build. From: To: Time: Mon Apr 2 18:12:03 2007 also you need to cvs update before editing the relnotes.html file because you are using an old version From: To: Time: Mon Apr 2 18:12:38 2007 [C:\src\kerberos\mit-cvs\pismere\doc\kerberos]cvs status relnotes.html =================================================================== File: relnotes.html Status: Up-to-date Working revision: 1.73 Repository revision: 1.73 /cvs/pismere/pismere/doc/kerberos/relnotes.html,v Sticky Tag: (none) Sticky Date: (none) Sticky Options: (none) From: To: Time: Mon Apr 2 18:25:01 2007 the build is still failing on a missing guiwrap.exe From: To: Time: Mon Apr 2 18:27:24 2007 and that's because pismere/athena/util/guiwrap is not included in the build From: To: Time: Mon Apr 2 18:27:48 2007 so please tell me, how was this script tested? From: To: Time: Mon Apr 2 18:31:53 2007 pismere/athena/util/guiwrap is listed in bpw.pl. I bet the its not being checked out because it wasn't tagged From: To: Time: Mon Apr 2 18:32:56 2007 and that would correct. it was never tagged. in other words, /cvstag wasn't actually tested From: To: Time: Mon Apr 2 18:36:25 2007 tag applied to pismere/athena/util/guiwrap and trying it again From: To: Time: Mon Apr 2 18:51:50 2007 the compilation has completed. From: To: Time: Mon Apr 2 18:55:54 2007 But ... [07/04/02 18:50:57] Info -- chdir to c:\temp\buildkfw\pismere\staging [07/04/02 18:50:57] [07/04/02 18:50:58] Could Not Find c:\temp\buildkfw\pismere\staging\install\wix\site-local.sed [07/04/02 18:50:58] Info -- chdir to c:\temp\buildkfw\pismere\staging\install\nsis [07/04/02 18:50:58] [07/04/02 18:50:59] Info -- *** End prepackage. From: To: Time: Mon Apr 2 18:58:36 2007 The NSIS installer is still pulling in things that it shouldn't. For 3.1 the sizes were: 538,986 kfw-3-1-0-sdk.zip 14,921,284 kfw-3-1-0-src.zip 5,744,092 kfw-3-1-0.exe 8,369,664 kfw-3-1-0.msi 6,465,239 kfw-3-1-0.zip For this script output from the first pass (no signing) 551,344 kfw-3-2-0-sdk.zip 16,522,326 kfw-3-2-0-src.zip 13,929,891 kfw-3-2-0.exe 8,537,088 kfw-3-2-0.msi 6,695,865 kfw-3-2-0.zip From: To: Time: Mon Apr 2 19:00:43 2007 On the second pass when /NOMAKE is specified neither the NSIS nor Wix installers get build. From: To: Time: Mon Apr 2 19:00:46 2007 built From: To: Time: Mon Apr 2 19:01:45 2007 The logs are: http://web.mit.edu/jaltman/Public/KFW/bkw-pass1.log http://web.mit.edu/jaltman/Public/KFW/bkw-pass2.log From: To: Time: Mon Apr 2 19:04:48 2007 After dinner & catching up on your comments. I have tested this over and over again. Did I make a mistake when creating the cvs tag? Or which svn tag I used? From: To: Time: Mon Apr 2 19:06:56 2007 I don't know how you could have tested this with "/cvstag kfw-3-2-0-alpha" because you failed to tag the pismere/athena/util/guiwrap directory which is required for building. Since the kfw-3-2-0-alpha was not applied, when the script checks out the tag kfw-3-2-0-alpha, the contents of the directory are not checked out. From: To: Time: Mon Apr 2 19:09:45 2007 at this point, the build scripts will not be used for Beta 1. work on your taxes. when tom gets back we will start the process of tagging the release and I will build by hand. From: To: Time: Mon Apr 2 19:12:30 2007 Your pass 1 looks like it finished. Your pass 2 died when the info from kerberos.ver didn't make it into var.VersionMajor, etc. I'm running the nsis installer to see what's in it. From: To: Time: Mon Apr 2 19:15:40 2007 i'm going to pull up the last build script changes on ticket #5490. all future build system commits need to go to a different ticket. From: To: Time: Mon Apr 2 19:17:51 2007 BTW it is important that you not duplicate documentation between relnotes.html and docs in src/windows/build. You can reference these docs or you can include info and delete those docs but do not duplicate content. From: To: Time: Mon Apr 2 19:18:44 2007 are we still supporting building krb5 outside of kfw? From: To: Time: Mon Apr 2 19:20:29 2007 My 13MB NSIS installer expands into 26.6MB in program files/mit.kerberos. The WIX installer (3.1) on my host PC uses 24.5MB. The NSIS installer may be correct, but the compression isn't working as well? From: To: Time: Mon Apr 2 19:20:49 2007 Yes. As you recall we discussed our desire to move ccapi and the name service glue library into the krb5 tree when we move from cvs to svn so that those builds produce useful krb5_32.dll From: To: Time: Mon Apr 2 19:21:13 2007 yes we did From: To: Time: Mon Apr 2 19:21:47 2007 Considering that bkw.pl calls build.pl for the build, I would say yes. From: To: Time: Mon Apr 2 19:22:43 2007 kevin, I'm asking a different question. I'm asking if the standalone krb5 tree by itself should still build. That is what src/kerberos/windows/README documents. From: To: Time: Mon Apr 2 19:23:02 2007 that build doesn't use src/windows/build From: To: Time: Mon Apr 2 19:24:18 2007 When I build NSIS by hand the output of the installer is 6,047,880 MITKerberosForWindows.exe From: To: Time: Mon Apr 2 19:31:30 2007 I'm comparing directory listings now. From: To: Time: Mon Apr 2 19:33:34 2007 I'm comparing the NSIS output. For NSIS, when BETA is set the value NOT_RELEASE should be defined instead of RELEASE. From: To: Time: Mon Apr 2 19:33:52 2007 Otherwise, the Beta tag is not added to the product name From: To: Time: Mon Apr 2 19:34:30 2007 OK. From: To: Time: Mon Apr 2 19:35:56 2007 tagging... From: To: Time: Mon Apr 2 19:36:09 2007 tagging pismere From: To: Time: Mon Apr 2 19:36:16 2007 what tag name are you using? From: To: Time: Mon Apr 2 19:36:50 2007 tags/kfw-3_2_0-beta1 From: To: Time: Mon Apr 2 19:37:03 2007 I will use the same name for pismere From: To: Time: Mon Apr 2 19:39:02 2007 done From: To: Time: Mon Apr 2 19:39:08 2007 thanks From: To: Time: Mon Apr 2 19:39:36 2007 I should have the beta packages available in about 90 minutes From: To: Time: Mon Apr 2 19:39:37 2007 Jeff, is your plan for us to post the binaries tonight? From: To: Time: Mon Apr 2 19:40:18 2007 they can be posted on mit's web site tomorrow. I will post them for my clients tonight. From: To: Time: Mon Apr 2 19:40:26 2007 ok From: To: Time: Mon Apr 2 19:40:41 2007 I will put the packages plus the announcement text in ~jaltman/Public/KFW/ From: To: Time: Mon Apr 2 19:42:38 2007 pismere tagged as "kfw-3_2_0-beta1" From: To: Time: Mon Apr 2 22:28:43 2007 Jeff, do you have access to the ISDA wiki and in particular, to the ';restricted content?' From: To: Time: Mon Apr 2 22:29:14 2007 No, he does not. From: To: Time: Mon Apr 2 22:30:41 2007 The release notes describing how to use the automated build script could be a lot like parts of the restricted page I wrote. From: To: Time: Mon Apr 2 22:32:12 2007 I thought I already asked you to remove that content and move it into src/windows/build. From: To: Time: Mon Apr 2 22:32:36 2007 Or at least to make sure there is no duplication in content From: To: Time: Mon Apr 2 22:34:40 2007 I think it was the latter, but now it will be the former. From: To: Time: Mon Apr 2 22:35:39 2007 Well, it needs to be both. You can certainly copy in content but need to avoid duplication From: To: Time: Mon Apr 2 23:58:30 2007 Jeff, want to give the KfW build one more try? I believe all your earlier points have been addressed. I installed KfW3.1.1 and 3.2.0 on a VM and the results were the same, exceptimng license.rtf and nsi-includes.nsi. From: To: Time: Tue Apr 3 08:46:45 2007 I've added a short section to relnotes.html, pointing at krb5/src/windows/build/bkw-automation.html. Its at http://stuff.mit.edu/afs/athena.mit.edu/user/k/p/kpkoch/Public/relnotes.html. From: To: Time: Tue Apr 3 08:49:21 2007 that's the same as http://web.mit.edu/kpkoch/Public/relnotes.html. You don't have to write out all of the AFS path From: To: Time: Tue Apr 3 08:52:53 2007 the kerberos.ver file says this is a beta, and yet the script is outputing the file names as kfw-3-2-0-final From: To: Time: Tue Apr 3 08:53:19 2007 You will see this behavior when you set BUILD_OFFICIAL=1 From: To: Time: Tue Apr 3 08:54:22 2007 BUILD_OFFICIAL=1 indicates to the pismere build script that the files should not be labeled "(UNOFFICIAL)". "UNOFFICIAL" means that the files did not come from MIT or an authorized source. From: To: Time: Tue Apr 3 08:56:34 2007 See the "build_official.bat" file in ~jaltman/Public/KFW From: To: Time: Tue Apr 3 08:58:14 2007 You still have not "cvs update" your pismere tree. The relnotes.html file you edited is the KFW 3.1 version, not the KFW 3.2 Beta 1 version. From: To: Time: Tue Apr 3 09:01:33 2007 there are now cvs and svn tags for "kfw-3_2_0-beta1". You should use that for testing and compare your output to the output in ~jaltman/Public/KFW/kfw-3_2_0-beta1. Differences in file paths, file sizes, versioning info, etc. are clues that there are still things that are wrong. From: To: Time: Tue Apr 3 09:02:42 2007 I'm going to busy on other things for the next several days. I'm not going to have time to more carefully examine the output of your script From: To: Time: Tue Apr 3 09:14:19 2007 WRT the relnotes, all I'm looking for is comments about the short section I added. The inserted section should be the same in whatever relnotes it ultimately goes into. From: To: Time: Tue Apr 3 09:15:11 2007 Between the lines, did you say that your two script invocations completed? From: To: Time: Tue Apr 3 09:19:43 2007 the script invocations completed. they also completed around 7:00pm prior to my giving up on the script output because the size of the NSIS installer was obviously wrong. I ran the script at 3:30am with your updated changes. The NSIS size is reasonable. Looking at the content of the zip file I immediately found problems which I have described. From: To: Time: Tue Apr 3 09:20:01 2007 I'm working on other things. I will get back to KFW in a few days From: To: Time: Tue Apr 3 09:20:24 2007 Do you ever sleep? From: To: Time: Tue Apr 3 09:21:04 2007 No From: To: Time: Tue Apr 3 09:51:34 2007 What you added to relnotes.html is this: "krb5/windows/build/bkw.pl will fetch the sources from a repository and then build, sign and package all the KfW distribution components. See krb5/windows/build/bkw-automation.html for more details." The target audience for relnotes.html are consumers who should not be expected to have cvs or svn access to MIT's repositories. What they have is the kfw--src.zip file output. The instructions that have to go into relnotes.html are how to use the build script to build the source files that they obtained from the zip file. They don't need to know about all of the options. Just the ones that would apply to someone building from sources already on their machine. From: To: Time: Tue Apr 3 11:45:11 2007 Is this KfW build release note better? http://web.mit.edu/kpkoch/Public/relnotes.html#bkw From: To: Time: Tue Apr 3 11:47:38 2007 Looks reasonably good to me. From: To: Time: Tue Apr 3 15:38:33 2007 do we need the "repository-tar" thing on krbdev anymore? From: To: Time: Tue Apr 3 17:18:12 2007 Can we just kill the info-kerberos list now? From: To: Time: Tue Apr 3 17:21:19 2007 what's it doing? From: To: Time: Tue Apr 3 17:25:08 2007 Forwarding spam to us, and not acting as a useful contact point. From: To: Time: Tue Apr 3 17:33:43 2007 just wondering if there was a recent incident that was annoying you From: To: Time: Tue Apr 3 19:36:53 2007 dynamic bugs/fixed lists for krb5 releases now do automatic login as "guest" when someone clicks on a link From: To: Time: Tue Apr 3 19:37:44 2007 Neat. Is this only when someone's not already logged in or presenting MIT certificates? From: To: Time: Tue Apr 3 19:38:03 2007 no, always logs in as guest if you're using a http url From: To: Time: Tue Apr 3 19:38:27 2007 it will blow away the login of someone who is getting in via http From: To: Time: Tue Apr 3 19:38:34 2007 that case is somewhat unlikely though From: To: Time: Tue Apr 3 19:39:01 2007 I suppose. Do we support http logins other than guest? From: To: Time: Tue Apr 3 19:39:09 2007 i suppose there's this self-service thing From: To: Time: Tue Apr 3 19:39:10 2007 (I've always used certs and https...) From: To: Time: Tue Apr 3 19:39:27 2007 I use password and https. From: To: Time: Tue Apr 3 19:39:37 2007 and theoretically we accept logins from actual users using http but i wouldn't recommend it From: To: Time: Tue Apr 3 19:40:12 2007 so part of the reason i did the http/https cookie separation was so that you don't send a privileged cookie via cleartext From: To: Time: Wed Apr 4 11:04:44 2007 Any comments on http://web.mit.edu/kpkoch/Public/bkw-automation.html, a working copy of the non-MIT-specific description of how to build KfW? The finished version will be included in krb5/src/windows/build. From: To: Time: Thu Apr 5 10:24:20 2007 How does the build system work for KfM? What's a submission? What's a jamfile? From: To: Time: Thu Apr 5 14:30:56 2007 kevin, did anyone answer your KfM questions? From: To: Time: Thu Apr 5 15:19:12 2007 Apple seems to have found a bug in our locate plugins From: To: Time: Thu Apr 5 15:19:29 2007 Oh? From: To: Time: Thu Apr 5 15:20:13 2007 From their tests it looks like if the locate plugin returns no IP addresses then it crashes: Thread 6 Crashed: 0 edu.mit.Kerberos 0x2005930d send_as_request + 200 (get_in_tkt.c:173) 1 edu.mit.Kerberos 0x2005ab39 krb5_get_init_creds + 2179 (get_in_tkt.c:1202) 2 edu.mit.Kerberos 0x2005bd46 krb5_get_init_creds_password + 335 (gic_pwd.c:146) From: To: Time: Thu Apr 5 15:20:30 2007 Mmm, looking... From: To: Time: Thu Apr 5 15:21:36 2007 They have a lot of debugging in their bug report. it looks like they tracked it down to the reply variable having a length of 0 and a NULL data From: To: Time: Thu Apr 5 15:26:01 2007 Hm, yeah, it looks like the code may not correctly handle the case where the plugin indicates that there are no addresses for the service. From: To: Time: Thu Apr 5 15:28:54 2007 krb5int_locate_server should run the check for an empty address list if it gets a success indication from module_locate_server. From: To: Time: Thu Apr 5 15:37:51 2007 You want to fix it or should I? From: To: Time: Thu Apr 5 15:38:30 2007 I'm working on a fix, but haven't tested (or, so far, tried to reproduce the bug). From: To: Time: Thu Apr 5 15:38:42 2007 have you tried to reproduce it? From: To: Time: Thu Apr 5 15:39:04 2007 no, I was just reading the open bugs list and that one is new From: To: Time: Thu Apr 5 15:39:15 2007 Doing my daily Radar audit From: To: Time: Thu Apr 5 15:39:26 2007 Okay, I'll keep playing with it then. From: To: Time: Thu Apr 5 15:59:27 2007 Hm, the library isn't looking for plugins under $prefix on my mac... it finds /System/Library/KerberosPlugins/KerberosFrameworkPlugins doesn't exist, and that's it. From: To: Time: Thu Apr 5 16:00:04 2007 For a kfm build that's correct isn't it? From: To: Time: Thu Apr 5 16:00:34 2007 yes From: To: Time: Thu Apr 5 16:00:36 2007 The library code is passing a list of (two) directories. And I'm not doing a kfm build specifically, this is a test build. From: To: Time: Thu Apr 5 16:00:46 2007 ... of plain krb5 From: To: Time: Thu Apr 5 16:00:54 2007 Ah From: To: Time: Thu Apr 5 16:01:17 2007 I believe it is special cased for the platform, but I'm not sure From: To: Time: Thu Apr 5 16:01:56 2007 The special case I see is that /System/... is added to the front of the list. It's only one directory if !TARGET_OS_MAC. From: To: Time: Thu Apr 5 16:02:26 2007 yeah that's what's supposed to happen. Oh wait you're saying it's not trying the other directories? From: To: Time: Thu Apr 5 16:03:46 2007 Right. An error is recorded because the first directory doesn't exist. So it's done. From: To: Time: Thu Apr 5 16:04:47 2007 oh heh that's a bug From: To: Time: Thu Apr 5 16:06:00 2007 where does the error come from? the code I'm looking at tosses the error from krb5int_open_plugin() From: To: Time: Thu Apr 5 16:09:06 2007 krb5int_open_plugin_dirs, in the branch where no filenames are passed so it has to use opendir. From: To: Time: Thu Apr 5 16:10:41 2007 oh yeah that's a bug From: To: Time: Thu Apr 5 16:11:54 2007 Ah, yes, and now that i've created the directory, here we go... Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_PROTECTION_FAILURE at address: 0x00000000 0x002359f4 in send_as_request (context=0x1800400, request=0xbfffdd2c, ret_err_reply=0xbfffdce8, ret_as_reply=0xbfffdcec, use_master=0xbfffde28) at ../../../../krb5/src/lib/krb5/krb/get_in_tkt.c:145 145 if (krb5_is_krb_error(&reply)) { From: To: Time: Thu Apr 5 16:16:23 2007 you want me to fix the problem with the opendir error handling? From: To: Time: Thu Apr 5 16:16:58 2007 Please. I'm writing the log message for the fix for Apple's problem now. From: To: Time: Thu Apr 5 16:17:18 2007 If you've got time. If not, we can open a ticket for now. From: To: Time: Thu Apr 5 16:17:48 2007 I'll shove it onto the trunk. if you've got a test setup I'd appreciate some testing. Otherwise I'll have to set something up to test it From: To: Time: Thu Apr 5 16:19:25 2007 Testing is pretty easy, sure. (Install and try to use the Python service-location plugin, with /System/... not existing.) From: To: Time: Thu Apr 5 16:23:35 2007 r19399, ticket 5509, has the fix for apple. From: To: Time: Thu Apr 5 16:32:44 2007 If there are no plugins should it be returning an empty list or an error? (right now it returns an empty list) From: To: Time: Thu Apr 5 16:34:31 2007 "it" being...? From: To: Time: Thu Apr 5 16:34:47 2007 krb5int_open_plugin_dirs From: To: Time: Thu Apr 5 16:35:26 2007 r19400, ticket 5510 is my fix for the opendir problem From: To: Time: Thu Apr 5 16:35:28 2007 Ah. I think an empty list is a reasonable degenerate case when the files or directories don't exist. From: To: Time: Thu Apr 5 16:35:54 2007 I updated a moment too soon. :-) From: To: Time: Thu Apr 5 16:40:08 2007 Works in my tests. From: To: Time: Thu Apr 5 16:40:25 2007 cool, it's a pretty minimal change, I just wanted to make sure From: To: Time: Sun Apr 8 02:02:20 2007 MIt Kerberos Development Team From: To: Time: Sun Apr 8 02:02:21 2007 raeburn has set the topic to: Kerberos From: To: Time: Tue Apr 10 17:22:54 2007 i'm looking through resolved tickets that have no target version, and marking some for 1.6.1. do we want #5517? From: To: Time: Tue Apr 10 17:28:50 2007 I have no idea ;-) From: To: Time: Tue Apr 10 17:35:44 2007 I'd say not yet on 5517, unless we've got a good long beta period. Might still need some bugs shaken out. From: To: Time: Tue Apr 10 17:36:31 2007 Though if Denis gets a chance to try it out in his environment, that'd be helpful. From: To: Time: Tue Apr 10 17:37:13 2007 i'm inclined to leave it out, then. i don't want a long beta period for 1.6.1 From: To: Time: Tue Apr 10 17:39:00 2007 Sounds good. From: To: Time: Wed Apr 11 10:47:50 2007 Why are there 5 different versions of com_err.h with 4 different file sizes? 745 /afsauth/afs-3.6/include/afs/com_err.h 1322 /krb4/include/com_err.h 1314 /krb4/krbv4/com_err/com_err.h 1839 /krb5/src/include/com_err.h 1839 /krb5/src/util/et/com_err.h From: To: Time: Wed Apr 11 11:30:14 2007 which repository are those in? From: To: Time: Wed Apr 11 11:49:26 2007 the krb4 & afsauth stuff is in pismere; the krb5 stuff is in svn. From: To: Time: Wed Apr 11 11:50:31 2007 com_err has a very long history. From: To: Time: Wed Apr 11 11:51:09 2007 The afsauth stuff shouldn't matter to us, we're not checking that out are we? From: To: Time: Wed Apr 11 11:57:56 2007 one of the two copies in krb5/src is placed there by the build process From: To: Time: Wed Apr 11 13:01:12 2007 com_err was an attempt long long ago in a galaxy known as MIT to implement a common error handling library that could be used within executables that would permit each library linked to the executable to register a set of error tables that linked error numbers to error message text. The idea was that after all of the libraries registered their error tables, an application writer could simply call error_message() from the com_err library with any error code that was received and get back the appropriate error text regardless of which library the error originated in. Unfortunately as is the case with many great ideas in open source, com_err is just one of example of many good ideas that spread far and wide but forked incompatibly while doing so. There are several different implementations of com_err at the moment with slightly different interfaces all of which are implemented in libraries with different names. As you have noticed, in the pismere tree there are three implementations. All incompatible to one or more degree. One of the side effects of this is that when you have an application that relies on two libraries that both have their own com_err implementations, more often than not you have to avoid using com_err at all in order to avoid linkage problems. This has been the case with aklog.exe as one example. The AFS and Krb5 and Krb4 implementations are all slightly different and the differences cannot be resolved without breaking backward compatibility in one or more of the packages. As it turns out, OpenAFS took the step yesterday of renaming all of its com_err interfaces to permit krb5 and afs com_err implementations to be linked into the same executable at the expense of now being forced to call both afs_error_message() and error_message() when searching for error text. I suggest that you avoid the com_err mess with a 10ft pole if at all possible. From: To: Time: Wed Apr 11 13:36:22 2007 Jeff, at least on Unix it is possible to have a superset com_err that has a strict semantic superset. From: To: Time: Wed Apr 11 13:36:57 2007 if you know how to do it, please share it with jhutz and shadow From: To: Time: Wed Apr 11 13:50:24 2007 could someone verify that the currently-posted 3.2-beta1 MSI is correct now? From: To: Time: Wed Apr 11 14:34:43 2007 after Windows Update finishes on lxiv I will install it there to verify From: To: Time: Wed Apr 11 15:03:37 2007 the msi is correct From: To: Time: Wed Apr 11 15:09:29 2007 ok, thanks From: To: Time: Wed Apr 11 15:33:01 2007 must be some weird server-side caching going on. i keep getting the old one. From: To: Time: Wed Apr 11 16:29:03 2007 Question: the ccapi library can't spawn extra threads in the process that loads it, right? From: To: Time: Wed Apr 11 16:29:31 2007 (ie: we support platforms with no threads, right) From: To: Time: Wed Apr 11 16:30:10 2007 we support platforms without threads, or at least we haven't yet declared that thread support must be available, i think. From: To: Time: Wed Apr 11 16:30:47 2007 okay, then I think I can't implement the "cache collection changed" non-polling API as a callback. I'll have to have it block From: To: Time: Wed Apr 11 16:31:44 2007 is the interface a fixed thing, or can you change it? From: To: Time: Wed Apr 11 16:32:28 2007 fixed, but not for Leopard. I was just going to implement a version of it to test the callback portion of the locking code. But it looks like my first API idea is unimplementable From: To: Time: Wed Apr 11 16:33:16 2007 ie: the API is for krb5-1.7 so it's not like it's going out the door soon. But it can't be changed once it goes out From: To: Time: Wed Apr 11 16:33:26 2007 ok From: To: Time: Wed Apr 11 16:33:37 2007 so how about both a blocking and a non-blocking (polling) interface? From: To: Time: Wed Apr 11 16:33:57 2007 there is already a polling interface (cc_context_get_change_time) From: To: Time: Wed Apr 11 16:34:43 2007 am i misunderstanding something or is it trivial to build a callback interface given a threads implementation and a blocking interface? From: To: Time: Wed Apr 11 16:34:45 2007 The issue is that everyone who wants to call the non-polling interface is going to want to spawn a thread and get a callback when they get a "changed" message. I was trying to figure out if I could do that for them, but it looks like the answer is no From: To: Time: Wed Apr 11 16:35:49 2007 The issue is that the message comes from the IPC server so I am listening on a socket/mach port/windows thingie. That listen blocks. So either I need a thread to block on the socket *or* my API will block From: To: Time: Wed Apr 11 16:36:52 2007 I'm not sure how to write a callback interface that comes from a message on a socket From: To: Time: Wed Apr 11 16:37:05 2007 (without a thread to listen on the socket) From: To: Time: Wed Apr 11 16:39:19 2007 there might be IPC mechanism specific ways to do that, but I don't think all our IPC mechanisms have them From: To: Time: Wed Apr 11 16:39:38 2007 so you want to provide an interface which spawns a thread to block listening to a socket for the convenience of the application? From: To: Time: Wed Apr 11 16:39:50 2007 yes From: To: Time: Wed Apr 11 16:40:22 2007 a callback API is what the application wants because this API is specifically for event driven GUI applications From: To: Time: Wed Apr 11 16:42:12 2007 it isn't a huge burden on the application to make them spawn their own thread and block on it, but it's bad API design since it forces every application to write their own version of the callback interface they really wanted From: To: Time: Wed Apr 11 16:42:12 2007 maybe we can provide that API or not depending on the underlying OS thread support? From: To: Time: Wed Apr 11 16:42:46 2007 I was hoping to avoid writing the blocking one, but I'll need to provide it if there are no threads From: To: Time: Wed Apr 11 16:44:19 2007 can it be done without actually using a callback? what data is being sent to the client? is it just a signal that something changed? From: To: Time: Wed Apr 11 16:45:30 2007 if its just a signal, then perhaps a shared reference to a semaphore communicated across the IPC might work From: To: Time: Wed Apr 11 16:48:06 2007 The client and server have a IPC connection between them which is implemented via various IPC mechanisms on different platforms. I don't believe that I have a cross-platform way to wait for a message from the server (the message that something changed) that both does not block and also does not poll From: To: Time: Wed Apr 11 17:14:27 2007 i'm not too familiar with all the types of IPC... which ones allow for a callback type interface? From: To: Time: Wed Apr 11 17:16:31 2007 mach IPC doesn't From: To: Time: Wed Apr 11 17:16:42 2007 i don't think POSIX does either From: To: Time: Wed Apr 11 17:17:47 2007 well... technically SystemV / XSI not POSIX From: To: Time: Wed Apr 11 17:50:31 2007 If we use unix domain sockets we do get a way to have non-blocking stuff by getting an fd and asking the application to monitor that in their event loop. But that's ickiy. From: To: Time: Wed Apr 11 17:50:53 2007 So, posix is a system where you can do non-blocking without threads, but you don't want to From: To: Time: Wed Apr 11 17:51:35 2007 sysV semaphores etc can be polled in non-blocking ways i think From: To: Time: Wed Apr 11 17:53:05 2007 Yes, but why would you ever use sysv ipc? From: To: Time: Wed Apr 11 17:54:20 2007 shared memory segments can be useful for passing large amounts of data, right? From: To: Time: Wed Apr 11 17:55:00 2007 Yes, but isn't mmap often better? From: To: Time: Wed Apr 11 18:22:57 2007 how do you do get independent processes to use mmap to get a shared mapping on shared memory? From: To: Time: Wed Apr 11 18:24:45 2007 Ah. Yeah, shm is probably best for that From: To: Time: Wed Apr 11 19:59:57 2007 I think multi-threaded and single-threaded programs have different behavior in some areas, like signal handling, that might be messed up by spawning threads; a program should not be made multi-threaded without knowing it. (Otherwise, it would be a good solution to the "taking too long to look up all the KDC hostnames" problem, by calling getaddrinfo in multiple threads at once and using answers as they become available.) And on most UNIX platforms, we're not requiring that the thread library be loaded, so we may not be able to create threads anyways (without adding that new requirement). From: To: Time: Wed Apr 11 20:02:59 2007 Signals and threads are a combination I'm really not familiar enough with. :-( From: To: Time: Thu Apr 12 15:36:19 2007 svn rev 19431 belongs in ticket #5521, right? From: To: Time: Thu Apr 12 15:45:11 2007 Yes. Oops. From: To: Time: Thu Apr 12 15:52:42 2007 ~jaltman/Public/KFW/vista-mit2ms-netidmgr.png From: To: Time: Thu Apr 12 15:53:55 2007 This is Network Identity Manager running on Vista where the Windows logon credentials userone@WINDOWS.SECURE-ENDPOINTS.COM have been replaced by tequila@ANDREW.CMU.EDU credentials. From: To: Time: Thu Apr 12 15:54:29 2007 the head & shoulder silhouette doesn't work at the small resolutions such as the ones located to the left of the principal names From: To: Time: Thu Apr 12 15:54:56 2007 I know. We need additional icons but there was no funding available for them in this release. From: To: Time: Thu Apr 12 15:55:34 2007 They are to be replaced by the medium sized icons used in the toolbar From: To: Time: Thu Apr 12 15:57:01 2007 Just as important, the installer that put this build on Vista was produced by Kevin's scripts modified so that the tagged files are not deleted after running sed on them. From: To: Time: Thu Apr 12 15:58:59 2007 Of course I had to build a custom source tree to get the right version of the identity sources because not all of the pullups have taken place. However, I believe that after Kevin commits the changes for the bkw.pl and updates the relnotes.html file that the scripts are high enough quality for a beta release. From: To: Time: Thu Apr 12 16:00:18 2007 The new taskbar functionality is not working on Vista but that is not enough of a reason to hold back the release. From: To: Time: Thu Apr 12 16:22:22 2007 The reason I haven't checked in bkw.pl yet is that the nsis installer is installing the site-local files in addition to the site-local-tagged files. From: To: Time: Thu Apr 12 16:23:03 2007 that will probably have to be fixed in the nsis installer From: To: Time: Thu Apr 12 16:24:01 2007 otherwise, you will need to make significant changes to the build script From: To: Time: Thu Apr 12 16:24:17 2007 Or maybe in the temp area where it is run. The problem right now is that the area it packages is the area where it is running. It needs the site-local files but wants to package the site-local-tagged files. From: To: Time: Thu Apr 12 16:24:19 2007 right now the nsis installer includes all files in the directory From: To: Time: Thu Apr 12 16:24:46 2007 So can the install builder be told to package an area other than . ? From: To: Time: Thu Apr 12 16:24:54 2007 I certainly believe that the installers should be run from some place other than the staging area From: To: Time: Thu Apr 12 16:25:09 2007 yes, that is how they are designed to be run From: To: Time: Thu Apr 12 16:25:24 2007 I never run the installers from the staging area From: To: Time: Thu Apr 12 16:25:56 2007 I have to take my son to fencing now ... How about a saomple of your makensis command? From: To: Time: Thu Apr 12 16:26:13 2007 they are in site-local From: To: Time: Thu Apr 12 16:26:22 2007 site-local.nsi !define KFW_TARGETDIR c:\temp\kfw\kfw-3_2_0-beta1-fermi From: To: Time: Thu Apr 12 16:27:03 2007 and in site-local.wxi its TargetDir From: To: Time: Thu Apr 12 16:47:21 2007 Tom, I'm going to try something to get the taskbar buttons to work on Vista. There may be one more commit From: To: Time: Thu Apr 12 16:55:11 2007 ok From: To: Time: Thu Apr 12 16:55:32 2007 from earlier conversation it looks like Kevin isn't done with the build script either From: To: Time: Thu Apr 12 16:55:37 2007 nope From: To: Time: Thu Apr 12 16:56:01 2007 is it useful to you to have 5521 pulled up before he finishes? From: To: Time: Thu Apr 12 16:56:05 2007 no From: To: Time: Thu Apr 12 16:56:41 2007 I don't need the build script in the tree to produce the release. the script has to exist somewhere else in order to pull the sources out of the repository From: To: Time: Thu Apr 12 17:14:10 2007 it works From: To: Time: Thu Apr 12 17:21:42 2007 ticket 5526 From: To: Time: Thu Apr 12 17:28:58 2007 ouch. it's full of EOL changes From: To: Time: Thu Apr 12 17:29:04 2007 ugh From: To: Time: Thu Apr 12 17:29:26 2007 I've got to remember to never use the cygwin 'patch' command From: To: Time: Thu Apr 12 17:29:28 2007 i'll pull it up anyway but we should try to get that under control From: To: Time: Thu Apr 12 17:29:39 2007 I tracked it down. From: To: Time: Thu Apr 12 17:29:43 2007 its cygwin. From: To: Time: Thu Apr 12 17:30:07 2007 what other patch or diff command do you use? From: To: Time: Thu Apr 12 17:30:20 2007 If I generate and apply patches with the Tortoise SVN tools it works fine. From: To: Time: Thu Apr 12 17:31:00 2007 let me revert the changes and then apply them correctly From: To: Time: Thu Apr 12 17:31:38 2007 already pulled up From: To: Time: Thu Apr 12 17:31:41 2007 unless of course you already pulled them up From: To: Time: Fri Apr 13 17:19:00 2007 Aaahh. Windows Update hell. Since I started the reinstallation, I've lost track of how many times I've run Windows Update and had it find things to update -- the Windows Update software, if nothing else. And how many times I've had to tell it that no, I really really don't want automatic updates turned on. From: To: Time: Fri Apr 13 17:21:48 2007 Install XP, get a bunch of updates. Update Windows Update. Get some more updates. Run Windows Update again. Oh, do you want WGA installed? No? Okay... update installation failed! Run Windows Update again. Here's SP2, have fun. Ooh, more updates. Do you want WGA installed? Update Windows Update. More updates. From: To: Time: Fri Apr 13 17:22:01 2007 Oh, and the totally excessive amount of rebooting that has to be done in the process. From: To: Time: Fri Apr 13 17:22:31 2007 updating a powerbook from 10.4.0 to something modern took a few rounds... From: To: Time: Fri Apr 13 17:26:32 2007 Maybe it's not much better. But with Windows I keep getting the feeling, "Oh, it's a day ending in 'y', I probably need to install an update and reboot." From: To: Time: Fri Apr 13 17:39:55 2007 I can't really imagine installing XP at this point without SP2 slipstreamed media. From: To: Time: Fri Apr 13 17:43:39 2007 i have XP/SP2 but it's in the form of a Virtual PC install disk, so not sure if that helps you From: To: Time: Fri Apr 13 17:45:43 2007 Next time I do an install I should see if the install sw MIT has has been updated to incorporate sp2. From: To: Time: Fri Apr 13 17:46:06 2007 i thought there was a SP2 RIS image From: To: Time: Fri Apr 13 17:49:14 2007 Probably. I keep forgetting about RIS installation. I think I blocked it out along with the hassle of getting some domain admin to reset things all the time so my reinstalled machine could rejoin a domain. From: To: Time: Fri Apr 13 18:15:41 2007 Ah, and apparently "cancel" to some of the WGA prompts means "cancel the rest of the update process". If I don't want WGA, I have to refuse the EULA, select "don't offer this again", let the rest of the update process fail, and start Windows Update again, to get offered the other updates again. From: To: Time: Fri Apr 13 18:17:44 2007 I suppose I could take the alternative view that Microsoft 0wnz this (virtual) machine already, so screw it, let 'em install whatever they want... From: To: Time: Fri Apr 13 18:18:04 2007 But it's *my* (well, MIT's) computer, dammit. From: To: Time: Fri Apr 13 18:18:28 2007 what exactly is WGA? From: To: Time: Fri Apr 13 18:19:10 2007 WGA is Windows Guaranteed Authenticity or something like that. Its Microsoft's anti-piracy scheme From: To: Time: Fri Apr 13 18:19:23 2007 for the OS or other stuff too? From: To: Time: Fri Apr 13 18:19:29 2007 Windows Genuine Advantage. Microsoft spyware to make sure you're properly licensed. I've never been clear on what the benefit to *me* is supposed to be. From: To: Time: Fri Apr 13 18:19:47 2007 Vista has it built in. If you change your hardware too often (or move your VM to different disks) it triggers and virtually shuts the OS down From: To: Time: Fri Apr 13 18:20:11 2007 If you don't run WGA non-critical patches won't apply From: To: Time: Fri Apr 13 18:21:26 2007 looks like Boston will be flooded on Monday From: To: Time: Fri Apr 13 18:21:41 2007 glub glub From: To: Time: Fri Apr 13 18:22:25 2007 I think the critical patches are the only ones I take anyways. (And there's *still* too many of them.) From: To: Time: Fri Apr 13 18:23:27 2007 Has Sam taken off for tonight? His office light's still on. From: To: Time: Fri Apr 13 18:25:36 2007 Kevin, did you test running the script on a drive other than the one the build is taking place? From: To: Time: Fri Apr 13 18:40:45 2007 I wonder if UNC paths would work better From: To: Time: Fri Apr 13 19:06:09 2007 No, why? From: To: Time: Fri Apr 13 19:06:22 2007 I only have one drive on my PC. From: To: Time: Fri Apr 13 19:06:53 2007 I'm trying to build with the output directories mapped to AFS so that the build can be accessed by the Kerberos team From: To: Time: Fri Apr 13 19:07:14 2007 Sam wants to archive each build tree and the distribution files From: To: Time: Fri Apr 13 19:08:17 2007 I am using NET USE to map a drive to AFS space. You should be able to do the same with the Dfs space if you don't want to install an AFS client on your machine From: To: Time: Fri Apr 13 19:09:20 2007 I'm at home now and can't mount the shares. The MIT firewall blocks the necessary port. From: To: Time: Fri Apr 13 19:09:32 2007 which shares? From: To: Time: Fri Apr 13 19:09:48 2007 the MIT firewall doesn't block AFS From: To: Time: Fri Apr 13 19:10:14 2007 you can use the Cisco VPN client if you need to use CIFS From: To: Time: Fri Apr 13 19:10:17 2007 If you install the VPN software, you should be able to get past the firewall. From: To: Time: Fri Apr 13 19:23:00 2007 BTW, Thursday when I flattened the config structure in bkwconfig.xml, I added environment variables. I just committd the code to set/delete the variables according to the xml. You should be able to control all the variables NIM uses from the config file now. From: To: Time: Fri Apr 13 19:23:50 2007 My wireless connection is flakey and I would really rather not try accessing remote shares with it. From: To: Time: Fri Apr 13 19:30:13 2007 can't use UNC paths because cmd.exe doesn't support them. From: To: Time: Fri Apr 13 19:30:20 2007 powershell would From: To: Time: Fri Apr 13 20:30:01 2007 can't use "chdir" with alternate drive letters. From: To: Time: Fri Apr 13 20:30:23 2007 it changes the directory on the alternate drive, but doesn't change the current drive From: To: Time: Fri Apr 13 20:30:52 2007 I can run the script from afs but it must be run with the current drive on afs From: To: Time: Fri Apr 13 20:33:08 2007 tom, would you please pullup 5521, 5527, and 5528? thanks From: To: Time: Fri Apr 13 20:35:22 2007 you have confirmed that 5521 is complete? From: To: Time: Fri Apr 13 20:35:49 2007 no From: To: Time: Fri Apr 13 20:35:55 2007 forget 5521 From: To: Time: Fri Apr 13 20:36:02 2007 and 5527 From: To: Time: Fri Apr 13 20:36:26 2007 :( From: To: Time: Fri Apr 13 20:39:40 2007 chdir /d [path] will change drives From: To: Time: Fri Apr 13 20:40:19 2007 AAahhhrrgh! KILL KILL KILL!!! From: To: Time: Fri Apr 13 20:40:21 2007 Sorry. From: To: Time: Fri Apr 13 20:40:51 2007 in perl? From: To: Time: Fri Apr 13 20:41:01 2007 Oh, perl... hrm From: To: Time: Fri Apr 13 20:41:19 2007 The update I've been waiting for for the past hour or two to finish installing hasn't been doing anything, because there's a window *buried* behind the other windows asking me if I really want to install IE7. From: To: Time: Fri Apr 13 20:41:36 2007 you do not From: To: Time: Fri Apr 13 20:42:08 2007 Why not? From: To: Time: Fri Apr 13 20:42:37 2007 there are still a large number of sites and tools that are incompatible From: To: Time: Fri Apr 13 20:43:19 2007 I believe that IE7 is a way of forcing companies to update their web sites and tools so that they will be compatible with Vista From: To: Time: Fri Apr 13 20:43:34 2007 It's not like I intend to *use* it, except if I need to look up stuff from the windows development environment. But older IE should work okay for that too.. From: To: Time: Fri Apr 13 20:44:41 2007 Ooh, and this time, quitting the IE installation didn't blow out all the following updates. How wonderful. From: To: Time: Fri Apr 13 20:46:21 2007 (...close window, restart the OS, check for more updates...) From: To: Time: Fri Apr 13 20:47:25 2007 yep From: To: Time: Fri Apr 13 20:47:55 2007 Perldoc says If EXPR is omitted, changes to the directory specified by $ENV{HOME}. Can you put the drive in there? From: To: Time: Fri Apr 13 20:50:24 2007 I don't think that will make a difference. Putting the drive letter in the path is not the problem. the directory does get changed. its the current drive that does not. From: To: Time: Fri Apr 13 20:55:42 2007 Ah, finally! No high-priority updates to install. From: To: Time: Fri Apr 13 20:58:09 2007 i keep forgetting that it's 1.5.3 next not 1.5.2... From: To: Time: Fri Apr 13 21:01:39 2007 even the Win32 package doesn't help From: To: Time: Fri Apr 13 21:11:26 2007 I've deleted myself from info-kerberos. From: To: Time: Fri Apr 13 21:11:43 2007 And now, while installers are running, it's time to grab dinner.... From: To: Time: Fri Apr 13 21:12:31 2007 (I've moved on to the visual studio installer. Again. Should have enough disk space this time.) From: To: Time: Fri Apr 13 21:14:25 2007 when you get to the question of whether or not you want to register the visual studio environment variables. please say 'no' From: To: Time: Fri Apr 13 21:15:02 2007 does it cause headaches for reproducible build environments if you have the variables registered? From: To: Time: Fri Apr 13 21:15:42 2007 it makes things hard for multiple versions of visual studio on the same machine From: To: Time: Fri Apr 13 21:16:18 2007 when i last had visual studio installed, it created a bunch of start menu items to launch command windows with various environment variables set in them From: To: Time: Fri Apr 13 21:16:19 2007 it also prevents you from testing to make sure that you have a visual studio environment from executing the vsvars32.bat file or due to inheritence From: To: Time: Fri Apr 13 21:16:59 2007 for our environment we need a combination of both a visual studio environment and a SDK environment which is different from the SDK that ships with visual studio From: To: Time: Sat Apr 14 08:22:36 2007 kevin: why is the build script building the wix installer in x:\test\build\pismere\buildwix\kfw.msi and then copying it to x:\test\build\pismere\staging\install\wix\kfw.msi ? same question for x:\test\build\pismere\buildnsi\MITKerberosForWindows.exe being copied to x:\test\build\pismere\staging\install\nsis\MITKerberosForWindows.exe ? I believe that once the staging area is constructed it should be read-only. The installers once built should be moved to the output directory. There shouldn't be a reason for them to be put into the staging area. If signing is required they can be signed in the buildwix or buildnsi directories before being moved. From: To: Time: Sat Apr 14 08:31:52 2007 the way things are now, the kfw.msi and MITKerberosForWindows.exe files are being copied from the staging area into the x:\test\dist\mit\ziptemp\install\.... From: To: Time: Sat Apr 14 08:36:41 2007 as part of: X:\test\build\pismere\staging\inc\*.* copied to X:\test\dist\mit\ziptemp\inc\ X:\test\build\pismere\staging\install\nsis\*.* copied to X:\test\dist\mit\ziptemp\install\nsis\\ X:\test\build\pismere\staging\install\wix\*.* copied to X:\test\dist\mit\ziptemp\install\wix\\ Only for the files to then be pruned prior to constructing the zip file Info -- Processing prunes in X:\test\dist\mit\ziptemp Info -- Looking for filenames containing *.exe Info -- Pruning ./install/nsis/MITKerberosForWindows.exe Info -- Looking for filenames containing *.msi Info -- Pruning ./install/wix/kfw.msi Info -- Looking for filenames containing *.dll Info -- Looking for filenames containing *.obj Info -- Looking for filenames containing *.wixobj In fact, if you treat the staging area as read-only, you won't have to do any pruning of the x:\test\dist\mit\ziptemp\install\... area at all. From: To: Time: Sat Apr 14 08:38:00 2007 When I implemented the buildxxx areas, the smallest change was to put the files into the staging area. Then they are moved out of staging into (and renamed) using the existing mechanism. Also, all the signing is done in . Your request would require changing when is created and another signing step and copy step, since MITKerberosForWindows.exe must be renamed. The way it is works. Well, what about this? Change the last copy step's from are from $wd/staging to $wd. Change the paths of everything except the installers to include staging. Change the paths of the installers to be the /buildxxx areas. Should be a one line code change and then munge the paths. From: To: Time: Sat Apr 14 08:38:29 2007 has already been created. From: To: Time: Sat Apr 14 08:38:44 2007 you are using as the root for the construction of all of your ziptemp areas From: To: Time: Sat Apr 14 08:39:58 2007 I have to make breakfast now. Will make the change I suggested later, unless you disprove it. From: To: Time: Sat Apr 14 08:40:41 2007 there are two signing steps. From: To: Time: Sat Apr 14 08:44:06 2007 you copy the binaries from the staging area to out\ziptemp. you sign the binaries. you build the zip file containing the binaries into the output directory you build the wix installer you copy kfw.msi from the buildwix directory to the output directory with the correct name you build the nsis installer you copy MITKerberosForWindows.exe from the buildnsi directory to the output directory with the correct name you sign the msi and exe installers in the output directory you cleanup the ziptemp, buildkfw, and buildnsi directories From: To: Time: Sat Apr 14 08:54:59 2007 btw, its the weekend. you shouldn't be working From: To: Time: Sat Apr 14 09:04:06 2007 I'm concerned about performance. If I have to run these scripts against a network drive so that all of the paths in the symbol files match the build tree location, then the number of file copies and find operations should be minimized. read operations are cheap, they come from the local cache. directory search and write operations are expensive. From: To: Time: Sat Apr 14 09:07:43 2007 overall, more of your time is going to be spent running these scripts than writing them. therefore, it is to your benefit as well that the scripts perform fewer copies because they will take less of your time later on. From: To: Time: Sat Apr 14 10:02:05 2007 if the staging area is read-only, the ziptemp directories shouldn't be needed at all From: To: Time: Sat Apr 14 10:02:16 2007 that's more copies that can go away From: To: Time: Sat Apr 14 10:04:50 2007 And a 4 day weekend for me at that. From: To: Time: Sat Apr 14 10:07:30 2007 (1) construct staging area from build tree (2) sign binaries (if required) (3) build zip files directly from staging area writing them to the output directory (4) build wix installer in the buildwix directory (5) sign wix installer in the buildwix directory (if necessary) (6) move/rename wix installer to the output directory (7) build nsis installer in the buildnsi directory (8) sign nsis installer in the buildnsi directory (if required) (9) move/rename nsis installer to the output directory (10) cleanup buildwix and buildnsi directories (11) copy documentation files from staging area to output directory (4) sign kfw.msi From: To: Time: Sat Apr 14 10:08:03 2007 > 4 day weekend for me at that. < then you should sign off the conference room and review the logs on wednesday From: To: Time: Sat Apr 14 10:10:00 2007 But this is fun. From: To: Time: Sat Apr 14 10:10:09 2007 ~jaltman/Public/KFW/test contains a build tree that was produced by running the latest scripts located in ~jaltman/Public/KFW/bkw with the command build_afs.cmd From: To: Time: Sat Apr 14 10:10:16 2007 "build_afs.cmd test" From: To: Time: Sat Apr 14 10:10:26 2007 this is not fun. this is work. From: To: Time: Sat Apr 14 10:12:22 2007 I am working for many reasons. one I work for myself. second, its too cold outside to play volleyball. third, Sara just got home from the hospital from a 27 hour shift and will be sleeping all day. four, this is better than housework. From: To: Time: Sat Apr 14 12:52:09 2007 I'm not objecting to any specific change. I strongly advise that we keep in mind though that we're in the end-game for this release. Correctness of output is more important than ideal design at this point. I'm not saying we should introduce hacks, but if we find better ways of doing things we should consider whether they actually are release blockers or should be thought of as bugs/features for KFW 3.3. From: To: Time: Sat Apr 14 12:54:15 2007 Sam, I agree. From: To: Time: Sat Apr 14 12:56:48 2007 Feel free to look at the build that is sitting in the directory I specified earlier. Its missing a couple of required pullups. It doesn't have the current build scripts in it, it does not have the vertical scrollbars on the realm combo box in the obtain new credentials and change password dialogs, and it is missing version information on a number of files. From: To: Time: Sat Apr 14 12:57:03 2007 and manifest data on kpasswd.exe From: To: Time: Sat Apr 14 12:57:25 2007 Other than that the installers that are there should be tested. From: To: Time: Sat Apr 14 12:57:34 2007 OK, will go do that. From: To: Time: Sat Apr 14 13:00:34 2007 The reason I am concerned about the build time is that over the public internet it is taking close to ten hours to complete the build in AFS. If two rounds of copies per pass times two passes of the script can be avoided that will save a lot of time. From: To: Time: Sat Apr 14 13:01:02 2007 Still, in the short term, I can perform test runs locally and then perform the final run in AFS From: To: Time: Sat Apr 14 13:21:36 2007 The installers are not picking up the beta flag. That is because BUILD_OFFICIAL is hard coded. I guess we will just have to live with it From: To: Time: Sat Apr 14 13:26:53 2007 What does the beta flag do. I tend to agree that living with it is the right answer. My question is motivated by a desire to figure out whether we want to get rid of the beta flag long term. Jeff, why can't you build locally and tar up the results into AFS? From: To: Time: Sat Apr 14 13:28:34 2007 BTW, as an explanation of why we're hard coding build_official you said verbally in the conversation that we had last week that it should be set even for betas From: To: Time: Sat Apr 14 13:45:41 2007 The Beta flag is used to alter the product version strings for the installers so they say "KFW 3.2.0 Beta 2" From: To: Time: Sat Apr 14 13:46:14 2007 > you said... From: To: Time: Sat Apr 14 13:46:27 2007 yes I did, there may be something else wrong then From: To: Time: Sat Apr 14 13:46:52 2007 I haven't checked the output that is being put into the installer include files. Perhaps the problem is there. From: To: Time: Sat Apr 14 13:47:42 2007 The reason for building in AFS is so that the paths in the symbols file matches the actually location of the build when you are debugging From: To: Time: Sat Apr 14 13:54:34 2007 Ah. Unix has the same feature/misfeature. From: To: Time: Sat Apr 14 13:55:25 2007 I'm going to try installing beta 1 from the msi on the website and the upgrading using the nsis installer from your build as a first test; will go forward from there. From: To: Time: Sat Apr 14 13:55:55 2007 be aware that swapping between nsis and msi installers is not recommended From: To: Time: Sat Apr 14 13:57:36 2007 O, is that not supposed to work? I thought there was logic to deal with that. From: To: Time: Sat Apr 14 13:57:49 2007 Which is why I was going to try it. From: To: Time: Sat Apr 14 13:58:25 2007 If it's not actually supported then I will just try the upgrade within one installer type From: To: Time: Sat Apr 14 13:58:34 2007 there is logic and it will upgrade the binaries. However, the MSI installer data is not completely removed. Attempting to go back to MSI will go badly From: To: Time: Sat Apr 14 13:59:29 2007 Ah. From: To: Time: Sat Apr 14 13:59:32 2007 the old MSI installer configuration data will have to be removed with the msizap.exe tool from the SDK From: To: Time: Sat Apr 14 14:21:52 2007 It's not just kpasswd that is missing version information. IT seems to be everything from the clients directory of the krb5 tree--copy ticket and delete ticket as well. Also, why is it that the files from the krb5 tree have a build number of 7 while the files from the kfw tree have a build number of 7002? From: To: Time: Sat Apr 14 14:22:32 2007 the commit message said that kpasswd was missing manifest data From: To: Time: Sat Apr 14 14:22:59 2007 it also said that resource data was missing from a large number of specified files From: To: Time: Sat Apr 14 14:23:09 2007 OK. From: To: Time: Sat Apr 14 14:23:44 2007 we only started using build numbers for the krb5 files in kfw 3.0. that is why the numbers are smaller From: To: Time: Sat Apr 14 14:24:16 2007 we are incrementing them for each public release (beta or final) From: To: Time: Sat Apr 14 14:26:17 2007 Where does that build number come from? From: To: Time: Sat Apr 14 14:27:04 2007 the pismere number comes from pismere/scripts/build/site/buildnum.inc (or something like that) and the krb5 number from krb5/src/windows/winlevel.h From: To: Time: Sat Apr 14 14:32:19 2007 Thanks. From: To: Time: Sun Apr 15 02:02:33 2007 MIt Kerberos Development Team From: To: Time: Sun Apr 15 02:02:33 2007 raeburn has set the topic to: Kerberos From: To: Time: Tue Apr 17 16:09:33 2007 interesting. Russ's login failure yesterday produced some Mason errors. From: To: Time: Tue Apr 17 16:10:29 2007 what do we use Mason for? From: To: Time: Tue Apr 17 16:12:20 2007 RT uses Mason From: To: Time: Tue Apr 17 16:12:47 2007 some username and password fields got set to the empty string, which made postgres unhappy From: To: Time: Tue Apr 17 16:35:06 2007 4ooku2 From: To: Time: Tue Apr 17 16:35:11 2007 mix From: To: Time: Tue Apr 17 16:42:13 2007 hehe I bet someone is changing their password right now :-) From: To: Time: Tue Apr 17 16:43:07 2007 stupid inconsistent screensaver... :-) From: To: Time: Tue Apr 17 16:43:47 2007 I sent one of my passwords to Nick Lane-Smith that way From: To: Time: Tue Apr 17 17:42:10 2007 Tom, when you get a chance, would you pullup my commits from Friday through today? From: To: Time: Tue Apr 17 17:43:07 2007 tickets 5528, 5529, 5530, 5532, 5533 From: To: Time: Tue Apr 17 17:43:38 2007 those address all of the issues that have been reported against kfw 3.2 beta 1 From: To: Time: Tue Apr 17 17:59:01 2007 I should have said "since beta 1" From: To: Time: Tue Apr 17 18:11:15 2007 specifically exclude the build system changes for now? From: To: Time: Tue Apr 17 18:12:01 2007 you can pull them up. I don't know that Kevin won't have additional changes to make. From: To: Time: Tue Apr 17 18:13:04 2007 what I am most interested in is being able to run the build scripts against krb5-1-6 to produce builds for testing. From: To: Time: Tue Apr 17 18:14:04 2007 5529 touches a bunch of makefiles and 1.6.1 is already in beta, so i don't know if i should pull that up just yet. i'll look at the diffs though From: To: Time: Tue Apr 17 18:16:01 2007 all the changes should be ##WIN32## From: To: Time: Tue Apr 17 18:50:37 2007 Sam remarked in 5530 that it was not for kfw-3.2... From: To: Time: Tue Apr 17 18:51:50 2007 I think Sam meant that he wasn't requiring that it be fixed for 3.2 From: To: Time: Tue Apr 17 18:54:40 2007 ok From: To: Time: Tue Apr 17 19:18:54 2007 thanks From: To: Time: Tue Apr 17 20:43:41 2007 ok, now why oh why is _isLimited getting reset somewheres? From: To: Time: Tue Apr 17 20:46:24 2007 > I think Sam meant that he wasn't requiring that it be fixed for 3.2 Correct From: To: Time: Tue Apr 17 20:57:43 2007 oh! maybe DBIx::SearchBuilder::CleanSlate kills show_rows and it used to not do so From: To: Time: Tue Apr 17 21:15:32 2007 search row count limits should work now From: To: Time: Tue Apr 17 21:16:01 2007 Got wwdc hotel tickets. From: To: Time: Tue Apr 17 21:17:35 2007 Yep, I have only 25 "25 highest priority tickets requested" now. From: To: Time: Tue Apr 17 21:17:55 2007 some people seem to not believe in interface stability... From: To: Time: Tue Apr 17 21:18:44 2007 Yeah, CPAN is really turning me off perl these days From: To: Time: Tue Apr 17 21:21:01 2007 It looks like the 802.11a cards won't work with the new mac laptops. Good thing IETF seems to have working 802.11g these days. From: To: Time: Tue Apr 17 21:21:20 2007 Good thing the new laptops do 11a:-) From: To: Time: Tue Apr 17 21:21:23 2007 i thought some of the MacBook Pro had 11a From: To: Time: Tue Apr 17 21:21:29 2007 Do they? I hadn't noticed. From: To: Time: Tue Apr 17 21:21:41 2007 well i haven't confirmed or anything From: To: Time: Tue Apr 17 21:22:07 2007 May 29-Jun 1 From: To: Time: Tue Apr 17 21:22:52 2007 Apr 30 my flight leaves at 6 AM; I get back around 10 or 11 that Thursday From: To: Time: Tue Apr 17 21:25:30 2007 granted, this is DBIx::SearchBuilder, so maybe Jesse is used to controlling the horizontal and the vertical From: To: Time: Tue Apr 17 21:25:50 2007 All the programs I'm pulling up are pretty good about hiding info on which 802.11 protocols are available.... From: To: Time: Tue Apr 17 21:26:33 2007 "IOModel" = "Wireless Network Adapter (802.11 a/b/g/n)" From: To: Time: Tue Apr 17 21:27:30 2007 If I pull up a "create computer-to-computer network" option, I get a selection of channels, 1 through 11. From: To: Time: Tue Apr 17 21:27:34 2007 Where's that, Tom? From: To: Time: Tue Apr 17 21:27:42 2007 ioreg -w0 -l From: To: Time: Tue Apr 17 21:27:48 2007 it will spew LOTS From: To: Time: Tue Apr 17 21:27:49 2007 AdHoc is only 802.11b From: To: Time: Tue Apr 17 21:28:19 2007 to activate 802.11a on laptops shipped before December requires a firmware upgrade From: To: Time: Tue Apr 17 21:28:30 2007 O, mix From: To: Time: Tue Apr 17 21:28:38 2007 i thought that was 802.11n From: To: Time: Tue Apr 17 21:28:53 2007 802.11a and 802.11n use the same frequency. From: To: Time: Tue Apr 17 21:29:07 2007 802.11a mode is a backward compatible mode From: To: Time: Tue Apr 17 21:29:42 2007 Ah, okay, there it is. So we have n support, at least in hardware? Nice. From: To: Time: Tue Apr 17 21:30:14 2007 Is 802.11n finalized? From: To: Time: Tue Apr 17 21:30:28 2007 not yet From: To: Time: Tue Apr 17 21:30:32 2007 Not last I knew, but I have not been tracking From: To: Time: Tue Apr 17 21:31:02 2007 So firmware updates to enable that would make sense. Keeping 802.11a disabled would be silly. From: To: Time: Tue Apr 17 21:36:50 2007 Ah. According to http://www.apple.com/wireless/80211/ the new airport extreme base station ships with software for enabling 802.11n in the laptop. From: To: Time: Tue Apr 17 21:37:15 2007 I have the airport extreme From: To: Time: Tue Apr 17 21:37:27 2007 I'm using it in 802.11a mode From: To: Time: Tue Apr 17 21:38:28 2007 Tom, I'm sorry, but I'm going to have one more commit. From: To: Time: Tue Apr 17 21:38:42 2007 Sam, what are we waiting for regarding Beta2? From: To: Time: Tue Apr 17 21:39:03 2007 Do you plan to use the build scripts or not? From: To: Time: Tue Apr 17 21:39:14 2007 I will build the way I built on Friday? From: To: Time: Tue Apr 17 21:39:17 2007 Either way, I don't know of anything we are waiting for on the MIT side From: To: Time: Tue Apr 17 21:39:21 2007 no question mark From: To: Time: Tue Apr 17 21:39:42 2007 I'd certainly prefer you to build the way you built on Friday. From: To: Time: Tue Apr 17 21:40:06 2007 I don't think Kevin has updated the build docs From: To: Time: Tue Apr 17 21:41:14 2007 In the release notes? From: To: Time: Tue Apr 17 21:41:25 2007 yes From: To: Time: Tue Apr 17 21:41:31 2007 Or in the src diretory? From: To: Time: Tue Apr 17 21:41:45 2007 pismere/doc/kerberos/relnotes.html From: To: Time: Tue Apr 17 21:43:38 2007 OK. As a stop gap I think pasting the section on bkw.pl from /mit/kpkoch/Public/release_notes.html into the current release notes would be enough to allow you to get beta2 building tonight if you desire From: To: Time: Tue Apr 17 21:44:02 2007 Note that you only want to graph the single paragraph as I think you are aware it iss an old relnotes files From: To: Time: Tue Apr 17 21:44:16 2007 thanks for the reminder From: To: Time: Tue Apr 17 21:55:54 2007 Tom, could you pull-up 5534, the src/windows/build tickets, update the patchlevel.h and winlevel.h files and tag beta2? From: To: Time: Tue Apr 17 21:56:15 2007 when you have time From: To: Time: Tue Apr 17 21:56:27 2007 (as you have obviously left for the night) From: To: Time: Tue Apr 17 22:14:28 2007 um, we are not issuing a beta tomorrow unless I solve a serious problem. From: To: Time: Tue Apr 17 22:14:51 2007 an invalid krb5.ini file will cause a blue screen From: To: Time: Tue Apr 17 22:14:59 2007 on logon From: To: Time: Tue Apr 17 22:17:11 2007 I have the change to read the config after the repository step ready to go. If there are more updates, do we want to include that? From: To: Time: Tue Apr 17 22:17:42 2007 none of your changes since last Tuesday have been pulled up yet From: To: Time: Tue Apr 17 22:17:55 2007 Just tried installing openafs-1.5.whatever and kfw3.2b1. First impression: The display of "currently have no credentials. Click here to obtain new credentia" looks kind of clunky. Clearly there's supposed to be additional text at the right, maybe on the left too. No scroll bar. (Theres a place for one, just no slider to grab.) From: To: Time: Tue Apr 17 22:17:57 2007 Also, is it sufficient to set environment variables from the config (as they are now), or must they be passed to build.pl? From: To: Time: Tue Apr 17 22:18:05 2007 (First impression of NIM that is.) From: To: Time: Tue Apr 17 22:18:19 2007 And when I moved the mouse over "here", the rest of the text disappeared. From: To: Time: Tue Apr 17 22:18:37 2007 Ken, that code has been fixed. From: To: Time: Tue Apr 17 22:18:47 2007 Okay. From: To: Time: Tue Apr 17 22:18:49 2007 please test the build that was posted here on Friday From: To: Time: Tue Apr 17 22:19:55 2007 ~jaltman/Public/KFW/test/dist/mit From: To: Time: Tue Apr 17 22:20:04 2007 Ah, okay. Will do. From: To: Time: Tue Apr 17 22:20:22 2007 that doesn't have all of the changes that were pulled up tonight but it has that fix From: To: Time: Tue Apr 17 22:22:25 2007 kevin, if you put your script somewhere I will try testing it but first I have to figure out what is wrong with krb5.ini From: To: Time: Tue Apr 17 22:34:17 2007 That's behaving better... From: To: Time: Tue Apr 17 22:34:57 2007 When I update th elist of afs cells I want tokens for, is that supposed to apply immediately, or next time I get new credentials? It appears to be the latter. From: To: Time: Tue Apr 17 22:38:53 2007 if you modify the list as part of the obtain new credentials dialog, it applies now. if you modify the list in the Identity configuration, it applies the next time you obtain credentials. From: To: Time: Tue Apr 17 22:40:02 2007 Is it the case that I can't install the SDK without installing WGA? From: To: Time: Tue Apr 17 22:40:20 2007 don't know From: To: Time: Tue Apr 17 22:40:31 2007 it wouldn't surprise me From: To: Time: Tue Apr 17 22:49:01 2007 ok, its not kfwlogon so we can issue a beta tomorrow. the problem must be in afslogon From: To: Time: Tue Apr 17 22:51:09 2007 I wonder if the problem is in the Leash library From: To: Time: Tue Apr 17 22:56:41 2007 The Leash library looks ok From: To: Time: Tue Apr 17 23:03:35 2007 How much space would I need to build kfw (including source, object, executables, installers)? Does it need to be local or can it work in AFS? From: To: Time: Tue Apr 17 23:04:03 2007 you can build in afs provided that you map a drive letter and run the build scripts from AFS From: To: Time: Tue Apr 17 23:04:15 2007 perl doesn't handle drive letter changes well From: To: Time: Tue Apr 17 23:04:38 2007 ok, the problem does occur with kfwlogon.dll if the damage is in the [libdefaults] section From: To: Time: Tue Apr 17 23:06:09 2007 if the problem is elsewhere in the profile, the crash does not occur From: To: Time: Tue Apr 17 23:06:52 2007 So if I set up a build tree in /mit/raeburn/work/kfw and pushd to \\afs\athena.mit.edu\user\etc and do all the work there I should be okay. Good. I'm still going through the "setting up the build environment" steps, and approaching 1G left with more to install. And that's before I go hunting for a win32 emacs install. :-) From: To: Time: Tue Apr 17 23:07:28 2007 you can't use UNC paths with cmd.exe which is required for the build. you must map a drive letter From: To: Time: Tue Apr 17 23:08:45 2007 I thought pushd would map one automatically? It appeared to map z: when I used pushd to get the new kfw installer from your directory. From: To: Time: Tue Apr 17 23:09:03 2007 hmm From: To: Time: Tue Apr 17 23:09:07 2007 didn't know that From: To: Time: Tue Apr 17 23:09:28 2007 I use a shell that is UNC aware most of the time From: To: Time: Tue Apr 17 23:09:59 2007 Maybe i'm wrong. Maybe it's only sometimes. I do vaguely recall seeing AFS directories without an obvious drive letter mapping. But it's been a while since I played with Windows development. From: To: Time: Tue Apr 17 23:10:15 2007 you can use UNC paths in Explorer From: To: Time: Tue Apr 17 23:10:22 2007 and in PowerShell From: To: Time: Tue Apr 17 23:20:58 2007 ok, now I'm really confused. I removed both network providers and my XP system is still crashing on Boot with a bad krb5.ini file. What else is reading it? From: To: Time: Tue Apr 17 23:29:18 2007 Boot in safe mode and run unlocker on it? From: To: Time: Tue Apr 17 23:29:43 2007 it crashes in safe mode From: To: Time: Tue Apr 17 23:29:53 2007 it crashes before the logon prompt is displayed From: To: Time: Tue Apr 17 23:30:07 2007 I'm setting up a kernel debugger to the VM From: To: Time: Tue Apr 17 23:54:28 2007 Kevin, if you have not already committed please consider whether adding the fetch config from repository to kfw 3.2 is desirable At this point we're working on stability rather than new features. If it's needed then commit, else I'd recommend committing to a user branch. ->bed From: To: Time: Tue Apr 17 23:58:54 2007 It is committed. I thought we agreed that your suggestion (using config info from the repository) was the only way to ensure building the right thing the right way? From: To: Time: Wed Apr 18 00:12:44 2007 For the Wix download, should I be getting this "votive" package as well as (instead of?) wix-2.###-binaries? From: To: Time: Wed Apr 18 00:13:24 2007 you do not need votive From: To: Time: Wed Apr 18 00:14:30 2007 Okay. So I just need to unzip the binaries and add the directory to PATH? Does it really call its programs "light" and "dark" and "candle" etc? Weird. (Wix, wicks, candles, yeah....) From: To: Time: Wed Apr 18 00:14:38 2007 yes From: To: Time: Wed Apr 18 00:15:12 2007 I'm going to bed. It looks like there is a crash within krb5_32.dll when the first line in the profile after [libdefaults] is garbage. From: To: Time: Wed Apr 18 00:16:06 2007 Ken, I'll be here for 5 more min if you have any config /env questions. From: To: Time: Wed Apr 18 00:18:15 2007 Thanks. I probably won't, though, I'm going to head home soon and grab some dinner. It's a bit annoying to use vmware over ssh over broadband to MIT, so I'll probably put the rest off until tomorrow. From: To: Time: Wed Apr 18 00:18:23 2007 Er, well, later today. :) From: To: Time: Wed Apr 18 01:13:07 2007 Hm. "The network path \\WIN.MIT.EDU\dfs could not be found." Okay, definitely time to go home... From: To: Time: Wed Apr 18 07:26:27 2007 Interesting. I wonder if the crash is windows specific. On something reasonably close to 1.6 I get a correct error from kinit when my krb5.conf is all screwed up. From: To: Time: Wed Apr 18 09:24:28 2007 The crash is taking place in krb5_free_config_files which means that somewhere a null context is being passed into krb5_free_context. From: To: Time: Wed Apr 18 09:24:40 2007 this is a windows specific error and it might not be in kfw From: To: Time: Wed Apr 18 09:25:43 2007 Is there a reason we don't perform even basic non-NULL parameter checking in our free functions? From: To: Time: Wed Apr 18 09:26:34 2007 granted passing null is wrong but I don't think it should cause a machine to trap From: To: Time: Wed Apr 18 11:31:28 2007 No, adding such checks is reasonable Although getting them pulled up to 1.6 before the release probably is not. From: To: Time: Wed Apr 18 11:31:51 2007 Obviously if there is a crash bug that needs to get pulled up that's fine. But checks can wait From: To: Time: Wed Apr 18 11:32:17 2007 Tom may force a 1.6.1 beta if you have to change the library, but that's OK From: To: Time: Wed Apr 18 11:36:03 2007 Um. CITI is located three blocks from charming and sophisticated downtown Ann Arbor, Michigan which boasts many fine restaurants and shops in an urban, caffeinated setting. From: To: Time: Wed Apr 18 11:36:38 2007 I read recently that Ann Arbor has the highest density of coffee shops. From: To: Time: Wed Apr 18 11:37:18 2007 The article was voicing a concern that the number of coffee shops was being reduced due to conversions to national bank store fronts From: To: Time: Wed Apr 18 11:38:28 2007 And another choice quote: The Embassy Hotel about a half mile from CITI is not an Embassy Suites hotel. Probably you don't want to stay there. From: To: Time: Wed Apr 18 11:39:52 2007 No changes to kfw are required. The bug is in the AFS Integrated Logon library. It would be nice to have a NULL check added to krb5_free_context but it is not required for KFW 3.2 in my opinion From: To: Time: Wed Apr 18 11:41:05 2007 Obviously will an invalid krb5 profile, integrated logon for kfw doesn't work. From: To: Time: Wed Apr 18 11:41:10 2007 s/will/with From: To: Time: Wed Apr 18 11:45:56 2007 I need to test the latest integrated logon code on Win2000 just to be sure. From: To: Time: Wed Apr 18 16:26:42 2007 windows 2000 testing successful From: To: Time: Wed Apr 18 18:24:08 2007 the order that e-mail messages arrive as a result of pull-ups is quite intriguing From: To: Time: Wed Apr 18 18:24:27 2007 RT sets "Precedence: bulk" From: To: Time: Wed Apr 18 18:24:44 2007 e-mail isn't guaranteed to arrive in-order anyway, but bulk mail even less so From: To: Time: Wed Apr 18 18:25:54 2007 the nico-larry show has begun. From: To: Time: Wed Apr 18 18:26:05 2007 or has it merely resumed? From: To: Time: Wed Apr 18 18:26:34 2007 they are appearing live at the Sands at 11 with a guest appearance by Martin Rex From: To: Time: Wed Apr 18 18:26:42 2007 :-) From: To: Time: Wed Apr 18 18:27:15 2007 is that everything? From: To: Time: Wed Apr 18 18:28:30 2007 that should be it. there are no non-buildlevel src/windows diffs between trunk and krb5-1-6 From: To: Time: Wed Apr 18 18:29:25 2007 thanks. Sara just got home and we are going to get some food. Lets see if I can get the build started before she is ready to leave. If not, I will do it when we get back. From: To: Time: Wed Apr 18 19:18:04 2007 argh From: To: Time: Wed Apr 18 19:25:28 2007 hate mail system From: To: Time: Wed Apr 18 20:07:58 2007 test build underway From: To: Time: Wed Apr 18 20:48:48 2007 So, I'm getting told \\WIN.MIT.EDU\dfs doesn't exist when I try to map it, but it takes 15-20 seconds to come up with that error. I've changed the firewall settings on this virtual machine as described in Kevin's notes (enable file sharing, scope 18.0.0.0/255.0.0.0). The virtual machine is behind a VMware NAT, but I think that should allow return traffic on TCP and UDP; AFS seems to work okay so far. Any other suggestions? From: To: Time: Wed Apr 18 20:50:26 2007 the VMWare NAT should not be the problem. From: To: Time: Wed Apr 18 20:50:30 2007 Are you getting net 18 addresses? I'd look at tcpdump. dfs seems to have a complicated protocol exchange From: To: Time: Wed Apr 18 20:53:51 2007 No, the dhcp server in the NAT isn't going to allocate net-18 addresses. Looks like it's giving me 192.168.42.130. From: To: Time: Wed Apr 18 20:55:08 2007 No, I mean is your global address net 18 From: To: Time: Wed Apr 18 20:55:35 2007 Oh. Yes, it's my desktop linux box. From: To: Time: Wed Apr 18 20:55:37 2007 The mit dcs are stupidly firewalled. You could always install the mit vpn client on your vm for extra special fun From: To: Time: Wed Apr 18 21:01:39 2007 Ah, well, tcpdump shows it was no timeout. Some NBT broadcast traffic, but also TCP traffic to m24dc1 and w92dc1 (http ports?) and m92dc2 (microsoft-ds port). I didn't enable capturing enough of the packets to see what's up; trying again. From: To: Time: Wed Apr 18 21:07:34 2007 And once more, filtering out the afs traffic... The traffic on the "http" port does *not* appear to be using the HTTP protocol. From: To: Time: Wed Apr 18 21:12:23 2007 I was serious that the vpn will probably solve your problems From: To: Time: Wed Apr 18 21:12:38 2007 Oh, but if I'm reading the flags right, the exchange is SYN->RST, over and over. Are the bytes it's showing me for TCP traffic going to include the TCP headers themselves, or just payload? It's showing 48 bytes send, 40 returned. (Normally SYN/RST would be a simple connection-refused, but I seem to recall MS does some funky things to speed up short exchanges, not sure if that would include carrying data with the SYN packet.) From: To: Time: Wed Apr 18 21:13:54 2007 Oh, it is TCP headers... From: To: Time: Wed Apr 18 21:14:51 2007 Okay. Will try that. From: To: Time: Wed Apr 18 21:23:10 2007 Weird. At this point, W: through Z: have all been mapped to \\afs\athena.mit.edu. I've been using "pushd \\afs\athena.mit.edu\blah" to get to stuff. From: To: Time: Wed Apr 18 21:49:20 2007 With the VPN up, \\WIN.MIT.EDU\dfs seems to exist. From: To: Time: Wed Apr 18 22:14:22 2007 Looking at lore-kfw-chronicle... is bkwconfig.xml a file I'm supposed to create, or a file that I'll find in one of the trees in the steps following the one where I'm told to set certain things in the file? From: To: Time: Wed Apr 18 22:15:05 2007 you take the one that is provided in the tree and modify it to meet your requirements. All configuration options are now specified in that config file From: To: Time: Wed Apr 18 22:15:37 2007 Okay. Check out first, and then go back to that step.... From: To: Time: Wed Apr 18 22:16:52 2007 you want to take the build scripts and then use them to do everything else for you From: To: Time: Wed Apr 18 22:23:43 2007 Should plink.exe have been renamed to ssh.exe? Or is "svn ... svn+ssh://..." going to look for "plink"? From: To: Time: Wed Apr 18 22:24:06 2007 you have to configure subversion to look for plink From: To: Time: Wed Apr 18 22:24:46 2007 which subversion are you using? From: To: Time: Wed Apr 18 22:24:54 2007 you do not want to use Cygwin From: To: Time: Wed Apr 18 22:25:29 2007 Ah, I've got the path order wrong then. From: To: Time: Wed Apr 18 22:26:05 2007 you have to configure Subversion, its \documents and settings\\Application Data\Subversion\config From: To: Time: Wed Apr 18 22:33:24 2007 Ah. Found the file format via google. "svn ls" hung, but running "plink raeburn@svn.mit.edu svnserve -t" directly showed me plink needed to confirm the host key (which apparently doesn't work when running under svn), and now svn ls works. From: To: Time: Wed Apr 18 22:33:56 2007 k From: To: Time: Wed Apr 18 22:34:48 2007 So can I just check out trunk/src/windows/build, update the config file, and run the script there? Or do I need to check out more to support running the script? From: To: Time: Wed Apr 18 22:35:03 2007 that's all you should need From: To: Time: Wed Apr 18 22:35:21 2007 the requirement is that you run the script from the drive letter you are using for the build From: To: Time: Wed Apr 18 22:35:50 2007 I hope 1G is enough for a build... From: To: Time: Wed Apr 18 22:35:57 2007 it is From: To: Time: Wed Apr 18 22:36:18 2007 I think it needs 300MB From: To: Time: Wed Apr 18 22:39:09 2007 Any particular SDK build environment I should use? Some of the directions seemed to suggest getting a build environment window, and I've got w2k, w server 2003, and xp options (and 32/64). From: To: Time: Wed Apr 18 22:39:39 2007 Oh, just noticed the SVN_SSH note I missed before. I used the config file instead, oh well. From: To: Time: Wed Apr 18 22:39:52 2007 don't use an SDK windows From: To: Time: Wed Apr 18 22:40:17 2007 start a command prompt: "c:\program files\microsoft visual studio .net 2003\common7\tools\vsvars32.bat" call "c:\program files\Microsoft Platform SDK\setenv.cmd" /2000 /RETAIL From: To: Time: Wed Apr 18 22:40:25 2007 leave out "call" From: To: Time: Wed Apr 18 22:40:37 2007 then run Kevin's script From: To: Time: Wed Apr 18 22:40:49 2007 So, this whole idea of trying to follow Kevin's instructions is going out the window then? From: To: Time: Wed Apr 18 22:41:24 2007 I don't know what his instructions say. From: To: Time: Wed Apr 18 22:41:41 2007 I know how KFW has been built for the last five years From: To: Time: Wed Apr 18 22:43:40 2007 I assume that Sam wants you to follow Kevin's directions From: To: Time: Wed Apr 18 22:43:50 2007 I think that's the idea, yes. From: To: Time: Wed Apr 18 22:44:11 2007 There is no "Microsoft Platform SDK", though I've got "Microsoft Platform SDK for Windows Server 2003 R2". From: To: Time: Wed Apr 18 22:44:20 2007 that's fine From: To: Time: Wed Apr 18 22:44:37 2007 the older platform sdks are no longer available from Microsoft's web site From: To: Time: Wed Apr 18 22:44:49 2007 you would need to have an old copy from the MSDN DVDs From: To: Time: Wed Apr 18 22:46:27 2007 I wish I had a mailbox that I could authenticate to with sasl gss-krb5 From: To: Time: Wed Apr 18 22:47:19 2007 Oh, and last I heard, Kevin was going to track down what header file needed to be copied from a Vista SDK. Whatever it is, I don't have it yet. Unless hacking that is now part of the scripts... From: To: Time: Wed Apr 18 22:47:29 2007 NTSecAPI.h From: To: Time: Wed Apr 18 22:48:00 2007 hacking is not part of the script and should not be part of the script From: To: Time: Wed Apr 18 22:51:29 2007 No, it shouldn't. But whatever I'm supposed to do should be part of the directions. Am I supposed to go fetch another SDK? (I got this one from Kevin who logged into his MSDN account or something.) From: To: Time: Wed Apr 18 22:53:45 2007 You need to fetch the Vista SDK and install it on a second machine. If you install it on the same machine as the Platform SDK for 2003 R2 the installer will want to upgrade you. The other option is to move the Platform SDK to a new directory and then allow the upgrade to take place From: To: Time: Wed Apr 18 22:57:34 2007 Well, I don't have a second machine, nor enough space to clone this one. Well, maybe I could make a snapshot and restore it. But I don't have an MSDN account, if that's needed to get the SDK. May be easier to get the file from Kevin tomorrow. From: To: Time: Wed Apr 18 22:58:07 2007 Can I do a test build without it? It only causes us to miss some Vista specific features, right? From: To: Time: Wed Apr 18 22:58:08 2007 or from me From: To: Time: Wed Apr 18 22:58:32 2007 Ah, true, good point. You've probably got a copy, if you've been doing builds. :-) Got it handy? From: To: Time: Wed Apr 18 22:59:23 2007 Except you should not need to modify the config file. Any modifications you need to make are probably bugs. Anything that causes you to look at the isda wiki is also probably a bug. We may choose to delay fixing these bugs beyond the 3.2 release though From: To: Time: Wed Apr 18 22:59:37 2007 yep From: To: Time: Wed Apr 18 23:00:15 2007 most of what you are going through should not be documented for end users. End users need to be able to build from the source code zip file From: To: Time: Wed Apr 18 23:00:26 2007 ~jaltman/Public/NTSecAPI.h.vista From: To: Time: Wed Apr 18 23:00:54 2007 The config file looks like it has the right values for those fields. And I'm looking at the wiki because that's where Kevin pointed me originally; I think that may have been before a lot of the stuff got put into the source tree? From: To: Time: Wed Apr 18 23:01:00 2007 Thanks. From: To: Time: Wed Apr 18 23:03:03 2007 (And still, each pushd into afs seems to assign a new drive letter. Is that supposed to happen?) From: To: Time: Wed Apr 18 23:04:24 2007 And this replaces NTSecAPI.h in the platform SDK, right, not in visual studio? From: To: Time: Wed Apr 18 23:06:35 2007 why don't you just use the drive letter it assigned the first time? From: To: Time: Wed Apr 18 23:07:05 2007 it replaces the one in the Platform SDK. You do not want to be use the VS version From: To: Time: Wed Apr 18 23:07:06 2007 I'd like to understand what is different between building in an sdk window and building as Jeff describes. We plan to build 3.2 as Jeff describes; we plan to understand the differences going forward and do something intelligent. From: To: Time: Wed Apr 18 23:07:24 2007 Sam, I have explained this countless times From: To: Time: Wed Apr 18 23:08:13 2007 Using the SDK rules by themselves only works if you have pushed the Visual Studio configuration into the System Environment From: To: Time: Wed Apr 18 23:08:26 2007 Jeff, that may well be true. I have missed your explanation. I have a lot of mail to go back through between you and Kevin after this release when I have more time From: To: Time: Wed Apr 18 23:08:46 2007 Ah, they don't include the common setup? From: To: Time: Wed Apr 18 23:09:08 2007 Doing so prevents you from supporting multiple versions of visual studio. We need both VS.NET 2003 for the 32-bit builds and VS8 (VS.2005) for the 64-bit builds From: To: Time: Wed Apr 18 23:09:45 2007 Well, we will for the next version; we're only doing 32-bit builds now, right? From: To: Time: Wed Apr 18 23:10:34 2007 The environment variables configured for VS.NET 2003 point to the VS.NET 2003 binaries, libs, headers, etc. The environment variables for VS8 point either to the 32-bit binaries,libs,headers, or either the 64-bit Itanium or 64-bit AMD versions From: To: Time: Wed Apr 18 23:10:43 2007 Or the cross-compiler versions From: To: Time: Wed Apr 18 23:10:52 2007 It all depends on how you want to build. From: To: Time: Wed Apr 18 23:11:17 2007 But for release builds of kfw 3.2 we're using vs2003 in 32-bit only mode since that's all it has From: To: Time: Wed Apr 18 23:11:26 2007 Then on top of that, each Visual Studio release ships with a copy of the Platform SDK that was current at the time. We never want to build using the SDK that shipped with Visual Studio From: To: Time: Wed Apr 18 23:11:40 2007 That part I understand:-) From: To: Time: Wed Apr 18 23:12:03 2007 So the Visual Studio configuration is executed first and then the SDK configuration is laid on top of it. From: To: Time: Wed Apr 18 23:12:21 2007 This puts the SDK paths in front of the Visual Studio paths From: To: Time: Wed Apr 18 23:13:53 2007 Visual Studio .NET 2003 does have 64-bit Itanium support. Its not very useful though From: To: Time: Wed Apr 18 23:14:07 2007 The perl script complains it can't find "filever" in PATH. From: To: Time: Wed Apr 18 23:14:27 2007 "filever.exe" is from the Support Tools From: To: Time: Wed Apr 18 23:14:39 2007 there should be a Support Tools directory on your install media From: To: Time: Wed Apr 18 23:15:00 2007 Maybe something I disabled in installing that I shouldn't have? Install media for Windows or for VS? From: To: Time: Wed Apr 18 23:15:09 2007 Windows XP From: To: Time: Wed Apr 18 23:15:23 2007 I'll check... From: To: Time: Wed Apr 18 23:15:29 2007 the support tools are in a separate directory and have a separate installer From: To: Time: Wed Apr 18 23:16:07 2007 ah. From: To: Time: Wed Apr 18 23:20:54 2007 Okay, now I'm up to printing the usage message. :-) And an uninitialized-value warning. From: To: Time: Wed Apr 18 23:20:58 2007 tom, my test run is still in the checkout phase From: To: Time: Wed Apr 18 23:21:30 2007 which variable? From: To: Time: Wed Apr 18 23:22:07 2007 Dunno. "... in concatenation (.) or string at commandandcontrol.pl line 167" From: To: Time: Wed Apr 18 23:22:15 2007 I ran "perl bkw.pl /?" From: To: Time: Wed Apr 18 23:26:10 2007 it takes several hours to do a checkout? From: To: Time: Wed Apr 18 23:26:27 2007 over my connection to the afs servers at mit, yes From: To: Time: Wed Apr 18 23:26:29 2007 Trying "perl bkw.pl /u raeburn /repository co /d" ... first checkout seems to be running fine. From: To: Time: Wed Apr 18 23:27:25 2007 the build goes relatively quickly. there seems to be sad interaction between svn and afs From: To: Time: Wed Apr 18 23:28:18 2007 remember svn makes an additional copy of every file when you do a normal checkout... or is this an export operation? From: To: Time: Wed Apr 18 23:28:44 2007 the script uses a normal checkout. it probably should use an export From: To: Time: Wed Apr 18 23:30:02 2007 Thunderbird 2.0 + Lightning Calendar + Google Provider for Lightning may come close to an Outlook Killer From: To: Time: Wed Apr 18 23:34:03 2007 watching a montior most of the writes are to the .svn directory From: To: Time: Wed Apr 18 23:35:18 2007 yeah, svn likes keeping a bunch of local state From: To: Time: Wed Apr 18 23:35:58 2007 the script should be modified to use support export for cvs and svn From: To: Time: Wed Apr 18 23:36:03 2007 that would make it go faster From: To: Time: Wed Apr 18 23:36:32 2007 and require less space From: To: Time: Wed Apr 18 23:37:20 2007 is there any rhyme or reason to the order in which the checkout occurs? its certainly not alphabetica From: To: Time: Wed Apr 18 23:37:24 2007 l From: To: Time: Wed Apr 18 23:37:55 2007 the svn or the cvs one? From: To: Time: Wed Apr 18 23:37:59 2007 svn From: To: Time: Wed Apr 18 23:39:07 2007 the cvs one may depend on what order the ,v files appear in the unsorted directory. for svn, dunno... maybe which files got touched last get checked out first. From: To: Time: Wed Apr 18 23:41:14 2007 reverse date order seems to make sense From: To: Time: Wed Apr 18 23:41:29 2007 Okay. My build is chugging along. I should head home and check on it later. From: To: Time: Wed Apr 18 23:42:25 2007 I should start laundry From: To: Time: Wed Apr 18 23:42:26 2007 i'm going to sleep From: To: Time: Wed Apr 18 23:42:39 2007 gn everyone From: To: Time: Wed Apr 18 23:42:49 2007 Good night. From: To: Time: Wed Apr 18 23:50:35 2007 Checkout is done. This information output by the script is incorrect: [07/04/18 23:50:16] Info -- Executing bkw.pl /config pass1-cfg.xml [07/04/18 23:50:16] Info -- Option settings: [07/04/18 23:50:16] CVSROOT :kserver:cvs.mit.edu:/cvs/pismere [07/04/18 23:50:16] KH_RELEASE OFFICIAL [07/04/18 23:50:16] NODEBUG [07/04/18 23:50:16] SVNURL svn.mit.edu [07/04/18 23:50:16] noclean [07/04/18 23:50:16] nocvstag [07/04/18 23:50:16] nodebug [07/04/18 23:50:16] nohelp [07/04/18 23:50:16] logfile bkw.pl.log [07/04/18 23:50:16] make [07/04/18 23:50:16] out C:\KfW\public [07/04/18 23:50:16] package [07/04/18 23:50:16] repository skip [07/04/18 23:50:16] nosign [07/04/18 23:50:16] src C:\KfW [07/04/18 23:50:16] nosvnbranch [07/04/18 23:50:16] nosvntag [07/04/18 23:50:16] nousername [07/04/18 23:50:16] noverbose [07/04/18 23:50:16] novverbose From: To: Time: Wed Apr 18 23:52:02 2007 the out is X:\test\dist\mit, src is x:\test\build, the svnbranch is krb5-1-6, the username was specified, and verbose was specified. The log file is also wrong. From: To: Time: Wed Apr 18 23:53:22 2007 Is the display wrong or is it not picking up options? From: To: Time: Wed Apr 18 23:53:33 2007 the display is wrong From: To: Time: Wed Apr 18 23:54:07 2007 at least from what I can verify its doing the right thing. I will know more when it completes From: To: Time: Wed Apr 18 23:55:13 2007 actually, its not logging From: To: Time: Wed Apr 18 23:55:49 2007 the svn checkout has the correct url From: To: Time: Thu Apr 19 00:05:44 2007 and that's because its Reading configuration from X:\test\build/pismere/athena/auth/krb5/src/windows/build/bkwconfig.xml. From: To: Time: Thu Apr 19 00:06:05 2007 instead of using the config file it was told to: Executing bkw.pl /config pass1-cfg.xml From: To: Time: Thu Apr 19 00:11:32 2007 and then the build fails with [07/04/19 00:12:22] Could not open pismere/athena/include/kerberos.ver. at bkw.pl line 194. From: To: Time: Thu Apr 19 00:11:48 2007 in other words, Kevin's commit last night broke things From: To: Time: Thu Apr 19 00:15:44 2007 ~jaltman/Public/KFW/bkw/ is the directory containing the scripts and the command file. build_afs.cmd is the command file I am running and it uses two config files pass1-cfg.xml and pass2-cfg.xml to specify the build options. All options are in the config files. the only command line options used are the ones necessary to specify which config files to use. From: To: Time: Thu Apr 19 00:38:42 2007 OK. You probably want to open a bug; Kevin will probably see this but assuming that would be non-ideal. I think he should just revert rather than trying to fix. From: To: Time: Thu Apr 19 00:39:31 2007 Actually I guess you could just revert it yourself. You don't technically have to use the bkw.pl from the branch. From: To: Time: Thu Apr 19 00:40:01 2007 don't we have to use the version that's being shipped in the zip file? From: To: Time: Thu Apr 19 00:41:45 2007 For the final release yes. And it is preferable that we do for this. I'm just trying to think of ways that you could make forward progress without waiting for Tom tomorrow From: To: Time: Thu Apr 19 00:42:10 2007 I'm going to bed From: To: Time: Thu Apr 19 00:42:16 2007 I will submit the ticket. From: To: Time: Thu Apr 19 00:42:22 2007 Tomorrow I will be out most of the day From: To: Time: Thu Apr 19 00:42:44 2007 OK. From: To: Time: Thu Apr 19 00:46:05 2007 its ticket 5536 From: To: Time: Thu Apr 19 00:46:31 2007 I assigned it to Kevin From: To: Time: Thu Apr 19 00:46:42 2007 gn From: To: Time: Thu Apr 19 00:46:46 2007 I've sent mail asking Kevin to arrange for a build into afs after Tom pulls up. You may not be willing to trust that as a beta2 build, but it can't hurt to do. From: To: Time: Thu Apr 19 00:47:25 2007 ->bed From: To: Time: Thu Apr 19 13:32:11 2007 I have created a new cmd script ~jaltman/Public/KFW/bkw/build_afs_use_cmdline_opts.cmd The script does not appear to be creating the log files The script is currently running and I will be back in five or six hours to check on it. From: To: Time: Thu Apr 19 15:02:16 2007 is Kevin's last commit supposed to go to ticket 5536? i can note that there. From: To: Time: Thu Apr 19 15:23:21 2007 oops (re web page)... fixed. From: To: Time: Thu Apr 19 21:26:30 2007 Ken, how is your XP system coming along? From: To: Time: Thu Apr 19 21:29:40 2007 Had to reboot my Mac, haven't reconnected to the XP box yet. (It's hosted on Linux so it should still be running fine.) My Mac doesn't seem to recover its ability to talk to its display sometimes if it's been disconnected or powered off. Very annoying. And I think a fan in the Mac may be dying, it was making unpleasant buzzing noises at power-up. But anyways... From: To: Time: Thu Apr 19 21:31:53 2007 Hm, and my VPN session shut down. The IS&T web pages say that the Windows client (or maybe it was all clients?) sometimes see sessions dropped if the connecting host is on campus and the session is idle a while. I think I need to run a ping in background. Yuck. From: To: Time: Thu Apr 19 21:33:26 2007 The build attempt ended with: Fatal -- Can't find C:\KfW\pismere\athena\auth\krb5\src\windows\identity\obj\i386\dbg\inc\\netidmgr_version.h at copyfiles.pl line 106. after a bunch of "SKIPPING MISSING DIR (softdirs enabled)" messages. From: To: Time: Thu Apr 19 21:35:44 2007 Before that point, it does appear to have built leash and its help file. From: To: Time: Thu Apr 19 21:37:41 2007 Which we don't ship:-) From: To: Time: Thu Apr 19 21:37:53 2007 The "i386" directory exists but has only a "rel" subdirectory, not "dbg". I ran the script with the /d option. From: To: Time: Thu Apr 19 21:37:54 2007 No, I guess we never dropped leash from this release. From: To: Time: Thu Apr 19 21:38:34 2007 Ah, don't do that. We apparently have a bug, but here we're trying to test release builds From: To: Time: Thu Apr 19 21:39:04 2007 And that stupid little dog in the search program tells me it does find netidmgr_version.h under the rel tree. From: To: Time: Thu Apr 19 21:39:48 2007 Okay, since I'm not actually trying to debug any programs, I guess there's no need for it... From: To: Time: Thu Apr 19 21:40:50 2007 Hm, that fan is still making funny noises. AT least, I hope it's the fan. From: To: Time: Thu Apr 19 21:46:13 2007 I brought the VPN back up, and trying running the script without /d. I got a prompt asking for my krb4 password, though I just checked that NIM had some credentials valid for several more hours. (Simple display, not advanced.) After I typed in my password, I got an error, "kerberos authentication failed: Don't have ticket granting ticket (get_ad_tkt)" From: To: Time: Thu Apr 19 21:46:53 2007 What version of kfw do you have installed? From: To: Time: Thu Apr 19 21:47:02 2007 And NIM advanced display shows v5, v4 and afs credentials valid for 9h58m. From: To: Time: Thu Apr 19 21:47:18 2007 Also, does the windows vpn client have the same feature as the mac where it hides your ip address? From: To: Time: Thu Apr 19 21:47:24 2007 I think this is the one you pointed me to. From: To: Time: Thu Apr 19 21:47:36 2007 Wouldn't surprise me. Though my checkout worked fine last night. From: To: Time: Thu Apr 19 21:47:44 2007 Hmm, I don't remember pointing you at one. From: To: Time: Thu Apr 19 21:48:01 2007 You shouldn't need the vpn except for accessing dfs. From: To: Time: Thu Apr 19 21:48:19 2007 No, I think Jeff had pointed me to a newer kfw than on the web site. Let me check the logs. From: To: Time: Thu Apr 19 21:49:09 2007 Well, if it is beta1 or newer, you are not running into the problem I'm thinking of From: To: Time: Thu Apr 19 21:49:28 2007 And, I see "Local Area Connection 2" with an 18.100.0.92 address, so no, the address isn't hidden. But the code may not know which address of the three (10.254.254.253 for AFS, 192.168.42.130 for VMware DHCP, or 18.100.0.92 for VPN) to use... From: To: Time: Thu Apr 19 21:52:07 2007 I just tried renewing credentials, and now it seems to be running okay. Probably the VPN address was gone from the list last time it renewed, and it didn't notice the change and invalidate the krb4 credentials. (Though the krb4 support has so many issues with multihomed clients anyways, it's just so much worse than having one interface that changes its one address now and then.) From: To: Time: Thu Apr 19 21:53:55 2007 Ah, I'm pleasantly surprised. The Windows netstat actually shows the local connections as coming from the VPN-assigned address, as opposed to the bogosity that Cisco imposes on the other platforms. From: To: Time: Thu Apr 19 21:56:23 2007 Here it is: ~jaltman/Public/KFW/test/dist/mit would be what I'm running. From: To: Time: Thu Apr 19 21:56:38 2007 Or, the stuff that was there on Tuesday night. From: To: Time: Thu Apr 19 21:57:57 2007 Yeah, definitely sounds like an unhappy fan. Tolerable for now. From: To: Time: Thu Apr 19 21:58:44 2007 And more so, if I remember to bring in my noise-cancelling earbuds. From: To: Time: Thu Apr 19 22:20:56 2007 Is krbdev on the kerberos-announce list? One copy of Kevin's mail I got has two sets of mailman footers added. From: To: Time: Thu Apr 19 22:29:16 2007 While I'm sitting here waiting for a build to run, I -- oh, never mind, it just blew out. From: To: Time: Thu Apr 19 22:31:29 2007 I'm getting "Access is denied" trying to run "candle". From: To: Time: Thu Apr 19 22:38:10 2007 Interesting... I can copy candle.exe to foo.exe and run it, which causes a debugger window to come up. If I click it away, I see a report of an unhandled exception reporting "Access is denied: 'wix'." There is no file called "wix" in the current directory, which has the wix binaries, and is called "wix". From: To: Time: Thu Apr 19 22:38:48 2007 The current folder is marked as read-only according to windows explorer. Despite the lack of any error message in my attempts to clear the flag, each time I check it, it's set. From: To: Time: Thu Apr 19 22:41:07 2007 Uh. But I had just created foo.exe in that folder. And I can create other temporary files. So while the explorer lists it as read-only, apparently it's not, sort of. From: To: Time: Thu Apr 19 22:53:40 2007 One of the messages written out at one point is "LOG: Attempting download of new URL file:///c:/Program Files/wix/wix.DLL." Not sure I like the sound of that. From: To: Time: Thu Apr 19 23:09:06 2007 Ah, well, copying over the wix directory and renaming the copy into place seems to have fixed it; I get usage messages now from candle and from the copy foo I made of candle. Still no idea what was wrong with the other one. From: To: Time: Thu Apr 19 23:13:22 2007 Ran svn update on the script directory before starting this time. And it's checking out again... From: To: Time: Thu Apr 19 23:27:49 2007 Ken, are you building to an afs file system? From XP, I, too, saw read only directories. From: To: Time: Thu Apr 19 23:28:04 2007 From last time, it looks like it'll be half an hour before I find out whether it passes the point of running the wix commands. I don't think I'm sticking around here that long; I'll probably check in from home. One of these days I should go back and figure out the proper remote desktop setup again. Oh, but the VM isn't protected behind a NAT any more; maybe I won't be quite that trusting. VMware over X over ssh it is, then.... From: To: Time: Thu Apr 19 23:28:18 2007 No, it's local, and the wix directory is local too. From: To: Time: Thu Apr 19 23:29:45 2007 Eventually I'll probably want to be able to do builds in AFS, but as this is just testing that a certain build configuration works (which, in fact, probably means I should be using 1.6 instead of trunk), not yet. From: To: Time: Fri Apr 20 15:17:18 2007 the build using the scripts at ~jaltman/Public/KFW/bkw/ looks ok for Beta 2. This was done with the "export" modifications. From: To: Time: Fri Apr 20 17:02:55 2007 My build last night seems to have worked. Almost 40 minutes to run. From: To: Time: Fri Apr 20 17:12:14 2007 Can I get you to try a beta2 build with the beta2 bkw.pl and beta2 pismere cvs? From: To: Time: Fri Apr 20 17:14:00 2007 40 minutes is about right. I have to go home now but will tune in, turn on and ... check what's up later. From: To: Time: Fri Apr 20 17:39:31 2007 Is there a tag to use, or just the current state of the krb5-1-6 branch? From: To: Time: Fri Apr 20 17:40:00 2007 current state of the krb5-1-6 branch and the head of the pismere branch From: To: Time: Fri Apr 20 17:41:24 2007 although for testing purposes using the kfw-3_2_0-beta1 tag for the pismere repository would not be bad. there weren't any changes of note in the pismere code other than version numbers and documentation. From: To: Time: Fri Apr 20 17:42:11 2007 I have been testing by building the kfw-3_2_0-beta1 tag for pismere and krb5-1-6 branch for krb5 From: To: Time: Fri Apr 20 17:43:54 2007 Do we think we're ready to do a beta2 build Jeff? From: To: Time: Fri Apr 20 17:45:05 2007 so ... /b krb5-1-6 /c kfw-3_2_0-beta1 /u raeburn /repository co ... and no /d ... the cvs checkout is running now. From: To: Time: Fri Apr 20 17:45:59 2007 I need to test the most recent changes from Kevin, they need to be pulled up, and then we need to updated the version numbers and tag. With that said, 'yes, I am think we should give it a shot." I've done everything I can do from here without actually have a beta2 set of installers. The next step is to deploy it within a test group at FNAL, Stanford, UNCC, etc. From: To: Time: Fri Apr 20 17:47:35 2007 ok, I just read what I wrote. I need to get some sleep. This inability to type English sentences is really becoming a problem. From: To: Time: Fri Apr 20 17:48:45 2007 Hmm. What changes were required? From: To: Time: Fri Apr 20 17:49:09 2007 I don't know. I'm looking at the diff's now From: To: Time: Fri Apr 20 17:50:14 2007 OK, it seems like the only change is exportrepository. I assume you decided that was critical or something From: To: Time: Fri Apr 20 17:50:25 2007 He changed the command line switch abbreviations. From: To: Time: Fri Apr 20 17:51:20 2007 And some quoting of variable expansion From: To: Time: Fri Apr 20 17:52:14 2007 Sure, but that change can't possibly have been critical. (I don't object to it being pulled up with the other changes) From: To: Time: Fri Apr 20 17:52:50 2007 Changing from checkout to export makes it possible to build in 1/3 the time. Not critical but certainly worth the testing time trade off From: To: Time: Fri Apr 20 17:53:12 2007 3 hours vs 10 hours is worth it to me From: To: Time: Fri Apr 20 17:53:58 2007 Sure. That's what I expected and that make sense. If I were you I'd be doing test builds locally and only building potential beta candidates into afs. Obviously you're welcome to do as you like. From: To: Time: Fri Apr 20 17:54:18 2007 ->weight liftming From: To: Time: Fri Apr 20 17:54:47 2007 There were some issues with building in AFS from alternate drive letters that I wanted to make sure were worked out From: To: Time: Fri Apr 20 17:55:00 2007 I suspect it won't be 1/3 for all of us... From: To: Time: Fri Apr 20 17:55:05 2007 Actually, it had nothing to do with AFS, just alternate drive letters From: To: Time: Fri Apr 20 17:55:51 2007 If you were building from a machine behind a cable modem or dsl, you would probably see the same performance benefits From: To: Time: Fri Apr 20 17:57:33 2007 Probably comparable, yeah. But from on campus, I suspect network lag in file system access to be much less of an issue, and at some point actual compilation time becomes relevant. Though I'm only guessing... From: To: Time: Fri Apr 20 17:57:49 2007 you would save a few minutes From: To: Time: Fri Apr 20 17:57:54 2007 I'll be happy to try out the export version and see. :) From: To: Time: Fri Apr 20 18:21:04 2007 interesting. i got knocked offline and when i reconnected, Adium didn't bother to tell me the messages i was sending to the krb5 chat weren't actually going anywhere. From: To: Time: Fri Apr 20 18:21:19 2007 that's a cool feature From: To: Time: Fri Apr 20 18:21:25 2007 Yeah, Adium kind of sucks like that. From: To: Time: Fri Apr 20 18:22:01 2007 I'm using Pandion and it has a bad habit of losing the connection and reconnection but failing to re-join conferences. From: To: Time: Fri Apr 20 18:22:12 2007 s/reconnection/reconnecting From: To: Time: Fri Apr 20 18:23:54 2007 I think most of the interesting bugs and missing features in Adium relating to multi-user chat are slated for 1.5 or 2.0 or something like that. Seems to be the milestone they set every time I look up such things in the bug tracker. From: To: Time: Fri Apr 20 18:24:47 2007 so... how about that zephyr->jabber transition? :-) From: To: Time: Fri Apr 20 18:25:19 2007 Build just finished cleanly (it appears). Options as before: krb5-1-6 branch, kfw-3_2_0-beta1 tag, checked out for building. From: To: Time: Fri Apr 20 18:26:07 2007 I'm updating my config files to incorporate Kevin's changes from the last commit and then I will re-test. From: To: Time: Fri Apr 20 18:31:40 2007 i'm getting ready to tag 1.6.1 for release; please set target versions of new tickets to 1.6.2 From: To: Time: Fri Apr 20 18:32:03 2007 ok From: To: Time: Fri Apr 20 18:32:09 2007 Trying another build with /r ex to compare times. The other builds were ~38m I think. From: To: Time: Fri Apr 20 18:35:05 2007 building. From: To: Time: Fri Apr 20 18:37:09 2007 Ken, are you seeing this warning? Name "main::logging" used only once: possible typo at bkw.pl line 344. From: To: Time: Fri Apr 20 18:57:10 2007 24m and counting... this is building in local (virtual) disk, so i don't expect that much of a speedup. yes, i got that message too. From: To: Time: Fri Apr 20 19:03:40 2007 24 minutes is what I would expect. that's good. From: To: Time: Fri Apr 20 19:03:53 2007 "and counting" From: To: Time: Fri Apr 20 19:04:07 2007 k From: To: Time: Fri Apr 20 19:04:19 2007 nearly done now, I think, it's doing installer stuff. From: To: Time: Fri Apr 20 19:21:18 2007 It looks like I missed one of my debugging lines when cleaning up (main::logging). From: To: Time: Fri Apr 20 19:23:28 2007 so that line should be removed? From: To: Time: Fri Apr 20 19:23:32 2007 36m, not much savings. the checkout does run pretty quickly to local disk, especially since i'm close to the server. From: To: Time: Fri Apr 20 19:25:06 2007 so much time seems to be spent doing all that darn compiling... From: To: Time: Fri Apr 20 19:25:54 2007 Well, so much of that 36 minutes. I shouldn't talk, with Jeff running his tests over long-distance file systems... From: To: Time: Fri Apr 20 19:26:36 2007 Perhaps when we drop leash and the C++ ccapi it wil shrink. From: To: Time: Fri Apr 20 19:32:59 2007 There's a bunch of odd stuff being logged, like RMDir: "$INSTDIR" SectionEnd Function: "un.onInit" ReadRegStr $LANGUAGE HKLM\Software\MIT\Kerberos\\Installer Language ... From: To: Time: Fri Apr 20 19:44:09 2007 that is all from the NSIS installer From: To: Time: Fri Apr 20 19:45:12 2007 on uninstall it removes the install directory if its empty, the first time the installer is run it asks the user for the preferred language and remembers it for future upgrades From: To: Time: Fri Apr 20 19:58:33 2007 FYI krb5-1.6.1 is tagged From: To: Time: Fri Apr 20 20:07:40 2007 re: mail::logging, yes, the line should be removed. From: To: Time: Fri Apr 20 20:11:45 2007 for post beta2 From: To: Time: Fri Apr 20 20:14:35 2007 WRT building kfw-3_2_0-beta1: Any idea why files.wxi:780 is looking for C:\KfW\pismere\staging\install\nsis\site-local.nsi instead of C:\KfW\pismere\buildwix\site-local.nsi? This used to work. From: To: Time: Fri Apr 20 20:17:24 2007 1.6.1 announcement out From: To: Time: Fri Apr 20 20:17:46 2007 Hm, okay, that was less than successful. From: To: Time: Fri Apr 20 20:18:35 2007 I haven't gotten to that part yet From: To: Time: Fri Apr 20 20:19:02 2007 I tried building in AFS. Checked out the 'build' directory from krb-1-6 into z:\project\kfw\build, added /s ..\sources to the command line. After the checkouts, "Could not open pismere/athena/include/kerberos.ver. at Z:\project\kfw\build\bkw.pl line 402." From: To: Time: Fri Apr 20 20:19:12 2007 Does the /s option not support relative paths? From: To: Time: Fri Apr 20 20:19:25 2007 are you running the script from Z: From: To: Time: Fri Apr 20 20:19:26 2007 ? From: To: Time: Fri Apr 20 20:19:36 2007 the script won't change drive letters From: To: Time: Fri Apr 20 20:19:49 2007 Yes, I'm on z: and running the script from the current directory (\project\kfw\build). From: To: Time: Fri Apr 20 20:19:59 2007 then I don't know. From: To: Time: Fri Apr 20 20:20:23 2007 Oh, hey, it's in AFS, which means it's easy to get at with a friendly editor. Heh. From: To: Time: Fri Apr 20 20:20:32 2007 the script I ran earlier today worked before the most recent commit. I'm still in the export phase From: To: Time: Fri Apr 20 20:22:06 2007 I mean /src. From: To: Time: Fri Apr 20 20:23:23 2007 files.wxi specifies the files that are being included and installed. It should be reading from the staging area From: To: Time: Fri Apr 20 20:23:52 2007 Then it has to take the tagged files, not the substituted ones. From: To: Time: Fri Apr 20 20:24:20 2007 however, it should not be referencing site-local.wxi anymore. It should be referencing site-local-tagged.wxi From: To: Time: Fri Apr 20 20:24:39 2007 are you building against the beta1 tag? From: To: Time: Fri Apr 20 20:24:54 2007 Yes. From: To: Time: Fri Apr 20 20:26:08 2007 that is why it won't work From: To: Time: Fri Apr 20 20:26:15 2007 you need to build against the krb5-1-6 branch From: To: Time: Fri Apr 20 20:39:20 2007 That worked much better. From: To: Time: Fri Apr 20 21:04:41 2007 GONE From: To: Time: Sat Apr 21 16:24:26 2007 I fired off a new build before leaving last night, with the /s option getting a full pathname (no drive letter) instead of a relative path. It failed differently -- after checkout, couldn't find \project\kfw\sources\pismere\athena at copyfiles.pl line 99. NIM indicates I still have tickets and tokens getting renewed. And the directory exists, and I can cd to it. From: To: Time: Sat Apr 21 16:42:56 2007 Ah, yuck. It looks like the VPN automatically disconnects at 23 hours. From: To: Time: Sat Apr 21 16:43:26 2007 Do you think that is related? From: To: Time: Sat Apr 21 16:44:15 2007 I doubt it. In this case, the build failed last night, and the VPN disconnected just a few minutes ago. From: To: Time: Sat Apr 21 16:46:14 2007 It looks like the script does chdir a few times, so I probably shouldn't expect it to work with a relative path for /s. (It ought to, IMNSHO, because it's useful. But at this stage while more important issues are being worked out, I shouldn't expect it.) I'm not sure about the problem in my second afs build attempt yet. From: To: Time: Sat Apr 21 16:50:35 2007 Did your absolute path include a drive letter? Was that the drive that was current when you ran the script? From: To: Time: Sat Apr 21 16:51:30 2007 No drive letter in the path I specified. The path was on the drive I was working in, and had the script stored in. Everything was in z: implicitly. From: To: Time: Sat Apr 21 16:57:22 2007 OK, this is not good From: To: Time: Sat Apr 21 16:57:49 2007 Could be something silly I'm overlooking. I'm running another test now with debugging print calls. From: To: Time: Sat Apr 21 17:04:00 2007 Oh! Okay, maybe I failed to override something. According to my print calls, the error happens when the current directory is C:\KfW\public. From: To: Time: Sat Apr 21 17:05:10 2007 Ah, I probably need to override the build-results directory too. It would help if the usage message described the defaults a bit better. From: To: Time: Sat Apr 21 17:07:52 2007 Yes. BKWconfig.xml specifies the src and out paths independently, and comments *there* indicate that they must be given as absolute paths. They should allow relative specs, eventually. And perhaps out should default to $src\public. From: To: Time: Sat Apr 21 17:35:52 2007 Well, the checkout finished. Then it sat there for six minutes. Afterwards it printed messages saying it had copied files into ziptemp. From: To: Time: Sat Apr 21 17:47:28 2007 Nearly two minutes to scan for anything named CVS. Then another pass looking for .cvsignore. Then another pass looking for ChangeLog. This could be done in one pass, pretty easily. From: To: Time: Sat Apr 21 17:48:03 2007 And now it's doing something else, apparently. It's been over nine minutes since it printed the ChangeLog message. Maybe I should've turned on the verbose option. From: To: Time: Sat Apr 21 17:48:55 2007 (Except /verbose is described as "debug mode" in the usage message. A debug mode probably isn't quite what I'm looking for.) From: To: Time: Sat Apr 21 17:50:08 2007 Ah, okay. Now it's actually compiling. From: To: Time: Sat Apr 21 17:51:01 2007 That's 21 minutes from end of checkout to first compiler invocation. From: To: Time: Sat Apr 21 17:54:32 2007 Too bad nmake doesn't do parallel builds. :-) Since I'm pretty sure it's file system delays slowing this down so much. The vmware process is only managing to use 70-80% of the cpu much of the time. From: To: Time: Sat Apr 21 20:38:58 2007 AFS build finished. Two and a half hours. From: To: Time: Sat Apr 21 20:43:46 2007 So that's similar to Jeff's result of ~3 hours. From: To: Time: Sat Apr 21 20:45:32 2007 Yes. A half hour faster, but he's got lots of network between NYC and here, and my AFS server is on the other side of my office. So, the distance adds ~30 min, and nearby AFS vs local virtual disk adds almost 2 hours. From: To: Time: Sun Apr 22 02:05:47 2007 MIt Kerberos Development Team From: To: Time: Sun Apr 22 02:05:47 2007 raeburn has set the topic to: Kerberos From: To: Time: Mon Apr 23 14:47:02 2007 fs on my windows vm says I'm using 98282 of the cache's available 0 1K byte blocks. From: To: Time: Mon Apr 23 14:47:30 2007 Does 0 mean unbounded, or minimum necessary, or what? (Clearly it doesn't mean "no cache".) From: To: Time: Mon Apr 23 14:49:51 2007 the cache size is fixed on windows at startup. you can't change it without restarting the afs service and destroying the cache contents. From: To: Time: Mon Apr 23 14:50:04 2007 that message is a bug From: To: Time: Mon Apr 23 14:51:28 2007 Okay. I'm wondering if cache size might contribute to the massive difference Kevin said he saw from my build time and yours, in AFS. The whole tree seems to be about 250M. From: To: Time: Mon Apr 23 14:52:19 2007 I mentioned here last week that the AFS cache size should be increased to 800MB. You didn't. Did Kevin? From: To: Time: Mon Apr 23 14:52:48 2007 No idea. 800MB? Why so large, if my 250M KfW tree is all i'm doing in afs at the moment? From: To: Time: Mon Apr 23 14:53:37 2007 you can set it to whatever you want. 800MB is what I use. Its backed by a paging file. From: To: Time: Mon Apr 23 14:54:46 2007 My cache size is apparently 98304K, so it looks like I am filling it, pretty much. No surprise there. From: To: Time: Mon Apr 23 14:55:00 2007 you are using the default From: To: Time: Mon Apr 23 14:55:14 2007 and you are thrashing From: To: Time: Mon Apr 23 15:10:30 2007 Kevin says he's using the default cache size. He's not running under vmware. From: To: Time: Mon Apr 23 15:10:57 2007 And he suggested defragmenting the drive might help a little. That's running now. From: To: Time: Mon Apr 23 15:11:35 2007 the cache thrashing will make a huge difference since nothing will ever be read back from the file server From: To: Time: Mon Apr 23 15:11:38 2007 GONE From: To: Time: Mon Apr 23 15:12:33 2007 It ought to improve things, yes, but if Kevin's got the same cache size and gets builds done in 40 minutes, there's something else going on too... From: To: Time: Mon Apr 23 15:13:20 2007 Kevin, could you check your cache size? ("fs getcache" will tell you) From: To: Time: Mon Apr 23 15:14:34 2007 Actually, that's current usage. The current limit is available from the AFS configuration windows. From: To: Time: Mon Apr 23 15:21:29 2007 fixed target_version on #5542 From: To: Time: Mon Apr 23 15:24:44 2007 E:\user\k\p\kpkoch\Public\bkw>fs getcache AFS using 98292 of the cache's available 0 1K byte blocks From: To: Time: Mon Apr 23 15:29:05 2007 Has anyone here ever built gssmonger? handlers.c wants netio/netio.h and sspiutil/util.h, neither of which exists anywhere on my C:\. From: To: Time: Mon Apr 23 17:52:02 2007 "the walk_rtree attacks...." From: To: Time: Mon Apr 23 18:00:02 2007 Ken, are any of your findings preventing the tagging of beta2? From: To: Time: Mon Apr 23 18:03:36 2007 No, I don't think so. From: To: Time: Mon Apr 23 18:04:51 2007 Tom, could you update patchlevel.h, winlevel.h and tag? I will take care of the pismere repository and build/test tonight. Hopefully, we can announce in the morning From: To: Time: Mon Apr 23 18:05:24 2007 do i pull up Kevin's last change? From: To: Time: Mon Apr 23 18:05:35 2007 no From: To: Time: Mon Apr 23 18:05:41 2007 I have not tested it From: To: Time: Mon Apr 23 18:06:23 2007 unless there is a serious error found I don't want anymore changes From: To: Time: Mon Apr 23 18:06:34 2007 so you confirm the krb5-1-6 branch as it currently is works for you? From: To: Time: Mon Apr 23 18:06:52 2007 that is what I have been testing From: To: Time: Mon Apr 23 18:07:41 2007 the script results in installers. I will have to test the installers in customer environments but I don't want to perform the limited deployments until we have an official beta From: To: Time: Mon Apr 23 18:08:09 2007 obviously, if there is a problem we will have to fix it and issue a beta3 From: To: Time: Mon Apr 23 18:19:42 2007 tagged From: To: Time: Mon Apr 23 18:19:47 2007 thanks From: To: Time: Mon Apr 23 18:26:16 2007 pismere has been tagged From: To: Time: Mon Apr 23 18:26:28 2007 both tags are the same "kfw-3_2_0-beta2" From: To: Time: Mon Apr 23 18:28:57 2007 oh, the latest Pluggable GSS thing on Kitten is from someone from Vintela. how about that... From: To: Time: Mon Apr 23 18:31:01 2007 yep From: To: Time: Mon Apr 23 18:31:10 2007 formerly Vintella, now Quest From: To: Time: Mon Apr 23 18:31:12 2007 Jeff, was your 3-hour build in Windows under VMware or running directly on the hardware? I wonder if that might make a difference... Also, my network connections are through the MIT VPN, not direct... From: To: Time: Mon Apr 23 18:31:37 2007 /me would suspect the VPN. From: To: Time: Mon Apr 23 18:31:43 2007 I wonder if either AFS or VPN code interacts badly with VMware somehow. From: To: Time: Mon Apr 23 18:31:51 2007 my 3 hour build is on a dual-core super fast machine with 4gb of ram From: To: Time: Mon Apr 23 18:32:14 2007 I have 68MB/sec bandwidth when reading from the AFS cache From: To: Time: Mon Apr 23 18:32:36 2007 I have 91KB/sec when writing to AFS From: To: Time: Mon Apr 23 18:32:49 2007 And not vmware, and not the mit vpn? From: To: Time: Mon Apr 23 18:33:03 2007 not vpn (you don't need it for afs) and not vmware From: To: Time: Mon Apr 23 18:33:40 2007 Is there a handy program for testing the AFS performance that Kevin and I could run on our machines to see how they compare? From: To: Time: Mon Apr 23 18:34:33 2007 copy a large (300MB) file to the server, read it back, fs flush the file, read it back. From: To: Time: Mon Apr 23 18:34:43 2007 measure the times of each operation From: To: Time: Mon Apr 23 18:35:15 2007 Yeah, I set up the vpn for \\win.mit.edu\dfs, and probably need it for krb4 cvs too. But I don't still need \\win.mit.edu\dfs, and I could grab the krb5 cvs binary and rewrite the config file... From: To: Time: Mon Apr 23 18:35:34 2007 why use krb4 cvs, we have gss-api cvs From: To: Time: Mon Apr 23 18:35:36 2007 Oh, I guess that'll work. From: To: Time: Mon Apr 23 18:35:54 2007 (pounds head against brick wall) From: To: Time: Mon Apr 23 18:36:35 2007 someone please shoot the krb4 cvs binary and make it go away From: To: Time: Mon Apr 23 18:36:41 2007 :) From: To: Time: Mon Apr 23 18:41:05 2007 I'm trying a build right now after defragmentation, raising the afs cache size to ~300M, and rebooting. Still vpn, still my personal cell server. Updated to current trunk version of script to exercise the new "find" code etc. From: To: Time: Mon Apr 23 18:41:35 2007 k From: To: Time: Mon Apr 23 18:44:46 2007 Days like today argue for laptops and wifi. Maybe, water-resistant laptops, and wifi at the beach. From: To: Time: Mon Apr 23 18:44:59 2007 (Water resistant, and sand resistant, and volleyball resistant...) From: To: Time: Mon Apr 23 18:45:13 2007 days like today are for hiding inside air conditioning From: To: Time: Mon Apr 23 18:45:22 2007 laptops and EVDO From: To: Time: Mon Apr 23 18:45:35 2007 the roof of my building is closed until May 13th From: To: Time: Mon Apr 23 18:46:03 2007 evdo would be fine, if mit would pay for it. From: To: Time: Mon Apr 23 18:50:36 2007 So pruneFiles no longer prints out anything if verbose mode isn't turned on? Maybe I should be using verbose mode. From: To: Time: Mon Apr 23 19:06:00 2007 Do the pismere folks need to use our build script? I wonder if we need to care about whether anyone else has gserver-capable cvs. From: To: Time: Mon Apr 23 19:06:07 2007 s/has/has deployed/ From: To: Time: Mon Apr 23 19:06:26 2007 I have only run with verbose mode. The silence in verbose mode is scary enough that I usually end up running procmon in the background so I can see what file operations are taking place From: To: Time: Mon Apr 23 19:06:48 2007 pismere should replace the cvs.exe on their build machines. From: To: Time: Mon Apr 23 19:06:59 2007 krb4 is dead From: To: Time: Mon Apr 23 19:07:58 2007 Yes, but short of going up to their machines and doing it ourselves, I don't know if we can make that happen. But, if we don't need to care about them using our script, we could use gserver in the script, and just not use the same cvs binary they seem to be stuck with. From: To: Time: Mon Apr 23 19:08:10 2007 well zephyr is still alive and kicking isn't it? From: To: Time: Mon Apr 23 19:08:43 2007 there is no one maintaining pismere anymore. From: To: Time: Mon Apr 23 19:09:11 2007 Oh. Then I guess there's nothing for us to care about. So why do we care what they're using? From: To: Time: Mon Apr 23 19:09:23 2007 I don't From: To: Time: Mon Apr 23 19:09:48 2007 can the repository specifiers be overridden? then it doesn't sound like such a problem to me From: To: Time: Mon Apr 23 19:09:49 2007 So, pismere can use krb4-only cvs, and we can use gssapi cvs, and we'll be happy. From: To: Time: Mon Apr 23 19:10:01 2007 sure From: To: Time: Mon Apr 23 19:10:05 2007 Needs editing the config file, I think. From: To: Time: Mon Apr 23 19:13:44 2007 MIT spam filters are getting an annoying number of false positives From: To: Time: Mon Apr 23 19:13:51 2007 17m from last file checkout to first compilation command. IIRC that's four minutes off of last time, which would be about right for the find optimizations. From: To: Time: Mon Apr 23 20:12:23 2007 damn, ran out of space From: To: Time: Mon Apr 23 20:29:51 2007 Build with bigger afs cache just passed 2h mark; cache isn't full. From: To: Time: Mon Apr 23 20:30:31 2007 Unfortunately, I didn't keep the older log files so that I could compare progress. From: To: Time: Mon Apr 23 20:31:06 2007 Next test, I think, will be to shut down the vpn. From: To: Time: Mon Apr 23 20:52:06 2007 Build finished in 2:20, a little faster, and afs cache did fill. No-VPN test running now. Heading home. From: To: Time: Tue Apr 24 01:04:22 2007 Without the VPN, my build time is still 2 hours. Next test, I think, is to an Athena AFS server. From: To: Time: Tue Apr 24 02:00:24 2007 Weird. Last time (to my cell), the checkout took 10 minutes. This time, to a volume in the Athena cell, it's been 40 minutes and it's still going. From: To: Time: Tue Apr 24 04:14:06 2007 ~jaltman/Public/KFW/kfw-3_2_0-beta2/ From: To: Time: Tue Apr 24 15:49:00 2007 So, I did a build to the Athena cell last night. It died, failing to find a file. When I noticed this (at something like 5am or 6am) and tried to cd to the directory where the file should be, I got some kind of "drive not available" message. Google pointed me to an article from Jeff suggesting that the AFS cache manager was responding too slowly. Since the host system running vmware does a massive parallel build at 4am, I figured this was the cause. I restarted the build at 6:15, and it ran to completion... in 2-1/2 hours. From: To: Time: Tue Apr 24 16:35:31 2007 How fast is a build on a local drive? From: To: Time: Tue Apr 24 17:07:38 2007 Kevin and I just talked a bit.... My build to "local" (vmware virtual) disk is ~40m, my build to AFS is ~2.5h. But, something Jeff said recently came back to mind. My VM doesn't have a lot of memory allocated to it. If the AFS cache, even backed by the swap file, makes heavier use of main memory than using a normal local file system, that might explain the significantly worse performance I'm getting. From: To: Time: Tue Apr 24 17:11:18 2007 The Windows VM has 128M allocated. (The host only has 512M, so it's not going to get a lot more, except maybe temporarily for testing this theory.) Kevin's machine has, what, 2G? So the AFS cache space isn't a big deal. From: To: Time: Tue Apr 24 17:20:50 2007 oh right, i should approve my announcement message. kfw-3.2-beta2 posted. From: To: Time: Tue Apr 24 17:50:58 2007 i'm still getting kicked off the active VLAN when on wireless From: To: Time: Tue Apr 24 18:14:15 2007 tom, I just found another case where krb5_get_credentials() is calling krb5_cc_store_cred() with an invalid tgts From: To: Time: Tue Apr 24 18:14:34 2007 what kind of invalid? From: To: Time: Tue Apr 24 18:14:49 2007 krb5_get_cred_from_kdc is returning success From: To: Time: Tue Apr 24 18:15:21 2007 tgts[0] is non-NULL From: To: Time: Tue Apr 24 18:15:33 2007 tgts[0].magic is 0 From: To: Time: Tue Apr 24 18:16:09 2007 does the rest of it look sane? From: To: Time: Tue Apr 24 18:16:50 2007 tgts[0].client is non-NULL with magic of 17233160 and the rest of the fields are not sane From: To: Time: Tue Apr 24 18:17:22 2007 are the client and server in the same realm? if not, what cross-realm TGTs are cached? From: To: Time: Tue Apr 24 18:17:59 2007 the client is in FERMI.WIN.FNAL.GOV and the server is in FNAL.GOV From: To: Time: Tue Apr 24 18:19:16 2007 there is a path through WIN.FNAL.GOV From: To: Time: Tue Apr 24 18:21:15 2007 were any cross-realm tickets cached? From: To: Time: Tue Apr 24 18:21:42 2007 we have already stored krbtgt/FERMI.WIN.FNAL.GOV@FERMI.WIN.FNAL.GOV krbtgt/WIN.FNAL.GOV@FERMI.WIN.FNAL.GOV krbtgt/FNAL.GOV@WIN.FNAL.GOV in the cache from a previous successful attempt at obtaining a service ticket for afs@FNAL.GOV From: To: Time: Tue Apr 24 18:23:26 2007 does this happen every time you have that series of TGTs cached and attempt to get a ticket for something@FNAL.GOV? From: To: Time: Tue Apr 24 18:23:37 2007 no. its intermittent From: To: Time: Tue Apr 24 18:24:25 2007 it could be a race condition with the afs and kca_service processes running at the same time walking the same chain From: To: Time: Tue Apr 24 18:24:58 2007 I can only reproduce the problem at logon so I can only look at it after the crash From: To: Time: Tue Apr 24 18:31:09 2007 the out_creds from krb5_get_cred_from_kdc() is sane From: To: Time: Tue Apr 24 18:31:17 2007 i'm not sure that race can affect things From: To: Time: Tue Apr 24 18:31:34 2007 out_creds is the actual requested ticket? From: To: Time: Tue Apr 24 18:36:57 2007 out_creds is pointing to a credential with client jaltman@FERMI.WIN.FNAL.GOV and server kca_server/hostname@FNAL.GOV From: To: Time: Tue Apr 24 18:37:06 2007 there is what appears to be a valid ticket field From: To: Time: Tue Apr 24 18:37:19 2007 and a valid key field and times structure From: To: Time: Tue Apr 24 18:37:31 2007 so yes, I believe this is the desired ticket From: To: Time: Tue Apr 24 18:38:00 2007 does the KDC support referrals? From: To: Time: Tue Apr 24 18:38:12 2007 Active Directory are the first two realms From: To: Time: Tue Apr 24 18:38:20 2007 oh great From: To: Time: Tue Apr 24 18:38:25 2007 FERMI.WIN.FNAL.GOV and WIN.FNAL.GOV From: To: Time: Tue Apr 24 18:38:41 2007 and to make matters worse, some of them are win2k and some win2k3 From: To: Time: Tue Apr 24 18:38:49 2007 each realm is mixed From: To: Time: Tue Apr 24 18:39:30 2007 I'm going to have to leave in about ten minutes. From: To: Time: Tue Apr 24 18:39:55 2007 i'm going to read through the code some more but i'm not optimistic. the referrals code is really ugly. From: To: Time: Tue Apr 24 18:40:11 2007 I hate to say it but this bug will prevent a final release of kfw 3.2 From: To: Time: Tue Apr 24 18:41:00 2007 I will try to narrow down the problem after Sam leaves tomorrow by restricting the KDC lists to either all win2k or all win2k3 From: To: Time: Tue Apr 24 18:41:26 2007 I seem to remember a comment that the code had not been tested against win2k active directory From: To: Time: Tue Apr 24 18:41:27 2007 dammit i rewrote this pre-referrals explicitly to avoid having 300+ line functions, and now it's back to that From: To: Time: Tue Apr 24 18:43:19 2007 the good news is that I do have a semi-reproducible case and worst comes to worst I can fill the function with output to a file to get a better idea of what paths are being taken. From: To: Time: Tue Apr 24 18:44:01 2007 unfortunately, I cannot attach a debugger to the machine since it is in another state behind a VPN From: To: Time: Tue Apr 24 18:45:12 2007 at this point i suspect the referrals code. if you can disable it that might help, but there's no ifdef to do that From: To: Time: Tue Apr 24 18:46:17 2007 I could go back to 1.4 but I don't think that makes sense. From: To: Time: Tue Apr 24 18:46:56 2007 what realm is being passed in with the server name? is it generated by sname_to_princ? From: To: Time: Tue Apr 24 18:50:47 2007 server name contains a realm From: To: Time: Tue Apr 24 18:51:04 2007 so it was not generated by sname_to_princ? From: To: Time: Tue Apr 24 18:51:12 2007 kca_server/hostname@FNAL.GOV From: To: Time: Tue Apr 24 18:51:27 2007 i'm sorry, that doesn't answer my question From: To: Time: Tue Apr 24 18:51:29 2007 its being produced with krb5_build_principal_ext() From: To: Time: Tue Apr 24 18:52:02 2007 ok From: To: Time: Tue Apr 24 18:52:22 2007 (sorry, it took a few minutes to find the relevant code and type the response) From: To: Time: Tue Apr 24 18:58:47 2007 I have to go. I will be back around 11 From: To: Time: Tue Apr 24 18:59:14 2007 i don't expect to have an answer by then From: To: Time: Tue Apr 24 18:59:40 2007 I'm not expecting you to. I am expecting that you might have more questions From: To: Time: Tue Apr 24 19:00:01 2007 I've left the debugger up. I will examine it further when I get back From: To: Time: Tue Apr 24 19:00:38 2007 I'm sorry I found this. :( From: To: Time: Tue Apr 24 20:07:05 2007 ok, existing cached TGT in the target realm strongly implicates the referrals code From: To: Time: Tue Apr 24 22:14:02 2007 mail sent with possible patch From: To: Time: Tue Apr 24 22:35:51 2007 back From: To: Time: Tue Apr 24 22:36:05 2007 checking e-mail From: To: Time: Tue Apr 24 23:17:22 2007 Tom, your analysis makes a lot of sense. From: To: Time: Tue Apr 24 23:18:02 2007 unfortunately it means you need to cause a race condition to happen in order to reproduce From: To: Time: Tue Apr 24 23:21:00 2007 I can reproduce it frequently enough. I have a good test case. In any case, given the complexity of this code I think that we should be setting any pointers to memory we free to NULL. From: To: Time: Tue Apr 24 23:21:32 2007 yeah. i need to find time to thwack the code really hard again. From: To: Time: Tue Apr 24 23:22:54 2007 I missed the original problem description (where do the log files live again?), but if this is serious enough to hold up the kfw release, and it's in libkrb5, is it serious enough that we should consider getting krb5-1.6.2 out soon-ish with the fix, too? From: To: Time: Tue Apr 24 23:24:05 2007 it sounds like a race condition involving gc_frm_kdc being called from two processes at once From: To: Time: Tue Apr 24 23:26:02 2007 Some weird interaction with the ccache contents? From: To: Time: Tue Apr 24 23:27:25 2007 something like that. do_traversal() gets called at least twice, except when it only gets called the first time because in between, some other process went and cached the final-hop TGT. From: To: Time: Tue Apr 24 23:34:00 2007 its actually a multi-threaded thing From: To: Time: Tue Apr 24 23:34:26 2007 same difference as far as this code is concerned From: To: Time: Tue Apr 24 23:34:48 2007 the reason that its crucial for KFW is that NIM is multi-threaded and the multi-realm MIT,Active Directory scenario is just so common a use case. From: To: Time: Tue Apr 24 23:34:58 2007 gc_frm_kdc doesn't hold an exclusive ccache lock across its entire execution From: To: Time: Tue Apr 24 23:35:31 2007 not that the ccache actually implements locking From: To: Time: Tue Apr 24 23:36:06 2007 i'm not sure we want applications or non-ccache code to be able to hold an exclusive lock on a ccache From: To: Time: Tue Apr 24 23:36:07 2007 I don't think we'd want the ccache locked while a process runs off to talk to a KDC. From: To: Time: Tue Apr 24 23:39:55 2007 unlike, say, the rcache code, which doesn't seem to lock at all last i checked... From: To: Time: Tue Apr 24 23:40:03 2007 I'm not sure when we'd ever want to let any ccache access be blocked, aside from maintaining consistency within the ccache. From: To: Time: Tue Apr 24 23:41:07 2007 No, but we *know* that code is horribly broken. :-) From: To: Time: Tue Apr 24 23:43:44 2007 off to sleep From: To: Time: Tue Apr 24 23:44:20 2007 gn From: To: Time: Tue Apr 24 23:46:30 2007 so far so good. I will test this another 30 times or so From: To: Time: Tue Apr 24 23:51:46 2007 I can't reproduce it with the new krb5_32.dll. Let me put the old one back to ensure that I can still reproduce it with that one. From: To: Time: Tue Apr 24 23:53:02 2007 and indeed, I can reproduce it in two attempts with the old version From: To: Time: Tue Apr 24 23:53:09 2007 Looks like Tom got it. From: To: Time: Tue Apr 24 23:53:27 2007 We should probably issue Beta 3 tomorrow From: To: Time: Tue Apr 24 23:54:23 2007 as for whether or not this is important enough for 1.6.2. if there is a multi-threaded PAM scenario, then it could be triggered From: To: Time: Wed Apr 25 10:39:54 2007 Why does VC++ 2003 stick an underscore on the beginning of references, but not on the definitions? For example, ccs_server.obj refers to _cci_stream_data, but cci_stream.c defined cci_stream_data. From: To: Time: Wed Apr 25 18:13:24 2007 do we really want to issue beta3 the day after beta2? From: To: Time: Wed Apr 25 18:14:05 2007 if we are going to go final next week, then we have to From: To: Time: Wed Apr 25 18:15:45 2007 Asanka has found an issue in the profile library. From: To: Time: Wed Apr 25 18:16:00 2007 new issue? From: To: Time: Wed Apr 25 18:16:42 2007 if the input is [section] subject = { foo = "" } when it is stored back to a file it gets written as [section] subject = { foo = } From: To: Time: Wed Apr 25 18:17:25 2007 of course, the next time that the profile library reads the file it throws up an error because there is no r-value From: To: Time: Wed Apr 25 18:17:34 2007 oh From: To: Time: Wed Apr 25 18:17:59 2007 prof_parse.c line 309 in need_double_quotes() should return true for empty strings From: To: Time: Wed Apr 25 18:18:18 2007 we might want to apply that patch as well. From: To: Time: Wed Apr 25 18:19:33 2007 The way things are now the profile editor in NIM will save changes to FNAL's krb5.conf that result in a profile that can't be read back. From: To: Time: Wed Apr 25 18:20:14 2007 you may want to have lxs look at this because i think KfM is the only other real user of the profile writing functionality From: To: Time: Wed Apr 25 18:20:30 2007 I believe that it was editing of the profile in NIM that resulted in the blue screen condition on Windows last week From: To: Time: Wed Apr 25 18:20:45 2007 blue screen??? From: To: Time: Wed Apr 25 18:20:57 2007 oh, did you miss that discussion? From: To: Time: Wed Apr 25 18:22:40 2007 KfM's gui does not allow for empty strings in any of its fields From: To: Time: Wed Apr 25 18:23:09 2007 (in the Kerberos.app Edit Realms dialog empty strings cause you to get a sheet bitching at you :-) ) From: To: Time: Wed Apr 25 18:23:12 2007 last week FNAL's CIO installed KFW 3.2 Beta 1 and was playing around with it. The next time he rebooted his machine the Windows Logon process produced a memory access violation which in turn caused the process to terminate unexpectedly. Windows in response shut down immediately with a "blue screen" indicating the unexpected error From: To: Time: Wed Apr 25 18:23:45 2007 lxs, what does KFM do if the input krb5.conf file contains a section that the realm editor doesn't look at? From: To: Time: Wed Apr 25 18:24:03 2007 it ignores it From: To: Time: Wed Apr 25 18:24:25 2007 And then when the profile library writes it back out, it can be damaged. From: To: Time: Wed Apr 25 18:25:28 2007 True, though I would think that is a sufficiently uncommon edge case that it is not something that needs to get fixed for Leopard From: To: Time: Wed Apr 25 18:25:35 2007 The profile library will accept input of the form [section] subject = { foo = "" } but when writing it back out saves it as [section] subject = { foo = } which is invalid From: To: Time: Wed Apr 25 18:25:47 2007 granted. From: To: Time: Wed Apr 25 18:25:56 2007 however, do you care if it gets fixed for KFW? From: To: Time: Wed Apr 25 18:26:32 2007 Fixing it so that the quotes are preserved should happen at the very least on the trunk. If it is impacting users on KfW then fixing it might be a good idea From: To: Time: Wed Apr 25 18:27:06 2007 It is impacting users at FNAL at the very least From: To: Time: Wed Apr 25 18:27:28 2007 they use empty quotes for something? From: To: Time: Wed Apr 25 18:27:30 2007 Asanka has a patch to prof_parse.c. Ah, here he is. From: To: Time: Wed Apr 25 18:28:30 2007 They have some section that was added called [instancemapping] afs/* = "" cron/* = "" etc. From: To: Time: Wed Apr 25 18:29:11 2007 Whoever created it doesn't understand the profile library grammar because they didn't realize that '*' is the finalizer symbol From: To: Time: Wed Apr 25 18:30:00 2007 However, they did enough testing to realize that they need to provide a double quoted empty string on the right hand side in order to allow the entries to parse. From: To: Time: Wed Apr 25 18:31:57 2007 need_double_quotes() in prof_parse.c was returning false for both NULL and empty values. The fix was to return true when the value was empty. From: To: Time: Wed Apr 25 18:32:28 2007 the NULL case is special and doesn't affect the case where the value is empty From: To: Time: Wed Apr 25 18:34:47 2007 The proposed patch is: Index: prof_parse.c =================================================================== --- prof_parse.c (revision 19525) +++ prof_parse.c (working copy) @@ -306,8 +306,10 @@ */ static int need_double_quotes(char *str) { - if (!str || !*str) - return 0; + if (!str) + return 0; + if (!*str) + return 1; if (isspace((int) (*str)) ||isspace((int) (*(str + strlen(str) - 1)))) return 1; if (strchr(str, '\n') || strchr(str, '\t') || strchr(str, '\b')) From: To: Time: Wed Apr 25 18:36:24 2007 the '!str' case applies when the right side is a subsection. we don't want to return a non-zero value there. From: To: Time: Wed Apr 25 18:37:26 2007 also need_double_quotes() is only called in dump_profile(). the change shouldn't disrupt things elsewhere From: To: Time: Wed Apr 25 18:40:31 2007 heh, Google is our friend. This page explains what FNAL is doing with this section: http://www.fnal.gov/docs/strongauth/krb5conf.html From: To: Time: Wed Apr 25 18:40:52 2007 quoting "This deals with the instance portion of a principal (see principal in the Glossary). The lines that follow instruct Kerberos to strip a trailing /cron/* or /cms/* portion of the client principal when generating a Kerberos v4 ticket for the service called afs." From: To: Time: Wed Apr 25 18:41:16 2007 looks like it is used by the krb524d they have deployed From: To: Time: Wed Apr 25 18:41:51 2007 It must be used with keytabs From: To: Time: Wed Apr 25 18:43:37 2007 we are still dropping the trailing '*' from the tag name when we are writing the profile back. From: To: Time: Wed Apr 25 18:43:59 2007 There is nothing we can do about that. That is how the profile library works From: To: Time: Wed Apr 25 18:44:07 2007 yup From: To: Time: Wed Apr 25 18:44:33 2007 lxs, does the patch look correct to you? From: To: Time: Wed Apr 25 18:49:10 2007 yeah that looks fine From: To: Time: Wed Apr 25 18:49:26 2007 thanks. I will commit it From: To: Time: Wed Apr 25 18:57:30 2007 ticket 5547. marked for pullup. From: To: Time: Wed Apr 25 18:57:35 2007 ok From: To: Time: Wed Apr 25 20:45:48 2007 anything else? or should i just tag stuff now? From: To: Time: Wed Apr 25 20:46:22 2007 that's all I got. From: To: Time: Wed Apr 25 20:46:28 2007 patchlevel and winlevel increments From: To: Time: Wed Apr 25 20:46:34 2007 then tag From: To: Time: Wed Apr 25 20:50:26 2007 Hello. Back from NYC From: To: Time: Wed Apr 25 20:50:37 2007 did you have a good trip back? From: To: Time: Wed Apr 25 20:51:01 2007 It was not as good as the trip out, but yes. From: To: Time: Wed Apr 25 20:51:40 2007 glad to hear it From: To: Time: Wed Apr 25 20:53:08 2007 what should I do with the build tree for kfw 3.2 beta 2? I only have enough quota for one build tree at a time in my personal volume From: To: Time: Wed Apr 25 20:55:38 2007 pismere tagged From: To: Time: Wed Apr 25 20:56:36 2007 tar or zip it? From: To: Time: Wed Apr 25 20:59:57 2007 let's see how large it is after a zip From: To: Time: Wed Apr 25 22:45:03 2007 ~62mb zipped From: To: Time: Wed Apr 25 22:45:17 2007 at some point the build tree should be moved somewhere else. From: To: Time: Wed Apr 25 22:45:23 2007 beta3 is now building From: To: Time: Wed Apr 25 22:48:42 2007 My Windows build with increased RAM and local disk ran in about 30 minutes, down from 38. I had increased the RAM allocated to the Windows virtual machine from 128M to 384M. The host machine has only 512M, though, so I probably don't want to keep it even that high in the long term. From: To: Time: Wed Apr 25 22:49:17 2007 I've chased down my sshd problem to gss_accept_sec_context failing and somehow com_err being messed up. so you don't get reasonable error codes From: To: Time: Wed Apr 25 22:49:45 2007 Where do the chat room log files live? From: To: Time: Wed Apr 25 22:49:49 2007 Now trying to see if I've misapplied a patch in the debian build From: To: Time: Wed Apr 25 22:50:24 2007 http://opteron-prime.mit.edu/~hartmans/krb5.log.txt From: To: Time: Wed Apr 25 22:50:39 2007 Thanks. From: To: Time: Wed Apr 25 22:59:00 2007 Very not good. Ok, let's see if 1.6.1 passes regression on x86_64 linux From: To: Time: Wed Apr 25 23:00:55 2007 (I'm assuming that we would not have released if it was failing tests on everything) From: To: Time: Wed Apr 25 23:15:26 2007 So, the tests don't work, but it's not clear that's the problem From: To: Time: Wed Apr 25 23:15:54 2007 In that they fail in a matter that suggests they don't work with the dejagnu in debian more than that they actually fail. From: To: Time: Wed Apr 25 23:16:37 2007 Oh, great. From: To: Time: Wed Apr 25 23:16:51 2007 I hope that's just a bug in the Debian version of dejagnu.... From: To: Time: Wed Apr 25 23:17:39 2007 Though our x86_64 nightly tests are getting done on Debian. From: To: Time: Wed Apr 25 23:21:59 2007 My build to AFS is running a little faster this time. At 34 minutes it started building rd_req.c, which it wasn't getting to before until 39 minutes. Saving 1/8 of the build time still leaves me with a really long build if I use AFS. From: To: Time: Wed Apr 25 23:23:04 2007 How are the tests doing in that build? It may also be my network configuration is too special From: To: Time: Wed Apr 25 23:24:31 2007 In the nightly test? They passed on the 20th. I'd fetch the latest results, but that'd mess with my AFS build timing test. Oh, wait. That's trunk only. For some reason it's not running the 1.6 branch tests... From: To: Time: Wed Apr 25 23:25:35 2007 Oh. It's one of the machines running a local copy of the build script, and therefore not up to date. From: To: Time: Wed Apr 25 23:33:16 2007 Why is it running a local copy of the build script? O, I bet I know why I'm seeing failures. "broken as designed" My default realm is athena my host lives in suchdamage.org and doesn't have a domain_realm mapping From: To: Time: Wed Apr 25 23:34:02 2007 I don't recall. Maybe AFS wasn't reliably running on the machine or something. That version of the script was still testing the 1.4 release. I'm updating it.... From: To: Time: Wed Apr 25 23:35:27 2007 In fact that was my problem. OK, so if the dejagnu tests are running on opteron-prime I'm going to call it a configuration error From: To: Time: Wed Apr 25 23:36:33 2007 Trunk worked fine 5 days ago. The 1.6 branch will get tested in about five hours. From: To: Time: Wed Apr 25 23:37:57 2007 Our tests should set up all the krb5.conf files for the programs we've built. What's left that your configuration would cause to mess up? Logging in as root to run servers maybe? From: To: Time: Wed Apr 25 23:39:12 2007 Mostly an ipv6 only machine. I tried to hack things together so it would think it had ipv4 enough for the tests to work, but may have failed From: To: Time: Wed Apr 25 23:42:51 2007 Oh. Hmm... I would think all you'd need would be a locally-assigned address on some non-loopback interface that's up, and an /etc/hosts entry for it. But maybe not... From: To: Time: Wed Apr 25 23:43:19 2007 (Using the loopback interface would be okay if you were using the pktinfo support that's on the trunk.) From: To: Time: Wed Apr 25 23:48:08 2007 Okay, exactly one hour into the build, it's starting to build kuserok.c; last time, it got to that file at 1:08. So, 8 minutes saved out of 68, so far. Either I need *way* more memory to make a real difference, or memory isn't the biggest problem in local vs AFS builds. From: To: Time: Wed Apr 25 23:54:31 2007 Jeff is the only thing you get out of afs builds easy access to pdb files? If so, wouldn't mapping a drive letter and copying into afs be far easier? From: To: Time: Thu Apr 26 00:01:08 2007 One of the points of building into AFS was so that someone from MIT could verify. From: To: Time: Thu Apr 26 00:01:30 2007 Or so that someone from MIT could build and I would just sign and package the second pass. From: To: Time: Thu Apr 26 00:01:35 2007 I see the advantages of using AFS as being (1) using my editor of choice on my machine of choice to edit the sources I'm building on Windows, and (2) being able to build and test the same source tree on multiple systems. If the Windows build procedure didn't insist on putting the generated files into the source tree, I'd be just as happy (perhaps happier) putting the generated files on local disk. From: To: Time: Thu Apr 26 00:01:36 2007 Obviously we are not there yet From: To: Time: Thu Apr 26 00:02:27 2007 I agree that it would be nice if a future version of the script allowed for separate drive letters for the build and destination paths From: To: Time: Thu Apr 26 00:02:37 2007 Or support of UNC paths From: To: Time: Thu Apr 26 00:03:31 2007 building locally and copying to AFS would work From: To: Time: Thu Apr 26 00:03:32 2007 It's not just the script, I think it's the makefile setup as well. From: To: Time: Thu Apr 26 00:03:58 2007 the destination directory is entirely controlled by the script From: To: Time: Thu Apr 26 00:05:35 2007 How? Override the setting of OUTPRE from win-pre.in? Will that even work for specifying something that's not a simple subdirectory? From: To: Time: Thu Apr 26 00:05:58 2007 No, the pismere build systems puts object directories in the source tree. OK. I think you might get faster results if you build locally and copy into afs. I think that still allows us to verify, allows signing in a second step, and with drive mapping allows for the pdbs to be read correctly. From: To: Time: Thu Apr 26 00:06:06 2007 the Makefile doesn't put anything into the directory you give the script for the destination From: To: Time: Thu Apr 26 00:06:48 2007 Sure, but once you've decided that the source tree is going to change in the build you gain a lot from specifying one rather than multiple directiors. From: To: Time: Thu Apr 26 00:07:38 2007 Oh. I see. I'm not thinking about the destination for the zip file and installers, though that'd be nice too. I'd like to get the .obj files out of the source tree. From: To: Time: Thu Apr 26 00:07:49 2007 No, actually, the code we introduced in 1.6 to deal with defaulting the keytab to the local realm seems broken. From: To: Time: Thu Apr 26 00:08:36 2007 Basically rd_req expects the principal not to change. The caller passes in principal@ the keytab code ends up finding a different principal and then things don't match. From: To: Time: Thu Apr 26 00:08:56 2007 So, you get a wrong principal in request error. From: To: Time: Thu Apr 26 00:09:15 2007 I'm fading tonight; will open a bug tomorrow From: To: Time: Thu Apr 26 00:10:26 2007 gn From: To: Time: Thu Apr 26 00:11:39 2007 wasn't that defaulting strategy one we had misgivings about anyway? From: To: Time: Thu Apr 26 00:12:10 2007 it was one the Nico had misgivings about From: To: Time: Thu Apr 26 00:12:54 2007 Regardless it's the one we implemented. I assure you that always breaks is worse than have misgivings. From: To: Time: Thu Apr 26 00:13:07 2007 Or always breaks absent domain_realm mapping From: To: Time: Thu Apr 26 00:22:22 2007 GONE From: To: Time: Thu Apr 26 02:31:09 2007 Total time for build with bigger memory: 2h5m. So there's a bit of a savings there. Still annoyingly long though. From: To: Time: Thu Apr 26 07:45:03 2007 I ran "time dd ..." to test speed writing to AFS from Windows. The dd program printed a time and rate as well. The two times differ by almost a minute and a half; I expect maybe one is after the final write() and the other was delayed for the write-back to the server at fd close time. For compiler performance, I'm guessing the latter is probably more interesting. It works out to about 291K/s, about three times Jeff's performance. From: To: Time: Thu Apr 26 09:07:37 2007 Why does VC++ 2003 stick an underscore on the beginning of references, but not on the definitions? For example, ccs_server.obj refers to _cci_stream_data, but cci_stream.c defined cci_stream_data. From: To: Time: Thu Apr 26 11:44:21 2007 Any idea what could be causing plink to fail in a XP VM? The same plink works on the host PC. Both host and VM can ping svn.mit.edu. From: To: Time: Thu Apr 26 11:48:53 2007 Both have krb5 credentials. From: To: Time: Thu Apr 26 12:07:43 2007 How does it fail? From: To: Time: Thu Apr 26 12:12:56 2007 C:\Projects\pismere\athena\auth\krb5\src\windows\build>plink kpkoch@svn.mit.edu Using username "kpkoch". FATAL ERROR: Server unexpectedly closed network connection From: To: Time: Thu Apr 26 12:52:14 2007 You're not forwarding tickets From: To: Time: Thu Apr 26 13:15:27 2007 Thanks. From: To: Time: Fri Apr 27 10:59:27 2007 Is there a reason the kfwdev archives should be members-only, when the other list archives are public, and gmane will make them public anyways? From: To: Time: Fri Apr 27 11:03:34 2007 No. Kevin was supposed to work withg you and Tom to set it up the same way as the other lists From: To: Time: Fri Apr 27 11:05:23 2007 Ah. I haven't talked to him about it, but I see Tom is now explicitly an admin for the list (I assume that helps with certificate access or something), along with Kevin and kerberos-list-admin (which means I'll probably see moderation email, if there is any). From: To: Time: Fri Apr 27 11:06:03 2007 Oh, btw, Novell has sent me some sample code I've started looking over. (Just briefly for now, so I can get back to unix ccapi evaluation.) From: To: Time: Fri Apr 27 12:02:32 2007 Does an etype-info with zero elements have any meaning? Shawn says he's running into it... From: To: Time: Fri Apr 27 12:04:17 2007 In Mailman, I picked some other list and compared all the settings and they were the same. What did I miss? Are there multiple pages of settings? From: To: Time: Fri Apr 27 12:07:09 2007 Yes, quite a few pages... The archives should be public. There's a page with addresses from which email will be discarded (obvious spam sources, like the list address itself), those can be copied from the other Kerberos lists. Non-member submissions should probably be held for moderation. From: To: Time: Fri Apr 27 12:07:34 2007 I haven't looked at the kfwdev settings. Does it still not use the same password as the other Kerberos lists? From: To: Time: Fri Apr 27 12:39:02 2007 No, it uses the same one. From: To: Time: Fri Apr 27 14:33:06 2007 So, in the multithreaded KDC code, Novell had this clever idea for avoiding having lots of database context handles, one per thread per database. They'll just use the same krb5_context in each thread. At the same time. From: To: Time: Fri Apr 27 14:41:41 2007 Clever. From: To: Time: Fri Apr 27 15:12:36 2007 Related to that I think, they're adding a field to krb5_context, to hold the number of threads that should be used in the KDC to support the indicated realm. From: To: Time: Fri Apr 27 15:22:41 2007 So, it may take a long time to redesign their project. Just factor it into your estimate From: To: Time: Fri Apr 27 15:25:14 2007 I think there will be a number of opportunities for refactoring the code once their final patch is applied. I'm not sure if I want to ask them to do it. And delay getting the code, which hopefully would need less work. From: To: Time: Fri Apr 27 15:26:04 2007 Well, you need to either factor in doing it yourself into the estimate, or helping them do it into the estimate. From: To: Time: Fri Apr 27 15:28:22 2007 I'm writing up some notes now. If we're likely to ever get code from them again, I'd like to encourage them to give us what we'll want... From: To: Time: Fri Apr 27 19:07:15 2007 Shawn says the empty etype-info is coming from a w2k3 server. Though Larry doesn't believe him. From: To: Time: Sat Apr 28 15:39:41 2007 Linux failed nightly testing last night, but it seems to be because I was getting error messages from "id" in the rcp tests. From: To: Time: Sat Apr 28 17:44:47 2007 Ah. I wasn't logged in at the time, so /etc/group had probably been cleaned up. From: To: Time: Sat Apr 28 17:45:07 2007 Um, well, except the group that "id" complained about was 101, and that's in group.local too. From: To: Time: Sat Apr 28 17:57:37 2007 Ah, so about that 1.6.2 release. It turns out the problem is not in gss_set_allowable_enctypes. But even though the context gets set up correctly, we request a full set of enctypes anyway From: To: Time: Sat Apr 28 17:58:16 2007 I don't know exactly why, but it is a serious problem From: To: Time: Sun Apr 29 02:02:17 2007 MIt Kerberos Development Team From: To: Time: Sun Apr 29 02:02:17 2007 raeburn has set the topic to: Kerberos From: To: Time: Sun Apr 29 10:46:46 2007 Putty 0.59 with GSSAPI support ~jaltman/Public/putty-0.59-with-gssapi.zip From: To: Time: Sun Apr 29 18:52:13 2007 Should 5551 be included in KFW 3.2? From: To: Time: Sun Apr 29 19:27:08 2007 No, because it would involve another beta. From: To: Time: Sun Apr 29 19:29:08 2007 Or rather, it's my opinion that we can make a release without it. It means that in certain situations you need to add a domain_realms entry to make windows servers work when absent the bug they would work fine on their own. From: To: Time: Sun Apr 29 19:29:35 2007 that is fine. From: To: Time: Mon Apr 30 12:32:28 2007 is there any feedback on my e-mail of 4/26 "KFW road maps for 3.x and 4.x"? From: To: Time: Mon Apr 30 14:45:39 2007 I'm looking at depends.exe netidmgr.exe and don't see an obvious connection to ccapi. What am I missing? Thanks. From: To: Time: Mon Apr 30 14:47:17 2007 NIM uses the ccapi to enumerate the credential caches. NIM uses krb4 and krb5 both of which talk to the ccapi From: To: Time: Mon Apr 30 14:47:34 2007 NIM only loads modules when it uses them From: To: Time: Mon Apr 30 14:47:52 2007 Thanks. From: To: Time: Mon Apr 30 14:48:16 2007 NIM is a framework application. It doesn't have any direct dependencies. All of the dependencies are in the identity provider and credential provider modules From: To: Time: Mon Apr 30 14:50:12 2007 depends will only show you modules that are staticly linked to the process. if you want to see what modules are actually in use you must use tools such as process explorer. From: To: Time: Mon Apr 30 15:19:22 2007 why is Ken joined with a livejournal jabber account? From: To: Time: Mon Apr 30 17:04:00 2007 Does the KDC location plugin allow you to specify domain-realm mappings or only kdc lookup? From: To: Time: Mon Apr 30 17:05:14 2007 not sure. i haven't looked at that interface in detail From: To: Time: Mon Apr 30 17:10:38 2007 is krb5_get_host_realm() the domain-realm mapping code? From: To: Time: Mon Apr 30 17:11:21 2007 yeah From: To: Time: Mon Apr 30 17:12:15 2007 I don't see any plugin calls in there so I guess the answer is no From: To: Time: Mon Apr 30 17:52:23 2007 Interesting. I joined this room over the weekend with my jis and lj accounts because I couldn't connect with my mit account. Actually, I could connect, or so Adium made it appear, but the room was empty except for me. When I joined with the other accounts it was fine. But I signed off of the others; so why does it still show me as signed on with LJ? I can also send messages to my LJ account while I'm signed off, without any errors reported back, though it does show me as not signed on (or not visible). From: To: Time: Mon Apr 30 17:56:58 2007 huh From: To: Time: Mon Apr 30 17:57:54 2007 Anyways. Sorry about not being in for the meeting. I assumed it was off, with Sam not in. Sent mail with my status, and mixed reviews of Novell code. :) From: To: Time: Mon Apr 30 17:59:15 2007 The decision to have the meeting was spontaneous and we mostly just wanted to have notes for Sam and ask each other a few questions From: To: Time: Mon Apr 30 17:59:56 2007 but now I'm off to dinner From: To: Time: Tue May 1 08:01:27 2007 regarding the posting from coolyahama@gmail. he cc'd kerberos_users@fnal.gov. That means he is probably using a pre-1.2 MIT Kerberos library. Possibly as old as 1.0.x From: To: Time: Tue May 1 15:18:12 2007 Does anyone know of a reason why having "-" in a principal would cause you to randomly not get tickets? From: To: Time: Tue May 1 18:41:16 2007 sent Purify bug report re RTLD_GROUP to 3partysw From: To: Time: Tue May 1 19:06:38 2007 please review the patch I submitted to #5552. From: To: Time: Tue May 1 19:07:04 2007 lxs, what are the circumstances of the random lossage? From: To: Time: Tue May 1 19:07:56 2007 wait, does the failure in #5552 only arise if you use the extended API? From: To: Time: Tue May 1 19:09:19 2007 when you call krb5_get_init_creds_password() it in turn calls krb5int_gic_opt_to_opte() which will crash if options is NULL From: To: Time: Tue May 1 19:09:34 2007 oh great From: To: Time: Tue May 1 19:09:50 2007 I'm seriously concerned about the KFW 3.2 release if this patch doesn't get applied From: To: Time: Tue May 1 19:09:54 2007 do all of our test cases allocate options? From: To: Time: Tue May 1 19:10:02 2007 they must From: To: Time: Tue May 1 19:11:02 2007 I don't know much about the problem. I'm trying to get Apple to reproduce it. Apparently they worked around it in tiger without talking to us and then one of the engineers just asked me if it was fixed yet... From: To: Time: Tue May 1 19:11:02 2007 Do you plan on issuing another beta or just applying the patch? From: To: Time: Tue May 1 19:11:33 2007 actually, that patch isn't complete. krb5int_gic_opte_copy() will need to be patched as well From: To: Time: Tue May 1 19:11:39 2007 we can't fix bugs other people find if they don't tell us about them... From: To: Time: Tue May 1 19:11:41 2007 I do know that they have a lot of their own code involved so it may be their problem From: To: Time: Tue May 1 19:11:42 2007 for the case where 'force' is true From: To: Time: Tue May 1 19:12:07 2007 I pointed out that I had not known about the original issue From: To: Time: Tue May 1 19:12:09 2007 sam, I don't know yet. I'm not happy. I need to make sure I get this right From: To: Time: Tue May 1 19:12:40 2007 should we back out the gic_opt extensibility? i guess we've already released it, though. From: To: Time: Tue May 1 19:13:17 2007 my question was more "has anyone seen anything like this". If you haven't that's fine. I am trying to make the debugging their problem From: To: Time: Tue May 1 19:13:36 2007 randomly not get tickets by what interfaces in what programs? From: To: Time: Tue May 1 19:14:00 2007 If Jeff thinks it is safer, we could back out gic_opt extensibility on a branch for kfw 3.2. From: To: Time: Tue May 1 19:14:46 2007 I don't think it is safer to do that than have four experts review a trivial patch From: To: Time: Tue May 1 19:15:05 2007 this is their AD and OD bind-client-to-domain code so I am not sure From: To: Time: Tue May 1 19:15:18 2007 They didn't even know what the error code they had gotten back was. :-P From: To: Time: Tue May 1 19:16:31 2007 I will review the patch later today but am now in an iesg retreat. Others should feel free to review now and people should not block on me. It seems reasonably unlikely that people will not use gic_options of some kind. From: To: Time: Tue May 1 19:18:06 2007 the patch to gc_frm_kdc.c has been added to #5552. This modifies krb5int_gic_opte_copy() to use memset() instead of memcpy() when opt is NULL From: To: Time: Tue May 1 19:21:38 2007 i should suppress an urge to write something like (opt?memcpy:memset)(oe, opt, sizeof(*opt)) From: To: Time: Tue May 1 19:22:02 2007 yes you should ;) From: To: Time: Tue May 1 19:24:08 2007 lxs, the hyphen problem sounds vaguely familiar. like we may have spoken about it years ago From: To: Time: Tue May 1 19:27:06 2007 Your patch assumes that memset is a reasonable way to initialize the structure which is probably true in practice. But besides that looks OK for both patches From: To: Time: Tue May 1 19:27:35 2007 good point. let me check something From: To: Time: Tue May 1 19:28:06 2007 we have an alloc function. I will use that instead From: To: Time: Tue May 1 19:28:15 2007 if we want to start being strict about not using memset() to initialize structs containing things which are not integers, we have lots and lots of code to update. From: To: Time: Tue May 1 19:28:36 2007 yeah, but this is new code and if I am going to apply a patch, I should do it correctly From: To: Time: Tue May 1 19:29:54 2007 static const struct foo foo0; *foo_in = foo0; From: To: Time: Tue May 1 19:30:08 2007 I have no recollection of it but I might have forgotten From: To: Time: Tue May 1 19:32:13 2007 Jeff, your last patch is against gic_opt.c not gc_frm_kdc.c From: To: Time: Tue May 1 19:32:45 2007 and this is why I need reviewers :) From: To: Time: Tue May 1 19:36:26 2007 How about this instead? Index: gic_opt.c =================================================================== --- gic_opt.c (revision 19536) +++ gic_opt.c (working copy) @@ -206,7 +206,14 @@ oe = krb5int_gic_opte_alloc(context); if (NULL == oe) return ENOMEM; + + if (NULL == opt) { + *opte = krb5int_gic_opte_alloc(context); + return(*opte ? 0 : ENOMEM); + } + memcpy(oe, opt, sizeof(*opt)); + /* Fix these -- overwritten by the copy */ oe->flags |= ( KRB5_GET_INIT_CREDS_OPT_EXTENDED | KRB5_GET_INIT_CREDS_OPT_SHADOWED); From: To: Time: Tue May 1 19:38:29 2007 that patch allocates a true extended options structure complete with the private fields and does not improperly set the KRB5_GET_INIT_CREDS_OPT_SHADOWED flag From: To: Time: Tue May 1 19:39:01 2007 nope. that patch is wrong oo. From: To: Time: Tue May 1 19:39:02 2007 too From: To: Time: Tue May 1 19:39:58 2007 This is correct. Index: gic_opt.c =================================================================== --- gic_opt.c (revision 19536) +++ gic_opt.c (working copy) @@ -206,11 +206,13 @@ oe = krb5int_gic_opte_alloc(context); if (NULL == oe) return ENOMEM; - memcpy(oe, opt, sizeof(*opt)); - /* Fix these -- overwritten by the copy */ - oe->flags |= ( KRB5_GET_INIT_CREDS_OPT_EXTENDED | - KRB5_GET_INIT_CREDS_OPT_SHADOWED); - + + if (opt) { + memcpy(oe, opt, sizeof(*opt)); + /* Fix these -- overwritten by the copy */ + oe->flags |= ( KRB5_GET_INIT_CREDS_OPT_EXTENDED | + KRB5_GET_INIT_CREDS_OPT_SHADOWED); + } *opte = oe; return 0; } From: To: Time: Tue May 1 19:40:27 2007 we don't want to allocate the structure twice From: To: Time: Tue May 1 19:44:07 2007 but the SHADOWED flag must be set when we allocated the value internally because the app is not going to free it for us. From: To: Time: Tue May 1 19:45:44 2007 opt_alloc and opt_free were additions to the original get_init_creds API? From: To: Time: Tue May 1 19:46:32 2007 yeah. From: To: Time: Tue May 1 19:49:11 2007 Index: gic_opt.c =================================================================== --- gic_opt.c (revision 19536) +++ gic_opt.c (working copy) @@ -206,11 +206,20 @@ oe = krb5int_gic_opte_alloc(context); if (NULL == oe) return ENOMEM; - memcpy(oe, opt, sizeof(*opt)); - /* Fix these -- overwritten by the copy */ - oe->flags |= ( KRB5_GET_INIT_CREDS_OPT_EXTENDED | - KRB5_GET_INIT_CREDS_OPT_SHADOWED); + + if (opt) + memcpy(oe, opt, sizeof(*opt)); + /* Fix the flags -- the EXTENDED flag would have been + * overwritten by the copy if there was one. The + * SHADOWED flag is necessary to ensure that the + * krb5_gic_opt_ext structure that was allocated + * here will be freed by the library because the + * application is unaware of its existence. + */ + oe->flags |= (KRB5_GET_INIT_CREDS_OPT_EXTENDED | + KRB5_GET_INIT_CREDS_OPT_SHADOWED); + *opte = oe; return 0; } From: To: Time: Tue May 1 19:53:03 2007 is unconditionally setting OPT_SHADOWED correct? From: To: Time: Tue May 1 19:53:39 2007 From the comment earlier in the file: * If KRB5_GET_INIT_CREDS_OPT_SHADOWED is set after a call to * krb5int_gic_opt_to_opte(), the resulting extended structure should be * freed (using krb5_get_init_creds_free). Otherwise, the original * structure was already extended and there is no need to free it. From: To: Time: Tue May 1 19:54:00 2007 hmm. From: To: Time: Tue May 1 19:54:35 2007 that language is ambiguous and the term SHADOWED is vague From: To: Time: Tue May 1 19:55:17 2007 damn. there is no way I'm releasing KFW 3.2 final tomorrow From: To: Time: Tue May 1 19:55:58 2007 grep'ing the sources, there is nothing that checks if KRB5_GET_INIT_CREDS_OPT_SHADOWED is set From: To: Time: Tue May 1 19:56:12 2007 no but there's a macro which does From: To: Time: Tue May 1 19:57:27 2007 you even posted a patch to that macro From: To: Time: Tue May 1 19:57:33 2007 funny, they check if (opte && is_shadowed()) but not if (opt && is_extended()) From: To: Time: Tue May 1 19:57:38 2007 yes I did From: To: Time: Tue May 1 19:59:21 2007 So krb5_get_init_creds_password() and krb5_get_init_creds_keytab() will cleanup the allocation From: To: Time: Tue May 1 19:59:49 2007 are there any other functions to which a gic_opt structure will be passed as input that calls opt_to_opte()? From: To: Time: Tue May 1 20:00:38 2007 gic_opt.c gic_pwd.c gic_keytab.c From: To: Time: Tue May 1 20:01:06 2007 krb5_get_init_creds_opt_set_pa() calls it but only to extended it if necessary From: To: Time: Tue May 1 20:01:20 2007 same for krb5_get_init_creds_opt_get_pa() From: To: Time: Tue May 1 20:02:46 2007 and krb5int_populate_gic_opt() is ok From: To: Time: Tue May 1 20:04:22 2007 is there any reason for there to be two separate flags? From: To: Time: Tue May 1 20:06:09 2007 EXTENDED means it is an extended structure. SHADOWED or the lack of SHADOWED determines whether or not the structure was allocated by the application calling krb5_get_init_creds_opt_alloc() From: To: Time: Tue May 1 20:07:23 2007 I want to make sure though that anywhere inside the library that krb5_get_init_creds_opt_alloc() is called that krb5_get_init_creds_opt_free() is called as well From: To: Time: Tue May 1 20:07:25 2007 does the application ever allocate an extended structure on its own? From: To: Time: Tue May 1 20:08:23 2007 Under the rules for using the preauth extensions, the app is required to allocate the structure with krb5_get_init_creds_opt_alloc() which returns an EXTENDED structure even though it says it is returning an old style one. From: To: Time: Tue May 1 20:09:36 2007 I am concerned about krb5int_populate_gic_opt(). From: To: Time: Tue May 1 20:09:44 2007 but SHADOWED gets set internally by stuff in gic_opt.c too From: To: Time: Tue May 1 20:10:01 2007 SHADOWED should only be set internally From: To: Time: Tue May 1 20:10:54 2007 the way I am interpretting this code, SHADOWED means "internally allocated, must free me" From: To: Time: Tue May 1 20:12:16 2007 opt_free checks is_extended not is_shadowed From: To: Time: Tue May 1 20:13:56 2007 yes, but krb5_get_init_creds_password() and krb5_get_init_creds_keytab() check krb5_gic_opt_is_shadowed() and if true calls krb5_get_init_creds_opt_free(); From: To: Time: Tue May 1 20:17:57 2007 this code looks confusing because krb5_get_init_creds_opt_alloc() is often followed by krb5int_gic_opt_to_opte() but that is just to convert the types. From: To: Time: Tue May 1 20:22:23 2007 I'm testing my patch From: To: Time: Tue May 1 20:22:33 2007 the last one I posted here From: To: Time: Tue May 1 20:28:13 2007 I don't have any apps that don't pass in a gic_opt. I'm going to have to modify something. From: To: Time: Tue May 1 20:49:54 2007 this looks good From: To: Time: Tue May 1 20:51:48 2007 anyway only a minor nit ... the block comment style, but that's not too big a deal. From: To: Time: Tue May 1 20:52:07 2007 how would you prefer it? From: To: Time: Tue May 1 20:52:36 2007 first line has "/*" by itself. should be described in doc/coding-style. From: To: Time: Tue May 1 20:53:39 2007 nit fixed From: To: Time: Tue May 1 20:55:54 2007 anyway i'm going to get dinner. go ahead and check it in if you want. From: To: Time: Tue May 1 20:56:05 2007 will do From: To: Time: Tue May 1 21:32:00 2007 the patch has been committed From: To: Time: Tue May 1 21:32:08 2007 I have marked it for pullup. From: To: Time: Tue May 1 21:32:59 2007 I'm going to perform a bit more testing later. I will decide tomorrow whether a new beta or the final build should be released. I encourage others to review the committed change. From: To: Time: Tue May 1 21:38:08 2007 if we issue another beta 5551 should be pulled up From: To: Time: Wed May 2 08:42:42 2007 Also 5542, 5548 From: To: Time: Wed May 2 08:46:01 2007 why? From: To: Time: Wed May 2 08:46:22 2007 They are improvements. From: To: Time: Wed May 2 08:47:07 2007 they are changes to the build system and I'm not going to spend more time testing it. we are only fixing things that are going to cause actual problems for end users From: To: Time: Wed May 2 08:48:07 2007 5552 because of a crash and 5551 because it prevents acquisition of service tickets from Windows domain controllers when a configuration file does not specify an explicit domain to realm mapping From: To: Time: Wed May 2 16:22:15 2007 > 5551 because it prevents acquisition of service tickets This should have been "prevents acceptance of service tickets ..." From: To: Time: Wed May 2 16:24:30 2007 Ah, makes more sense. From: To: Time: Wed May 2 16:24:39 2007 What is your current thinking? From: To: Time: Wed May 2 16:26:12 2007 5552 has been tested by me with NULL input, old style input and new style input. It has been reviewed by Tom, Ken and Kevin Coffman. The patch was independently tested at NCSA. I think it is safe to release final with it. From: To: Time: Wed May 2 16:26:22 2007 I am not going to pullup 5551 From: To: Time: Wed May 2 16:26:52 2007 I've also reviewed the 5552 patch. That sounds like a fine approach From: To: Time: Wed May 2 16:26:52 2007 The only concern at the moment is the lack of copyright and license in gic_opt.c. From: To: Time: Wed May 2 16:28:04 2007 Don't worry about that. We shouldfix but it is not a show stopper. I can fall back on my email discussing license for all the pkinit work. From: To: Time: Wed May 2 16:28:19 2007 ok From: To: Time: Wed May 2 16:28:43 2007 When Tom comes in we will tag, build and announce. From: To: Time: Wed May 2 16:29:40 2007 For Tom: Please either create a directory in the krbdev locker if it has space or grab a copy of Jeff's build directory for archival From: To: Time: Wed May 2 17:07:54 2007 sorry, wasn't logged in earlier because Ken was talking with me before i got jabber running From: To: Time: Wed May 2 17:08:04 2007 which of Jeff's builds do i archive? From: To: Time: Wed May 2 17:08:23 2007 You can have them all From: To: Time: Wed May 2 17:08:37 2007 but I think Sam is concerned only about the final release build From: To: Time: Wed May 2 17:09:56 2007 the build tree is about 60MB when zipped From: To: Time: Wed May 2 17:11:29 2007 what tag are we going to use? "kfw-3_2_0-final" ? From: To: Time: Wed May 2 17:12:46 2007 oops. my test build didn't build the right things. From: To: Time: Wed May 2 17:24:30 2007 smoke test using Purify on kinit on the 1.6 branch succeeds. From: To: Time: Wed May 2 17:25:18 2007 tags/kfw-3_2_0-final .... not yet tagged though. From: To: Time: Wed May 2 17:27:33 2007 ok. I'm going to tag pismere From: To: Time: Wed May 2 17:27:49 2007 updating the build versions first of course From: To: Time: Wed May 2 17:31:45 2007 tagged From: To: Time: Wed May 2 17:34:22 2007 pismere tagged. building. From: To: Time: Wed May 2 18:15:04 2007 oops, alexp's new Purify install appears to have changed some defaults. From: To: Time: Thu May 3 16:38:48 2007 do we still need to provide copies of "extras" for kfw? From: To: Time: Thu May 3 16:42:03 2007 No. From: To: Time: Thu May 3 16:50:29 2007 Jeff, is it difficult to prevent "smartquotes" from being generated in your announcement text? From: To: Time: Sun May 6 02:02:17 2007 MIt Kerberos Development Team From: To: Time: Sun May 6 02:02:17 2007 raeburn has set the topic to: Kerberos From: To: Time: Wed May 9 13:13:36 2007 If we do end up having an Apple call, I will call in from home From: To: Time: Wed May 9 18:05:35 2007 Got more code from Novell. From: To: Time: Wed May 9 18:17:51 2007 Looks like it still has "issues". Like, still using a krb5_context in multiple threads. From: To: Time: Wed May 9 19:04:43 2007 the official workaround for the dlopen RTLD_GROUP problem in purify is the poorly-named "-allow-dlopen-rtld-group=no" option. sadly, that works by clearing the flag passed to dlopen. From: To: Time: Wed May 9 19:49:57 2007 oh great. newest purify coredumps in deltat.c. From: To: Time: Wed May 9 19:50:18 2007 Lovely. From: To: Time: Wed May 9 19:50:43 2007 it dealt with my testcase ok, but my testcase is nowhere near as hairy as bison output From: To: Time: Wed May 9 19:50:58 2007 Not much is. :) From: To: Time: Sun May 13 02:02:21 2007 MIt Kerberos Development Team From: To: Time: Sun May 13 02:02:21 2007 raeburn has set the topic to: Kerberos From: To: Time: Mon May 14 11:11:13 2007 FYI Nalin is here and in 212 (aquarium) and lunch will be at noon From: To: Time: Mon May 14 11:38:27 2007 and lunch has arrived early From: To: Time: Mon May 14 17:56:52 2007 oh, suck. i think i figured out the Apple gss cred issue. From: To: Time: Mon May 14 18:47:33 2007 hm, maybe i'm missing something, but the docs for Mach-O don't seem to say anything about the symbol table being hashed. From: To: Time: Mon May 14 19:13:05 2007 and if there's no hashing of the symbol table, no wonder it sucks. From: To: Time: Wed May 16 11:46:11 2007 What do we want our xen server to be called? From: To: Time: Wed May 16 11:48:15 2007 SIPB's comment on the matter when I complained that we didn't really have a hostname scheme was that since we'd named our product after one of the traps in Harry Potter 1, we could go on with that theme. Passed along mostly only for amusement value From: To: Time: Wed May 16 13:15:33 2007 the Apple conference call meeting appears to be on the wrong day. looks like it should be on the 23rd From: To: Time: Wed May 16 13:15:48 2007 (in techtime) From: To: Time: Thu May 17 09:44:14 2007 WRT naming: as mentioned in person: Slavic gods & mythology. From: To: Time: Sun May 20 02:02:20 2007 MIt Kerberos Development Team From: To: Time: Sun May 20 02:02:20 2007 raeburn has set the topic to: Kerberos From: To: Time: Mon May 21 11:07:05 2007 Windows uses CRLF for line breaks in text files, right? So you get CRLF in the file when you write '\n' to a file? What happens if you write "\r\n" to a text file? From: To: Time: Mon May 21 11:07:55 2007 (We have an email report suggesting that config file parse errors should include the line number. But we do weird things with \r and \n when reading, and it looks like we output \r\n in text mode on Windows.) From: To: Time: Mon May 21 11:10:52 2007 In text mode \n gets you \r\n written. I'm not sure what writing \r\n would do From: To: Time: Mon May 21 11:10:54 2007 BTW, don't forget the IS&T Infinite Mile Award Celebration lunch today on the W91 lawn. Our team was one of the winners last year, so it'd be nice to show up and offer support for this year's winners. (And I was drafted for the nomination review committee, so I really ought to go anyways. :-) From: To: Time: Mon May 21 11:41:24 2007 So if we get \r\r\n in the file, and read it back as \r and then \n because we're in text mode, then the line number tracking would have to accept \r or \n or \r\n as a line-ending sequence. Ick. Currently the code just looks for \r and replaces it by \n before (re)scanning for line breaks, so adding line number tracking isn't totally trivial, at least if we want it to work right on Windows. From: To: Time: Mon May 21 12:18:12 2007 I've installed the new sendmail.cf on krbdev, finally. So various spam messages should be rejected at SMTP time like so: ----- The following addresses had permanent fatal errors ----- rt@krbdev.mit.edu (reason: 550 5.0.0 RT feed requires ticket indication in subject line) From: To: Time: Mon May 21 12:20:31 2007 It applies to mail to rt, rt-comment, rt-kfw, rt-kfw-comment, including messages addressed to those recipients and other recipients on the machine at the same time. Of course, there shouldn't *be* any messages addressed that way. From: To: Time: Mon May 21 13:49:41 2007 Oh, hm. The sendmail.cf hack may not cope properly with a base64-encoded subject line. Though I'm inclined to say, "so what?" From: To: Time: Mon May 21 14:28:51 2007 so out of curiosity, can we finagle enough names out of Through the Looking Glass? From: To: Time: Mon May 21 14:30:02 2007 i guess ESG used to have some Jabberwocky names, though. From: To: Time: Mon May 21 14:41:18 2007 hm. schlage is already taken, but medeco, chubb, bramah, ... are not From: To: Time: Mon May 21 16:56:46 2007 So far the new sendmail.cf seems to be performing as expected. Going to leave it in tonight I guess. From: To: Time: Tue May 22 16:25:48 2007 oops. there's one address that shouldn't be on the magic sendmail.cf list because it's the kfw mail front end From: To: Time: Tue May 22 16:37:53 2007 tweaking sendmail. there may be a disturbance in the Force. From: To: Time: Tue May 22 17:43:09 2007 oops. From: To: Time: Tue May 22 17:45:20 2007 if that address gets advertised in outgoing we might want to change it eventually. From: To: Time: Tue May 22 17:47:39 2007 hm. if i click on one of the "find new/open tickets" links in rt, is there supposed to be a sort order imposed? i can't discern one in this report. From: To: Time: Wed May 23 10:10:42 2007 Sam, any reason I shouldn't tell the guy wanting to port libkadm5 to Windows to go ahead with it? I assume we may want to either review the exported API or make it a static library on Windows until we're ready to consider committing to an ABI, but otherwise, I think we should encourage him... From: To: Time: Wed May 23 10:18:49 2007 Telling him to go for it is fine, although you should point out that unless he works reasonably closely with us we are unlikely to accept the patches. From: To: Time: Wed May 23 10:19:31 2007 Okay. From: To: Time: Wed May 23 10:21:02 2007 As an example, deciding how to deal with symbols that are not exported from krb5_32 will be tricky. As will other posixisms From: To: Time: Wed May 23 13:36:24 2007 Reserving a room for the Apple conference call is becoming a waste of time ;-) From: To: Time: Wed May 23 13:37:06 2007 "this conference call pre-cancelled for your convenience" From: To: Time: Wed May 23 13:37:59 2007 I definitely think coming in for the conference call was a mistake on my part. From: To: Time: Thu May 24 14:44:54 2007 Where is the 3PM meeting? From: To: Time: Thu May 24 14:45:22 2007 looks like Downtown Crossing From: To: Time: Thu May 24 14:45:32 2007 225 I think From: To: Time: Fri May 25 14:56:14 2007 how annoying. the wince.mit.edu pages are failing. From: To: Time: Fri May 25 15:39:18 2007 oh look there's Tim Alsop again From: To: Time: Fri May 25 17:17:12 2007 hm, Parallels seems to have some issues with switching from X back to NetBSD wscons From: To: Time: Fri May 25 18:12:39 2007 or maybe it's actually xf86 being bogus From: To: Time: Sun May 27 02:02:21 2007 MIt Kerberos Development Team From: To: Time: Sun May 27 02:02:22 2007 raeburn has set the topic to: Kerberos From: To: Time: Tue May 29 10:54:52 2007 Why is it that today my VMs can't log into my domain, even though the domain controller is running? From: To: Time: Tue May 29 16:49:51 2007 yeah, looks very similar to the xf86 text palette restoration bug i saw before. From: To: Time: Wed May 30 14:51:56 2007 [raeburn@mit.edu has set the topic to: Κέρβερος] From: To: Time: Wed May 30 14:58:53 2007 Ow, that renders poorly in barnowl. From: To: Time: Wed May 30 14:59:43 2007 Sorry... is it barnowl or xterm? From: To: Time: Wed May 30 15:00:55 2007 It is certainly barnowl, it may be other things too. Not to say I don't like the subject. From: To: Time: Wed May 30 15:03:07 2007 I wonder if I can get the IDNA version of that as a hostname on campus. I could just do it in my own domain, actually. But it'd be less easy to mess with people that way. From: To: Time: Wed May 30 17:04:41 2007 Garry gives us krbdev-xen From: To: Time: Wed May 30 17:05:06 2007 as in it's set up now? From: To: Time: Wed May 30 17:05:47 2007 Yes. so, I guess we need to choose an OS image for krbdev. From: To: Time: Wed May 30 17:11:38 2007 what are your preferences? From: To: Time: Wed May 30 17:12:29 2007 Well, I could most easily give you a system with working apache, postgres etc using Debian or Ubuntu. But it's not sure my preferences matter that much. From: To: Time: Wed May 30 17:13:32 2007 also how soon do we want to move the RT server onto the xen machine? From: To: Time: Wed May 30 17:13:55 2007 I think by end of June we want to get rid of opteron-prime and krbdev From: To: Time: Wed May 30 17:15:58 2007 also what subnet is the xen machine on? From: To: Time: Wed May 30 17:16:20 2007 A different one. w91 From: To: Time: Wed May 30 17:16:48 2007 that could make migration interesting From: To: Time: Wed May 30 17:17:03 2007 We have an outage or something. From: To: Time: Wed May 30 17:21:07 2007 what are the procedures for accessing the xen host remotely? From: To: Time: Wed May 30 17:22:46 2007 It will have an ip address. you ssh to it. From: To: Time: Wed May 30 17:27:03 2007 kerberized ssh presumably? From: To: Time: Wed May 30 17:30:38 2007 Yes, presumably we would choose to install kerberized ssh on a domain. From: To: Time: Wed May 30 17:39:07 2007 are there significant differences in package availability for debian vs ubuntu? From: To: Time: Wed May 30 17:40:16 2007 Not that we care about. From: To: Time: Wed May 30 17:52:07 2007 Does this barnowl instance for jabber thing really work? From: To: Time: Wed May 30 17:52:39 2007 That would be a no. Of course I'm not sure I'm running that code From: To: Time: Wed May 30 17:55:04 2007 Did you use -i or -s, you want -s. From: To: Time: Wed May 30 17:55:24 2007 Trying with the right option From: To: Time: Wed May 30 17:55:46 2007 I used -t it works with -s From: To: Time: Wed May 30 18:00:38 2007 -t appears to have set the Thread: header. From: To: Time: Wed May 30 18:01:17 2007 of course it's not like Adium shows me this stuff From: To: Time: Wed May 30 18:13:03 2007 I would like to make a decision on OS reasonably soon. My requirements as manager are that we be able to deploy reasonably quickly and that the OS we choose have a good way of handling security support for the OS and any OS packages we use From: To: Time: Wed May 30 18:18:58 2007 Unless Tom wants to make an argument for Solaris, I'd suggest just going with either RH/Athena (if we want to get a real Athena environment, Hesiod, Zephyr, blah blah, as maintained by Greg et al, instead of approximating it with random packages) or Debian. From: To: Time: Wed May 30 18:19:18 2007 i think mostly my requirements for the RT server are recent apache2, mod_fastcgi, postgres, and perl From: To: Time: Wed May 30 18:20:22 2007 i don't know if we want an approximation of an Athena environment unless AFS or Zephyr help us significantly. actually i think we currently use AFS to hold some RT pages but we don't have to do that necessarily. From: To: Time: Wed May 30 18:20:35 2007 Keep in mind that rh-athena is likely somewhat of a dead end. From: To: Time: Wed May 30 18:21:08 2007 I suspect there will be an upgrade to some version of SUSE or RHEL From: To: Time: Wed May 30 18:30:07 2007 does Ubuntu have significant advantages over plain Debian? From: To: Time: Wed May 30 18:32:46 2007 Not in my incredibly biased opinion for this application. From: To: Time: Wed May 30 18:34:31 2007 It has what many people believe as a better experience for installs on desktops and what many believe is better laptop support. From: To: Time: Wed May 30 18:42:30 2007 does it have a "live" CD? would that be one reason people like it for desktops? From: To: Time: Wed May 30 18:44:43 2007 It certainly has a live CD. From: To: Time: Wed May 30 18:57:32 2007 if the marginal utility of Ubuntu isn't large enough to outweigh the risks that its "friendliness" may get in the way, i'd say go with Debian. From: To: Time: Wed May 30 21:54:13 2007 I think having AFS and Zephyr would be good. Not critical, but possibly useful. AFS should be easy on any of the OS options; Zephyr I think would be (slightly) more of a reason to go with an Athena install. But it's still not *that* hard to do ourselves or via random packages. From: To: Time: Thu May 31 17:10:08 2007 why does krbdev-rt-new think its hostname is krbdev? From: To: Time: Thu May 31 17:11:03 2007 I told it that. Presumably it will eventually become true. If that's inconvenient, change /etc/hostname and either reboot or run hostname From: To: Time: Thu May 31 17:14:37 2007 BTw, Steve and I had a very positive meeting with Intel today. From: To: Time: Thu May 31 17:14:43 2007 cool From: To: Time: Thu May 31 17:16:04 2007 anyway is it a good idea to have the kerberos.org page live with "lorem ipsum" still visible in places? From: To: Time: Thu May 31 17:17:02 2007 Well, I don't know. Arguably since the uri is not public it's not a huge deal for a day or so. Alternatively I could take away the a record From: To: Time: Thu May 31 17:17:27 2007 Does anyone here have an opinion on blog software or should I go ask on -c sipb -i scripts? From: To: Time: Thu May 31 17:17:56 2007 no strong opinions. do people still tend towards typepad? From: To: Time: Thu May 31 17:18:03 2007 Already gave you my lack of opinion.... From: To: Time: Thu May 31 17:18:49 2007 M-x html From: To: Time: Thu May 31 17:18:51 2007 -mode From: To: Time: Thu May 31 17:19:28 2007 That doesn't support comments or rss so well From: To: Time: Thu May 31 17:20:31 2007 also are we running the blog on a separate VM from the RT server? From: To: Time: Thu May 31 17:23:07 2007 Yes. kerberos-consortium-www.mit.edu is a different vm. From: To: Time: Thu May 31 17:23:31 2007 also, krbdev-rt-new now has working keytab From: To: Time: Thu May 31 17:23:57 2007 oddly enough, get_srvtab fails to work if you're using a secureid-based principal From: To: Time: Thu May 31 17:25:47 2007 I plan to run the blogs and the website on the same vm, but not combine that with rt From: To: Time: Thu May 31 17:26:01 2007 ah ok From: To: Time: Thu May 31 17:36:37 2007 CCAPI sources should now be checked into the krb5 trunk if anyone wants to look at them. The locking support isn't done but the sources do compile and sort of work on the Mac. :-) From: To: Time: Thu May 31 17:37:27 2007 I think Kevin has already started to look briefly. Although he's now off fighting the good fight against Vista From: To: Time: Thu May 31 18:15:26 2007 does a Xen VMX guest see something VGA-like which actually is a VNC server? From: To: Time: Thu May 31 18:19:25 2007 My "mission" to unify our configure.in scripts continues: We now have one at the top level, one for the db2 library, and four in the appl/ tree. That's three fewer times to run autoconf than yesterday. From: To: Time: Thu May 31 18:20:31 2007 I'm resisting the urge to tackle the ones in the appl tree (and make just one for that subtree), though there's a bunch of common stuff shared between them... From: To: Time: Thu May 31 18:20:38 2007 I don't think I have that enabled. I think currently we have text console. But yes you can set that up From: To: Time: Thu May 31 18:21:03 2007 i think we want to keep the appl/ tree separate so we can jettison more readily From: To: Time: Thu May 31 18:21:27 2007 Sam, mostly asking for usefulness in setting up my new desktop when it gets here From: To: Time: Thu May 31 18:21:46 2007 Yes. But if that's going to take a while, reducing four appl/*/configure.in scripts to one appl/configure.in script would save a few autoconf cycles too. From: To: Time: Thu May 31 18:21:50 2007 If you log into krbdev-xen.mit.edu and do xm console krbdev or xm console kerberos-consortium-www you get the console From: To: Time: Thu May 31 18:29:51 2007 hm, when did GovConnection switch to DHL for ground service? From: To: Time: Thu May 31 18:32:50 2007 What did they ship via DHL? From: To: Time: Thu May 31 18:35:48 2007 a hard disk. they used to use UPS for ground shipping From: To: Time: Thu May 31 18:52:34 2007 anyone else finding the kerberos.org stylesheet makes body text too small? From: To: Time: Thu May 31 18:53:36 2007 The front page looks okay to me in Safari. From: To: Time: Thu May 31 18:54:19 2007 A little small, but tolerable. From: To: Time: Thu May 31 18:54:50 2007 in Solaris firefox for me it looks damn near unreadably small. Safari is only slightly better. From: To: Time: Thu May 31 18:56:40 2007 Feel free to send Steve comments From: To: Time: Thu May 31 18:59:35 2007 I don't read css, but some things like "font-size: 70%" make me guess that it is configured to display certain stuff somewhat smaller than the user's default font size? Which would be rude. From: To: Time: Thu May 31 19:00:01 2007 yeah, body text should be displayed at the user's preferred size unless there's a really good reason not to. From: To: Time: Thu May 31 19:02:09 2007 I really believe that for the random Latin text he should use classic alphabet (no w, u and v interchangible) From: To: Time: Thu May 31 19:02:42 2007 heh. all capitals too? From: To: Time: Thu May 31 19:03:23 2007 though i think it's typical to set lorem ipsum text using modern spellings, i.e. distinct u, v. From: To: Time: Thu May 31 19:04:05 2007 For the Kerberos pages, he *should've* done it in Greek, not Latin. From: To: Time: Thu May 31 19:04:35 2007 Yeah. but classic Latin would be more acceptable:-) From: To: Time: Thu May 31 19:28:58 2007 anyway netops has apparently tweaked the kadmin acls to allow get_srvtab type operations using krb5. From: To: Time: Fri Jun 1 13:18:10 2007 it turns out that there's quite the controversy about font sizes of web pages. great. From: To: Time: Fri Jun 1 13:19:35 2007 i hate the web. From: To: Time: Fri Jun 1 14:57:26 2007 anyway i'm really unimpressed with the designer's response From: To: Time: Fri Jun 1 15:29:04 2007 So how does one submit an expense report at MIT? From: To: Time: Sun Jun 3 02:02:17 2007 MIt Kerberos Development Team From: To: Time: Sun Jun 3 02:02:18 2007 hartmans@jis.mit.edu/owl has set the topic to: test From: To: Time: Sun Jun 3 21:47:26 2007 The best candidate I found in the krb5 sources for converting an error code to a string is khm_krb5_get_error_string in krb5\src\windows\identity\plugins\common. It includes krb5.h (from krb5/src/include), which just includes krb5/krb5.h. But there isn't any other krb5.h. Shouldn't krb5/src/include/krb5.h include krb5/krb5.hin instead of krb5/krb5.h? From: To: Time: Sun Jun 3 21:48:55 2007 That is, khm_krb5_get_error_string is in \src\windows\identity\plugins\common\krb5common.h. Then krb5common.h includes krb5.h. From: To: Time: Sun Jun 3 22:55:52 2007 1) To convert an error code to a string you may well want to be calling error_message unless you are writing nim-specific code. 2) No, krb5.h should not include krb5.hin From: To: Time: Sun Jun 3 22:59:17 2007 Take a look at the makefiles in the include directory From: To: Time: Mon Jun 4 09:09:06 2007 What security updates have been made to Kerberos in the last 4 years? [This is for background info to be supplied when MIT KfW 3.2 is released] From: To: Time: Mon Jun 4 09:12:42 2007 The website has all our security advisories. However you'll need to go through them and understand which ones apply to kfw. I think it would be a great learning experience (read kind of hard but you'll get a lot out of it) if you made a first cut at deciding which advisories are and are not related to kfw. For each decision, give a reason. If you need it sooner than this process would allow, run through the list with Tom, Ken or I. From: To: Time: Mon Jun 4 09:15:23 2007 I agree that the path you suggested is the right path. However, I do need the info this morning for an email to business process owners. From: To: Time: Mon Jun 4 09:23:46 2007 OK. Nothing in 2007 applies. MITKRB5-SA-2006-003 kadmind (via GSS-API mechglue) frees uninitialized pointers Note that while kfw does not include kadmind, I think that we may have changed the mech glue to be more correct. Actually, no wait, KFW is old enough that it did not have the mech glue, so it was not effected From: To: Time: Mon Jun 4 09:26:09 2007 MITKRB5-SA-2005-003 double-free in krb5_recvauth Probably MITKRB5-SA-2004-003 ASN.1 decoder denial-of-service Possibly MITKRB5-SA-2004-002 Double-free vulnerabilities in KDC and libraries MITKRB5-SA-2004-001 May involve code that KFW ships but I bet no one using KFW ever calls that code From: To: Time: Mon Jun 4 09:29:13 2007 MITKRB5-SA-2003-005: Buffer overrun and underrun in principal name handling MITKRB5-SA-2003-004: Cryptographic weaknesses in Kerberos v4 protocol; KDC and realm compromise possible. From: To: Time: Mon Jun 4 09:29:59 2007 This is great. Don't go back before KfW 2.6.5. From: To: Time: Mon Jun 4 09:30:30 2007 OK. I don't know when that was released. I think I'm done. From: To: Time: Mon Jun 4 09:31:00 2007 Thanks. From: To: Time: Mon Jun 4 09:35:07 2007 Please note that none of those are particularly serious as KFW is used at MIT From: To: Time: Mon Jun 4 13:13:37 2007 kfw 3.2 is based on the krb5-1.6 branch and thus has all security patches applied to the 1.6 branch From: To: Time: Mon Jun 4 13:16:04 2007 Tom, understood. The question is more which advisories actually touch code that gets built on kfw From: To: Time: Mon Jun 4 13:16:43 2007 this is for some release-notes type document? From: To: Time: Mon Jun 4 13:17:28 2007 Yes. From: To: Time: Mon Jun 4 13:17:35 2007 Close. Some 'why you want this' comments in a note to MIT application owners. From: To: Time: Tue Jun 5 13:50:50 2007 I'm back from my eye doctor appointment but I now have another one for tomorrow :-P From: To: Time: Tue Jun 5 16:44:04 2007 ok, apparently the machine-readable privacy policy stuff is called "P3P" From: To: Time: Tue Jun 5 19:00:21 2007 do we prefer development policy/procedure documentation to be in the source tree or on web pages? From: To: Time: Tue Jun 5 19:04:19 2007 I think something in /doc, with a pointer or copy on the web, is best. Lets people review them when offline, and is easy for online browsing for people without checked-out trees already... From: To: Time: Tue Jun 5 19:05:38 2007 hm, linking to it would involve linking to the cvsweb stuff on opteron-prime From: To: Time: Tue Jun 5 19:06:46 2007 Yup. From: To: Time: Tue Jun 5 19:07:10 2007 just checked to make sure that leaving off "?rev=.." works; it does. From: To: Time: Wed Jun 6 09:38:04 2007 What happened to krb5/src/include/autoconf.h? It's in an old checkout of the repository but not in a new checkout. The new CCAPI code needs it. From: To: Time: Wed Jun 6 09:38:53 2007 It's built. It has never been in the repository. From: To: Time: Wed Jun 6 09:40:19 2007 Then how did it find its way into an out of date checkout area on my PC? Where is it / who will add it to the repository? From: To: Time: Wed Jun 6 12:23:25 2007 Bets on whether there is a conference call today? From: To: Time: Wed Jun 6 12:24:25 2007 10 to 1 no call From: To: Time: Wed Jun 6 16:15:42 2007 so did I miss a conference call? ;-) From: To: Time: Wed Jun 6 16:17:08 2007 If so, I did too From: To: Time: Wed Jun 6 18:20:27 2007 are we the "MIT Kerberos Development Team" or the "MIT Kerberos Team"? i've shifted towards using the latter... From: To: Time: Wed Jun 6 18:26:03 2007 Dunno, I'd lean a little towards the former, since we have nothing to do with maintaining or administration of the deployment here. But, eh... From: To: Time: Wed Jun 6 18:26:25 2007 having a shorter name is useful From: To: Time: Wed Jun 6 18:27:27 2007 True. From: To: Time: Wed Jun 6 19:26:56 2007 and our pages still rank way up there for searches on the myths of firewalls From: To: Time: Fri Jun 8 17:35:25 2007 oh great From: To: Time: Fri Jun 8 17:35:30 2007 thor is trashing us on bugtraq From: To: Time: Fri Jun 8 18:25:51 2007 is he? i'm having trouble finding it in the archives. maybe it's too recent... From: To: Time: Fri Jun 8 18:26:21 2007 yeah it's on a thread about krb5-related vulnerabilities in sudo; basically sudo does one of the obvious Wrong Things. From: To: Time: Fri Jun 8 18:26:58 2007 And it's our fault? From: To: Time: Fri Jun 8 18:27:27 2007 only very indirectly, but he's advocating breaking things so they won't link with our code at all, ever. From: To: Time: Fri Jun 8 18:28:10 2007 of course, i don't know how many people actually take his opinions seriously, but i do note that our code was kicked out of OpenBSD and NetBSD many years ago on the basis of such FUD. From: To: Time: Fri Jun 8 18:40:09 2007 You going to reply? I've started writing a little text, if not... From: To: Time: Fri Jun 8 18:40:43 2007 i'd suggest not replying without first circulating a draft. could be politically touchy. From: To: Time: Fri Jun 8 18:43:03 2007 Hm, yeah, and I'm sorely tempted to reply along the lines of "yeah, that's why we've been telling people for years not to do it that way", perhaps not the most polite response. From: To: Time: Fri Jun 8 18:45:49 2007 He's also factually wrong on a few minor points. From: To: Time: Fri Jun 8 18:45:56 2007 not surprising From: To: Time: Fri Jun 8 18:47:13 2007 mail forwarded to krbcore From: To: Time: Fri Jun 8 19:03:23 2007 Unfortunately, our the state of our documentation makes it a bit harder to argue our case. Are we actually telling people in all the right places that they should use init_secure_context under such-and-such conditions, like in our tutorials on Kerberizing application services, our web/pdf/man documentation of krb5_init_context, etc? From: To: Time: Fri Jun 8 19:03:35 2007 (What *is* the state of our new documentation, anyways?) From: To: Time: Fri Jun 8 19:30:24 2007 It's a bit disappointing, but I've seen other cases where people write code or build packages so as to go out of their way to use Heimdal despite MIT code being installed with the base system. I think the last case I looked at was in MacPorts -- some package included a patch to explicitly use Heimdal, when the upstream package supported MIT Kerberos already. From: To: Time: Sun Jun 10 02:02:21 2007 MIt Kerberos Development Team From: To: Time: Sun Jun 10 02:02:21 2007 hartmans@jis.mit.edu/owl has set the topic to: test From: To: Time: Mon Jun 11 13:18:36 2007 Hello from WWDC. From: To: Time: Mon Jun 11 13:19:28 2007 Hi. From: To: Time: Mon Jun 11 15:05:51 2007 are we meeting today? From: To: Time: Mon Jun 11 15:07:11 2007 If it just the two of us, I don't see the need. Is anybody who's not present in IM physically here? From: To: Time: Mon Jun 11 15:13:40 2007 Ken might show up, but i guess he's not on Jabber either From: To: Time: Mon Jun 11 15:20:59 2007 also Steve doesn't listen here but i don't think he regularly attends anyway. From: To: Time: Mon Jun 11 15:59:24 2007 oops. i was confusing Thor for Theo, but they've both been known to be highly vocal and opinionated, i think. From: To: Time: Mon Jun 11 17:25:04 2007 looks like this might be a very old bug in walk_realm_tree From: To: Time: Mon Jun 11 17:34:00 2007 Not surprising. It's not like we seriously test the cross-realm stuff. From: To: Time: Mon Jun 11 17:34:24 2007 basically the string consisting of a single period character has its pointer overwritten and therefore leaks From: To: Time: Mon Jun 11 17:34:39 2007 BTW, I'm writing up a reply to bugtraq using Sam's suggestions. Anyone want to review the "final" text before I send it off? From: To: Time: Mon Jun 11 17:42:57 2007 sure, i'll take a look at your text From: To: Time: Mon Jun 11 17:47:07 2007 Hm. I can't get mail to save a nice text format. /mit/raeburn/bt/response.txt has the text, but the quotation markers are missing. response.rtf and response.html have what i got by copying into TextEdit. This is annoying.... From: To: Time: Mon Jun 11 17:48:17 2007 (In the .txt file, the long unwrapped lines are my response, it looks like, and Thor's text is wrapped.) From: To: Time: Mon Jun 11 17:49:28 2007 also note that "Zanarotti attack" is a very local reference. From: To: Time: Mon Jun 11 17:49:45 2007 I've selected the use of plain text for responses, but it looks like Apple Mail uses html or rtf until you actually send it. From: To: Time: Mon Jun 11 17:50:06 2007 I thought it'd gotten some outside exposure. From: To: Time: Mon Jun 11 17:54:48 2007 Should I use "...Zanarotti attack in some circles" or just drop the reference? From: To: Time: Mon Jun 11 17:55:20 2007 I've personally attempted to *give* it outside exposure over the years. From: To: Time: Mon Jun 11 17:55:45 2007 usually every time someone screws up another screensaver From: To: Time: Mon Jun 11 17:57:02 2007 Drop it completely From: To: Time: Mon Jun 11 17:57:09 2007 It does not add clarity. From: To: Time: Mon Jun 11 17:57:15 2007 Okay. From: To: Time: Mon Jun 11 17:58:08 2007 Dropped. Any other issues? From: To: Time: Mon Jun 11 18:02:30 2007 Oh, I forgot to add something about the saved set-user-ID bit Russ mentioned. From: To: Time: Mon Jun 11 18:03:28 2007 Revised paragraph: It might be a useful enhancement to have krb5_init_context create a "secure" context when invoked with uid!=euid (and likewise check for setgid, oh and check saved set-user-ID too).  But I think it would be sloppy to rely on that for security. From: To: Time: Mon Jun 11 18:06:06 2007 would you rewrite the sed substitution? it seems excessively informal. From: To: Time: Mon Jun 11 18:07:27 2007 How about 'Change "..." to "...".' instead? Or more complete rewriting? From: To: Time: Mon Jun 11 18:08:00 2007 Just reply with the altered text, "Anyone using... written by someone..." ? From: To: Time: Mon Jun 11 18:08:45 2007 i'm not sure the altered text stands alone as well, and the "change ..." doesn't work terribly well either. From: To: Time: Mon Jun 11 18:09:07 2007 I'm not sure I'd like to suggest "should be very, very afraid" myself, but suggesting altering the conditions on his concern seems more harmless. From: To: Time: Mon Jun 11 18:11:04 2007 How about: Any using MIT krb5 with any application written by someone...etc... should be concerned. Especially with the current state of our documentation (which is already being addressed), it's not hard to make mistakes if you don't know what you're doing. From: To: Time: Mon Jun 11 18:11:43 2007 admitting to the poor quality of our documentation invites additional attack From: To: Time: Mon Jun 11 18:12:32 2007 Yeah. Okay -- drop the doc clause, make the sentence "It's not hard..." ? From: To: Time: Mon Jun 11 18:13:03 2007 "Anyone using MIT krb5 with any application written by someone not sufficiently familiar with Kerberos or the APIs should be concerned. It's not hard to make mistakes if you don't know what you're doing." From: To: Time: Mon Jun 11 18:13:11 2007 sure From: To: Time: Mon Jun 11 18:13:53 2007 Anything else? Sam, anyone? From: To: Time: Mon Jun 11 18:14:14 2007 I'd drop that paragraph From: To: Time: Mon Jun 11 18:14:32 2007 Why do you want to insult your audience by claiming they don't know what they are doing? Even if it is true From: To: Time: Mon Jun 11 18:15:08 2007 Hm, true. After Thor's attitude, it's tempting to insult him, but still... :-) Okay, dropping it... From: To: Time: Mon Jun 11 18:15:16 2007 we're already indicated we think the bug is in sudo, not krb5 From: To: Time: Mon Jun 11 18:16:23 2007 Yes. That's different though. We acknowledge all software has bugs. Instead I'd suggest that people interested in getting their use of kerberos reviewed send mail to kerberos@mit.edu From: To: Time: Mon Jun 11 18:17:09 2007 also we should suggest that complaining at bugtraq and not mentioning it more directly to us is less then helpful From: To: Time: Mon Jun 11 18:17:43 2007 Rather than less than helpful, mention that had people contacted us before posting on bugtraq we would have been happy to give advice. From: To: Time: Mon Jun 11 18:18:52 2007 In reply to an earlier paragraph ("make sudo no longer work with mit krb5, accident waiting to happen"), I already have "You might consider talking with the MIT Kerberos team about the issue." I could expand on that. From: To: Time: Mon Jun 11 18:20:14 2007 Hm, maybe that's the wrong place. From: To: Time: Mon Jun 11 18:22:01 2007 I could add at the very end: People concerned about proper use of Kerberos in applications are welcome to send mail to the kerberos@mit.edu list for discussion; we'd be glad to help, and there are a lot of people besides the MIT team on the list. From: To: Time: Mon Jun 11 18:23:16 2007 (New response.txt saved.) From: To: Time: Mon Jun 11 18:26:22 2007 it does point out the necessity of emphasizing the assumptions our library makes about the caller's execution environment... From: To: Time: Mon Jun 11 18:29:20 2007 Yup. If and when we get revised API docs, we should add something about that. Weren't we supposed to have them already? From: To: Time: Mon Jun 11 18:32:17 2007 Sadly, that project seems to be failing. From: To: Time: Mon Jun 11 18:32:59 2007 *sigh* I'm going to pull out my elisp code again, then. From: To: Time: Mon Jun 11 18:33:11 2007 elisp for what? From: To: Time: Mon Jun 11 18:33:51 2007 Provided that you can do that without getting behind on other things on your plate, excellent!~ From: To: Time: Mon Jun 11 18:34:51 2007 Sucking down the HTML pages from HP, parsing the HTML into a Lisp structure, doing pattern matching on the Lisp structure to extract the "interesting" text. What's left to be done includes converting the HTML markup of that text into the right doxygen markup, especially since there are tables IIRC, and then massaging krb5.hin. From: To: Time: Mon Jun 11 18:35:35 2007 so does doxygen still not deal with omitted identifiers in prototypes? From: To: Time: Mon Jun 11 18:35:38 2007 (The part already done is based largely on the hacks I did to process the mailman moderation pages in elisp. E.g., "approve all the messages to kerberos@mit that came through the NRL news->mail relay".) From: To: Time: Mon Jun 11 18:36:43 2007 Correct. We need to add identifiers to all the prototypes From: To: Time: Mon Jun 11 18:37:04 2007 AFAIK, yeah, that'd be part of the work remaining. Though unless doxygen has significant ways of describing how to rearrange doc sections, we're probably also looking at a significant rearrangement of krb5.hin to put the functions in desired doc order, etc. From: To: Time: Mon Jun 11 18:39:06 2007 i still think having identifiers in prototypes in a public header is not robust From: To: Time: Mon Jun 11 18:40:23 2007 Agreed. But, well, that's doxygen. I think with docbook we could avoid it, but mostly because we'd be writing the function decl in C and in docbook separately and manually keeping them in sync. From: To: Time: Mon Jun 11 18:40:58 2007 it would be ok if doxygen could read specially formatted comments which are in the place of identifiers in prototypes From: To: Time: Mon Jun 11 18:41:08 2007 I wonder, if doxygen does any preprocessing equivalent, such that we could make names show up for doxygen but not for C... From: To: Time: Mon Jun 11 18:41:40 2007 We are not reopening these decisions. From: To: Time: Mon Jun 11 18:41:46 2007 Popping back a topic, though, any more comments on my text before I send it to bugtraq? From: To: Time: Mon Jun 11 18:42:26 2007 will Mail.app format the quoting correctly in plain text? From: To: Time: Mon Jun 11 18:43:04 2007 Yes, I believe it uses "> " for indentation. From: To: Time: Mon Jun 11 18:43:08 2007 ok From: To: Time: Mon Jun 11 18:43:48 2007 Just confirmed, looking at an earlier message... From: To: Time: Mon Jun 11 18:45:34 2007 (I wonder if anyone's looked to see if Heimdal has the "set KRB5_CONFIG to rewinding tape drive" issue.) From: To: Time: Mon Jun 11 18:46:31 2007 So is this a lack of further comments, or lack of response? Sam? From: To: Time: Mon Jun 11 18:46:52 2007 opening/closing of files having side effects might be considered to be a security flaw in the OS.. From: To: Time: Mon Jun 11 18:47:58 2007 True, but it's long-established practice for some devices. And there's also the probe-for-file-existence issue. From: To: Time: Mon Jun 11 18:47:58 2007 A lack of response from my point but you should not block on me From: To: Time: Mon Jun 11 18:48:17 2007 Okay. Will send then... From: To: Time: Mon Jun 11 18:52:21 2007 Sent. From: To: Time: Tue Jun 12 19:53:48 2007 I just turned on the mail->news relay (one direction) in mailman. From: To: Time: Wed Jun 13 20:00:22 2007 Meetings went well today. Steve got in his second car accident. From: To: Time: Wed Jun 13 20:00:51 2007 ow! is he okay? From: To: Time: Wed Jun 13 20:01:15 2007 Yes. But apparently parked cars are not safe around him. From: To: Time: Wed Jun 13 20:01:36 2007 Rather, yes, but apparently From: To: Time: Wed Jun 13 20:02:44 2007 Stanford is very positive on the consortium From: To: Time: Wed Jun 13 20:03:48 2007 krbdev-xen has an ops root password. I apparently forgot to ask for you to be added to its k5login. I will do that. How is Adam doing? From: To: Time: Wed Jun 13 20:07:51 2007 Ah, okay. Thanks. He seems to be doing pretty well -- getting a few gssmonger configurations set up, getting a Windows build environment, etc. At this point, the VMs are putting a bit of a strain on his resources, hence my interest in moving something off to krbdev-xen. From: To: Time: Wed Jun 13 20:08:50 2007 OK. I've been thinking about it and imho giving him root provided that we don't move over subversion seems like a good idea From: To: Time: Wed Jun 13 20:09:06 2007 I forget, did we discuss whether we want to use gssmaggot vs inventing our own? Starting with the MS code seems good to me unless the license is a problem. From: To: Time: Wed Jun 13 20:10:15 2007 I don't know. I have not looked at the license From: To: Time: Wed Jun 13 20:10:18 2007 Ah, okay, that'll simplify things. From: To: Time: Wed Jun 13 20:10:25 2007 Okay, I'll dig it up and look. From: To: Time: Wed Jun 13 20:11:15 2007 Even if we go with inventing our own, having Adam get the experience with gssmonger is good, though. From: To: Time: Wed Jun 13 20:12:48 2007 Yes. From: To: Time: Thu Jun 14 17:04:28 2007 Keeping my mouth shut is hard. One guy near me is explaining why you want Windows servers rather using OS X server for an all mac shop. Another person is explaining how his algorithm is n factorial. From: To: Time: Thu Jun 14 17:04:48 2007 what's the session? From: To: Time: Thu Jun 14 17:05:03 2007 hallway track From: To: Time: Sun Jun 17 02:02:22 2007 MIt Kerberos Development Team From: To: Time: Sun Jun 17 02:02:23 2007 hartmans@jis.mit.edu/owl has set the topic to: test From: To: Time: Mon Jun 18 09:21:29 2007 I've just turned on "emergency moderation" for the Kerberos mailing list. I'm about to turn on the mailman code for relaying news articles in comp.protocols.kerberos into the mailing list, and I *think* it'll start with a big backlog. The emergency moderation is so I can get control over it without hosing the list members.... From: To: Time: Mon Jun 18 09:24:03 2007 Are we having a 3:30 meeting today? From: To: Time: Mon Jun 18 09:25:18 2007 Maybe... Tom thought it might be a good idea to catch up and see what the state of everyone's work is, hear about the WWDC trip, etc. I'm inclined to agree. From: To: Time: Mon Jun 18 09:25:28 2007 I won't be there, but I suggest that you do hold a meeting I think it would be good to discuss how you want to run a review of release progress for next week's meeting and make sure that people are tracking what they need to track. You may also want to see if anything needs to be stored globally or anything like that From: To: Time: Mon Jun 18 09:26:05 2007 The reason I ask is that today is my kids' last day at school and I need to pick them up. From: To: Time: Mon Jun 18 09:27:48 2007 Well, I think having the meeting is important, but I think that the timing is not . If you all find a time that works better for those attending then by all means change the time. From: To: Time: Mon Jun 18 09:28:59 2007 Yeah, rescheduling doesn't seem like a big deal. Earlier today probably isn't good; I and (I think) Tom will be having lunch with Luke Howard today. From: To: Time: Mon Jun 18 09:29:09 2007 Tom, Ken & Alexis won't be here today before I need to leave. What about tomorrow at 3:30? From: To: Time: Mon Jun 18 09:29:33 2007 I'm in already. (But don't tell anyone! :) From: To: Time: Mon Jun 18 09:30:23 2007 Tomorrow looks good for me, we'll see how Tom and Alexis and Justin feel... From: To: Time: Mon Jun 18 09:31:47 2007 Is Alexis actually back today? From: To: Time: Mon Jun 18 09:32:11 2007 I don't know, I was assuming so. Or is she taking some vacation time? From: To: Time: Mon Jun 18 09:32:51 2007 she's marked off today as WWDC From: To: Time: Mon Jun 18 09:33:05 2007 so i'd say she's coming back to work tomorrow From: To: Time: Mon Jun 18 09:33:26 2007 Oh, yeah, my notes from the last meeting say she's out today and Wednesday. From: To: Time: Mon Jun 18 09:33:35 2007 The better to move the meeting. I've booked a room and am adding attendees. From: To: Time: Mon Jun 18 09:34:03 2007 Good, thanks. From: To: Time: Mon Jun 18 09:38:14 2007 Did anybody get the meeting email? It's in my calendar but I don't have email. From: To: Time: Mon Jun 18 09:38:33 2007 I got it. From: To: Time: Mon Jun 18 09:38:42 2007 About 2 minutes ago. From: To: Time: Mon Jun 18 09:38:58 2007 i got it too From: To: Time: Mon Jun 18 09:51:07 2007 Ah, it looks like the news gateway script actually does a mass-catchup if it has never been run for this list before. So, no flood of messages coming. From: To: Time: Mon Jun 18 10:29:12 2007 Hm, I posted a test message to the newsgroup at 10:02, and it still hasn't come through. From: To: Time: Mon Jun 18 10:37:40 2007 Emergency moderation turned off. From: To: Time: Mon Jun 18 17:21:47 2007 ok, commit handler is b0rken because it is sensitive to people's ssh config files. From: To: Time: Mon Jun 18 17:37:23 2007 ok, now it sets a config file of /dev/null From: To: Time: Tue Jun 19 11:32:56 2007 Someone just called who sounded like she worked for the DoD. She wants to know why Kerberos 1.5.3 and 1.6.1 say they fix the same three bugs. Why would someone want one or the other? Also, what is the difference between the 'current' and 'maintenance' releases? From: To: Time: Tue Jun 19 13:59:17 2007 did this person send mail? From: To: Time: Tue Jun 19 14:00:31 2007 1.5.x is in maintenance, so we don't do anything other than critical bugfixes like security patches. 1.6.x is what we are recommending that people actually use. and 1.6.1 and 1.5.3 fix the same security holes but 1.6.1 has many more changes. From: To: Time: Tue Jun 19 15:28:56 2007 5564 is a duplicate of 5480. merging From: To: Time: Tue Jun 19 15:31:04 2007 oh oops i guess it's meeting time From: To: Time: Tue Jun 19 21:26:23 2007 Does anything care about the svn:mime-type property? From: To: Time: Wed Jun 20 17:19:07 2007 oops. i guess building on linux and darwin isn't sufficient testing. :( From: To: Time: Wed Jun 20 19:57:42 2007 I understand that the kerberos code must be written in C, not C++. But what about the DLL wrapper for the CCAPI library on Windows? Can it be C++? From: To: Time: Thu Jun 21 13:00:40 2007 Kevin, responding to your C vs C++ query from yesterday. You should avoid using C++ for shared libraries that must have consistent interfaces over time. There is no standard for how a C++ compiler should munge the function name and the parameters to determine what the exported name from the library will be. A C++ compiler must munge the function name and the parameters in order to support function overloading. You can use C++ for private non-exported functions within the library provided that all of the public functions are designated as export "C". However, unless there is some overwhelming need to use C++, using straight C is preferred. From: To: Time: Thu Jun 21 16:39:20 2007 There are some standards for name encoding, but extern "C" also deals with that. I think a more important question is whether you can require the C++ run time, and if multiple C++ runtimes can cause worse issues than multiple C runtimes. And whether exceptions might be generated that could leak out into the C world. Using C++ might get you access to some convenient support libraries... From: To: Time: Thu Jun 21 16:40:43 2007 I have seen Microsoft change the export names for C++ functions between major compiler releases. Fixing things up after that is not fun. From: To: Time: Thu Jun 21 16:42:42 2007 I didn't say Microsoft followed the standards. :) It also may be a matter of converting over to using the standards; G++ has had issues in that department too. But in any case, using C++ mangled names in APIs is bad. That's a separate question from using C++ and exporting only C names. From: To: Time: Thu Jun 21 16:45:19 2007 I don't think our statements are in disagreement with each other. From: To: Time: Thu Jun 21 18:36:19 2007 jis says he'll set up the news->mail cron job on the mailman server tonight or tomorrow. From: To: Time: Thu Jun 21 19:24:08 2007 oh great, no wonder it doesn't work. the sata cdrom is recognized by the scsi driver but there was no scsi cdrom driver on the initramfs. From: To: Time: Thu Jun 21 19:24:21 2007 well recognized after i frobbed the libata setting, that is From: To: Time: Sun Jun 24 02:02:28 2007 MIt Kerberos Development Team From: To: Time: Sun Jun 24 02:02:29 2007 hartmans@jis.mit.edu/owl has set the topic to: test From: To: Time: Mon Jun 25 19:40:07 2007 Ah, Simon's problem *isn't* the referral code, per se. From: To: Time: Mon Jun 25 21:38:03 2007 Jeff, where the heck are the CCOPTS set in the KfW build system? From: To: Time: Mon Jun 25 21:39:00 2007 Now the DoD lady wants to know if Kerberos "can be used on a Windows system." I think the answer is yes for kerberized clients and suspect the answer is no for a KDC? From: To: Time: Mon Jun 25 21:40:07 2007 Yeah, we don't build KDC-side programs for Windows currently. (And we don't export all the functions that would be needed to build our KDC, either.) From: To: Time: Tue Jun 26 18:21:16 2007 Now the DoD lady wants to know the timeframe for 1.6.2. ?? From: To: Time: Tue Jun 26 18:29:23 2007 Is Ken or Jeff able to build KfW from the trunk? From: To: Time: Tue Jun 26 19:39:28 2007 Kicking off a build now to see. From: To: Time: Tue Jun 26 19:42:22 2007 [raeburn@mit.edu has set the topic to: Kerberos discussion — log at http://opteron-prime.mit.edu/~hartmans/krb5.log.txt] From: To: Time: Tue Jun 26 19:53:27 2007 The build appears to have run to completion successfully. Are you having trouble building something, or is this just to check that you're not the only one it does work for? From: To: Time: Wed Jun 27 09:54:33 2007 The DoD Information Assurance Vulnerability Management lady __really__ wants to know when Kerberos 1.6.2 will be released, so that she knows whether to push the CERTs out as internal DoD advisories. If we are going to release 1.6.2 within a week or so, they might avoid pushing the patches out. When will the release timeframe be known? From: To: Time: Wed Jun 27 09:56:32 2007 This is a check to confirm my _in_ability to build. But you can build, which is good news. Did you do a repository checkout from the trunk? (-r co without any tags specified) ? From: To: Time: Wed Jun 27 10:10:50 2007 My reason for trying to build from the trunk is that Jeff's changes to pop the password prompt dialog to the top should be in KfW 3.2. If it isn't, people will start complaining immediately. So maybe the real question is if the 3.2 release tag can be built with those changes. From: To: Time: Wed Jun 27 12:58:02 2007 I checked out the "build" directory from the trunk, and used the scripts there to check out the sources to build. It didn't occur to me at the time to check whether that specifies the trunk or not... From: To: Time: Wed Jun 27 14:01:57 2007 Is there an apple conference call today? From: To: Time: Wed Jun 27 16:13:03 2007 Hm, it looks like the script should be checking out the trunk, so I wonder why the build worked for me but not for you guys. From: To: Time: Wed Jun 27 16:14:22 2007 Ah, no, it's not using the trunk. My bad. From: To: Time: Wed Jun 27 16:35:51 2007 we should be careful about "in_" prefix for parameter names because it may conflict with netinet/in.h etc. From: To: Time: Wed Jun 27 16:37:12 2007 that's why I was also suggesting making the variable names fully expanded (eg "in_client_principal", not "in_princ") From: To: Time: Wed Jun 27 16:37:24 2007 "cvs [checkout aborted]: cannot dup net connection: Bad file descriptor" ... lovely. No other messages to indicate why the fd might be bad. NIM says I've got valid tickets... From: To: Time: Wed Jun 27 16:37:33 2007 Does doxygen have a way to mark a parameter as in? From: To: Time: Wed Jun 27 16:38:06 2007 Because I think having in_ and out_ prefixes is really ugly From: To: Time: Wed Jun 27 16:40:51 2007 I don't believe there is a way to mark it as such so you'd need to manually add that text to the variable description From: To: Time: Wed Jun 27 16:40:58 2007 Oh, right, I have the cvs binary with gssapi support; maybe it doesn't like the kserver cvsroot spec. From: To: Time: Wed Jun 27 16:42:08 2007 Interesting. how did we handle that in kim? *goes to look* From: To: Time: Wed Jun 27 16:42:22 2007 we didn't. KIM uses the prefixes From: To: Time: Wed Jun 27 16:42:22 2007 But I do agree client_principal is better than client_princ From: To: Time: Wed Jun 27 16:42:54 2007 BTW, the HTML output looks really ugly in Safari, at first glance. From: To: Time: Wed Jun 27 16:43:01 2007 OK, well, then let's do that (prefixes) From: To: Time: Wed Jun 27 16:43:10 2007 There is no css file. Doxygen uses CSS.... a lot From: To: Time: Wed Jun 27 16:43:31 2007 I am quite sure that once the CSS file exists it will look a lot better ;-) From: To: Time: Wed Jun 27 16:43:31 2007 That might save it, yeah. From: To: Time: Wed Jun 27 16:44:33 2007 I'm not wedded to the in_, out_ and io_ prefixes. I'm just used to them from other API on the Mac From: To: Time: Wed Jun 27 16:46:01 2007 At this point I want rapid results and to actually have enough of krb5.h marked up that we can mandate new additions include api docs From: To: Time: Wed Jun 27 16:47:38 2007 Overall, the doc looks pretty good, formatting issues that CSS might cope with aside. I'd like to see magic constant strings like [appdefaults] emphasized in some way -- quoted, fixed-width, whatever. From: To: Time: Wed Jun 27 16:49:25 2007 OK. So, this sounds like something I should try and find money to finish? From: To: Time: Wed Jun 27 16:49:27 2007 If we're going to put it in without reviewing all of the actual function description texts, I think I'd like to see each definition noted in some way as "not yet reviewed" or "may be out of date" or something, which we could remove as we look at individual descriptions. From: To: Time: Wed Jun 27 16:49:53 2007 Yeah, I think so. From: To: Time: Wed Jun 27 16:52:45 2007 OK. Please try and get comments like that to me this evening in email. From: To: Time: Wed Jun 27 16:54:25 2007 ok From: To: Time: Wed Jun 27 16:57:41 2007 Building kfw from trunk now. It looks like bkw.pl doesn't remove an existing exported tree already in place, even if it's the wrong tree? From: To: Time: Wed Jun 27 16:58:58 2007 Okay, now the build fails for me... From: To: Time: Wed Jun 27 17:15:04 2007 Can you clarify 'doesn't remove tree ...' From: To: Time: Wed Jun 27 17:22:48 2007 My old (1.6) build tree was still there from a previous build. I switched to a different "build" directory checkout (which I've got stored in a different place from \kfw) which uses the trunk instead of krb5-1-6 branch, and bkw.pl happily built the existing krb5-1-6 sources, which is why I didn't notice the build failure. From: To: Time: Wed Jun 27 17:26:02 2007 Which in some cases is probably fine, but if "export" is the default (is it?), then shouldn't it always use the current svn source? From: To: Time: Wed Jun 27 17:35:03 2007 Send mail, but ... xen+rhel is failing for adam & me. Can't install 4, 5 fails like debian did. From: To: Time: Wed Jun 27 17:38:09 2007 Why are you installing svm linux? From: To: Time: Wed Jun 27 17:38:40 2007 svm linux? From: To: Time: Wed Jun 27 17:38:54 2007 For linux I'd install something paravirtualized From: To: Time: Wed Jun 27 17:39:08 2007 This is RHEL5 as dom0, trying to install a Windows guest. From: To: Time: Wed Jun 27 17:39:32 2007 Why doesn't Adam use krbdev-xen? From: To: Time: Wed Jun 27 17:39:44 2007 RHEL5 and Debian dom0, with the various versions of Xen we've tried, lock up installing Windows. From: To: Time: Wed Jun 27 17:40:04 2007 On your desktops, right? From: To: Time: Wed Jun 27 17:40:58 2007 He may have to, but if it's in production (for kerberos.org), I'm wary of messing around with the Xen config there too much before we've figured out how we want it set up. But given that using VMware now and then migrating to Xen looks like our only other option, maybe we might as well. From: To: Time: Wed Jun 27 17:40:59 2007 Yes. From: To: Time: Wed Jun 27 17:41:23 2007 Do you yet have a good idea of what Adam is going to try and accomplish this summer? If so, it would be good to write that up (or have him write that up) and send it out From: To: Time: Wed Jun 27 17:42:19 2007 I think we're getting there, yes. He's been exploring the gssmonger framework a while now. From: To: Time: Wed Jun 27 17:43:06 2007 That's wonderful From: To: Time: Wed Jun 27 17:43:51 2007 Yeah. So, screwing with the network config on krbdev-xen would be bad, as would screwing too much with installing software on dom0. But installing non-production vms is fine From: To: Time: Wed Jun 27 17:44:14 2007 /me wonders when the server for sipb-xen will arrive From: To: Time: Wed Jun 27 17:46:24 2007 The network stuff would just be one local virtual network behind a NAT. Once that's set up, he can just attach VMs. From: To: Time: Wed Jun 27 17:46:49 2007 Or should we get N public addresses, including for the Windows VMs that could get exposed to attack? From: To: Time: Wed Jun 27 17:49:12 2007 i finally managed to build the xen-3.1 debian package from subversion and it doesn't help with the hanging and reboots of hardware From: To: Time: Wed Jun 27 17:51:28 2007 OK. I'd seriously consider the possibility that your hardware is under-cooked. From: To: Time: Wed Jun 27 17:52:13 2007 No, I think exposing Windows is not such a good idea. I think that I'd set up a bridge natted to the outside that all the vms live on with one of the vms running some vpn or ipsec software so you can join that network From: To: Time: Wed Jun 27 17:52:55 2007 hm, booting xen with noirqbalance seems to get me farther into a netbsd install From: To: Time: Wed Jun 27 17:53:05 2007 Yeah, that's the sort of configuration I was thinking of. From: To: Time: Wed Jun 27 17:53:27 2007 It turns out that xen and linux don't quite do such a nice think with mac addresses on a bridge with no real ethernets and ipv6. We quite probably don't care provided that dom0 doesn't need to run ipv6 on that interface From: To: Time: Wed Jun 27 17:55:11 2007 If you really care about dom0 and ipv6 I bet I could fix it. You definitely do not want xen's network bridge scripts to set up your virtual bridge. But vif-bridge is fine. I can send sample details from my machine at home From: To: Time: Wed Jun 27 17:55:24 2007 Am about to disappear to go swimming From: To: Time: Wed Jun 27 17:55:34 2007 Okay. From: To: Time: Wed Jun 27 17:56:05 2007 oh well, got netbsd to crash into ddb From: To: Time: Wed Jun 27 17:56:24 2007 dom0 or domU? From: To: Time: Wed Jun 27 17:56:25 2007 then it rebooted the harware not long after i rebooted the vm From: To: Time: Wed Jun 27 17:56:29 2007 domU From: To: Time: Wed Jun 27 17:57:25 2007 svm or para? If you gave me an install image that supported serial console with no From: To: Time: Wed Jun 27 17:57:56 2007 Rather if I had a serial console image or a paravirtualized image I could try it on hardware I think works From: To: Time: Wed Jun 27 17:58:38 2007 it's probably not the netbsd kernel, because it had worked before From: To: Time: Wed Jun 27 17:59:41 2007 also sometimes i get a watchdog tripped when i hit "d" in the xen console From: To: Time: Wed Jun 27 19:23:04 2007 i wonder if we'll have any luck exchanging these machines for intel-based dell hw From: To: Time: Wed Jun 27 19:24:04 2007 Have you figured out what Govconnection's return policy is? From: To: Time: Wed Jun 27 19:25:11 2007 i thought we bought directly from dell for these due to ecat stuff, but i'll mail Bryan now From: To: Time: Wed Jun 27 19:25:40 2007 OK, whatever. Dell's policies From: To: Time: Wed Jun 27 19:30:17 2007 do we know the specs on general-dink or whatever the sipb xen machines are? From: To: Time: Wed Jun 27 19:34:00 2007 I can mail you dmesg and lspci on dink. It's kind of old now. SIPB is buying two 2u sun servers for sipb-xen, but you probably don't want those for your office From: To: Time: Wed Jun 27 19:35:05 2007 yeah From: To: Time: Wed Jun 27 19:35:51 2007 O, hey it's been upgraded to xen 3.1 From: To: Time: Wed Jun 27 19:36:07 2007 anyway various xen forums have predominantly Dell Precision machines represented among Dell hardware, with some mentions of problems with the Optiplex 745, which was an alternative i was considering. From: To: Time: Wed Jun 27 19:36:14 2007 is it AMD or Intel? From: To: Time: Wed Jun 27 19:39:00 2007 intel. But I have an amd machine that works fine. From: To: Time: Wed Jun 27 19:44:38 2007 what chipset on the AMD machine? From: To: Time: Wed Jun 27 19:47:08 2007 hm, guess it might not be the chipset. someone claims to have winxp running on a laptop with an nVidia C51 chipset under hvm From: To: Time: Wed Jun 27 19:50:20 2007 How do I tell what chipset I have? 00:00.0 RAM memory: nVidia Corporation MCP55 Memory Controller (rev a2) 00:01.0 ISA bridge: nVidia Corporation MCP55 LPC Bridge (rev a3) 00:01.1 SMBus: nVidia Corporation MCP55 SMBus (rev a3) 00:02.0 USB Controller: nVidia Corporation MCP55 USB Controller (rev a1) 00:02.1 USB Controller: nVidia Corporation MCP55 USB Controller (rev a2) 00:04.0 IDE interface: nVidia Corporation MCP55 IDE (rev a1) 00:05.0 IDE interface: nVidia Corporation MCP55 SATA Controller (rev a3) 00:06.0 PCI bridge: nVidia Corporation MCP55 PCI bridge (rev a2) 00:08.0 Bridge: nVidia Corporation MCP55 Ethernet (rev a3) 00:09.0 Bridge: nVidia Corporation MCP55 Ethernet (rev a3) 00:0a.0 PCI bridge: nVidia Corporation MCP55 PCI Express bridge (rev a3) 00:0b.0 PCI bridge: nVidia Corporation MCP55 PCI Express bridge (rev a3) 00:0c.0 PCI bridge: nVidia Corporation MCP55 PCI Express bridge (rev a3) 00:0d.0 PCI bridge: nVidia Corporation MCP55 PCI Express bridge (rev a3) 00:0e.0 PCI bridge: nVidia Corporation MCP55 PCI Express bridge (rev a3) 00:0f.0 PCI bridge: nVidia Corporation MCP55 PCI Express bridge (rev a3) 00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] HyperTransport Technology Configuration 00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address Map 00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM Controller 00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Miscellaneous Control From: To: Time: Wed Jun 27 19:51:47 2007 it's probably the MCP55, i think From: To: Time: Wed Jun 27 19:56:19 2007 Hmm. Debian seems to have xen 3.0.4 in unstable for i386 but not amd64 From: To: Time: Wed Jun 27 19:56:51 2007 Xen 3.1 doesn't seem to have any user visible features I care much about possibly including say better vista support From: To: Time: Wed Jun 27 19:57:11 2007 I wonder if it loves the solaris ide driver better than 3.0.3 From: To: Time: Wed Jun 27 19:58:17 2007 i wonder if i should try installing i386 Debian and seeing if that helps xen From: To: Time: Wed Jun 27 19:59:36 2007 I don't think it will. From: To: Time: Wed Jun 27 19:59:46 2007 Besides, you probably want to be able to run 64-bit oses From: To: Time: Wed Jun 27 20:00:09 2007 probably From: To: Time: Wed Jun 27 23:31:14 2007 ken, thanks for taking care of the vsnprintf issue. From: To: Time: Wed Jun 27 23:32:14 2007 although now I'm getting com_err and error_message errors in k524init.c. checking for recent changes to src/include/com_err.h From: To: Time: Wed Jun 27 23:41:26 2007 I don't think there have been changes there in a little while... From: To: Time: Wed Jun 27 23:42:07 2007 I don't see any From: To: Time: Wed Jun 27 23:42:34 2007 Possibly other changes in include/ affect some needed types or something? What kind of errors? From: To: Time: Wed Jun 27 23:43:21 2007 c:\src\kerberos\mit-cvs\pismere\athena\auth\krb5\src\include\com_err.h(42) : warning C4028: formal parameter 1 different from declaration c:\src\kerberos\mit-cvs\pismere\athena\auth\krb5\src\include\com_err.h(42) : warning C4028: formal parameter 3 different from declaration From: To: Time: Wed Jun 27 23:45:58 2007 looks like a collision between the pismere auth krb4 com_err.h and the krb5 version. From: To: Time: Wed Jun 27 23:46:29 2007 That's the declaration of com_err(), and the main interesting thing I see that arguments 1 and 3 have in common is that both are "const char *". Maybe if there's another decl without const, or somehow const is being defined away somewhere... From: To: Time: Thu Jun 28 00:16:33 2007 Hm, my Windows build got some kind of error in the help compiler. A window popped up asking if I wanted to submit a report to Microsoft, and the build paused. After I sent off the report (3.5 hours later), the build resumed with no indication of an error. From: To: Time: Thu Jun 28 00:17:15 2007 Ah, and now I see the com_err.h related build failure From: To: Time: Thu Jun 28 00:18:01 2007 looks to be like some change is now resulting in both the krb4 and krb5 com_err.h being pulled into the build From: To: Time: Thu Jun 28 00:18:35 2007 I would have no qualms about modifying the krb4 com_err.h to use const From: To: Time: Thu Jun 28 00:19:58 2007 Yeah, I'd definitely say that the one saying "ha ha ha this is a com_err substitute!! ha ha" is the one to be "fixed", in whatever sense you want to apply that word. From: To: Time: Thu Jun 28 00:20:37 2007 I wonder why the change, though... From: To: Time: Thu Jun 28 00:21:43 2007 and why does the problem appear in that file? From: To: Time: Thu Jun 28 00:21:48 2007 com_err is used elsewhere From: To: Time: Thu Jun 28 00:22:24 2007 Maybe not with the krb4 headers? From: To: Time: Thu Jun 28 00:24:43 2007 that is the first directory to reference USE_ALTERNATE_KRB4_INCLUDES From: To: Time: Thu Jun 28 00:24:59 2007 Is that a new thing? From: To: Time: Thu Jun 28 00:25:04 2007 no From: To: Time: Thu Jun 28 00:25:45 2007 what that does is set KRB4_INCLUDES to use the pismere versions instead of the krb5 versions From: To: Time: Thu Jun 28 00:26:25 2007 LOCALINCLUDES is then set to KRB4_INCLUDES ; . ; srcdir From: To: Time: Thu Jun 28 00:27:16 2007 that still doesn't explain how both versions are being used From: To: Time: Thu Jun 28 00:28:18 2007 Well, the krb4 include directory is listed ahead of the krb5 one, so if com_err.h is included directly, that's the one it'll get; krb5.h will include com_err.h also, getting the krb5 one I suspect. From: To: Time: Thu Jun 28 00:29:10 2007 k524init.c includes "com_err.h" and krb5.h includes From: To: Time: Thu Jun 28 00:29:34 2007 why wouldn't those both resolve to the same include file? From: To: Time: Thu Jun 28 00:30:21 2007 I assume the reference in krb5.h would only look further down the include path, not back from the beginning. From: To: Time: Thu Jun 28 00:30:32 2007 Could be wrong. From: To: Time: Thu Jun 28 00:31:39 2007 I thought that "" meant that you look in the source directory and then the include path. I didn't think placement in the include path mattered. From: To: Time: Thu Jun 28 00:40:40 2007 if com_err.h is going to be loaded by krb5.h then there is no reason to include it directly in k524init.c From: To: Time: Thu Jun 28 00:42:40 2007 true From: To: Time: Thu Jun 28 00:55:09 2007 removing the include from k524init.c doesn't help. ok. I will generate pre-processor output and look at where the includes are coming from From: To: Time: Thu Jun 28 00:55:19 2007 *tomorrow* From: To: Time: Thu Jun 28 10:56:18 2007 Jeff, do you see SecureCRT & SecureFX asking for passwords on XP64? From: To: Time: Thu Jun 28 11:02:30 2007 Kevin, that question is incredibly ill-formed. From: To: Time: Thu Jun 28 11:02:56 2007 Do you get asked for passwords by what with what authentication method under what circumstances? From: To: Time: Thu Jun 28 11:03:23 2007 Apps should not ask for passwords. From: To: Time: Thu Jun 28 11:04:18 2007 Um. an ssh app using ssh password auth certainly should From: To: Time: Thu Jun 28 11:06:53 2007 I agree that kerberos gssapi-with-mic is better than password auth because among other reasons the app doesn't ask for the password. From: To: Time: Thu Jun 28 11:07:10 2007 On XP32, SecureXXX do not ask for passwords. On XP64, they do. From: To: Time: Thu Jun 28 11:10:01 2007 Again, what does it mean to ask for a password. That could be anything from popping up a NIM dialogue to ask for your kerberos password if you don't have tickets to asking for passwords for keyboard interactive or password. To debug ssh products, you need to know what authentication mechanism you're trying against the server, what authentication mechanisms you offer, etc. .3 From: To: Time: Thu Jun 28 11:10:48 2007 NIM doesn't ask for the password, the app does, which is what I said in the first place. From: To: Time: Thu Jun 28 11:13:24 2007 *gives up* From: To: Time: Thu Jun 28 17:19:04 2007 Do we have a public API to get the domain for a realm? krb5_get_realm_domain() appears to be private From: To: Time: Thu Jun 28 18:11:47 2007 What is "the domain" for a realm? krb5_get_realm_domain is used to get the default domain to use when mapping krb4 service principal names when there's no v4_instance_convert listing. From: To: Time: Thu Jun 28 18:12:48 2007 But a realm can service multiple DNS domains... maybe a hierarchy under one common root name, maybe not. From: To: Time: Sun Jul 1 02:02:23 2007 MIt Kerberos Development Team From: To: Time: Sun Jul 1 02:02:23 2007 raeburn@mit.edu has set the topic to: Kerberos discussion — log at http://opteron-prime.mit.edu/~hartmans/krb5.log.txt From: To: Time: Mon Jul 2 13:16:27 2007 Adam may come to the meeting today. From: To: Time: Mon Jul 2 14:36:16 2007 Hm, looks like I broke the Solaris build again. :( Fixing... From: To: Time: Mon Jul 2 14:50:41 2007 Oh. Nightly builds use an old, crufty gcc version. From: To: Time: Mon Jul 2 18:08:23 2007 64bit applications cannot load 32-bit libraries. Therefore, as far as the 64-bit versions of applications are concerned, there is no KFW installed. From: To: Time: Mon Jul 2 18:09:24 2007 (that was a response to Kevin's discussion from a last week.) From: To: Time: Mon Jul 2 19:11:06 2007 Oh, great. I just finished running a few tests on the Windows build -- svn update -r####, nmake, nmake clean -- and found that none of them broke in the krb524 directory. Then I found that at least some of them weren't building it at all. From: To: Time: Mon Jul 2 19:11:53 2007 (Well, at least the one I just looked at.) From: To: Time: Mon Jul 2 19:12:07 2007 Explicitly building in that directory also works. From: To: Time: Mon Jul 2 19:16:36 2007 Trying a fresh check-out. From: To: Time: Mon Jul 2 19:54:17 2007 Well, that's an interesting bit... nmake in the krb524 directory works, but bkw.pl doesn't. From: To: Time: Mon Jul 2 19:55:57 2007 Oh, I see. bkw.pl is what overrides the krb4 header selection; plain nmake would use the krb5-tree versions of them. From: To: Time: Tue Jul 3 11:01:07 2007 Ken, where is bkw.pl overriding something? Also, if you can build the trunk one way or another, I'd like to check with a complete 3.2.1 build my observation that the newcredwnd.* changes didn't fix the 'pop-under' problem. From: To: Time: Wed Jul 4 04:26:53 2007 For anyone reading the logs... Kevin and I talked a bit at lunch. I don't think it's so much bkw.pl doing the overriding so much as it is some makefile outside of the krb5 tree used in the build process launched by bkw.pl. From: To: Time: Wed Jul 4 18:12:32 2007 Ken, when you build krb5 outside of the pismere tree you do not build with the alternative krb4 headers. Hence you don't run into the collision between the pismere krb4 com_err.h and the krb5 com_err.h From: To: Time: Wed Jul 4 18:19:19 2007 Kevin, if you look at the patch you will see that it requires that you add a registry value Key: "HKLM\Software\MIT\NetIdMgr\CredWindow\Windows\NewCred" Value: "ForceToTop" DWORD Creating windows with the WS_EX_TOPMOST style is really impolite and should not be done by default. Organizations that want this behavior can set the registry value in their transform. From: To: Time: Wed Jul 4 19:16:33 2007 Jeff, are you saying that the registry change causes the prompt dialog to be created with WS_EX_TOPMOST? When AutoInit is set and the dialog displays at login time, does the dialog get that flag? From: To: Time: Thu Jul 5 10:22:57 2007 To anyone contemplating coming in today: there is currently no AC in our part of the building and the temp is going up. Another half hour of this and I'll be moving to the kitchen area. From: To: Time: Thu Jul 5 11:18:43 2007 I'm in the kitchen area. ☹ Supposedly there's a guy from Facilities up on the roof working on it. From: To: Time: Thu Jul 5 14:02:08 2007 The kfw build seems to build two different com_err libraries. One from krb4, and one from krb5. Do we install both? From: To: Time: Thu Jul 5 14:06:31 2007 I don't think so. From: To: Time: Thu Jul 5 14:07:12 2007 Or rather if we install more than one, it's not obvious how that works. I think we only install comerr_32.dll From: To: Time: Thu Jul 5 14:08:53 2007 Seems kind of silly to install both, and have both headers in the build tree. From: To: Time: Thu Jul 5 15:38:34 2007 Okay, so here's my current understanding of the Windows build issue.... #include "foo" looks first in the directory containing the source file issuing the include directive; k5-int.h includes krb5.h and com_err.h; k524init.c includes k5-int.h on the trunk and not in 1.6. A few other directories use KRB4_INCLUDES, but krb524 is the only one with USE_ALTERNATE_KRB4_INCLUDES support. But it looks to me like anything using k5-int.h and USE_ALTERNATE_KRB4_INCLUDES will fail on Windows. From: To: Time: Thu Jul 5 15:39:42 2007 (krb5.h is in a subdir, so its inclusion of com_err.h causes a path search, which gets the pismere-krb4 one; direct inclusion of com_err.h gets the one in the krb5 include directory.) From: To: Time: Thu Jul 5 15:42:03 2007 so this is another instance of nested includes biting us? From: To: Time: Thu Jul 5 15:42:12 2007 OK, so, fixing the prototypes to be the same does seem like a reasonable response as we're moving away from krb4 support for kfw From: To: Time: Thu Jul 5 15:48:06 2007 Not so much nested includes, I think, as multiple headers with the same name and different and conflicting content. From: To: Time: Thu Jul 5 15:49:13 2007 ok. so the move of krb5.h into include/krb5 is part of what caused this? From: To: Time: Thu Jul 5 15:49:16 2007 Since we do appear to be building the pismere-krb4 version of com_err, those source files may need tweaking too. From: To: Time: Thu Jul 5 15:49:33 2007 Hm, yeah, sort of, but that was done before 1.6. From: To: Time: Thu Jul 5 15:50:17 2007 Also, really, if we're installing only the krb5 version of com_err, that's what the krb4 library *should* be built against, but.... From: To: Time: Thu Jul 5 16:30:56 2007 Is __stdcall the default on Windows? One of the declarations of error_message uses it, the other does not. From: To: Time: Thu Jul 5 16:31:37 2007 i think so given some explanation of KRB5_CALLCONV_WRONG i heard from jaltman From: To: Time: Thu Jul 5 16:32:48 2007 Ok. Sounds vaguely familiar, yeah. From: To: Time: Thu Jul 5 18:42:45 2007 Hey! "bkw.pl /clean" isn't supposed to be compiling things, is it? From: To: Time: Thu Jul 5 18:45:24 2007 Or is this supposed to be "make clean before building"? Which it also doesn't seem to be doing. From: To: Time: Thu Jul 5 18:57:56 2007 does the script silently ignore unrecognized options perhaps? From: To: Time: Thu Jul 5 19:01:15 2007 Maybe. But it looks like it should handle /clean. From: To: Time: Fri Jul 6 10:17:24 2007 I asked the same question about clean the first time I saw it. Sam explained it to me but to be truthful, I forgot the explanation. From: To: Time: Fri Jul 6 10:17:53 2007 What's up with clean? From: To: Time: Fri Jul 6 10:20:07 2007 Some of the clean targets in KfW compile some things. It seems odd but you had an explanation when I first asked about it. From: To: Time: Fri Jul 6 10:20:56 2007 Well, the explanation was explaining how that sort of bug comes about. IT's not actually good. Basically the clean targets must depend on things they don't need to From: To: Time: Fri Jul 6 13:47:08 2007 Where is the right place to report NIM bugs? From: To: Time: Fri Jul 6 14:58:17 2007 Letting "bkw.pl /clean" run to completion does leave object files in the tree. In fact, I'm not sure if it removes any. From: To: Time: Fri Jul 6 17:58:12 2007 Well, I haven't managed to reproduce the problem Russ forwarded. I'm even trying the 1.4.4-7etch1 package on opteron-prime. From: To: Time: Fri Jul 6 17:59:18 2007 weird From: To: Time: Fri Jul 6 18:25:56 2007 Ah, the addresses aren't so bogus. The libraries get loaded at 2-gazillion, but the executable itself is at low addresses. It's just stripped. "info files" in gdb tells me: 0x0000000000403da0 - 0x000000000040ac48 is .text From: To: Time: Fri Jul 6 18:26:10 2007 oh... From: To: Time: Fri Jul 6 18:29:46 2007 In 1.4.4-7etch1, 0x40aa3c is mid-instruction, so I think I need to look at -7etch2. From: To: Time: Fri Jul 6 18:36:16 2007 Hm, going to http.us.debian.org I still find only -7etch1. From: To: Time: Fri Jul 6 18:36:31 2007 weird. From: To: Time: Fri Jul 6 18:44:29 2007 So, I've got -7etch1 built with symbols. Assuming the addresses in -7etch2 will be fairly close... the symbols in the neighborhood of the addresses in the stack trace are: 0000000000408230 T request_exit 0000000000408260 T do_schpw 0000000000408530 T log_badauth_display_status_1 [...] 0000000000408b10 t usage 0000000000408b40 T main 00000000004099e0 T process_chpw_request 000000000040a770 T check_min_life 000000000040a980 T schpw_util_wrapper 000000000040aa20 T randkey_principal_wrapper_3 000000000040aad0 T chpass_principal_wrapper_3 000000000040ab70 T kadm5_get_policy_v1 000000000040ab80 T kadm5_get_principal_v1 000000000040ab90 T __libc_csu_fini From: To: Time: Fri Jul 6 18:46:43 2007 So, I'm guessing: strlen, schpw_util_wrapper, chpass_principal_wrapper_3, process_chpw_request, do_schpw, main. From: To: Time: Fri Jul 6 18:49:38 2007 this might be the missing string.h problem in server_stubs.c From: To: Time: Fri Jul 6 18:50:23 2007 schpw_util_wrapper doesn't call strlen, but it does call check_min_life and kadm5_chpass_principal_util. check_min_life (at least) does call strlen. From: To: Time: Fri Jul 6 18:50:46 2007 string.h is included by the server_stubs.c I see here. From: To: Time: Fri Jul 6 18:51:03 2007 yes, but is it in the 1.4-branch stuff? From: To: Time: Fri Jul 6 18:51:23 2007 diffing server_stubs.c between 1.4.x and trunk shows an addition of string.h From: To: Time: Fri Jul 6 18:51:30 2007 Oh, wait, wrong source tree. From: To: Time: Fri Jul 6 18:53:10 2007 Yeah, it's missing. From: To: Time: Fri Jul 6 19:28:33 2007 chpass_principal_wapper_3 doesn't call schpw_util_wrapper, but it does call check_min_life, so that's probably the strlen caller. From: To: Time: Fri Jul 6 19:28:45 2007 yeah that seems likely From: To: Time: Fri Jul 6 19:30:14 2007 Ah, I think I might've found it. A generated instruction that sign-extends 32->64 the return value from ctime. ../../../src/kadmin/server/misc.c:148: warning: assignment makes pointer from integer without a cast From: To: Time: Fri Jul 6 19:30:42 2007 ../../../src/kadmin/server/misc.c:148 12b: 31 c0 xor %eax,%eax 12d: e8 00 00 00 00 callq 132 12e: R_X86_64_PC32 ctime+0xfffffffffffffffc ../../../src/kadmin/server/misc.c:149 132: 48 c7 c7 0c 6f 09 a7 mov $0xffffffffa7096f0c,%rdi ../../../src/kadmin/server/misc.c:148 139: 4c 63 e8 movslq %eax,%r13 From: To: Time: Fri Jul 6 19:33:06 2007 Fixed in current sources. Well, disassembly of objects built from current sources. :) From: To: Time: Fri Jul 6 19:45:04 2007 Oh, no wonder I couldn't reproduce it. That path requires that the minimum password life not have passed yet. From: To: Time: Fri Jul 6 19:49:14 2007 oh... From: To: Time: Fri Jul 6 19:49:22 2007 that also explains the symptoms From: To: Time: Fri Jul 6 19:50:03 2007 Yah. Writing up a reply now... From: To: Time: Fri Jul 6 19:53:52 2007 sent. From: To: Time: Sat Jul 7 02:36:41 2007 Well, that was fun. I just installed Parallels on my laptop, and tried installing Windows. It crashed OS X. Twice. From: To: Time: Sun Jul 8 02:02:20 2007 MIt Kerberos Development Team From: To: Time: Sun Jul 8 02:02:21 2007 raeburn@mit.edu has set the topic to: Kerberos discussion — log at http://opteron-prime.mit.edu/~hartmans/krb5.log.txt From: To: Time: Mon Jul 9 16:59:43 2007 oh. the particular naming of their forest and their lack of capaths is part of their problem. From: To: Time: Mon Jul 9 17:06:26 2007 yeah but they wanted to use referrals, not capaths From: To: Time: Mon Jul 9 17:06:50 2007 Is there a way to get it to try referrals and still have the domain-realm mapping? From: To: Time: Mon Jul 9 17:07:16 2007 we'd have to restructure the code so if we get an off-path TGT referral in the initial non-referral iteration of do_traversal() it won't be a fatal error. From: To: Time: Mon Jul 9 17:07:36 2007 let me as eric if he can just remove the referrals From: To: Time: Mon Jul 9 17:07:45 2007 ur I mean mappings... gah From: To: Time: Mon Jul 9 17:11:01 2007 Okay they can't. The reason they can't is that they can have mixed AD and OD forests. Since OD is our KDC there's no server-side referrals support so there will be domain-realm mappings From: To: Time: Mon Jul 9 17:11:27 2007 how about adding capaths? From: To: Time: Mon Jul 9 17:12:08 2007 They autogenerate capaths for complex AD environments. They wanted referrals support specifically so they didn't have to do that for anything except the OD cases (which are simpler than the AD cases) From: To: Time: Mon Jul 9 17:14:40 2007 so right now it's that do_traversal() always considers an off-path referral TGT to be a hard failure... and the referrals path bypasses the first call to do_traversal() almost by accident From: To: Time: Mon Jul 9 17:16:09 2007 it's not "referrals" if you know the destination realm. it may just be that the pre-referrals library code would've lost if it got back a tgt for a realm it wasn't expecting. From: To: Time: Mon Jul 9 17:16:41 2007 i mean "referral" in the limited sense permitted by RFC1510 From: To: Time: Mon Jul 9 17:16:43 2007 the "referrals" stuff is specifically when you're asking the kdc about the realm for a service, not when you're asking for a cross-realm tgt. From: To: Time: Mon Jul 9 17:16:59 2007 ok. terminology problem... From: To: Time: Mon Jul 9 17:17:32 2007 how about "shortcut TGT" for lack of a better name? From: To: Time: Mon Jul 9 17:18:20 2007 works, i guess. though i think it's a misnomer. From: To: Time: Mon Jul 9 17:18:57 2007 (the shortcut would be if the kdc could give you back the tgt you asked for, instead of pointing you to an intermediate realm.) From: To: Time: Mon Jul 9 17:21:52 2007 Okay so I understand this a little more. The problem is that by default Mac OS X server names the Kerberos realm the uppercase of the server name. So if you had a server "kerberos.example.com" you'd get "KERBEROS.EXAMPLE.COM" as your realm by default. Which forces them to always have domain_realm mappings when their OD server is involved From: To: Time: Mon Jul 9 17:24:07 2007 But they really don't want to use capaths for AD because AD is all dynamic so they need to constantly rewrite the capaths. Apparently in the complicated cases the autogenerating capaths code is icky From: To: Time: Mon Jul 9 17:24:40 2007 so basically we need to solve the off-path returned TGT problem From: To: Time: Mon Jul 9 17:25:30 2007 We should probably just fix the library to deal with the off-path tgt return, at least in preference to walking the tree. With explicitly configured capaths, we'd probably want to stick with what's configured, I suspect. From: To: Time: Mon Jul 9 17:26:04 2007 well the question is how should we deal with getting an off-path TGT? fall through to referrals code? From: To: Time: Mon Jul 9 17:26:51 2007 Falling through to referrals should fix Eric's problem From: To: Time: Mon Jul 9 17:27:47 2007 Possibly. Though we might want to try the tree-walk-with-shortcuts from the new realm to destination, in case the new realm can't directly give us a tgt for the destination. From: To: Time: Mon Jul 9 17:28:35 2007 (I.e., ask it for the destination, if that fails without a useful tgt return, ask for one level up from the destination and/or check capaths, something like that.) From: To: Time: Mon Jul 9 17:29:09 2007 we'd have to make walk_rtree provide a graph rather than a sequence of realms From: To: Time: Mon Jul 9 17:29:35 2007 As if that code isn't hairy enough already.... From: To: Time: Mon Jul 9 17:30:15 2007 grah. the referrals code needs to be broken out into smaller pieces but i may be able to fix Eric's problem without doing so. From: To: Time: Mon Jul 9 17:33:38 2007 Steve says Stanford just signed the consortium agreement, and will be cutting a check this week. Woo! From: To: Time: Mon Jul 9 17:33:47 2007 (like, 10 minutes ago) From: To: Time: Mon Jul 9 17:36:39 2007 It's not a huge amount, but we've got a member. From: To: Time: Mon Jul 9 18:51:55 2007 I saw some of the earlier discussion about referrals today. I definitely agree supporting the rfc4120 behavior is correct, but I'd like to see a writeup of the specific behavior you propose to implement focusing on number of kdc round trips and what tickets get cached. From: To: Time: Thu Jul 12 13:59:59 2007 Does our GSSAPI have user-to-user support From: To: Time: Fri Jul 13 14:12:24 2007 Working from home today... From: To: Time: Fri Jul 13 14:14:16 2007 Wow. It took ~2 minutes for my mit.edu account to join this chat room. From: To: Time: Sun Jul 15 02:02:35 2007 MIt Kerberos Development Team From: To: Time: Sun Jul 15 02:02:35 2007 raeburn@mit.edu has set the topic to: Kerberos discussion — log at http://opteron-prime.mit.edu/~hartmans/krb5.log.txt From: To: Time: Mon Jul 16 17:44:27 2007 jis just got the mail<->news gateway function switched on on mailman. (actually, the news->mail direction, specifically, as it required a cron job.) From: To: Time: Mon Jul 16 17:46:56 2007 techtime behaves ... interestingly if you try to schedule a daily repeating meeting of duration 23h59m across a DST change From: To: Time: Fri Jul 20 14:58:55 2007 Reinstalling OS so I need to leave the chat. In my office if anyone needs me From: To: Time: Sun Jul 22 02:02:28 2007 MIt Kerberos Development Team From: To: Time: Sun Jul 22 02:02:29 2007 raeburn@mit.edu has set the topic to: Kerberos discussion — log at http://opteron-prime.mit.edu/~hartmans/krb5.log.txt From: To: Time: Wed Jul 25 11:27:52 2007 hm, i just got "Received disconnect from 18.7.14.135: 15: You are not allowed to log in here: Logins currently disabled Workstation is reactivating." from my script to process nightly testing results. That's krbdev.mit.edu. From: To: Time: Wed Jul 25 11:28:13 2007 umich just signed the consortium agreement From: To: Time: Wed Jul 25 11:29:37 2007 That's great news. From: To: Time: Wed Jul 25 14:18:20 2007 There does not seem to be an Apple conference call From: To: Time: Wed Jul 25 18:45:41 2007 yet more TIm Alsop... From: To: Time: Thu Jul 26 16:33:37 2007 Tim Alsop? From: To: Time: Thu Jul 26 18:34:03 2007 Tim is at Cybersafe, and pops up now and then on the Kerberos list to tell people when their implementation does something that's being asked about. From: To: Time: Sat Jul 28 01:56:09 2007 Ick. Flight cancelled, stuck in Chicago one more night. At least it was a mechanical problem, which means the airline puts me up for the night... From: To: Time: Sun Jul 29 02:02:41 2007 MIt Kerberos Development Team From: To: Time: Sun Jul 29 02:02:41 2007 raeburn@mit.edu has set the topic to: Kerberos discussion — log at http://opteron-prime.mit.edu/~hartmans/krb5.log.txt From: To: Time: Mon Jul 30 08:45:28 2007 I sent about a dozen emails to kfw-bugs on Friday. Shouldn't there be entries in krbdev.mit.edu/rt? From: To: Time: Mon Jul 30 09:33:28 2007 Yes, unless they are stuck in the moderation queue From: To: Time: Mon Jul 30 09:57:11 2007 How do I determine that? From: To: Time: Mon Jul 30 09:58:21 2007 Do you have the mailman password? If so, go to https://mailman.mit.edu/mailman/admindb/kfw-bugs From: To: Time: Mon Jul 30 10:13:16 2007 There are no pending requests. From: To: Time: Mon Jul 30 10:22:33 2007 Interesting. I'd recommend debugging with Tom, but meanwhile you can open tickets using the web interface From: To: Time: Mon Jul 30 11:08:28 2007 so paul moore is the CTO of Centrify. They use our code base to integrate everything around AD. I spoke with him last week about joining. I'm 90% sure that will happen. He may join our Board From: To: Time: Mon Jul 30 11:09:20 2007 he's been posting to kerberos_v5_dev From: To: Time: Mon Jul 30 16:57:37 2007 BTW, I sent email poking Coverity again. From: To: Time: Mon Jul 30 18:12:20 2007 Friday's mail fell off the sendmail logs already. From: To: Time: Mon Jul 30 18:14:49 2007 Mark's report of Nico's suggestion (which I didn't see in Nico's mail to the list) actually sounds pretty reasonable: Store the credentials under both names (well, when we know two names that are applicable). From: To: Time: Mon Jul 30 18:15:34 2007 On a related note, maybe foo/bar should mean foo/bar@ instead of foo/bar@LOCAL.REALM in some contexts. From: To: Time: Mon Jul 30 18:30:01 2007 On another only vaguely related note, when Tom and I were talking at IETF, it occurred to me that it might not be that hard to add some minimal referrals support to our KDC. Look for NT-HOST or two-component names with the first component in a magic list; if the second component looks like a non-local FQDN, use the domain_realm mapping on the KDC to figure out where it lives. (And if it's in the local realm, well, you lose, because we don't do server principal aliases.) From: To: Time: Mon Jul 30 18:30:24 2007 Of course, getting a finalized spec first would be nice. *sigh* From: To: Time: Mon Jul 30 19:29:58 2007 So, last week, I was contemplating the use of counter mode ciphers in Kerberos. The way our code is designed, it would be difficult if not impossible to avoid reuse of counter values, but is it inherent in the protocol? Assume for the sake of argument that each system (or each server cluster) has the ability to track the range of counter values used by that system associated with a given key. The two halves of a given exchange also need to avoid duplicating counter values, but the counter-value space (or, for a scheme like GCM, the nonce space) could be split in half, with one bit (conceptually, at least) used to indicate initiator vs acceptor, client vs server, whatever. It's not currently supplied to our abstract crypto API, but that could be changed. From: To: Time: Mon Jul 30 19:32:59 2007 how large is your counter space? if you use a good PRNG with a large enough counter space, do you actually have a problem? From: To: Time: Mon Jul 30 19:36:09 2007 Sometimes no more than 2**32. And in some modes, the risk of reusing a counter value is high. From Morrie Dworkin's talk on GCM, I got the impression that you'd lose integrity protection, at least, for all uses of that key to a relatively easy brute-force attack. From: To: Time: Mon Jul 30 19:46:33 2007 So I kind of think we'd want an actual guarantee of non-overlap. As long as there's a counter/nonce bit we could steal, and set from an initiator/acceptor flag, it might be doable. (In theory -- tracking the counter values system-wide is probably enough of a problem for user-mode software that we wouldn't actually want to do it. For specialized kernel implementations, on the other hand, there might be some benefit, especially if you've got hardware support.) From: To: Time: Mon Jul 30 19:47:08 2007 Like I said, just something I was contemplating. I'm not planning to write up specs or anything. From: To: Time: Mon Jul 30 19:57:51 2007 Except rfc3961 doesn't give you such a bit. I'd really like to see it done using random counters if we can show that's secure From: To: Time: Tue Jul 31 15:56:44 2007 Did anybody see a reply to RT5609 that I made about an hour ago? From: To: Time: Tue Jul 31 15:56:58 2007 That is, did you receive email that there was a reply? From: To: Time: Tue Jul 31 15:59:07 2007 The database sees it. I'm not sure you would because you're directly on the cc list and I think rt does not send you mail you created. From: To: Time: Tue Jul 31 16:54:09 2007 OK, this whole goals thing is a mess. From: To: Time: Tue Jul 31 16:58:10 2007 it's certainly somewhat challenging to chase down all the CG/HR documents From: To: Time: Tue Jul 31 17:01:00 2007 Yeah. I need to see if I can go dig up a copy of our operational plan. From: To: Time: Tue Jul 31 17:24:54 2007 Ah, no wonder no one has managed to find the right magic to fill in for the how does this relate to the blah blah blah link: as far as I can tell the document you need exists no where on the web. From: To: Time: Tue Jul 31 17:30:06 2007 oh right. it was sent out as a .doc by Rosalind to isda. From: To: Time: Wed Aug 1 18:25:14 2007 yay! (pkinit merged.) From: To: Time: Wed Aug 1 18:31:56 2007 hi jeff! From: To: Time: Wed Aug 1 18:33:06 2007 hi ken. From: To: Time: Wed Aug 1 18:33:47 2007 I think my e-mail to krbcore answers Kevin's posting here around 4pm. The answer is no one saw it. From: To: Time: Wed Aug 1 18:34:17 2007 I'm wondering, is it the team's intention to release KFW 3.2.1 next week? From: To: Time: Wed Aug 1 18:35:14 2007 well, where should the mail go? do we create a new list for kfw ticket changes? From: To: Time: Wed Aug 1 18:36:07 2007 at the very least I would like to see it go to the queue admins where kevin and I should be listed as admins From: To: Time: Wed Aug 1 18:37:02 2007 you're both on there currently From: To: Time: Wed Aug 1 18:37:09 2007 I seem to receive a message indicating that the ticket was created but not when it is changed From: To: Time: Wed Aug 1 18:37:10 2007 on adminccs for the kfw queue that is From: To: Time: Wed Aug 1 18:38:46 2007 perhaps there is a setting that controls when messages are sent to adminccs that is configured only for creation From: To: Time: Wed Aug 1 18:38:57 2007 hm. that might be it. From: To: Time: Wed Aug 1 18:39:02 2007 I guess we should have a redist list. We could do it parallel to krb5-bugs. It's kind of ugly, but I don't think we want it to be a discussion list that doesn't feed into the bug database. From: To: Time: Wed Aug 1 18:39:44 2007 having a mailing list setup that parallels kfw-bugs would be nice. I'm sure that there are others who would like to pay attention to the changes. From: To: Time: Wed Aug 1 18:40:00 2007 Asanka and Danny Mayer come to mind From: To: Time: Wed Aug 1 18:40:17 2007 and perhaps Chris Clausen From: To: Time: Wed Aug 1 18:41:41 2007 The krb5-bugs setup uses two lists, an "incoming" list on the mailman server that is fed from krb5-bugs@mit, and a list known as "krb5-bugs" on the mailman server, that advertises itself as (but isn't) krb5-bugs@mit, and to which people can subscribe. So when they reply to the (supposed) list address, it really feeds back into the database. From: To: Time: Wed Aug 1 18:42:28 2007 the existing krb5-bugs setup is special, and probably difficult to replicate for kfw-bugs due to requiring manual configuration by jis. From: To: Time: Wed Aug 1 18:42:34 2007 I think I'd probably like to see the traffic too. From: To: Time: Wed Aug 1 18:42:55 2007 I wouldn't object to that traffic going to the krb5-bugs output list From: To: Time: Wed Aug 1 18:43:06 2007 Yeah. But I don't think we have a general solution to the problem -- though I haven't gone back and re-thought what other approaches might work. From: To: Time: Wed Aug 1 18:43:26 2007 We could do that too, if people wouldn't mind too much... From: To: Time: Wed Aug 1 18:43:27 2007 i don't know if the people subscribed to krb5-bugs all want to see kfw bug traffic. From: To: Time: Wed Aug 1 18:43:28 2007 will RT care if it receives a message on krb5-bugs for a ticket in the kfw-bugs queue? From: To: Time: Wed Aug 1 18:43:48 2007 it'll send it to the correct queue if the subject tag is there. From: To: Time: Wed Aug 1 18:43:56 2007 No, I think anything that's a reply to RT outgoing messages will have a subject that points to a particular ticket, so the queue doesn't matter. From: To: Time: Wed Aug 1 18:44:30 2007 In fact, that's how I've hacked some of the RT addresses to avoid spam -- if you omit the subject tag, the command line specifies a default queue of "spam" which no one has write access to. From: To: Time: Wed Aug 1 18:45:15 2007 for the time being if adminccs can be sent messages for all changes that is probably a good start. From: To: Time: Wed Aug 1 18:45:26 2007 i fixed the adminccs to get correspondence and comments From: To: Time: Wed Aug 1 18:46:00 2007 if asanka@mit.edu could be added to kfw-bugs as an admincc that would also be useful. If not, I can forward to him From: To: Time: Wed Aug 1 18:46:50 2007 (*sigh* must focus. brain still churning on the "ipv6 as metric system" comparison doug otis brought up, and "great white north", and a possible skit...) From: To: Time: Wed Aug 1 18:47:03 2007 so how much traffic is generated from kfw-bugs and related discussion? From: To: Time: Wed Aug 1 18:47:09 2007 very very little From: To: Time: Wed Aug 1 18:47:21 2007 kevin's tickets were the first in months From: To: Time: Wed Aug 1 18:47:33 2007 So, the krb5-bugs outgoing list might be an okay place to send it. From: To: Time: Wed Aug 1 18:47:35 2007 kfw 3.2 addressed most people's issues From: To: Time: Wed Aug 1 18:52:08 2007 would kfwdev be an acceptable place? From: To: Time: Wed Aug 1 18:52:18 2007 yes From: To: Time: Wed Aug 1 18:52:59 2007 Do we want replies to automatically feed back into the tickets? I would think we would, but I don't think we want RT on the kfwdev list. From: To: Time: Wed Aug 1 18:54:07 2007 can a reply-to be set to kfw-bugs? From: To: Time: Wed Aug 1 18:55:00 2007 frobbing reply-to is a bit more involved From: To: Time: Wed Aug 1 18:59:19 2007 but if RT is on the kfwdev list and the subject line is not a ticket number, its going to be spam junked anyway, isn't it? From: To: Time: Wed Aug 1 18:59:37 2007 its not like kfwdev gets even dozens of e-mails a month From: To: Time: Wed Aug 1 19:00:58 2007 hmm... yeah, though not if someone follows up to a krb5-bugs message but intentionally redirects traffic to krbdev; we'd be changing that behavior as well, and I'm not sure I'd want that. From: To: Time: Wed Aug 1 19:01:12 2007 (if they keep the rt subject) From: To: Time: Wed Aug 1 19:01:57 2007 i changed the correspondence address for kfw to kfw-bugs@mit.edu so it'll filter through mailman. From: To: Time: Wed Aug 1 19:02:12 2007 also added kfwdev@mit.edu to adminccs for kfw From: To: Time: Wed Aug 1 19:02:19 2007 well, at least then I will be able to moderate it From: To: Time: Wed Aug 1 19:07:31 2007 who's austinj? From: To: Time: Wed Aug 1 19:07:48 2007 who? From: To: Time: Wed Aug 1 19:08:33 2007 Someone Tom added to RT and krbcore. From: To: Time: Wed Aug 1 19:09:00 2007 External contact I guess. From: To: Time: Wed Aug 1 19:13:13 2007 Hm, so I got Parallels to install Windows without crashing OS X, finally. Unfortunately, I didn't tweak just one variable. A couple security updates, disabling the vmware kernel extensions, and maybe one or two other things. So, still not sure how stable it's going to be for me. From: To: Time: Wed Aug 1 19:13:47 2007 austinj is an Apple contact From: To: Time: Wed Aug 1 19:20:48 2007 does someone want to test my RT queue changes? From: To: Time: Wed Aug 1 19:20:54 2007 sure From: To: Time: Wed Aug 1 19:22:49 2007 hm, hit a mod queue From: To: Time: Wed Aug 1 19:23:06 2007 I sent one via e-mail and one via the web interface From: To: Time: Wed Aug 1 19:24:25 2007 hm, i think i have forgotten that the "correspond address" is used as the "From:" header From: To: Time: Wed Aug 1 19:25:39 2007 I received the create messages but not the reply or comment updates to 5618 From: To: Time: Wed Aug 1 19:25:52 2007 Tom, by "krbcore group" did you mean Moira or something in RT? From: To: Time: Wed Aug 1 19:26:02 2007 krbcore RT group From: To: Time: Wed Aug 1 19:26:37 2007 messages may have been held up in moderation. lemme check. From: To: Time: Wed Aug 1 19:26:38 2007 received the reply and comment messages From: To: Time: Wed Aug 1 19:27:05 2007 Ah, okay. From: To: Time: Wed Aug 1 19:27:24 2007 let's test replies via e-mail From: To: Time: Wed Aug 1 19:29:31 2007 hm, interesting, my mail reader marked all four messages i got so far as spam. :) From: To: Time: Wed Aug 1 19:30:43 2007 looks like its working From: To: Time: Wed Aug 1 19:31:14 2007 well one message got hung up in moderation due to implicit destination which i'm still working on From: To: Time: Wed Aug 1 19:35:20 2007 Weird. I re-enabled the vmware drivers and started the windows-under-parallels install again (express install, mit iso install image), and it failed with "Run a DLL as an App has encountered a problem". Oh, but it's actually still doing something... From: To: Time: Wed Aug 1 19:36:08 2007 can you actually install vmware and parallels on the same machine? From: To: Time: Wed Aug 1 19:37:00 2007 Apparently. :) Whether they'll both still work, well, I'm investigating. From: To: Time: Wed Aug 1 19:37:51 2007 anyway for now i've enabled implicit destination for kfwdev; i'll work on getting RT to put something sane in the To: line later. From: To: Time: Wed Aug 1 19:43:42 2007 Oh, the express install defaults to shared networking. That's not gonna work. I'm not sure I trust Windows to not get infected by the time the install is done if its address is exposed. :( From: To: Time: Wed Aug 1 19:44:03 2007 oh well From: To: Time: Wed Aug 1 19:47:49 2007 wow, walk_realm_tree() spits out a format that none of its callers can use without munging it. From: To: Time: Wed Aug 1 19:48:30 2007 so now IPv4 address allocation mechanisms are being compared to the new orleans levees prior to Katrina From: To: Time: Wed Aug 1 19:52:01 2007 Foo, I mis-read. "shared" meaning NAT, not direct access to the interface. Duh. From: To: Time: Wed Aug 1 19:52:12 2007 bridged is direct From: To: Time: Wed Aug 1 19:52:18 2007 Yeah. From: To: Time: Wed Aug 1 19:54:52 2007 now i really want to make a walk_realm_tree() replacement that spits out a digraph or somehting. From: To: Time: Wed Aug 1 19:55:08 2007 Go for it. From: To: Time: Wed Aug 1 19:55:09 2007 of course that's a somewhat long-term goal From: To: Time: Wed Aug 1 19:55:14 2007 Yeah, well. From: To: Time: Wed Aug 1 19:55:51 2007 probably not a raw adjacency list because we want some edge info like hierarchical vs capath vs .... From: To: Time: Wed Aug 1 19:58:40 2007 Weird. If I try doing a non-express install, it says "unable to allocate virtual machine memory". The VM is configured for 512MB, and the partition has 10G free. From: To: Time: Wed Aug 1 20:02:19 2007 Same for express install. But quitting and restarting parallels seems to have fixed it. *sigh* From: To: Time: Wed Aug 1 21:29:34 2007 huh. the install went okay this time, when i was paying closer attention so i could gather info to file a bug report. From: To: Time: Thu Aug 2 16:14:32 2007 pkinit merge broke nightly snapshots due to some error in admin.texinfo From: To: Time: Fri Aug 3 19:26:19 2007 why oh why is the basic indent in cc_file.c *5* columns? From: To: Time: Fri Aug 3 19:28:54 2007 If there were a point in time when it wouldn't mess with merging patches, I'd be tempted to go through the tree, reindenting most of the C source files, and adding emacs local-variables sections for imported files where we'd logically keep the native style. From: To: Time: Sun Aug 5 02:02:26 2007 MIt Kerberos Development Team From: To: Time: Sun Aug 5 02:02:27 2007 raeburn@mit.edu has set the topic to: Kerberos discussion — log at http://opteron-prime.mit.edu/~hartmans/krb5.log.txt From: To: Time: Mon Aug 6 13:51:44 2007 ow, I am sick From: To: Time: Mon Aug 6 13:52:04 2007 to the point of ow? From: To: Time: Mon Aug 6 13:52:05 2007 I will drag myself in for the meeting but don't expect me in before that From: To: Time: Mon Aug 6 13:52:16 2007 It's in my sinuses :-( From: To: Time: Mon Aug 6 13:52:19 2007 ow From: To: Time: Mon Aug 6 13:52:45 2007 I think I will try sudafed. Currently it feels like my head is going to explode From: To: Time: Mon Aug 6 14:19:30 2007 the trunk once again builds as part of kfw. The required changes to krb5 included revisions 19754 and 19755. There was also a required change to pismere krb4/include/com_err.h to prevent incompatible declaration collisions with the real krb5 distributed com_err.h. Post 1.6, an include "com_err.h" was added to "k5-int.h". The side-effect of that change is that the "com_err.h" that is included by "k5-int.h" is always the one found in the same directory as "k5-int.h". This broke the compilation of source files that required both krb4 and krb5 headers when the krb5 tree is being built with the ALTERNATE_KRB4_INCLUDE option. Instead of the krb4 version being used consistently, now the krb4 and krb5 versions were being mixed. I addressed this in the krb4 version by defining "__COM_ERR_H" in order to prevent the processing of the krb5 version after the krb4 version had already been processed. From: To: Time: Mon Aug 6 14:33:14 2007 doing anything with inclusion protection macros except in the exact header file defining them is a bad idea. this may be ok as an interim solution though. From: To: Time: Mon Aug 6 14:33:45 2007 my other option is a re-write of the krb4 com_err and that is not an option From: To: Time: Mon Aug 6 14:34:47 2007 imho nested includes are to be used with extreme caution for exactly these sorts of reasons. From: To: Time: Mon Aug 6 14:36:12 2007 the incompatibilities are: * use of "const char *" in krb5 vs "char *" in krb4 * krb5 com_err() returns void whereas krb4 com_err() returns int * krb5 error_message() is KRB5_CALLCONV whereas krb4 error_message() is the default calling convention From: To: Time: Mon Aug 6 15:02:59 2007 So, I thought we agreed to handle the com_err issue by making the com_err definitions consistent. From: To: Time: Mon Aug 6 15:03:36 2007 do we run into problems with ABI compatibility? From: To: Time: Mon Aug 6 15:04:22 2007 If doing so was a trivial change that would have been fine. for example, if it were just the const-ness I would have done that. but since the change requires an ABI change in the exported function definitions, that is not an option. From: To: Time: Mon Aug 6 15:05:04 2007 doing so would break applications that are linked to the krb4 versions From: To: Time: Mon Aug 6 15:07:51 2007 so, yes, we had agreed to fix the header file. However the person (Ken?) proposing that did not notice the calling convention issue. However the current state seems kind of broken in that if the krb5 library calls error_message in some directory that does not use alternate includes then it will get the wrong ABI, right? From: To: Time: Mon Aug 6 15:09:25 2007 I'm not sure how that follows. Only in cases where ALTERNATE_KRB4_INCLUDE And ALTERNATE_KRB4_LIB are specified (krb524) do we want to use the krb4 version of com_err(). In all other cases, you want the krb5 version. From: To: Time: Mon Aug 6 15:10:21 2007 Which com_err do we install? I didn't think it was both of them. From: To: Time: Mon Aug 6 15:11:21 2007 Previous to the change that added com_err.h to k5-int.h, the behavior was "use krb4 versions if alternate is specified, otherwise use krb5". The change to k5-int.h altered this behavior because now the krb5 header is included within k5-int.h regardless of even when ALTERNATE_KRB4_INCLUDE is specified. From: To: Time: Mon Aug 6 15:11:47 2007 The change I made restores the behavior we have been using forever From: To: Time: Mon Aug 6 15:12:00 2007 Your statement, while true, is not responsive to my question From: To: Time: Mon Aug 6 15:12:15 2007 don't be impatient From: To: Time: Mon Aug 6 15:13:27 2007 we install the krb5 com_err.dll but the krb4 com_err functions are included in the krb4 dll. From: To: Time: Mon Aug 6 15:14:43 2007 Ah. Do they share an et_list? I.E. what happens when you use both in the same application? From: To: Time: Mon Aug 6 15:15:43 2007 Actually, I'm not at all convinced it matters much. Once krb4 goes away this is a non-issue and trying to adjust it before then would be challenging if possible From: To: Time: Mon Aug 6 15:15:50 2007 they should not share an et_list and they shouldn't both be used in the same application. From: To: Time: Mon Aug 6 15:16:55 2007 I don't think that it matters at all which is why all I care about is getting back to the state where things were before the addition of com_err.h to k5-int.h From: To: Time: Mon Aug 6 15:31:18 2007 I cannot wait until KFW 4.0 when we can drop the krb4 library entirely From: To: Time: Mon Aug 6 15:55:48 2007 the pkinit patches to src/libkrb5/krb/preauth2.c leak memory when grow_pa_list() returns ENOMEM. From: To: Time: Mon Aug 6 16:09:03 2007 Leaking memory on ENOMEM is nothing new for our code, I think. :( From: To: Time: Mon Aug 6 16:09:55 2007 are you saying it doesn't need to be fixed? From: To: Time: Mon Aug 6 16:10:46 2007 No, just that it hasn't been a big priority so far. But if you find a case that's easy to fix, there's nothing wrong with fixing it. From: To: Time: Mon Aug 6 16:11:46 2007 We should make an effort to clean that sort of thing up, someday. But that's probably a big project. From: To: Time: Mon Aug 6 16:12:10 2007 but this is new code? From: To: Time: Mon Aug 6 16:12:21 2007 ! From: To: Time: Mon Aug 6 16:12:39 2007 Yeah, shouldn't have slipped by. Oops. From: To: Time: Mon Aug 6 16:26:45 2007 I think the asn.1 code is particularly bad. We probably leak memory if you get a corrupted message. From: To: Time: Mon Aug 6 16:32:18 2007 are you describing the pkinit asn.1 or the krb5 asn.1 in general? From: To: Time: Mon Aug 6 16:34:57 2007 in general From: To: Time: Mon Aug 6 16:37:37 2007 e.g., asn1_decode_principal_name allocates space for a krb5_data, then if asn1_decode_generalstring fails, returns without freeing the space. this is inside a loop over the components. From: To: Time: Mon Aug 6 16:38:41 2007 oh, i just discovered that in the current referrals implementation, we only cache the first referral TGT from the local KDC, not the one that reaches the destination realm. From: To: Time: Mon Aug 6 16:50:50 2007 so given that we don't currently cache the destination realm TGT for the referrals case, should i do likewise for the off-path TGT case? From: To: Time: Mon Aug 6 16:59:26 2007 We should cache the ticket received from the local kdc (first ticket) and the final ticket (service ticket) and nothing else From: To: Time: Mon Aug 6 16:59:52 2007 For on-path you can cache more From: To: Time: Mon Aug 6 17:00:14 2007 so if the off-path TGT comes from an on-path non-local realm we don't cache that one either? From: To: Time: Mon Aug 6 17:04:55 2007 Correct. Your path is a->b->c->d. You get a referral for e when you ask b for c. You don't know that if you had asked a for e you would get b. In the on-path case the client is saying it has enough knowledge to trust the delegation as a general delegation. By definition that's not true of an off-path case From: To: Time: Mon Aug 6 17:06:08 2007 so basically only trust the local KDC to refer us to somewhere we don't have configured, at least for caching purposes? From: To: Time: Mon Aug 6 17:06:24 2007 er, s/only trust/ trust only/ From: To: Time: Mon Aug 6 17:07:24 2007 Well, we trust whomever the local kdc tells us to trust, but only for this one final destination. From: To: Time: Mon Aug 6 17:07:30 2007 But besides that yes From: To: Time: Mon Aug 6 17:08:01 2007 Athena vm is hvm? From: To: Time: Mon Aug 6 17:08:07 2007 mix From: To: Time: Mon Aug 6 17:11:11 2007 According to "svn annotate" the inclusion of com_err.h from k5-int.h was added in 2003, not post-1.6. From: To: Time: Mon Aug 6 17:11:42 2007 did something else change to cause k5-int.h to get included on some Windows-specific thing? From: To: Time: Mon Aug 6 17:12:26 2007 possibly the krb524 code didn't include it before From: To: Time: Mon Aug 6 17:13:12 2007 Jeff, to be clear, I was not objecting to your change once I realized that our original proposal was just wrong. I think that the com_err situation may be horribly broken on windows in KFW 3.2 but have chosen not to investigate whether I am correct or confused because even if I was correct I would not want to spend effort fixing the problem for krb4 apps From: To: Time: Mon Aug 6 17:14:56 2007 yeah, in r19544 I added k5-int.h to k524init.c... never suspecting the windows build environment could be so broken... From: To: Time: Mon Aug 6 17:19:56 2007 i reiterate my distaste for nested includes. From: To: Time: Mon Aug 6 17:21:04 2007 Avoiding nested includes would merely have hidden the brokenness, not fixed it. From: To: Time: Mon Aug 6 17:26:12 2007 Looking at k524init.c, I think all the calls to com_err are with error codes returned from krb5 routines, *not* krb4 routines. So I think we actually want to be using the krb5 version (both declaration and library) there. Otherwise, with an unshared error table list, we probably won't get correct error messages out. From: To: Time: Mon Aug 6 17:26:31 2007 And if the calling conventions differ, we could crash in error cases. From: To: Time: Mon Aug 6 17:26:57 2007 Oh, but com_err is variadic, I think there is only one calling convention. From: To: Time: Mon Aug 6 17:36:39 2007 Still, Jeff, with your fix, I'd be curious if you get messages for libkrb5-generated error codes. From: To: Time: Mon Aug 6 17:37:19 2007 (And, if we were to change the code to use error_message, whether it would crash.) From: To: Time: Mon Aug 6 17:43:47 2007 Random thought: Do we care about having more than one NAT network on krbdev-xen? E.g., we could isolate the network for Adam's testing framework (which people should be able to join via tunnels for running tests) from others, or separate developers' build systems from other systems, etc. Or do we just set up one, and assume that everything on it will be virus-free? Seems like a bad assumption... From: To: Time: Mon Aug 6 18:12:55 2007 I think at this point we don't need more than one nat network From: To: Time: Mon Aug 6 20:54:23 2007 ken, I do not doubt that com_err() in k524init.exe is broken. However, it has been broken since it was added and there has never been a complaint filed. It is no more broken today than it was a year ago. It is simply broken the same that it was. today's change does nothing to fix the broken behavior. If we were going to be supporting krb4, I would do something about it. since we have announced we are killing it off within the next nine months, why bother? From: To: Time: Mon Aug 6 20:54:42 2007 I just don't have cycles to waste on stuff we are getting rid of From: To: Time: Tue Aug 7 02:11:14 2007 I just ran a little test, and got a useful error message from com_err in the libkrb5 case. Looks like the krb4 library doesn't export the com_err function, so we pick up the krb5 version after all. But I still suspect it wouldn't be safe to change k524init.c to use error_message anywhere. From: To: Time: Tue Aug 7 04:21:05 2007 I also got a build failure on Windows when I used VMware Fusion's host-file-system access for the build drive instead of local disk. It failed in a command to copy some krb4 headers around, one which is hidden with "@" in the makefile rule for some reason. From: To: Time: Tue Aug 7 12:40:50 2007 I'm out sick today. My cold is being annoying From: To: Time: Tue Aug 7 16:03:15 2007 krb5-bugs was holding some of the kfw RT traffic for moderation because "rt" != "rt-comment" From: To: Time: Wed Aug 8 00:58:33 2007 Mmm, random wishlist item: A way of doing "svn ci" or "svk ci" with a log message that has various RT tags, plus a one-line description, all specified from the command line. Oh, and while I'm at it, the description might as well be word-wrapped if it exceeds 80 columns. From: To: Time: Wed Aug 8 00:59:00 2007 I suppose a little script could create a temporary file for the log message, and rewrite the argument list appropriately. From: To: Time: Wed Aug 8 01:35:54 2007 I find svk commit -m "foo bar baz " works ok for that From: To: Time: Wed Aug 8 01:39:08 2007 Ah. I've always been skeptical of using newlines in shell commands. But if it works... From: To: Time: Wed Aug 8 01:40:28 2007 Is there any news on the doxygen work? From: To: Time: Wed Aug 8 01:41:15 2007 As best I can tell that project has failed yet again. Technically speaking we don't know until Aug 31 but I strongly suspect we will not see any more than we have. From: To: Time: Wed Aug 8 01:41:37 2007 *sighs* From: To: Time: Wed Aug 8 15:02:38 2007 So, our krbdev-xen NAT situation seems to be, NAT isn't working, and Adam and Sam can't figure out why, and AFAIK we have no more comparable Linux iptables or xen expertise. Is that about right? Why are we not using VMware again? From: To: Time: Wed Aug 8 15:23:54 2007 should I ship Apple the tip of the krb5-1-6 branch or the krb5-1-6-2 tag? From: To: Time: Wed Aug 8 15:28:52 2007 ah I think I just answered my own question. there's at least one bug Apple wants fixed which is pulled up but tagged for krb5-1.6.3 From: To: Time: Wed Aug 8 15:28:54 2007 It seems to be a rhel4 problem or something. I've gotten exactly the configuration he's expecting to work to be happy on my machines. It's also working on his private machine. We're not using vmware because 1) ops runs Xen boxes not vmware boxes 2) I have a lot more familiarity with xen debugging than vmware debugging From: To: Time: Wed Aug 8 15:29:37 2007 I asked Adam a few debugging questions last time we talked. I don't remember the questions but would appreciate knowing the answers From: To: Time: Wed Aug 8 15:30:34 2007 So, if "ops runs Xen boxes" then we should just be able to say ops should give us one with a working NAT configuration? From: To: Time: Wed Aug 8 15:31:08 2007 No, they do not support nat From: To: Time: Wed Aug 8 15:31:30 2007 Ah. From: To: Time: Wed Aug 8 16:04:29 2007 Who is the right person to ask for access to krbdev-xen? From: To: Time: Wed Aug 8 16:05:33 2007 me. I got your mail. I want to sit down with you and go over security procedures etc. If you are going to be in Friday you should schedule a meeting on my calendar for us to discuss. From: To: Time: Wed Aug 8 16:05:39 2007 I'm sorry I did not respond From: To: Time: Wed Aug 8 16:06:53 2007 You talkin' to me? From: To: Time: Wed Aug 8 16:08:16 2007 Yep From: To: Time: Wed Aug 8 16:09:13 2007 I'm not sure what email you received and why you think you are late responding to something. From: To: Time: Wed Aug 8 16:10:13 2007 From: "Kevin Koch" Subject: root access to krbdev-xen? To: "Sam Hartman" , "'Ken Raeburn'" Date: Mon, 6 Aug 2007 17:28:16 -0400 From: To: Time: Wed Aug 8 16:40:53 2007 ah, hi: == hartmans: Sorry, wasn't sure if you wanted a reply, since I didn't learn much... You asked me to look into the internal table on krbdev-xen that tracks NATted connections, I believe, and see if I saw anything unusual. From: To: Time: Wed Aug 8 16:41:01 2007 The table's in /proc/net/ip_conntrack (and /proc/sys/net/ipv4/netfilter/ip_conntrack_* appear to be relevant control files). From: To: Time: Wed Aug 8 16:41:07 2007 I didn't find anything obviously different in that file on krbdev-xen, from that file in a similar state on a working system From: To: Time: Wed Aug 8 16:41:16 2007 I did try pinging, trying to get Web pages, etc., to generate different traffic. The contents of the file continued to look sane, though I can't say I'm 100% sure what to look for. From: To: Time: Wed Aug 8 16:41:24 2007 (if you had any other questions, I've forgotten what they were since then; if you remember what they were, though, I may have checked them) From: To: Time: Wed Aug 8 17:18:51 2007 Any reason I shouldn't kill the SunOS 4 support? Aside from that, some of the compile/link commands are pretty regular and shlib.conf could probably be simplified a bit. From: To: Time: Wed Aug 8 17:21:51 2007 No, please kill sunos4. I'm reasonably certain that it would fail in other ways From: To: Time: Wed Aug 8 17:22:07 2007 And death to its not quite posix not quite termios From: To: Time: Wed Aug 8 17:50:28 2007 yay Ticket cache: FILE:/tmp/krb5cc_18940.0 Default principal: tlyu@A Valid starting Expires Service principal 08/08/07 17:42:30 08/08/07 18:42:30 krbtgt/A@A renew until 08/08/07 20:42:30 08/08/07 17:42:38 08/08/07 18:42:30 krbtgt/B@A renew until 08/08/07 20:42:30 08/08/07 17:42:38 08/08/07 18:42:30 testfoo@C renew until 08/08/07 20:42:30 From: To: Time: Thu Aug 9 10:10:30 2007 query for the NAT problem: Has anyone gotten NAT working on a vanilla (or a different Xen) rhel 4 box? I'm trying to debug in a VM (so that I can do uglier things than I'd want to do on a live server), wondering how close it should be to krbdev-xen From: To: Time: Thu Aug 9 10:11:39 2007 (Xen does run inside VMWare, though not the reverse) From: To: Time: Thu Aug 9 15:25:51 2007 i get a huge pile of conflicts trying to pull up r19618 From: To: Time: Thu Aug 9 15:35:32 2007 i wonder if it's eol-style From: To: Time: Thu Aug 9 16:40:39 2007 no, apparently it's not just eol-style From: To: Time: Thu Aug 9 17:04:59 2007 ok, this is going to take quite some time to sort out. From: To: Time: Thu Aug 9 17:06:33 2007 and it's certainly the case that eol-style is hurting things a lot From: To: Time: Thu Aug 9 17:08:30 2007 is the version in svn inconsistent within any given file? Otherwise could you just mass-convert your local copy to the same eol-style? From: To: Time: Thu Aug 9 17:09:06 2007 some stuff on the trunk has been converted to eol-style:native but the krb5-1-6 branch has not, etc. From: To: Time: Thu Aug 9 17:09:13 2007 ah From: To: Time: Thu Aug 9 17:09:15 2007 which makes merging changes really annoying From: To: Time: Thu Aug 9 17:09:17 2007 Are there changes to this file that should not end up on the branch? If not, why not copy the file From: To: Time: Thu Aug 9 17:09:50 2007 Adam is there anything I can do to help with nat mess? From: To: Time: Thu Aug 9 17:10:08 2007 i don't know yet. there are hundreds of files touched it looks like. From: To: Time: Thu Aug 9 17:10:58 2007 nat: I was just composing mail about that, actually. I've done some testing (I was sending details/procedure/etc., for people to sanity check), and it looks to me to be a rhel 4-specific issue From: To: Time: Thu Aug 9 17:11:17 2007 ie., still there if Xen goes away, not there in rhel 5 From: To: Time: Thu Aug 9 17:12:11 2007 Does it go away if you turn off spoof protection? From: To: Time: Thu Aug 9 17:12:17 2007 i can't tell if the conflicts are real or not easily. From: To: Time: Thu Aug 9 17:14:46 2007 Being rhel4 specific is useful. I think that means we can ask the union of ops+computing-help and probably get an answer. However I'd start with ops. Follivng the CHD path is going to be really frustrating. From: To: Time: Thu Aug 9 17:16:35 2007 spoof protection: I believe that's controlled by "/proc/sys/net/ipv4/conf/all/rp_filter"? That doesn't seem to help... I just tested it on a vanilla rhel 4 VM, for good measure From: To: Time: Thu Aug 9 17:16:40 2007 Tom, does Kevin have anything useful to say about the changes? From: To: Time: Thu Aug 9 17:17:17 2007 Turning that off doesn't seem to help? In one way that's good. From: To: Time: Thu Aug 9 17:17:59 2007 /all/ was 0 already, actually. /natbr1/ (the bridge interface I'm using) was 1; I set it to 0 and observed no change From: To: Time: Thu Aug 9 17:18:33 2007 (assuming 0 is Off, rather than True) From: To: Time: Thu Aug 9 17:18:45 2007 I'd flush the nat table after frobbing that and try again. But I expect you'll see no change From: To: Time: Thu Aug 9 17:18:53 2007 0 is off From: To: Time: Thu Aug 9 17:19:39 2007 flushing doesn't have any obvious effect From: To: Time: Thu Aug 9 17:19:46 2007 still no NAT From: To: Time: Thu Aug 9 17:21:13 2007 so ultimately what we want is zero difference between trunk/src/windows and branches/krb5-1-6/src/windows right? From: To: Time: Thu Aug 9 17:21:20 2007 OK. So, I'd write up mail describing this as a rhel4 problem to ops and asking them for help From: To: Time: Thu Aug 9 17:22:23 2007 ok. Should I send mail with a summary of how I narrowed it down, in case I did something silly (or in case anyone sees a pattern that I don't in which distro's worked)? From: To: Time: Thu Aug 9 17:22:30 2007 Tom, that is what Kevin has been testing with. However it would probably be desirable if someone went through at least a svn log of changes commited on the trunk since the 1.6 branch cut to confirm there are not changes we really don't want From: To: Time: Thu Aug 9 17:22:57 2007 If you and Kevin decide to drop that check it is fine with me. From: To: Time: Thu Aug 9 17:23:07 2007 Adam, that's fine too From: To: Time: Thu Aug 9 17:23:07 2007 i thought he said that you and Kevin had done that check. From: To: Time: Thu Aug 9 17:23:53 2007 Kevin and I looked at patches applied to 1.6 since kfw 3.2.0 to confirm that basing 3.2.1 off the 1.6 branch rather than the 3.2.0 tag is OK From: To: Time: Thu Aug 9 17:24:04 2007 ok From: To: Time: Thu Aug 9 17:24:53 2007 it seems that svk is happier about doing merges if the property changes are actually committed, rather than being happy with them only in the working dir From: To: Time: Thu Aug 9 17:25:37 2007 now i've successfully merged 19618 on my local branch From: To: Time: Thu Aug 9 17:42:53 2007 tickets #5607 and #5609 have interdependent changes. this should never happen. From: To: Time: Thu Aug 9 17:48:20 2007 and r19744 of branches/krb5-1-6/src/windows/idenity/ui/credwnd.c was the one erroneously committed to the branch and doesn't apply cleanly to the trunk From: To: Time: Thu Aug 9 17:57:09 2007 oh this is quite a mess From: To: Time: Thu Aug 9 17:58:33 2007 I just tested changing the ip_forward and rp_filter values in /etc/sysctl.conf (in a vanilla rhel-4 VM) and rebooting. NAT didn't magically start working. Oh well, worth a shot. From: To: Time: Thu Aug 9 17:58:52 2007 (I've been hit with random sticky sysctl entries in the recent past) From: To: Time: Fri Aug 10 17:23:05 2007 Is there some magic incantation I should be using on a Mac to keep the portmapper available when "make check" gets to the RPC tests? From: To: Time: Fri Aug 10 17:42:19 2007 No idea From: To: Time: Fri Aug 10 17:43:18 2007 starting portmap manually doesn't work? From: To: Time: Fri Aug 10 17:43:27 2007 I found "launchctl start com.apple.portmap", which starts it, but it seems to quit after a little while if it doesn't have anything to do. Sometimes quickly enough that a full "make check" doesn't get as far as the RPC tests. From: To: Time: Fri Aug 10 17:43:48 2007 Generally, no, it complains that it's supposed to be started by launchd, and exits. From: To: Time: Fri Aug 10 17:44:02 2007 enable some RPC service in inetd.conf? From: To: Time: Fri Aug 10 17:44:42 2007 And I haven't figured out enough of the config file and rpc registration process to see if there's a way to tell launchd to start it when an RPC program using our library tries to register itself. (I think it'll start if something using the native RPC library tries to register itself.) From: To: Time: Fri Aug 10 17:45:03 2007 Hmm...maybe.... From: To: Time: Fri Aug 10 17:50:21 2007 Heh. inetd.conf says xinetd is used instead, oh, but use the "service" program instead of editing xinetd config files. And "service" appears to talk to launchd. From: To: Time: Fri Aug 10 17:53:27 2007 Oh, hello... http://www.corebounce.org/wiki/Soundium/PortmapMacosX says how to tell launchd that it's not an on-demand service but should be started at boot time. Maybe that'll do the trick. From: To: Time: Fri Aug 10 17:53:40 2007 have you tried addingOnDemand From: To: Time: Fri Aug 10 17:53:46 2007 oh, looks like you've found that From: To: Time: Fri Aug 10 19:18:03 2007 Oh, great. After all this work I'm doing to remap minor status codes coming out of GSSAPI, I find that the auth_gssapi code in the RPC library *sends* the major and minor status codes across the wire. No way that's gonna work cleanly. From: To: Time: Fri Aug 10 19:19:02 2007 Gosh, what a good thing it is that the normal response to RPC authentication errors in the kadm5 library is to return a totally generic and unhelpful error code that says only that a GSSAPI or Kerberos error happened... *grumble* From: To: Time: Fri Aug 10 19:19:46 2007 oh that's interesting From: To: Time: Fri Aug 10 19:20:16 2007 Ooh, and the RPC test programs, both client and server, have locked up on me. As in, "kill -9" doesn't seem to do anything. From: To: Time: Fri Aug 10 19:21:22 2007 Ah, well, they've chanegd state to "trying to exit", but they don't seem to be having much luck with that. From: To: Time: Sun Aug 12 02:02:28 2007 MIt Kerberos Development Team From: To: Time: Sun Aug 12 02:02:28 2007 raeburn@mit.edu has set the topic to: Kerberos discussion — log at http://opteron-prime.mit.edu/~hartmans/krb5.log.txt From: To: Time: Mon Aug 13 12:45:04 2007 Are we meeting today or not? From: To: Time: Mon Aug 13 12:46:06 2007 which of us are still around? From: To: Time: Mon Aug 13 12:46:20 2007 alexis is on vacation this week, right? From: To: Time: Mon Aug 13 12:47:25 2007 Yes. From: To: Time: Mon Aug 13 12:49:41 2007 Sam's email says he's on the west coast. (My notes from last meeting are on my laptop, which I'm not using at the moment; I don't recall if he said it was the entire week.) From: To: Time: Mon Aug 13 12:52:14 2007 i don't believe it was the entire week, but i'm not sure about that From: To: Time: Mon Aug 13 15:11:30 2007 Haven't seen anyone else on to discuss meeting. I'm running late heading to campus, though; if we are meeting, I won't be there until 3:45 or so. From: To: Time: Mon Aug 13 22:20:59 2007 Linux build fails now: Function encode_krb5_kdc_req_body should have calling convention 'KRB5_CALLCONV', but has 'default' instead. Function decode_krb5_as_req should have calling convention 'KRB5_CALLCONV', but has 'default' instead. Function krb5int_set_prompt_types should have calling convention 'KRB5_CALLCONV', but has 'default' instead. No calling convention specified for profile_get_values! No calling convention specified for profile_free_list! From: To: Time: Mon Aug 13 22:22:04 2007 I don't think the encode* and decode* functions should've been added to the export list. From: To: Time: Tue Aug 14 18:50:18 2007 We are in Portland OR today spending a day with Intel, we go to Seattle tomorrow, fly home Thursday arriving late. The intel meeting is going very well From: To: Time: Wed Aug 15 21:14:13 2007 Tom, the copy of the pismere build tree to AFS finished. From: To: Time: Wed Aug 15 21:21:19 2007 ok thanks From: To: Time: Wed Aug 15 21:21:47 2007 fyi the build tree is for archival purposes and not part of the main release From: To: Time: Wed Aug 15 21:22:49 2007 If Atticus is still working, could the public MSI be put on the website? If you say yes, I'll call him and check. From: To: Time: Wed Aug 15 21:24:10 2007 i've just copied it. it's not linked yet, but you can get there by editing the URLs in the obvious ways. From: To: Time: Wed Aug 15 21:36:11 2007 Ha!! Atticus and I moved his PC into my office so that it wouldn't be in mover-limbo all day tomorrow. Although Atticus is there (packing), he doesn't have a key to my office. So the MIT KfW3.2.1 will go online tomorrow. From: To: Time: Wed Aug 15 21:41:52 2007 ok. i will try to work on getting stuff announced tonight, but if that doesn't work out, tomorrow is mostly travel, so things may not get announced until friday. From: To: Time: Wed Aug 15 21:42:37 2007 ideally SWRT won't make a public announcement before we make our public announcement. what level of "online" are you speaking of? From: To: Time: Wed Aug 15 21:48:01 2007 going offline; private mail sent From: To: Time: Sun Aug 19 02:02:28 2007 This room is not anonymous. From: To: Time: Mon Aug 20 12:03:51 2007 This room is not anonymous. From: To: Time: Mon Aug 20 14:29:54 2007 So I've got this code that makes mechglue remap the individual mechanism's minor status codes into a counter, 1, 2, 3, ... and keep track of which mechanism OID and which mech-specific status code goes with each. Turns out, the RPC code knows that our GSSAPI implementation returns com_err codes from the Kerberos library in the minor status code, and looks for "service principal unknown" specifically. From: To: Time: Mon Aug 20 14:32:58 2007 I could change it to use the original status code if it hasn't already been used by another mechanism, and rip out the counter idea, and pre-load that one error code into the mapping, but which of the three OIDs for Kerberos do I record for it? Or do I force all three to map that code to itself? From: To: Time: Mon Aug 20 14:33:27 2007 Right now, I'm pre-loading it, but letting it map to 1, 2, and 3 for the three OIDs, and adjusted the RPC code to match. Ick. From: To: Time: Mon Aug 20 14:56:35 2007 in lib/gssapi/generic/util_errmap.c where does the errmap.h come from? From: To: Time: Mon Aug 20 14:57:29 2007 Generated by a perl script. Oh, I should've added it to generated stuff for mac, right? Sorry about that. From: To: Time: Mon Aug 20 15:00:13 2007 want me to fix it? From: To: Time: Mon Aug 20 15:00:54 2007 If you've got the files open anyways, sure. I was just about to pull up the makefile and look... From: To: Time: Mon Aug 20 15:01:16 2007 I changed the makefile and am running a build to test From: To: Time: Mon Aug 20 15:01:53 2007 I thought during the design process we said that if not already mapped you should return the unity mapping From: To: Time: Mon Aug 20 15:04:26 2007 Identity you mean? Maybe we did, if so I'd forgotten it. I'll fix that. That still leaves the question of which mechanism OID gets the identity mapping for that status code. I suppose it's mostly theoretical, as kadmin is mostly what we care about for RPC, and that means our implementation, which means we'll pretty much always wind up with the same OID. From: To: Time: Thu Aug 23 16:45:27 2007 [raeburn@mit.edu has set the topic to: Kerberos discussion — log at http://opteron-prime.mit.edu/~hartmans/krb5.log.txt] From: To: Time: Thu Aug 23 18:40:21 2007 why is the memory ccache linked list stuff broken out into utility functions and the corresponding file ccache stuff not? From: To: Time: Thu Aug 23 18:42:52 2007 Which utility functions are these? From: To: Time: Thu Aug 23 18:43:05 2007 new_mcc_data for starters From: To: Time: Thu Aug 23 18:47:48 2007 Oh. Looks like I did that while working on thread safety in that file. Multiple functions (generate_new, resolve) were updating the global linked list of mem ccaches and needed to be made thread-safe; a good time to factor out the common code. Did the file ccache code have a global linked list back then? From: To: Time: Thu Aug 23 18:49:06 2007 probably not, but i haven't checked for certain. also lots of discrepancies between the fcc_generate_new and fcc_resolve From: To: Time: Fri Aug 24 14:18:42 2007 sigh, it would be really nice if there weren't "I upgraded to Xcode 3" changes in the project files in addition to the real changes for the patches From: To: Time: Fri Aug 24 14:19:08 2007 agh From: To: Time: Fri Aug 24 14:19:13 2007 i wondered if that would happen From: To: Time: Fri Aug 24 14:19:28 2007 can we get away with using xcode 2.5? From: To: Time: Fri Aug 24 14:19:48 2007 well he didn't upgrade the project but there are totally changes in https://krbdev.mit.edu/rt/Ticket/Display.html?id=5644 which are entirely there because he opened the project with Xcode 3 From: To: Time: Fri Aug 24 14:20:34 2007 What's even more stupid is that afaict the only relevant change in that list of changes is the one to Common/Resources/Release.xcconfig. The rest of it is all changing hidden Xcode variables that aren't used From: To: Time: Fri Aug 24 14:21:53 2007 Maybe those variables aren't hidden in xcode 3 but still, who cares if gcc debugging is turned on in a target which consists of a python script :-P From: To: Time: Fri Aug 24 14:22:54 2007 Or our configure script build phase, which also carefully has GCC_GENERATE_DEBUGGING_SYMBOLS set for it once his changes are applied From: To: Time: Fri Aug 24 14:23:12 2007 if our configure script cares about GCC_GENERATE_DEBUGGING_SYMBOLS I will be shocked From: To: Time: Fri Aug 24 15:20:06 2007 I just ran into Dan Geer at the gas station. From: To: Time: Fri Aug 24 15:20:17 2007 And my car passed inspection. Fourth time's the charm. From: To: Time: Fri Aug 24 16:01:49 2007 Sigh, why are so many of these patches things that break stuff I do as part of the release process? :-( From: To: Time: Fri Aug 24 16:03:33 2007 Also any of the build system ones could explain why the change was necessary since by definition they all work just fine the way they are. From: To: Time: Fri Aug 24 16:03:42 2007 for me, that is From: To: Time: Fri Aug 24 16:04:23 2007 The Apple patches, or stuff we've inflicted^H^H^H^H^H^H^H^H^H changed recently? From: To: Time: Fri Aug 24 16:04:32 2007 Apple patches From: To: Time: Fri Aug 24 16:04:55 2007 you guys are pretty good about writing commit messages, even for build system changes ;-) From: To: Time: Fri Aug 24 16:05:21 2007 For example: From: austinj@mit.edu Subject: SVN Commit Applying Apple patch: DVG+SC-Makefile.patch (skipping hunk 2) Commit By: austinj Revision: 6316 Changed Files: U users/austinj/Makefile_changes/Makefile From: To: Time: Fri Aug 24 16:05:38 2007 That's all the info I have on that change and it breaks my builds if applied ;-) From: To: Time: Fri Aug 24 16:06:09 2007 I know why it doesn't break their builds -- they're not using the split build system I created for them so they could build the framework and clients separately From: To: Time: Fri Aug 24 16:07:02 2007 I'm really not sure how you can label changes to a Makefile less informatively than with "Makefile changes" ;-) From: To: Time: Fri Aug 24 16:08:10 2007 Give them time. From: To: Time: Fri Aug 24 16:08:22 2007 hehe From: To: Time: Fri Aug 24 16:12:36 2007 Some of the krb5 ones could use a little more info. Like https://krbdev.mit.edu/rt/Ticket/Display.html?id=5657 doesn't contain enough information to tell if they need exactly that change or if that was a quick fix to get it working and there is a fix which would make it work for all OSes From: To: Time: Fri Aug 24 16:22:16 2007 That one's kind of interesting. They patched krb5-config.in to switch from replacing $(PROG_LIBPATH) with a -L option, to just removing $(PROG_LIBPATH). If the libraries are going into standard directories searched by the linker, that would be the right thing. And if you want special options to support frameworks, we don't support that either. From: To: Time: Fri Aug 24 16:22:39 2007 "/usr/bin/krb5-config --libs krb5" on tiger starts with "-L/usr/lib", which is kind of silly. From: To: Time: Fri Aug 24 16:24:16 2007 I'll reply to that one and ask for a little clarification. From: To: Time: Fri Aug 24 16:24:17 2007 well we don't actually want the framework options because command line folks should use the symlinks From: To: Time: Fri Aug 24 16:24:36 2007 Okay. But -L/usr/lib is still silly. :) From: To: Time: Fri Aug 24 16:24:37 2007 but yeah they need the -L/usr/lib removed. From: To: Time: Fri Aug 24 16:25:44 2007 is there a way to get what the system include paths are? could we detect that PROG_LIBPATH is one of those paths and not include it From: To: Time: Fri Aug 24 16:26:28 2007 I don't think so. I think just assuming /lib and /usr/lib are searched is probably good enough for most UNIX boxes. From: To: Time: Fri Aug 24 16:37:53 2007 What's the "sandbox" code referred to in #5660? From: To: Time: Fri Aug 24 16:38:59 2007 They have something called seatbelt which monitors certain important programs. I don't really know anything more From: To: Time: Fri Aug 24 16:39:26 2007 I'm not terribly happy about putting in random hacks like that without more information. From: To: Time: Fri Aug 24 16:40:02 2007 yeah these bugs could contain more information about what the patches do ;-) From: To: Time: Fri Aug 24 16:42:19 2007 Is Austin generally in the conference calls? From: To: Time: Fri Aug 24 16:43:44 2007 Replying to the sandbox ticket. From: To: Time: Fri Aug 24 16:44:40 2007 yeah he's usually there From: To: Time: Fri Aug 24 16:44:59 2007 you might want to take a look at the patches before next weds and come to the conference call and ask about them From: To: Time: Fri Aug 24 16:45:00 2007 You might mention that "because Apple says so" isn't sufficient reason for us to put in a patch. :) From: To: Time: Fri Aug 24 16:45:25 2007 I can certainly gripe about the KfM ones effectively From: To: Time: Fri Aug 24 16:45:27 2007 Maybe I will. I'm skimming the non-kfm bits of some of them. From: To: Time: Fri Aug 24 16:48:21 2007 The password-server patch is poorly commented. Plenty of comments of the sort "write to server" and "read from server", but no explanation of *why* or what the protocol is supposed to be. From: To: Time: Fri Aug 24 16:50:31 2007 So, it's dawning on me that maybe his intent is to give us the patches they're using, rather than to give us patches that *we* can use, and make the latter part be our problem? From: To: Time: Fri Aug 24 16:53:48 2007 yeah I'd guess that's the idea From: To: Time: Fri Aug 24 16:55:36 2007 Which kind of sucks. Did we (for some value of "we") agree to integrate whatever changes they throw over the fence, or are they supposed to be working with us to make them more suitable? From: To: Time: Fri Aug 24 16:58:03 2007 They should be working with us From: To: Time: Fri Aug 24 16:58:29 2007 Good. Then maybe he'll do something about the comments I've sent back. :) From: To: Time: Fri Aug 24 17:00:06 2007 Generally I try not to sell the homeworld;-) From: To: Time: Fri Aug 24 17:00:53 2007 Thanks. :) From: To: Time: Sun Aug 26 02:02:26 2007 This room is not anonymous. From: To: Time: Mon Aug 27 16:19:39 2007 great, triple exclamation points trip our header filters From: To: Time: Tue Aug 28 14:56:03 2007 at least some of the mentioned Debian bugs having to do with referrals look like they should be fixed in 1.6.2 From: To: Time: Tue Aug 28 15:01:42 2007 Yes, I think the bugs related krb5_rd_req should be fixed. I'm concerned though about 436512 From: To: Time: Tue Aug 28 15:05:50 2007 the text of 436512 suggests he is doing something weird like opening up the firewall only long enough to get a service ticket or something. it looks like it could be a ccache interaction with an empty realm name. From: To: Time: Tue Aug 28 15:07:40 2007 Yeah, but if he already has the ticket why is he going after the kdc From: To: Time: Tue Aug 28 15:08:20 2007 maybe because get_credentials tries to fetch the ticket from the ccache and doesn't find it due to some referrals interaction? From: To: Time: Tue Aug 28 15:08:39 2007 i don't think he says how he got the pre-existing ticket. From: To: Time: Tue Aug 28 15:11:36 2007 O, hey, I wonder if he's trying to delegate somehow. From: To: Time: Tue Aug 28 15:11:48 2007 how would that affect things? From: To: Time: Tue Aug 28 15:13:50 2007 but in any case i think asking him how exactly he gets his service ticket and showing the klist output would be helpful. From: To: Time: Tue Aug 28 15:14:07 2007 Although I don't understand how that could interact with domain realm. From: To: Time: Tue Aug 28 15:14:46 2007 also, how exactly is libcurl calling into our code? From: To: Time: Tue Aug 28 15:15:09 2007 Or telling him to build with referrals debugging enabled From: To: Time: Tue Aug 28 15:17:08 2007 Look at lib/krb5.c in the curl sources From: To: Time: Tue Aug 28 15:17:24 2007 got a pointer to the relevant curl sources? From: To: Time: Tue Aug 28 15:18:28 2007 apt-get source libcurl3 was how I got it. So probably http://debian.lcs.mit.edu/debian/pool/main/c From: To: Time: Tue Aug 28 15:20:34 2007 O, hey, that's ftp. Actually take a look at http_negotiate.c From: To: Time: Tue Aug 28 15:21:03 2007 It just calls accept_sec_ctx From: To: Time: Tue Aug 28 15:21:48 2007 Rather init_sec_ctx It calls import_name with a hostbased service name From: To: Time: Tue Aug 28 15:22:17 2007 It does include delegation From: To: Time: Tue Aug 28 15:25:48 2007 so init_sec_ctx calls get_credentials itself rather than allowing mk_req to do it. From: To: Time: Tue Aug 28 15:26:27 2007 Can you think of ways that would matter? From: To: Time: Tue Aug 28 15:28:16 2007 hm, probably not From: To: Time: Tue Aug 28 15:29:08 2007 note gc_frm_kdc rewrites the server realm of the ticket it gets back to be the realm that was originally passed in. this can cause a lookup to fail if there's a mismatch in realm name passed into get_credentials From: To: Time: Tue Aug 28 15:29:53 2007 so if i ask for host/foo.mit.edu@ it will cache host/foo.mit.edu@ even though it got host/foo.mit.edu@ATHENA.MIT.EDU , and vice versa From: To: Time: Tue Aug 28 15:33:40 2007 That's desirable behavior though so if you try the same lookup twice it works. Do you think you could get into a situation where forwarding and get_credentials would get different realms? From: To: Time: Tue Aug 28 15:34:28 2007 forwarding by what means? From: To: Time: Tue Aug 28 15:35:23 2007 I suspect that parsing a KRB_CRED will produce a cache entry that has the actual realm and not the "" realm. From: To: Time: Tue Aug 28 15:36:35 2007 i don't think it would be correct for rd_cred to store the empty realm principal name. From: To: Time: Tue Aug 28 15:37:13 2007 gss_c_delegate_flag like curl does. Basically there will be two calls to krb5_get_credentails. Although I guess one of them will be for a tgt and one for the service. So, I'm not surprised that he sees extra kdc transactions. I am surprised that domain_realm affects anything From: To: Time: Tue Aug 28 15:37:37 2007 I agree rd_cred should not store the empty realm name From: To: Time: Tue Aug 28 15:37:55 2007 having a domain_realm setting will cause sname_to_princ to spit out a real realm name not the empty realm name, i think. From: To: Time: Tue Aug 28 15:38:19 2007 Yes. But how will that actually affect anything From: To: Time: Tue Aug 28 15:41:22 2007 so the OP's problem is that having no domain_realm mapping causes a 40sec delay, which probably corresponds to sname_to_princ outputting an empty realm principal name, which init_sec_ctx then uses to call get_credentials, which kicks off the referral stuff if the only service ticket in the cache was cached with a non-empty realm name. From: To: Time: Tue Aug 28 15:42:31 2007 But how do you get something cached with a non-empty realm name. From: To: Time: Tue Aug 28 15:42:54 2007 that's why i'm wondering how he got the service ticket that is in his cache. he doesn't mention how it got there. From: To: Time: Tue Aug 28 15:43:39 2007 i think we may want to cache the actual principal name as well as the one that was requested. From: To: Time: Tue Aug 28 15:44:50 2007 Sun has a patch to do that in the kinit -s case. I think generalizing that would be fine. From: To: Time: Tue Aug 28 15:47:22 2007 i'm wondering if the relevant code actually belongs in the ccache implementation. From: To: Time: Tue Aug 28 15:49:15 2007 Clearly if in the ccache it would need to be in backend-independent parts. What breakdown do you propose? From: To: Time: Tue Aug 28 15:50:45 2007 i'd have to do a bit more digging to figure that out. certainly having duplicated functionality in kinit, get_credentials, etc. won't help things. From: To: Time: Tue Aug 28 15:51:58 2007 *nod* I think fixing this for 1.6.3 is important. From: To: Time: Tue Aug 28 15:53:12 2007 so almost all of the ccache APIs are thin wrappers that call through the ops vector. are we ok with changing this so we can add backend-independent stuff? From: To: Time: Tue Aug 28 15:54:41 2007 I don't know. You should make that determination. If the answer is no then you have to add this code both in gc_frm_kdc and in the as path through get_init_creds From: To: Time: Tue Aug 28 15:55:25 2007 i think get_init_creds explicitly makes the design choice to not cache the creds, which complicates things somewhat. From: To: Time: Tue Aug 28 15:55:31 2007 I think for something to be backend independent it should be executed before calling through the ops vector. there are too many custom cache implementations that get glued into krb5_cc_xxx From: To: Time: Tue Aug 28 15:56:00 2007 glued into krb5_cc_xxx how? From: To: Time: Tue Aug 28 15:56:06 2007 Jeff, I agree that is the definition of backend independent From: To: Time: Tue Aug 28 15:56:31 2007 adding a new krb5_cc type and recompiling From: To: Time: Tue Aug 28 15:56:42 2007 I.E. if it goes in the ccache it is before the ops vector. We don't want to implement for file, mslsa, api etc separately From: To: Time: Tue Aug 28 15:56:51 2007 sam, exactly From: To: Time: Tue Aug 28 15:57:24 2007 so we can even do it without explicit dependence on referrals by looking to see if the creds structure has a different principal name than the ASN.1 encoding. From: To: Time: Tue Aug 28 16:12:58 2007 oh wait, Sun's kinit -S problem is a bit more complicated From: To: Time: Tue Aug 28 16:24:08 2007 looking at #5663, it appears that the thing to do may be to cause the ccache search in get_credentials to look for default realm service ticket if it is passed an empty realm. From: To: Time: Tue Aug 28 16:26:07 2007 No, that would be bad. default realm is not what is meant by empty realm. empty realm means *client realm* From: To: Time: Tue Aug 28 16:28:45 2007 but as the mailing list discussion indicates, part of the problem with kinit -S is that by the time get_init_creds get the principal, it can't tell in what form kinit got it. From: To: Time: Tue Aug 28 16:30:33 2007 What transformations take place before get_init_creds? From: To: Time: Tue Aug 28 16:30:53 2007 parse_name sticks the default realm on if there is no '@' in the string. From: To: Time: Tue Aug 28 16:31:30 2007 Right. So, that's very different than an empty realm. From: To: Time: Tue Aug 28 16:32:25 2007 It's my understanding of the sun issue is that you don't know whether gss will eventually look for empty realm or for qualified realm and that depends on whether there is a domain_realm entry From: To: Time: Tue Aug 28 16:39:24 2007 so my proposed store_cred change will help that for the normal TGT-based case, but not for the kinit -S case. From: To: Time: Tue Aug 28 16:40:53 2007 I think in the kinit -s case you somehow need to know to store both creds. From: To: Time: Tue Aug 28 16:41:26 2007 maybe zap the realm name that parse_name puts in there if the user passed in a string without a realm From: To: Time: Tue Aug 28 16:43:06 2007 Um. I don't think that's related From: To: Time: Tue Aug 28 16:45:18 2007 also i think the suggested patch in #5663 is many kinds of wrong. From: To: Time: Tue Aug 28 16:45:27 2007 Even if the user specifies kinit -s foo@BAR, gss may select foo@ From: To: Time: Tue Aug 28 16:48:15 2007 I think 5663 does the right thing. I think modifying kinit to do it is wrong. But in the case where there is no tgt, you definitely want a cache that behaves as if it has the ticket both with and without a realm. From: To: Time: Tue Aug 28 16:48:52 2007 so do we want the code dealing with the kinit -S case to actually be in store_cred? From: To: Time: Tue Aug 28 16:49:28 2007 I bdon't know. do you really have the information you need there? From: To: Time: Tue Aug 28 16:50:38 2007 check for service realm == client realm and if so store another copy with empty realm? From: To: Time: Tue Aug 28 16:51:09 2007 Would work. From: To: Time: Tue Aug 28 16:51:26 2007 You could potentially do that in retrieve also, but it would be much more of a mess there From: To: Time: Tue Aug 28 16:51:27 2007 that might even help with the case of kvno host/foo@REALM and then attempting to get host/foo@ From: To: Time: Tue Aug 28 16:52:07 2007 so until we actually implement some form of principal aliasing in ccaches, we're probably stuck with multiple copies From: To: Time: Tue Aug 28 16:57:18 2007 So, you'll store multiple copies in the following cases: * if the asn.1 principal is not the same as the creds principal store both * if the decoded principal from the ticket is the client's realm also store null. From: To: Time: Tue Aug 28 16:57:40 2007 Except that will make klist output quite messy and you really only need the second case for the kinit -s case. I wonder what we could do to narrow it more From: To: Time: Tue Aug 28 16:59:47 2007 you don't think we need the second case for kvno host/foo@REALM? From: To: Time: Tue Aug 28 16:59:54 2007 klist and ticket managers could keep track of the hashes of tickets to determine if there are duplicates and only display the entry that contains the realm name From: To: Time: Tue Aug 28 17:02:28 2007 to what extent do we care about cluttering the output of klist? From: To: Time: Tue Aug 28 17:02:47 2007 Why do we want to change the kvno behavior From: To: Time: Tue Aug 28 17:03:19 2007 Well, I think we care a lot more about cluttering kerberos.app and nim From: To: Time: Tue Aug 28 17:03:21 2007 if someone uses kvno to get a service ticket it may not get used if referrals are in effect From: To: Time: Tue Aug 28 17:03:48 2007 We could fix that by adding an option to kvno to take a hostname and service From: To: Time: Tue Aug 28 17:04:33 2007 i'm trying to think of cases other than kvno which might cause a service principal to get cached with an explicit realm name rather than an empty realm name. From: To: Time: Tue Aug 28 17:05:00 2007 This is kind of icky. From: To: Time: Tue Aug 28 17:05:20 2007 maybe putting the intelligence into the retrieval side might be better. From: To: Time: Tue Aug 28 17:05:48 2007 I think the right way to think about it is cases where you call krb5_get_credentials with the intent of caching something and cannot be guaranteed you will use the same principal you eventually use From: To: Time: Tue Aug 28 17:06:59 2007 oh. one reason to do duplication is mixed implementations. From: To: Time: Tue Aug 28 17:07:02 2007 OK. I do think storing both if the creds realm does not match the encoded realm is fine. I think that for case two using the retrieval side will be better From: To: Time: Tue Aug 28 21:33:10 2007 *amused* The internet claims that xbox uses 3des enctypes for login. Considering that MS doesn't implement 3des for Windows that's amusing. I wonder whose kdc they use From: To: Time: Tue Aug 28 21:34:27 2007 my guess is Vintella's Heimdal derived KDC From: To: Time: Tue Aug 28 21:34:55 2007 Hmm. That would work. From: To: Time: Tue Aug 28 22:21:23 2007 The trunk's cc_file.c appears to be broken. The file description gets cached in the ccache context but the file is not necessarily opened in the required mode. If krb5_cc_set_flags() is called when the ccache file is closed, the file is opened in readonly mode. the file descriptor is then cached and subsequent calls to krb5_cc_store fail. From: To: Time: Wed Aug 29 13:43:44 2007 64-bit Network Identity Manager is now using krbcc64.dll to communicate with a 32-bit krbcc32s.exe. Now if only I could figure out why the server can't be built with VS 2005 we would have a 64-bit KFW release. From: To: Time: Wed Aug 29 14:03:42 2007 Grr. Unsatisfied dependency chain in joins Attachments_2 Transactions_1 at /var/rt2/perl5/lib/DBIx/SearchBuilder/Handle.pm line 1045, line 236. Stack: [/var/rt2/perl5/lib/DBIx/SearchBuilder/Handle.pm:1045] [/var/rt2/perl5/lib/DBIx/SearchBuilder.pm:353] [/var/rt2/perl5/lib/DBIx/SearchBuilder.pm:430] [/var/rt2/perl5/lib/DBIx/SearchBuilder.pm:233] [/var/rt2/perl5/lib/DBIx/SearchBuilder.pm:498] [/var/rt2/lib/RT/Tickets.pm:996] [/var/rt2/WebRT/html/Search/Listing.html:170] [/var/rt2/WebRT/html/autohandler:71] From: To: Time: Wed Aug 29 14:03:52 2007 Seems to be repeatable. From: To: Time: Wed Aug 29 14:03:57 2007 what were you doing? From: To: Time: Wed Aug 29 14:04:50 2007 Search with two "ticket content matches..." criteria. From: To: Time: Wed Aug 29 14:05:22 2007 https://krbdev.mit.edu/rt/Search/Listing.html?Bookmark=FrT%3B%402%7C%256%7C%242%7C11%241%7C6%241%7C8%258%7C%2411%7CDESCRIPTION%245%7CFIELD%248%7COPERATOR%245%7CVALUE%2429%7CTicket%20content%20LIKE%20dependenc%247%7CContent%244%7CLIKE%249%7Cdependenc%258%7C%2411%7CDESCRIPTION%245%7CFIELD%248%7COPERATOR%245%7CVALUE%2426%7CTicket%20content%20LIKE%20librar%247%7CContent%244%7CLIKE%246%7Clibrar%258%7C%2411%7CDESCRIPTION%245%7CFIELD%248%7COPERATOR%245%7CVALUE%2429%7CTicket%20content%20LIKE%20dependenc%247%7CContent%244%7CLIKE%249%7Cdependenc%242%7C12&TicketsSortBy=id&TicketsSortOrder=DESC&RowsPerPage=50 From: To: Time: Wed Aug 29 14:17:47 2007 could be a DBIx::SearchBuilder bug. dunno. From: To: Time: Wed Aug 29 14:25:39 2007 CCAPIv2 now compile with Visual Studio 2005 on both I386 and AMD64. There is now an API: ccache implementation for 64-bit Windows. Either the 32-bit or 64-bit server can be used depending on which was started first. From: To: Time: Wed Aug 29 15:24:00 2007 I've done some test builds; I think the config/makefile changes I put in regarding the pkinit code are in fact complete. From: To: Time: Wed Aug 29 15:24:45 2007 In fact the fix to fake-install went in on the 16th. From: To: Time: Wed Aug 29 15:25:52 2007 yeah my fake-install problem was due to not having my source tree up to date From: To: Time: Wed Aug 29 15:27:05 2007 on the subject of making kvno have an option to do sname_to_princ type things... what would people prefer as an interface? From: To: Time: Wed Aug 29 15:28:46 2007 maybe something with gssapi-style service@host syntax? or would that be too confusing? From: To: Time: Wed Aug 29 15:29:07 2007 that might lead to all sorts of quoting fun From: To: Time: Wed Aug 29 15:29:53 2007 i was thinking something more along the idea of -S and then the non-flag arguments would be interpreted as hostnames, so you'd get servicename/hostname@ From: To: Time: Wed Aug 29 15:30:37 2007 ah, so you give one service and potentially multiple hostnames. yeah, that's good... From: To: Time: Wed Aug 29 15:36:22 2007 hm, code could get a little tricky if it also has to handle krb4 From: To: Time: Wed Aug 29 15:42:02 2007 You don't need to handle krb4 with the service name option From: To: Time: Wed Aug 29 15:43:43 2007 fixing 3887 -- excess libraries listed by krb5-config --libs -- seems a bit more important with the keyring support. apps linked using krb5-config --libs on a system where krb5 was built against -lkeyutils will have libkeyutils in their dependencies, so the executables can't be moved to a system without libkeyutils (and with an otherwise compatible libkrb5 that was not linked against libkeyutils)... From: To: Time: Wed Aug 29 15:47:36 2007 should document somewhere that this could be a problem if we ever go back to doing static libs From: To: Time: Wed Aug 29 15:53:12 2007 Probably worth marking for pullup to 1.6 From: To: Time: Wed Aug 29 15:55:21 2007 worth marking what? From: To: Time: Wed Aug 29 15:58:31 2007 If you fix the krb5-config issue it is worth marking for pull up From: To: Time: Wed Aug 29 15:59:12 2007 ah, yes. not worth marking if it stays unfixed. :) From: To: Time: Wed Aug 29 18:31:05 2007 Interesting. Support for determining the peer's identity with unix-domain sockets seems to be more widely available than I'd thought. According to http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-core/7978 , it's available in various forms on FreeBSD, OS X, Linux, and Solaris 10; from googling a bit, it appears that OpenBSD and AIX also support it. So it might be common enough to plan to use it (where available) for ccapi-on-unix. From: To: Time: Wed Aug 29 18:32:45 2007 Or *maybe* require the functionality, and let porters to hpux or whatever worry about implementing the functionality there, or lose ccapi availability. From: To: Time: Wed Aug 29 18:37:32 2007 Not entirely clear if the implementations are all consistent about real vs effective ids though. From: To: Time: Wed Aug 29 18:55:31 2007 Ah, looks like effective ids are available in each, real ids also in some. From: To: Time: Wed Aug 29 19:21:50 2007 um, looks like commit handler ate something. argh. From: To: Time: Wed Aug 29 20:55:39 2007 Tom, could you review the patch in #5704? From: To: Time: Thu Aug 30 16:32:51 2007 oh great i'll have to swap in my asn1 library state From: To: Time: Thu Aug 30 17:14:28 2007 hm, simply using unused_var() in various places is likely to be wrong. From: To: Time: Thu Aug 30 17:14:43 2007 looks like the problem is a lot deeper than that patch would imply From: To: Time: Thu Aug 30 18:19:09 2007 The use of unused_var in various places does have me thinking there's something worse than a minor coding error going on. But is there a quick hack we can use to fix it up for initial deployment? (E.g., error out on indefinite encoding, and use unused_var or garbage initializations on the values only actually used if the encoding is indefinite?) From: To: Time: Thu Aug 30 18:19:29 2007 (worse -> in our asn.1 code design, not just the pkinit bits) From: To: Time: Thu Aug 30 18:21:44 2007 Hm, I should really figure out why my KDC keeps saying "request is a replay" when I try to get tickets for my AFS service. From: To: Time: Thu Aug 30 18:22:37 2007 I think I tracked it down once before, I don't remember if I ever reported the details in a bug report. I think it had to do with sending to multiple addresses (ipv4 & ipv6) and losing some of the returning traffic. From: To: Time: Thu Aug 30 18:25:14 2007 RT's use of cookies for search terms is so annoying. When I add some terms in the search page, I want them added to the search I did that got me that page, and which is described by the search terms in that page; I don't want them added to the last search I did in some other window, dammit. From: To: Time: Fri Aug 31 16:13:16 2007 re #5697, should i just ignore all errors from decode_krb5_ticket? it will be troublesome to chase down all of the ones that should be ignored From: To: Time: Fri Aug 31 16:15:46 2007 I think so From: To: Time: Fri Aug 31 16:21:59 2007 does MIT still want an iprop implementation? From: To: Time: Fri Aug 31 17:29:30 2007 the patch in #3334 changes the signature of a function in the accessor. should the accessor version get bumped for that? From: To: Time: Fri Aug 31 17:36:38 2007 Yes. Which ticket is that? From: To: Time: Fri Aug 31 17:37:04 2007 #3334, lukeh's ticket about weird non-fatal errors from KDCs From: To: Time: Tue Sep 4 14:55:12 2007 oops. i hate it when i accidentally commit unfinished changes. From: To: Time: Tue Sep 4 15:21:15 2007 argh From: To: Time: Tue Sep 4 15:21:23 2007 an error in our patch for rpcsec From: To: Time: Tue Sep 4 15:26:04 2007 and i thought i'd checked it too From: To: Time: Tue Sep 4 15:26:17 2007 ouch. From: To: Time: Tue Sep 4 15:27:16 2007 Kevin Coffman sent me mail saying the check fails to account for the bytes already encoded into the buffer. From: To: Time: Tue Sep 4 15:30:33 2007 I guess that's what we get for not confirming the patch with him. I never established a secure electronic channel From: To: Time: Tue Sep 4 15:50:51 2007 amusingly, purify doesn't complain... but then again it's not great at detecting overflow of small sizes on the stack. From: To: Time: Tue Sep 4 15:52:14 2007 Yeah, we should probably move stack buffers into heap, for all but the most trivial of cases. (I was working on some email last week suggesting that, among other things.) From: To: Time: Tue Sep 4 15:54:31 2007 oh, and the overflow is reduced to 32 bytes at most, which overwrites stuff that either isn't read again or hasn't yet been initialized, at least if you're allocating locals in "push" order. From: To: Time: Tue Sep 4 15:55:34 2007 of course you could still lose if your optimizer is really aggressive From: To: Time: Tue Sep 4 16:00:12 2007 now coordinating is going to be annoying. or we could just publish a correction soon.... but how soon? From: To: Time: Tue Sep 4 16:00:58 2007 As soon as you can with sufficient review. From: To: Time: Tue Sep 4 16:01:42 2007 revised patch already sent to kwc and cc'ed From: To: Time: Tue Sep 4 16:06:35 2007 could people take a look? From: To: Time: Tue Sep 4 16:13:29 2007 Looks okay to me... From: To: Time: Tue Sep 4 16:25:06 2007 now why can't there be an IXDR_PUTBYTES? From: To: Time: Tue Sep 4 16:28:32 2007 Where is the discussion taking place. I don't see it on krbcore-security, krbcore or krbdev From: To: Time: Tue Sep 4 16:28:45 2007 i cc'ed to krbcore-security From: To: Time: Tue Sep 4 16:29:02 2007 kwc's original note was to me personally From: To: Time: Tue Sep 4 16:29:04 2007 I love the mailhubs. From: To: Time: Tue Sep 4 16:31:37 2007 does gcc under linux allocate locals in "push order"? From: To: Time: Tue Sep 4 16:31:49 2007 i386-linux that is From: To: Time: Tue Sep 4 16:36:14 2007 I think gcc allocates locals in the order that it decides they need stack slots. From: To: Time: Tue Sep 4 16:38:56 2007 hm, maybe i'm seeing the ordering i'm seeing due to compiling with '-g' From: To: Time: Tue Sep 4 17:24:13 2007 do we want to comment in https://krbdev.mit.edu/rt/Ticket/Display.html?id=5658 that we are interested in a version of this patch implemented as a plugin? Austin seems to have ignored Ken's comment. From: To: Time: Tue Sep 4 17:24:56 2007 do we have enough plugin support for them to do that? From: To: Time: Tue Sep 4 17:25:23 2007 No I presume we'd be asking them to add the plugin hooks as well From: To: Time: Tue Sep 4 17:25:49 2007 My question is really "how much work do we want to ask Apple to do for us to get their patches in" From: To: Time: Tue Sep 4 17:26:40 2007 if they're going to do the plugin hooks as well i'd like it if we got to review the design From: To: Time: Tue Sep 4 17:27:06 2007 I know we've gotten "synchronize passwords with X" requests from others before From: To: Time: Tue Sep 4 17:27:47 2007 true From: To: Time: Tue Sep 4 17:29:33 2007 oh nevermind what i said about IXDR_PUTBYTES... looks like the other IXDR macros don't bounds-check either From: To: Time: Tue Sep 4 17:30:31 2007 My web browser's kind of hosed at the moment, but IIRC "synchronize passwords" didn't really seem to describe what they were doing. From: To: Time: Tue Sep 4 17:31:29 2007 "This is an Apple-specific mechanism for keeping Kerberos passwords synchronized with other authentication mechanisms. " From: To: Time: Tue Sep 4 17:32:53 2007 Yes, and if the patch actually changed kadmind or the kadm5 libraries I might believe it. Instead, it changed files in the KDC only. The KDC doesn't change passwords. From: To: Time: Tue Sep 4 17:33:53 2007 what does it do? ping an external db for freshness? From: To: Time: Tue Sep 4 17:34:00 2007 we already have a patch for this same feature in some part of kadmind/kadm5. That was the patch that I had to rewrite because it was so.... not in C ;-) From: To: Time: Tue Sep 4 17:34:10 2007 Most of the comments are of the sort "write a line to the server" and "returns the socket or -1". From: To: Time: Tue Sep 4 17:34:38 2007 did it even compile? From: To: Time: Tue Sep 4 17:34:49 2007 "Add code that checks the pws for account validity" From: To: Time: Tue Sep 4 17:35:22 2007 "call code to notify PWS of the failure iff not NEEDS_Preauth" From: To: Time: Tue Sep 4 17:35:33 2007 Those two are the most useful comments in the code. From: To: Time: Tue Sep 4 17:37:03 2007 yeah we already added OS-specific password changes for them in kadm5_chpass_principal_3() which use /usr/sbin/mkpassdb From: To: Time: Tue Sep 4 17:37:13 2007 see USE_PASSWORD_SERVER From: To: Time: Tue Sep 4 17:39:43 2007 The first seems to check a flag to see if the account can be used; the other reports any non-preauth error in process_as_req to PWS. From: To: Time: Tue Sep 4 17:39:54 2007 Wow that code really doesn't follow our coding conventions From: To: Time: Tue Sep 4 17:40:18 2007 So much whitespace.... so much intercaps From: To: Time: Tue Sep 4 17:40:27 2007 The kadm5_chpass_principal_3 stuff should probably be a plugin. From: To: Time: Tue Sep 4 17:40:38 2007 (now that we have some plugin support) From: To: Time: Tue Sep 4 17:40:41 2007 Yeah we took that patch a long time ago From: To: Time: Tue Sep 4 17:41:25 2007 In fact, if Russ's proposed plugin can't implement this functionality, it probably needs to be fixed. From: To: Time: Tue Sep 4 17:43:03 2007 whitespace isn't too bad. the line length is atrocious in places though. From: To: Time: Tue Sep 4 17:44:04 2007 okay yeah this patch is annoying. there's not really enough information about what it is trying to do From: To: Time: Tue Sep 4 17:45:07 2007 The use of spaces is erratic actually. Like + compareLen = strlen(kPasswordServerAuthErrPrefixStr); + if ( strncmp( tstr, kPasswordServerAuthErrPrefixStr, compareLen ) == 0 ) From: To: Time: Tue Sep 4 17:46:08 2007 They also appear to have ninjaed the -a option to the kdc. From: To: Time: Tue Sep 4 17:46:42 2007 heh From: To: Time: Tue Sep 4 17:50:24 2007 So if my understanding is correct it looks like this patch does two things: a) Allows the password server to disable Kerberos principals b) Tell the password server that a "password is incorrect" error has been sent to a client Not sure if (b) actually works if preauth is turned on for the principal though. From: To: Time: Tue Sep 4 17:50:44 2007 looks like there may be comments in the code to that effect From: To: Time: Tue Sep 4 17:51:06 2007 Presumably this means that they are also using the other patch to actually do the synchronization From: To: Time: Tue Sep 4 17:53:42 2007 Anyway I think we need to tell them how we want to clean it up since it's clearly not in a state we can take it now From: To: Time: Tue Sep 4 18:04:37 2007 Hm... what if oa->oa_length is 0xfffffffc ? From: To: Time: Tue Sep 4 18:05:01 2007 that's why i wrote my length check the other way around From: To: Time: Tue Sep 4 18:05:21 2007 or that's one of the reasons From: To: Time: Tue Sep 4 18:06:58 2007 I think I'm looking at yours. If oa_length is (unsigned)-4 and buf-rpchdr is, say, 8, the sum is 4, less than sizeof(rpchdr), so you'll call memcpy with -4? From: To: Time: Tue Sep 4 18:07:53 2007 I think Will and Nico's version may be safer. From: To: Time: Tue Sep 4 18:08:40 2007 oh. true, but only because the buf-rpchdr is going to be a known constant :-) From: To: Time: Tue Sep 4 18:08:59 2007 in any case i know that xdr_callmsg will validate oa_length From: To: Time: Tue Sep 4 18:11:31 2007 Ah, I see. That helps. There's still the theoretical issue that oa_length+buf could be out of bounds, but... From: To: Time: Tue Sep 4 18:12:18 2007 which patch does that? From: To: Time: Tue Sep 4 18:13:21 2007 Yours: "(oa->oa_length + (u_char *)buf - rpchdr) <= sizeof(rpchdr)" From: To: Time: Tue Sep 4 18:13:52 2007 oh. oops. left off some parentheses. From: To: Time: Tue Sep 4 18:14:59 2007 i seem to not be doing well today. From: To: Time: Tue Sep 4 19:19:45 2007 i hate how C deals with arithmetic From: To: Time: Tue Sep 4 19:20:21 2007 Will's comment about the declaration of rpchdr seems like a good idea From: To: Time: Tue Sep 4 19:23:18 2007 why not make it MAX_AUTH_BYTES+8*BYTES_PER_XDR_UNIT? From: To: Time: Tue Sep 4 19:25:20 2007 Why the extra padding? From: To: Time: Tue Sep 4 19:25:51 2007 8 words plus the auth data are put there. From: To: Time: Tue Sep 4 19:26:00 2007 because that's how big it needs to be if it is going to fit the cb_cred plus the other 8 words of IXDR_* From: To: Time: Tue Sep 4 19:34:26 2007 Point From: To: Time: Tue Sep 4 19:36:56 2007 also a valid RPCSEC cb_cred will be rather smaller than MAX_AUTH_BYTES From: To: Time: Wed Sep 5 17:13:35 2007 argh. svk is spinning taking up all my CPU again From: To: Time: Wed Sep 5 17:28:11 2007 and of course turning up verbosity to debug it makes the problem stop... From: To: Time: Wed Sep 5 17:35:53 2007 oh great, i also just noticed i introduced a dependency between #3334 (lukeh's patch to sendto_kdc etc) and pkinit due to the accessor version bump. From: To: Time: Fri Sep 7 15:40:37 2007 Anyone look at the keytab bug reported by Apple? From: To: Time: Fri Sep 7 15:45:27 2007 oh yeah that's dumb. krb5_ktfile_get_entry() closes the file when it is done and krb5_ktfile_get_next() blindly refers to the file descriptor without checking to see if it is open. Which means that you can get screwed if you are walking over a keytab and then call some krb5 API that calls krb5_ktfile_get_entry() and closes the file on you because your calls to the keytab iterators will crash From: To: Time: Fri Sep 7 15:47:46 2007 oh heh that's even better. krb5_ktfile_get_entry also blindly opens the file at the beginning (via krb5_ktfileint_open()) so in fact you also leak a file descriptor From: To: Time: Sun Sep 9 02:02:26 2007 This room is not anonymous. From: To: Time: Mon Sep 10 13:26:33 2007 Grr, now we're getting web comment spam. :( From: To: Time: Mon Sep 10 13:29:35 2007 We need the ability to kill a comment. I don't think we want to advertise an oriental antique site to people looking at our tickets on thread support. From: To: Time: Mon Sep 10 13:48:37 2007 perhaps they're markov chaining off keywords From: To: Time: Mon Sep 10 17:20:13 2007 ok i did the evil thing and bashed the "Ticket" column of the offending transaction to 0, which left the LastUpdated stuff bogus but shouldn't break anything. From: To: Time: Mon Sep 10 17:21:22 2007 thanks From: To: Time: Mon Sep 10 17:21:44 2007 i could just nuke that row but i think it's safer to keep it around just in case From: To: Time: Mon Sep 10 18:31:34 2007 at some point i should figure out what about gcc -O2 makes purify blow up on bison output From: To: Time: Tue Sep 11 12:35:54 2007 bleh, sick again From: To: Time: Tue Sep 11 16:17:30 2007 If the Apple guy is still confused in his next reply can someone else take a stab at explaining it to him? Clearly something about the way I'm explaining the problem isn't getting through to him From: To: Time: Tue Sep 11 16:18:54 2007 I think he just didn't realize that krb5_ktfile_close() and krb5_ktfileint_close() are two different functions and hopefully my pointing that out specifically will help him understand the code better From: To: Time: Tue Sep 11 16:19:19 2007 They are sort of poorly named :-) From: To: Time: Tue Sep 11 16:32:52 2007 Ah there we go, he was confused about those two function names. From: To: Time: Tue Sep 11 18:46:12 2007 dammit. From: To: Time: Tue Sep 11 18:46:29 2007 have turned on mod bit for "Prof." Antiba From: To: Time: Wed Sep 12 13:58:57 2007 Sam and i are still on the Intel call From: To: Time: Fri Sep 14 15:12:18 2007 r19745 (pkinit merge) doesn't pull up to 1.6 due to build system changes. how much back-porting am i going to need to do? From: To: Time: Fri Sep 14 16:31:45 2007 Paul Hoffman and Jim Schaad have announced their ASN.1 compiler project. I haven't taken a look yet. From: To: Time: Fri Sep 14 16:42:15 2007 hm ok... where did you hear this? From: To: Time: Fri Sep 14 16:43:56 2007 In email in my mailbox. Paul said they were announcing it to anyone that they'd talked to about it already; I've no idea how big an audience that is. From: To: Time: Fri Sep 14 16:44:26 2007 (it was to: paul cc: jim, presumably bcc everyone else) From: To: Time: Fri Sep 14 18:33:17 2007 Hm, potential strike against the Hoffman-Schaad compiler: They wrote the compiler (but not the runtime support) in C#. From: To: Time: Fri Sep 14 18:33:31 2007 oh great From: To: Time: Fri Sep 14 18:33:58 2007 i'm usually highly skeptical of the design quality of BER encoders/decoders but i haven't looked at this one yet From: To: Time: Fri Sep 14 18:34:21 2007 Which means installing Mono, on a non-Windows box, if we want to run that tool. But saving the generated C code and runtime should be pretty easy. From: To: Time: Fri Sep 14 18:39:20 2007 Ooh. They support directives in ASN.1 comments, like "--#Namespace: "krb5int_"#-- to put a prefix of krb5int_ on identifiers in the generated code. From: To: Time: Fri Sep 14 18:40:17 2007 Hm, needs Mono 1.2, but they say most distributions are 1.1. From: To: Time: Fri Sep 14 18:41:10 2007 Generates A2C_Runtime.lib for the runtime library. On UNIX. From: To: Time: Fri Sep 14 18:43:07 2007 No autoconf; you cd into either Mono-files or NET-files and run "make" or "nmake" there (respectively), and that copies the makefiles into place. CFLAGS defaults to empty. From: To: Time: Fri Sep 14 18:43:28 2007 No "install" target. From: To: Time: Fri Sep 14 18:44:18 2007 Clearly, if we were to incorporate this, the build system for the runtime library would have to be thrown away. Even calling it a "build system" may be giving it too much credit... From: To: Time: Fri Sep 14 18:48:37 2007 speaking of build system, did you see my previous question about the pkinit merge? From: To: Time: Fri Sep 14 18:52:29 2007 Saw it, yes, haven't pulled up the changes to look yet. From: To: Time: Fri Sep 14 18:54:34 2007 a2c seems to be missing generalstring support. So, yeah, it translates rfc4120.asn, you just can't compile the result. Oops... From: To: Time: Fri Sep 14 19:03:45 2007 well one obvious approach would be to extract it as octets and let the caller sort it out... From: To: Time: Fri Sep 14 19:07:47 2007 Yeah, I don't really expect them to do validation or conversion of encodings or anything, but generating references to undefined symbols won't do. From: To: Time: Fri Sep 14 19:45:18 2007 Well, simple build systems are easier to throw away From: To: Time: Fri Sep 14 19:50:46 2007 Yes, for projects like ours that would want to integrate the runtime code rather than keep it a separate library, the current form is pretty reasonable. No special requirements, just compile, link, and go. From: To: Time: Fri Sep 14 20:00:17 2007 nothing generated for the oid for the module itself (KerberosV5Spec2=1.3.6.1.5.2.4.2), but a2c does generate an object for oids defined inside the module (like id-krb5=1.3.6.1.5.2). From: To: Time: Fri Sep 14 21:27:19 2007 Another useful directive: "Binary". As in, leave this certificate in binary form so I can pass it off to some other library. From: To: Time: Fri Sep 14 21:48:28 2007 Okay, it's becoming more and more clear that Jim Schaad (who I assume is doing most of the work?) is primarily a Windows programmer, and probably not too intimately familiar with the C standard. The support library provides an allocation function: A2C_ERROR A2C_Alloc(PVOID *ppv, PC_A2C_DESCRIPTOR pdesc); and recommends calling it with a first argument that's the address of a pointer to an object type. And function pointer types get cast (and never cast back) a lot. From: To: Time: Fri Sep 14 21:50:29 2007 Wait, in C aren't all object pointer types the same size? From: To: Time: Fri Sep 14 21:51:03 2007 Is there any real world system where for C (not C++) the function pointer issue matters? From: To: Time: Fri Sep 14 21:53:30 2007 I'm not sure about modern real-world general-purpose systems, but no, there's no requirement for all object pointer types to be the same size, or have the same representation. Certainly there have been systems with pointers of different sizes. And I believe gcc supports some modern embedded systems with multiple pointer sizes, though I don't know if the difference is based on the pointed-to type or is a separate attribute of the pointer types. From: To: Time: Fri Sep 14 21:55:13 2007 As for the function pointers, since pointers are passed, any system with different flavors of pointers for different pointed-to types would lose. I'm assuming that otherwise (aside from the types pointed to by argument pointers) the function signatures are compatible, so things probably won't break. But it's sloppy, IMNSHO. From: To: Time: Fri Sep 14 21:56:07 2007 Interesting. That is not what I remember but I never read the standard in detail For all the systems I've run across with multi-sized pointers it is an attribute of the pointer not the object. From: To: Time: Fri Sep 14 21:56:10 2007 And these functions are just used internally. The only benefit of using Type* in the signature instead of void* is that you don't have to do the cast in the function. Because of the function pointer casting, and the invocation of the function being buried in the library code, you get basically no type-checking benefit at all. From: To: Time: Fri Sep 14 21:58:53 2007 That's probably almost universal, these days, but certainly isn't required. The requirements are pretty minimal -- void* and char* variants have to be the same, I think qualified and unqualified pointers have to have the same representation (or it's explicitly very strongly encouraged), and certain conversions have to result in getting the original pointer value out, though the conversions can cause the execution of code. From: To: Time: Fri Sep 14 22:00:38 2007 Well, and you don't have to cast to/from void, although I'm happy to believe that does not extend as far as pointer to pointer to void From: To: Time: Fri Sep 14 22:02:06 2007 That just means the conversions to and from void* are done automatically, even if it means executing code. Converting pointer-to-pointer types like that would mean rewriting the pointed-to values, which would mean knowing how many there were in what could be a pointed-to array of values, etc. And if void* is bigger than the other pointer type... From: To: Time: Fri Sep 14 22:03:50 2007 One mental model I use sometimes is an address space of (say) 2**34, so void* is 64 bits, but int* can be 32 bits (throwing away the low 2 bits because "int" requires strict alignment, and throwing away the upper 30 because they're never used). So the pointers are different sizes, and converting also requires a shift. From: To: Time: Fri Sep 14 22:03:52 2007 I understand. However I actually think that the constraints you need to assume for this code to be reasonable are in fact likely to be reasonable constraints. The question is simply whether they are stated. If not, I agree it is sloppy. If so, I disagree that it is sloppy. From: To: Time: Fri Sep 14 22:05:33 2007 They are not stated so far as I've noticed. Furthermore, whether the assumption is being made or not, I would expect any decent compiler to issue warnings about calls done the way they're actually recommending doing them. From: To: Time: Fri Sep 14 22:09:59 2007 They probably aren't terribly unreasonable constraints for most modern systems. However, the ones I'm complaining about aren't necessary constraints, either. From: To: Time: Fri Sep 14 22:11:08 2007 Eh. I'd do a lot to get rid of casts. I'm not sure I'd accept the warnings. From: To: Time: Fri Sep 14 22:13:13 2007 I wouldn't, in code I was maintaining. Certainly not when doing it correctly isn't much harder. From: To: Time: Fri Sep 14 22:14:38 2007 In cases like this, casts *in the right places* are the right answer, I think. From: To: Time: Fri Sep 14 22:15:29 2007 Right. That's a valid opinion. I personally thing that believing required casts like that obscure meaning is also a valid approach. From: To: Time: Fri Sep 14 22:17:41 2007 Under the approach of always passing void*, and always getting the same function signature, casts shouldn't be needed, of the data pointer types or the function pointer types, I think. From: To: Time: Fri Sep 14 22:17:56 2007 I do think it would be reasonable to write up your comments and send them off. From: To: Time: Fri Sep 14 22:19:08 2007 However, I haven't checked that there aren't *some* explicit calls to these routines where type checking is (minimally) useful. So I'll be careful in my comments on that point. From: To: Time: Fri Sep 14 22:21:16 2007 Hm. They're assuming everyone has . Ick. From: To: Time: Fri Sep 14 22:22:33 2007 What's in memory.h? From: To: Time: Fri Sep 14 22:24:17 2007 On most systems these days? "#include ", I'd guess. AFAIK, it was a *very* old way to pull in the declarations of memcpy and friends, which have been declared in string.h for a decade or so. From: To: Time: Fri Sep 14 22:24:54 2007 (And they're also including string.h.) From: To: Time: Fri Sep 14 22:30:20 2007 Hm, they are different on Solaris 10. But with string.h included, I think there are only a few non-standard functions declared by memory.h, and this code shouldn't use them, for maximum portability. From: To: Time: Fri Sep 14 22:31:21 2007 I take it back. I think string.h does include all the memory.h functions on Solaris, including extensions. But using memory.h does omit the string functions. From: To: Time: Fri Sep 14 22:35:49 2007 heading out, back online later. From: To: Time: Fri Sep 14 23:48:58 2007 re function pointers... "Harvard architecture" From: To: Time: Sat Sep 15 01:35:52 2007 not sure i see how harvard architecture fits.. From: To: Time: Sun Sep 16 02:02:26 2007 This room is not anonymous. From: To: Time: Mon Sep 17 16:38:45 2007 Oh, I've also been tweaking gcc to make the -ftrapv (trap on signed overflow) option a little more useful. It's still seriously buggy, I wouldn't bother with trying to use it much right now unless you want to check for bugs in its implementation. But I've started a little discussion on the gcc lists about fixing it... From: To: Time: Mon Sep 17 17:07:27 2007 unmodified 1.6-branch blows out in ac sym check in plugins/kdb/libdb2/hash. i think it has something to do with there being a local config.h.in near there. From: To: Time: Mon Sep 17 17:09:55 2007 i imagine i could turn of maintainer mode but it's still kind of wrong. From: To: Time: Mon Sep 17 17:12:16 2007 There were some bugs in that code... I think deleting the .h.in file might work around it. From: To: Time: Mon Sep 17 17:12:35 2007 won't autoheader regenerate it? From: To: Time: Mon Sep 17 17:13:43 2007 Yes. But I think there was something weird about the order in which things got done, such that an okay configuration could get errors because the check was done using an old version of one of the files. Maybe just a missing dependency. From: To: Time: Mon Sep 17 17:13:57 2007 ick ick ick From: To: Time: Mon Sep 17 17:14:51 2007 Yeah. I think I finally got rid of that stuff on the trunk. (And the libdb2 code doesn't have its own generated header any more, we just pull in autoconf.h.) From: To: Time: Mon Sep 17 17:21:20 2007 Ken Renard was at UMich for the PKINIT interop testing. From: To: Time: Mon Sep 17 17:25:50 2007 Paul & Jim have made v2 of the ASN.1 compiler available already. From: To: Time: Mon Sep 17 17:28:36 2007 Building libkrb5.dylib on ppc mac with -Os reduces code size by about 6.8%, overall library file size by a bit less than 1%. From: To: Time: Mon Sep 17 17:40:10 2007 on solaris: From: To: Time: Mon Sep 17 17:40:15 2007 ./lib/crypto/aes/aeskey.so: 15040 + 0 + 0 = 15040 ./appl/gssftp/ftpd/ftpcmd.o: 17028 + 928 + 40 = 17996 ./kadmin/dbutil/dump.o: 17288 + 160 + 28 = 17476 ./appl/telnet/telnet/telnet.o: 18308 + 80 + 640 = 19028 ./kadmin/cli/kadmin.o: 19804 + 288 + 6520 = 26612 ./lib/crypto/aes/aestab.o: 20596 + 0 + 0 = 20596 ./lib/crypto/aes/aestab.so: 20596 + 0 + 0 = 20596 ./kadmin/testing/util/tcl_ovsec_kadm.o: 20812 + 300 + 48 = 21160 ./lib/krb5/asn.1/asn1_k_encode.so: 21224 + 0 + 0 = 21224 ./lib/krb5/ccache/cc_file.so: 23676 + 240 + 4 = 23920 ./appl/gssftp/ftp/cmds.o: 23772 + 168 + 3080 = 27020 ./appl/gssftp/ftp/ftp.o: 25072 + 4 + 6264 = 31340 ./kadmin/testing/util/tcl_kadm5.o: 25408 + 500 + 48 = 25956 ./appl/gssftp/ftpd/ftpd.o: 26212 + 264 + 1112 = 27588 ./lib/krb5/asn.1/krb5_decode.so: 27640 + 0 + 0 = 27640 ./appl/telnet/telnet/commands.o: 28276 + 4112 + 2944 = 35332 ./tests/asn.1/krb5_decode_test.o: 56288 + 0 + 4 = 56292 ./lib/krb5/asn.1/asn1_k_decode.so: 56644 + 0 + 0 = 56644 ./plugins/kdb/db2/db2.so: 81864 + 3272 + 52 = 85188 ./util/fakedest/var/src/krb5/dest/lib/krb5/plugins/kdb/db2.so: 81864 + 3272 + 52 = 85188 From: To: Time: Mon Sep 17 17:40:24 2007 that's sorted by text size From: To: Time: Mon Sep 17 17:40:54 2007 IIRC AES has an option to reduce table size, at some run-time expense. From: To: Time: Mon Sep 17 17:41:10 2007 so in terms of library code my recollection appears to be correct and our main offenders are asn.1 decoders and crypto tables From: To: Time: Mon Sep 17 17:41:47 2007 I tweaked some code a while back to build smaller objects under -DCONFIG_SMALL, including the AES code. From: To: Time: Mon Sep 17 17:42:50 2007 If I recall correctly, in the crypto code, that means smaller or no tables, loops not unrolled, and the inner DES loop pulled out into a separate function instead of expanded inline in multiple places. From: To: Time: Mon Sep 17 17:44:43 2007 Ah, yes, and sha1 and md{4,5} loops also not unrolled. From: To: Time: Mon Sep 17 17:45:04 2007 No changes outside the crypto code. From: To: Time: Mon Sep 17 17:45:18 2007 Um, so as I said in the meeting I expect the mac and in particular kfm to be very different than even darwin kerberos From: To: Time: Mon Sep 17 17:46:04 2007 Sure. But I expect some of the optimizations to translate, even if there's a lot of other goop. From: To: Time: Mon Sep 17 17:46:23 2007 Yes, but I suspect you may be micro-optimizing in a big way From: To: Time: Mon Sep 17 17:46:25 2007 Like, -Os should improve things a little anyways, and CONFIG_SMALL will still make the crypto code smaller than it was. From: To: Time: Mon Sep 17 17:48:08 2007 Perhaps. The kfm-specific stuff definitely needs to be looked at. I did the CONFIG_SMALL stuff looking at Linux builds and the biggest object files in the crypto code. From: To: Time: Mon Sep 17 17:49:12 2007 And, as you said, we need more specifics on *what* they want reduced -- i.e., what they're measuring. From: To: Time: Mon Sep 17 18:04:43 2007 Turning off some of the debugging code in the k5_mutex support would reduce some code size. It's saving the current thread id and file name and line number. From: To: Time: Mon Sep 17 18:06:21 2007 The framework file has a lot of local relocation entries. I bet some of those are unnecessary. They'll slow library loading, as well as contributing to size. From: To: Time: Mon Sep 17 18:13:44 2007 Fixing r19745 src/configure.in conflicts does look pretty straightforward. The configuration of pkinit needs to go in AC_CONFIG_SUBDIRS (look for wpse), not in V5_AC_OUTPUT_MAKEFILE (where klist is). From: To: Time: Mon Sep 17 18:14:30 2007 Though merging 19758 will move it to a separate call anyways. From: To: Time: Mon Sep 17 18:15:40 2007 And will probably require manual merging as well. From: To: Time: Mon Sep 17 18:30:44 2007 ok that's close to what i'd foun From: To: Time: Mon Sep 17 18:32:38 2007 oh wait there is a separate configure.in for plugins/preauth/pkinit? From: To: Time: Mon Sep 17 18:33:45 2007 Yes, initially, not now. But the merging of configure.in files to the top-level one happened post-1.6. From: To: Time: Mon Sep 17 18:33:58 2007 oh. this will be exciting From: To: Time: Mon Sep 17 18:50:38 2007 ick. maintainer mode loops around rerunning autoconf and configure a lot. i'll have need to analyze this at some point. From: To: Time: Mon Sep 17 18:51:23 2007 I know there are (or were) cases where it could happen a couple of times. It shouldn't keep looping. From: To: Time: Mon Sep 17 18:51:44 2007 i just ran reconf --force, so it shouldn't be rebuilding any autoconf stuff at all. From: To: Time: Mon Sep 17 18:52:17 2007 Yeah, but some of the dependencies for consistency checking were (are?) screwy, and forced a rebuild anyways. From: To: Time: Mon Sep 17 18:52:36 2007 i think they're more screwy than they used to be but i don't know what that happened exactly. From: To: Time: Mon Sep 17 18:52:49 2007 Checking out a fresh tree now to take a look. It's probably my fault. :( From: To: Time: Mon Sep 17 18:55:40 2007 Ah. In maintainer mode, autoconf.h.in depends on a timestamp file created by the build rules in the makefile, but not created by the reconf script. From: To: Time: Mon Sep 17 18:55:53 2007 oh. From: To: Time: Mon Sep 17 18:56:19 2007 That's to keep us from running autoheader all the time if configure.in gets updated but without impact on autoconf.h.in (in which case autoheader doesn't replace it). From: To: Time: Mon Sep 17 18:57:05 2007 i think reconf doesn't correctly handle config.h.in in db2 either From: To: Time: Mon Sep 17 18:57:37 2007 Probably true. That's fixed on the trunk (by getting rid of the file). From: To: Time: Mon Sep 17 18:59:27 2007 Oh. The reconf script *does* update the timestamp file, on the trunk. I'll check if the extra-rebuild is still done though. From: To: Time: Mon Sep 17 19:16:35 2007 Oh. Weird. I *thought* I got rid of pkinit's local configure script. Looks like not. From: To: Time: Mon Sep 17 19:17:05 2007 Ah, I think it's not used, just not removed. From: To: Time: Mon Sep 17 20:00:31 2007 We do run config.status unnecessarily at first, because we do the timestamp trick again for autoconf.h, and this second timestamp file is only created by the makefile rules, not by config.status itself. Fixed. From: To: Time: Mon Sep 17 20:23:32 2007 MIT Consortium hit slashdot From: To: Time: Tue Sep 18 15:57:18 2007 anyone able to test pkinit builds on the 1.6 branch? From: To: Time: Tue Sep 18 16:10:31 2007 Sure let's try From: To: Time: Tue Sep 18 16:18:55 2007 make[1]: Entering directory `/home/hartmans/krb5-trunk/build/plugins/preauth/pkinit' cd ../../.. && /bin/sh config.status plugins/preauth/pkinit/Makefile config.status: error: invalid argument: plugins/preauth/pkinit/Makefile From: To: Time: Tue Sep 18 16:19:31 2007 oh hell From: To: Time: Tue Sep 18 16:20:24 2007 also, why do we have makefile variables so helpfully named "mydir" and "myfulldir"? From: To: Time: Tue Sep 18 16:22:53 2007 anyway in that makefile, try setting thisconfigdir=. mydir=. From: To: Time: Tue Sep 18 16:29:08 2007 Yeah, that's sufficient From: To: Time: Tue Sep 18 16:29:55 2007 so the configure script itself is actually working? From: To: Time: Tue Sep 18 16:30:12 2007 Well, it produced a pkinit.so. Don't know if it works. From: To: Time: Tue Sep 18 16:30:16 2007 heh From: To: Time: Tue Sep 18 16:39:28 2007 anyway fix committed From: To: Time: Tue Sep 18 17:03:04 2007 i wonder if there were things that got sucked into the top-level configure.in that are actually needed in the 1.6 branch plugins/preauth/pkinit/configure.in From: To: Time: Wed Sep 19 16:21:08 2007 oh, i asked Wilson about attire for the launch event; he's going to check with Jerry on details but full-blown suits is probably overdoing it... more like button-down shirt and slacks or something. From: To: Time: Wed Sep 19 16:28:47 2007 Shouldn't Steve, rather than either Wilson or Jerry be deciding on that sort of thing? From: To: Time: Wed Sep 19 16:39:56 2007 has Steve said anything about this? From: To: Time: Wed Sep 19 18:01:41 2007 Has anyone besides me gotten an invitation to a poorly designed goal setting website? From: To: Time: Wed Sep 19 18:01:53 2007 i don't think so From: To: Time: Wed Sep 19 18:02:53 2007 Well, if you have gotten one to a well-designed website then we are using different websites From: To: Time: Wed Sep 19 18:03:23 2007 i think i have gotten no message pointing at any goal-setting website From: To: Time: Wed Sep 19 18:06:58 2007 oh, my ears... From: To: Time: Wed Sep 19 18:07:43 2007 i've got a relatively comfy headset for use with the phone, but i've just been on with paul hoffman for nearly 2 hours, talking about his asn.1 compiler and kerberos. it's not *that* comfy. From: To: Time: Wed Sep 19 18:08:06 2007 now i'm late for a mitg&sp meeting. back later... From: To: Time: Wed Sep 19 18:14:33 2007 Eh. Whatever, it'll be half over by the time I get there, and there's not much I need to do yet anyways. From: To: Time: Wed Sep 19 18:19:09 2007 So, Paul seems very interested in having us use his code, and at least for now is pretty much willing to make any reasonable changes we want, though changes to the API may be harder (and will only get more so). From: To: Time: Wed Sep 19 18:34:30 2007 I'm working up a list of changes to propose (or write patches for), but everything I've talked to Paul about he seems willing to accept. But it's Jim who's doing the coding, so he'd have the final say, and I gather for the next few weeks he's going to be busy crushing grapes. From: To: Time: Wed Sep 19 18:35:04 2007 I didn't realize Paul doesn't do C development. From: To: Time: Wed Sep 19 18:48:55 2007 Mono is looking a bit like a Linux-only tool. Installing from macports failed, though there is a downloadable binary package available. Paul says he's had trouble trying to install it on FreeBSD, too. From: To: Time: Wed Sep 19 19:06:40 2007 Paul also suggested a bar bof in Vancouver for people interested in/using a2c, along with some of the NSA guys who are paying for it. From: To: Time: Wed Sep 19 19:13:15 2007 It needs a little tweaking to integrate more nicely, and I haven't experimented yet with actually running the generated code, but at some point you should probably take a look too, Tom. When you've got time, of course... integrating it would be a little ways down the road at best, but if we want to suggest any API changes, sooner is better than later. From: To: Time: Wed Sep 19 19:13:32 2007 could you forward me a pointer to this thing? From: To: Time: Wed Sep 19 19:13:43 2007 Sure. From: To: Time: Wed Sep 19 19:49:52 2007 (*sigh* Stop thinking about UTF-8 issues and just send the stupid mail before it gets even longer.) From: To: Time: Wed Sep 19 19:55:47 2007 The longer I think about it, the less I think a single utf8ness flag in the context will work. But maybe there are other simplifications I'm not anticipating. Mail sent, anyways. From: To: Time: Wed Sep 19 20:34:30 2007 gah. for a while i thought i typoed and the release was supposed to be 1.6.4 not 1.6.3, but it's actually ok. From: To: Time: Wed Sep 19 21:16:10 2007 I just got email about a goal-setting web site. It insists that I enable pop-ups in my web browser. Oh well. From: To: Time: Wed Sep 19 21:42:17 2007 The emails inviting us to visit the halogen goal setting website just came out ... Is this what you were talking about, Sam? From: To: Time: Thu Sep 20 12:22:23 2007 Do we have to do the goal thing again now that the halogen system is up? From: To: Time: Thu Sep 20 12:24:18 2007 Hold off for now. I don't have a clue. From: To: Time: Thu Sep 20 12:34:03 2007 wow that web site is.... um From: To: Time: Thu Sep 20 12:34:36 2007 so many popup windows From: To: Time: Sun Sep 23 02:02:30 2007 This room is not anonymous. From: To: Time: Mon Sep 24 11:50:11 2007 Taking a wild guess at the cause of ticket 5765. I'm guessing that either the realm name or the Administrators' principal name in the root domain contains at least one UNICODE character that cannot be represented in the ANSI code page of the XP SP2 workstation. From: To: Time: Mon Sep 24 14:39:17 2007 I will be visiting MIT on Wednesday and Thursday for the Consortium launch and will be available to discuss KFW and review open issues. From: To: Time: Mon Sep 24 15:02:40 2007 I don't yet know what my availability is. I do hope I have time because I think it would be really good to get together From: To: Time: Mon Sep 24 15:14:54 2007 I could also conceivably be around Friday morning if necessary From: To: Time: Mon Sep 24 15:15:45 2007 Let me talk to Steve and see how hectic Wednesday is going to be. Naturally press interrupts should they happen will trump anything. From: To: Time: Mon Sep 24 15:17:42 2007 I assume that I am invited to Thursday. I still have not received an invitation or details. From: To: Time: Mon Sep 24 15:28:31 2007 I'm going to to the team meeting; I will ask Steve to deal in person From: To: Time: Mon Sep 24 15:28:41 2007 Kevin: in brief, your patch is taking a string that was provided by the krb5 identity provider to the NIM application and then chasing after the control it was assigned to in the dialog during a subsequent call into the identity provider. This causes an unnecessary abstraction layer violation and makes it impossible for the dialog to change without making matching changes in the krb5 provider. Assuming there wasn't already an API for doing what you need to do, the proper solution would be to specify the API that you require. From: To: Time: Mon Sep 24 16:17:33 2007 I'm sure you all saw this today. http://www.boston.com/business/technology/articles/2007/09/24/a_20_year_old_technology_may_soon_protect_cellphones/ From: To: Time: Mon Sep 24 17:18:21 2007 So, we want eol-style set for mostly everything but image files. Do we also want mime-type set for *.c and *.h if it's not already set? From: To: Time: Mon Sep 24 17:18:58 2007 i think so. i don't remember if svn defaults to text for files without mime-type properties. From: To: Time: Mon Sep 24 17:26:39 2007 No, you don't. svn will default to text. From: To: Time: Mon Sep 24 18:15:31 2007 svn:eol-style checked in. I created a ticket describing how I made the changes; it wouldn't surprise me if automatic merging doesn't work on this change... From: To: Time: Mon Sep 24 18:16:40 2007 i might just do the change independently to the release branch From: To: Time: Wed Sep 26 13:56:47 2007 heading over to W92 From: To: Time: Wed Sep 26 14:08:14 2007 We're getting some odd duplicates in RT. 5761+5762 (both subject "sdfsdf" from guest, okay, some loser could've clicked twice), 5768+5769 (both my "set svn:eol-style" message, I'm pretty sure I didn't click twice), 5770+5774 (both the AIX patch). From: To: Time: Wed Sep 26 14:09:52 2007 (I've killed the spam and merged the others... arguably perhaps I should've killed the duplicates instead of merging, since they appeared to be identical...) From: To: Time: Wed Sep 26 14:52:14 2007 Ugh. The line-wrapping in RT's web submission interface is atrocious. I type in a paragraph, submit the ticket, and view it, and it looks like the lines have been broken based on length two different times, with different lengths, so I get long line, short line, long line, short line, all the way through (when there are short enough words in the right places), all regardless of how wide my browser window is. From: To: Time: Thu Sep 27 13:52:20 2007 We should get a room for meeting with Jeff From: To: Time: Thu Sep 27 15:44:29 2007 UNIFIED THEORY OF RELATIVISTIC IDENTIFICATION OF INFORMATION IN A SYSTEMS AGE: Proposed Convergence of Unique Identification with Syntax and Semantics through Internet Protocol version 6 From: To: Time: Fri Sep 28 17:37:07 2007 oh! that's why i didn't get this week's Apple call info. spam filter ate it. From: To: Time: Fri Sep 28 17:37:44 2007 ha From: To: Time: Fri Sep 28 17:38:27 2007 i wonder what's different about it that caught the filter's eye From: To: Time: Fri Sep 28 17:38:49 2007 not sure. i don't have it pulled up right now and it's not like MIT's SpamAssassin puts the scoring details in. From: To: Time: Fri Sep 28 17:39:13 2007 X-Scanned-By: MIMEDefang 2.42 X-Spam-Score: 8.501 X-Spam-Flag: YES X-Spam-Level: ******** (8.501) From: To: Time: Fri Sep 28 17:39:30 2007 that's not too much over the threshold From: To: Time: Fri Sep 28 17:41:25 2007 previous ones that made it through seem to range widely (0.01, 0.27, 5.47) the majority are 0.27 though From: To: Time: Fri Sep 28 17:41:37 2007 weird From: To: Time: Fri Sep 28 17:43:16 2007 sending multipart/alternative text+html probably doesn't help From: To: Time: Fri Sep 28 17:48:54 2007 all children of tracking ticket 5691 have been marked for pullup to 1.6.4 From: To: Time: Fri Sep 28 17:49:06 2007 now time for a nap From: To: Time: Fri Sep 28 18:15:03 2007 gah. given timing, i just realized it should be target 1.6.3 because we are still in beta for 1.6.3. i guess i'll fix. From: To: Time: Fri Sep 28 18:33:36 2007 argh From: To: Time: Fri Sep 28 18:33:49 2007 no problem. done already From: To: Time: Fri Sep 28 18:33:53 2007 thanks From: To: Time: Fri Sep 28 18:34:09 2007 my bad originally anyway. From: To: Time: Fri Sep 28 19:34:47 2007 ouch. EOL churn. From: To: Time: Fri Sep 28 19:36:17 2007 anyway... incoming! From: To: Time: Fri Sep 28 19:36:49 2007 I've ducked under the table From: To: Time: Fri Sep 28 19:37:40 2007 this is a partial set of pullups... there are some tricks i have to do to ensure ordering of the actual EOL property changes w.r.t. other stuff that has been interleaved. From: To: Time: Sun Sep 30 02:02:23 2007 This room is not anonymous. From: To: Time: Mon Oct 1 14:39:17 2007 WRT KfW version numbers in registry paths, should the path contain the patch level or not? For example, should a registry path be like HKEY_LOCAL_MACHINE\SOFTWARE\MIT\Kerberos\Documentation\3.2 or HKEY_LOCAL_MACHINE\SOFTWARE\MIT\Kerberos\Documentation\3.2.2? Also, should the version strings, which were last given in the release notes as 3.1 be 3.2 or 3.2.2? My guesses are 3.2 in the registry path and 3.2.2 for the version string. From: To: Time: Mon Oct 1 14:45:34 2007 r20024 breaks the unix builds. is there a reason why i shouldn't back it out? From: To: Time: Mon Oct 1 14:54:37 2007 also, i appear to have missed some changes that should have gone in prior to the eol-style change. this could get painful. From: To: Time: Mon Oct 1 14:58:01 2007 Oh, ick, the export-checking script is going to need updating, isn't it? I really should arrange for that to be run on Windows, too. From: To: Time: Mon Oct 1 14:58:50 2007 and some tickets have interleaved commits again. this is rather inconvenient. From: To: Time: Mon Oct 1 14:59:41 2007 i thought i id'ed all the sequencing quirks when i started this batch of pullups, but apparently not. From: To: Time: Mon Oct 1 15:06:03 2007 Kevin, have you looked at the changes jaltman has committed over the weekend? From: To: Time: Mon Oct 1 15:06:33 2007 I looked at the subjects but not the code itself. From: To: Time: Mon Oct 1 15:14:17 2007 r19955 has a whole pile of conflicts. From: To: Time: Mon Oct 1 15:14:23 2007 Back out anything that breaks the build yes. From: To: Time: Mon Oct 1 15:15:47 2007 alternative is for someone to commit a fix to def-check.pl immediately. From: To: Time: Mon Oct 1 15:15:57 2007 20024 only breaks the unix build because I have a script in the unix build checking consistency between the Windows export list and presence of calling-convention directives in krb5.h, and that script doesn't handle the @123 notation. Fixing that looks easy, though now it seems to be flagging some declarations as inconsistent. From: To: Time: Mon Oct 1 15:16:40 2007 are they actually inconsistent? From: To: Time: Mon Oct 1 15:16:59 2007 Checking. Trying to remember what our conventions were. :( From: To: Time: Mon Oct 1 15:18:40 2007 Ah, silly me, put my patch in the wrong place. It complained about krb5_build_principal in the .def file because krb5_build_principal@44 wasn't recorded as a variadic function from the .h file. Fix coming soon... From: To: Time: Mon Oct 1 15:22:04 2007 Checked in. From: To: Time: Mon Oct 1 15:25:07 2007 Ticked merged to 5791. From: To: Time: Mon Oct 1 15:26:17 2007 Interesting... after merging, my original subject line (from subject: line in svn log message body) appears to be lost. From: To: Time: Mon Oct 1 15:29:09 2007 i don't think merge preserves everything from the ticket being merged from. From: To: Time: Mon Oct 1 16:34:59 2007 Apparently not. From: To: Time: Mon Oct 1 17:17:06 2007 oh great. i'm being bitten by eol-style problems. From: To: Time: Mon Oct 1 17:18:48 2007 Did I mis-label something? Or is it "just" merging hell? From: To: Time: Mon Oct 1 17:19:21 2007 no, not your change. the problem was r19955 which generated a huge pile of conflicts because i got the ordering wrong w.r.t. the eol-style change. From: To: Time: Mon Oct 1 17:19:47 2007 Ah. From: To: Time: Mon Oct 1 19:51:41 2007 Kevin, the version number in the installation registry paths should be 3.2.2 From: To: Time: Mon Oct 1 19:53:09 2007 The version numbers are there so that upgrades can be performed on a per component basis. From: To: Time: Mon Oct 1 19:56:20 2007 So, I've been thinking about the keytab bug, and iterators vs add/remove operations. Our current implementation, bugs aside, gives us an iterator that will let you list the contents of the keytab file as it existed at a specific point in time; changes are blocked for the duration. I assume we want to preserve this property? If so, I think I need to make the add/remove calls error out if an iterator is active, or have them mark the iterator as broken; I don't think I can effectively block the add/remove until the iteration finishes, because I can't be sure that they're working in different, uncoordinated threads. From: To: Time: Mon Oct 1 19:57:01 2007 Then the question is, is it better to allow the change and break the iterator (cause get_next to report an error), or error out on the change? From: To: Time: Mon Oct 1 19:59:34 2007 Thanks. From: To: Time: Mon Oct 1 20:11:33 2007 what is the meaning of the message from Russ forwarded to ticket #5800? From: To: Time: Mon Oct 1 20:17:49 2007 Well, he points out that our code is broken and he had to release a new version of pam-krb5 From: To: Time: Mon Oct 1 20:18:24 2007 oh. somehow i missed that part. From: To: Time: Mon Oct 1 21:31:16 2007 A keytab management tool is likely to want to iterate through the contents of a keytab and remove entries as it finds them. This requires that an iterator not fail due to a content change and that the content change not be blocked or fail simply because an iterator is active. From: To: Time: Mon Oct 1 21:32:36 2007 keytab entries aren't very large. why not create an iterator by creating an in-memory copy of the list that is freed with the iterator completes? From: To: Time: Mon Oct 1 21:33:39 2007 even in the worst case scenario described by Nico years ago, it is unlikely that there will be more than 10,000 entries. From: To: Time: Mon Oct 1 21:40:32 2007 Jeff, that sounds like an approach to consider for the future and might be a good idea. Ken estimated this would be a quick fix and has spent more than a week on it. I don't know that we have time for the sort of redesign you are talking about From: To: Time: Mon Oct 1 21:41:23 2007 So, the question is are any of Ken's proposed fixes sufficiently better than the current state that they are worth implementing. (Or is there some other low-effort fix that works) From: To: Time: Mon Oct 1 21:41:55 2007 which ticket are we talking about? I would like to re-read the original complaint From: To: Time: Mon Oct 1 21:48:04 2007 Hmm. I can't find the ticket. I expected it to be sparse but to exist From: To: Time: Mon Oct 1 21:49:58 2007 Basically the problem is that all sorts of badness happens if you use an iterator and other operations on the same keytab object at the same time. From: To: Time: Mon Oct 1 21:52:38 2007 what type of badness? corruption of the keytab by the add/remove operation or corruption of the iterator? if corruption of the iterator? what type of corruption? do entries get reported more than once? do entries not get reported at all? From: To: Time: Mon Oct 1 21:56:36 2007 FD leak, keytab becomes corrupted and future operations on that keytab object fail. Rather keytab object (not file) become corrupted From: To: Time: Mon Oct 1 21:58:30 2007 then I would block changes while the iterator is active to prevent the corruption. however, I suspect that cloning the entries would minimize the thread safety issues and make it a lot easy to put in a real fix in a short period of time. From: To: Time: Tue Oct 2 16:23:22 2007 Original complaint was via email, though I opened a ticket describing the problem a few days ago. From: To: Time: Tue Oct 2 16:23:37 2007 I've been thinking about it off and on for a week, not so much working on it for a week. From: To: Time: Tue Oct 2 16:24:56 2007 The iterate-and-remove case occurred to me, but I think we already don't support it. I could be wrong. From: To: Time: Tue Oct 2 16:25:41 2007 Yeah, _remove closes the file at the end, which would break the iterator. So that already doesn't work. From: To: Time: Tue Oct 2 16:25:52 2007 => lunch From: To: Time: Tue Oct 2 16:33:55 2007 #5697 did in fact fix the debian bug we were hoping it would fix. From: To: Time: Tue Oct 2 16:38:46 2007 yay From: To: Time: Tue Oct 2 16:38:55 2007 do we care about #5802 for 1.6.3? From: To: Time: Tue Oct 2 16:49:59 2007 Yes, if the patch looks good From: To: Time: Tue Oct 2 16:51:45 2007 hm, it does raise the question of whether accept_sec_context is supposed to store delegated creds even if ret_flags is null. From: To: Time: Tue Oct 2 16:54:59 2007 I think so if the delegated cred handle is non-null. Or rather if they provided a pointer where the creds go From: To: Time: Tue Oct 2 17:25:36 2007 so rfc2744 isn't clear on whether deleg_cred_handle can get set if ret_flags is null. it says that the cred handle isn't valid unless deleg_flag is true, but also gives some behavior w.r.t. null vs non-null settings of the output cred handle. From: To: Time: Tue Oct 2 17:50:31 2007 Hm, plugin support for auth_to_local makes sense... From: To: Time: Tue Oct 2 17:50:56 2007 auth_to_local always struck me as being somewhat inappropriate for the krb5 library From: To: Time: Tue Oct 2 17:51:13 2007 There is that, but we're stuck now. From: To: Time: Wed Oct 3 15:59:26 2007 Um, what does line 1906 of cc_file.c do? It looks like it does nothing but I'm not sure. From: To: Time: Wed Oct 3 16:01:10 2007 The line in question is cursor = (krb5_cc_cursor *) fcursor; for a function with the prototype krb5_fcc_next_cred(krb5_context context, krb5_ccache id, krb5_cc_cursor *cursor, krb5_creds *creds) From: To: Time: Wed Oct 3 16:03:43 2007 look totally superfluous From: To: Time: Wed Oct 3 16:04:01 2007 I think the correct thing would be *cursor = (krb5_fcc_cursor *) fcursor; From: To: Time: Wed Oct 3 16:04:06 2007 But it isn't necessary From: To: Time: Wed Oct 3 16:06:10 2007 sorry *cursor = (krb5_cc_cursor) fcursor; From: To: Time: Wed Oct 3 16:09:46 2007 Have not yet looked at the code. I assume what it is trying to do is to set up an internal variable and cast to the private data type so I'd expect an assignment to fcursor not cursor I think it is about avoiding casts From: To: Time: Wed Oct 3 16:10:00 2007 I'm going to remove it because it's just confusing and appears to be a paste-o from krb5_fcc_start_seq_get() From: To: Time: Wed Oct 3 16:10:13 2007 that line is just before the error return handling code From: To: Time: Wed Oct 3 16:10:41 2007 and the error return handling code doesn't even reference cursor. From: To: Time: Wed Oct 3 16:10:57 2007 it's totally: fcursor->pos = fcc_lseek(d, (off_t) 0, SEEK_CUR); cursor = (krb5_cc_cursor *) fcursor; lose: MAYBE_CLOSE (context, id, kret); k5_mutex_unlock(&d->lock); if (kret != KRB5_OK) krb5_free_cred_contents(context, creds); return kret; } From: To: Time: Wed Oct 3 16:11:31 2007 I agree it is bogus having looked at the code From: To: Time: Wed Oct 3 16:13:12 2007 yeah, i agree it look bogus and unnecessary. From: To: Time: Wed Oct 3 16:31:13 2007 so re setting ticket numbers when somebody specifies "ticket: new", it seems that it's possible to modify a transaction in a pre-commit hook, or at least so claims the docs. From: To: Time: Wed Oct 3 16:32:33 2007 i'm not sure how it interacts with things like svk though. From: To: Time: Wed Oct 3 16:39:03 2007 It should interact fine. That would be cool From: To: Time: Wed Oct 3 16:39:30 2007 i would think that svk wouldn't like having the svn:log revprop changed out from under it. From: To: Time: Wed Oct 3 16:43:16 2007 tagging kfw-3.2.2-beta1 From: To: Time: Wed Oct 3 16:47:52 2007 So long as it changes in the pre-commit hook not before svk pulls down the revision it is fine From: To: Time: Wed Oct 3 16:49:12 2007 oh, svk syncs from the transaction that actually got committed, and not what it thought it was going to commit? From: To: Time: Wed Oct 3 16:50:05 2007 Yes From: To: Time: Wed Oct 3 18:36:19 2007 hrm, looks like the ops build of svn doesn't have the swig bindings From: To: Time: Thu Oct 4 11:06:04 2007 Fun trying to build KfW: CVS is pulling from the trunk, but that shouldn't make any difference. [07/10/04 10:49:11] Executing bkw.pl -svntag kfw-3_2_2-beta1 -src r:\ -out r:\public -r co -u kpkoch ... [07/10/04 10:57:38] Making in crypto\crc32 [07/10/04 10:57:38] nmake -L [07/10/04 10:57:38] Output going into obj\i386\rel [07/10/04 10:57:38] cl -I.\..\..\..\include -I.\..\..\..\include\krb5 -IR:\pismere\scripts\..\athena\wshelper\include -DWSHELPER=1 -DKRB5_DNS_LOOKUP=1 -D KRB5_DNS_LOOKUP_KDC=1 -DKRB5_PRIVATE=1 -DWIN32_LEAN_AND_MEAN -DKRB5_DEPRECATED=1 -D_CRT_SECURE_NO_DEPRECATE -DUSE_LEASH=1 -D_USE_32BIT_TIME_T /Os /MD /ZI -nolog o /W3 -Fdobj\i386\rel\\ -FD -Foobj\i386\rel\\ -c ... [07/10/04 10:57:38] crc32.c [07/10/04 10:57:39] r:\pismere\athena\auth\krb5\src\include\k5-int.h(1983) : error C2059: syntax error : '(' [07/10/04 10:57:39] r:\pismere\athena\auth\krb5\src\include\k5-int.h(1986) : error C2365: 'krb5int_set_prompt_types' : redefinition; previous definition was a 'function' [07/10/04 10:57:39] r:\pismere\athena\auth\krb5\src\include\k5-int.h(1809) : see declaration of 'krb5int_set_prompt_types' [07/10/04 10:57:39] r:\pismere\athena\auth\krb5\src\include\k5-int.h(1988) : error C2365: 'encode_krb5_authdata_elt' : redefinition; previous definition was a 'function' [07/10/04 10:57:39] r:\pismere\athena\auth\krb5\src\include\k5-int.h(1451) : see declaration of 'encode_krb5_authdata_elt' [07/10/04 10:57:39] r:\pismere\athena\auth\krb5\src\include\k5-int.h(1990) : error C2059: syntax error : '}' [07/10/04 10:57:39] r:\pismere\athena\auth\krb5\src\include\k5-int.h(1997) : error C2143: syntax error : missing ')' before '*' [07/10/04 10:57:39] r:\pismere\athena\auth\krb5\src\include\k5-int.h(1997) : error C2143: syntax error : missing '{' before '*' [07/10/04 10:57:39] r:\pismere\athena\auth\krb5\src\include\k5-int.h(1997) : error C2059: syntax error : ',' [07/10/04 10:57:39] r:\pismere\athena\auth\krb5\src\include\k5-int.h(1997) : error C2059: syntax error : ')' [07/10/04 10:57:39] NMAKE : fatal error U1077: 'cl' : return code '0x2' From: To: Time: Thu Oct 4 11:06:38 2007 Test. From: To: Time: Thu Oct 4 11:22:20 2007 Reverting to 19759 gives a different compile error. From: To: Time: Thu Oct 4 11:22:51 2007 Rather than reverting, I'd actually look at the code and see why it is broken From: To: Time: Thu Oct 4 11:39:53 2007 So, one of those declarations is in a struct; one is not. Unless there is some syntax error introduced somehow I don't see the problem From: To: Time: Thu Oct 4 12:50:16 2007 It turns out that krb5int_set_prompt_types doesn't have anything to do with it. This modification of the line before krb5int_set_prompt_types compiles: ... void /*__stdcall*/ (*krb5_free_kdc_req) (krb5_context, krb5_kdc_req * ); /* KPK */ void (*krb5int_set_prompt_types) (krb5_context, krb5_prompt_type *); krb5_error_code (*encode_krb5_authdata_elt) (const krb5_authdata *rep, krb5_data **code); } krb5int_access; From: To: Time: Thu Oct 4 12:54:18 2007 Do you understand the problem? From: To: Time: Thu Oct 4 12:58:47 2007 No. From: To: Time: Thu Oct 4 12:59:14 2007 The syntaxt for calling conventions in function pointers is different for functional declarations From: To: Time: Thu Oct 4 13:07:57 2007 So, my main question is why is there a function in k5-int.h with krb5_callconv? From: To: Time: Thu Oct 4 13:13:22 2007 Maybe to fix [07/10/04 13:05:27] Making in krb5\os ... [07/10/04 13:05:27] accessor.c [07/10/04 13:05:28] r:\pismere\athena\auth\krb5\src\lib\krb5\os\accessor.c(107) : error C2440: '=' : cannot convert from 'void (__stdcall *)(krb5_context,krb5_kdc_req *)' to 'void (__cdecl *)(krb5_context,krb5_kdc_req *)' or was that a leading question? From: To: Time: Thu Oct 4 13:21:09 2007 No, I understand that you need to get the function pointer calling convention correct (and you need to look up how to do that in the msvc docs) but what I don't understand is why the function being assigned to that pointer is krb5_callconv From: To: Time: Thu Oct 4 13:59:21 2007 Sam, there are dozens of functions in k5-int.h that are defined as KRB5_CALLCONV From: To: Time: Thu Oct 4 13:59:43 2007 I believe that many of them started in krb5.h and were moved to k5-int.h From: To: Time: Thu Oct 4 14:00:51 2007 In krb5int_access, the function pointer for krb5_free_kdc_req should be defined as: void (KRB5_CALLCONV *krb5_free_kdc_req) (krb5_context, krb5_kdc_req * ); From: To: Time: Thu Oct 4 14:01:05 2007 In this instant I'd be happy with renaming the function to some sort of krb5int_*. But fixing the function pointer declaration is also fine From: To: Time: Thu Oct 4 14:01:29 2007 I believe I committed a fix for that quite a while ago From: To: Time: Thu Oct 4 14:01:48 2007 revision 19754 From: To: Time: Thu Oct 4 14:02:11 2007 Was it not pulled up? From: To: Time: Thu Oct 4 14:03:12 2007 apparently not. it should have been with the pkinit fixes From: To: Time: Thu Oct 4 14:03:46 2007 ticket 5625 From: To: Time: Thu Oct 4 14:07:15 2007 ah, it wasn't merged into 5617 as the rest of the pkinit tickets were From: To: Time: Thu Oct 4 14:07:24 2007 I have marked it for pullup From: To: Time: Thu Oct 4 16:18:32 2007 should i bump the build level for the re-tag? or not bother because the build was impossible? From: To: Time: Thu Oct 4 16:18:51 2007 Don't bother From: To: Time: Thu Oct 4 16:19:00 2007 there was no code distribute From: To: Time: Thu Oct 4 16:19:01 2007 d From: To: Time: Thu Oct 4 17:01:34 2007 I will confirm that this tag builds From: To: Time: Thu Oct 4 17:24:33 2007 also going to fix 4136 because it falls under "embarrassing and trivial to fix" From: To: Time: Thu Oct 4 17:28:21 2007 agreed From: To: Time: Thu Oct 4 18:15:53 2007 i wonder if we can convince ops to rebuild the svn installation on svn.mit.edu so it has SWIG binding support. From: To: Time: Thu Oct 4 18:47:56 2007 What would swig on svn.mit.edu give us? From: To: Time: Thu Oct 4 18:48:42 2007 the svn distribution doesn't have any way to modify the revprops on a transaction in-flight using the provided programs. From: To: Time: Thu Oct 4 18:50:52 2007 i suppose i could write a program that called into the svn API that would do the equivalent of svnadmin setlog on a transaction rather than a committed revision. From: To: Time: Thu Oct 4 21:29:54 2007 copyfiles.xml [svn rev 20099] needs to be pulled up so we can try the build again. No need to change the beta number, since the build didn't succeed. From: To: Time: Fri Oct 5 11:13:48 2007 since you are going to need to retag anyway. might as well take the incoming ticket. From: To: Time: Fri Oct 5 11:14:55 2007 Which incoming ticket? From: To: Time: Fri Oct 5 11:15:20 2007 the one that fixes the bug report that was posted to kfwdev From: To: Time: Fri Oct 5 11:17:11 2007 I don't see a new bug report on kfwdev. What is the bug? From: To: Time: Fri Oct 5 11:17:28 2007 you don't see an e-mail from Beata? From: To: Time: Fri Oct 5 11:18:00 2007 kfwdev@mit.edu not kfw-bugs From: To: Time: Fri Oct 5 11:18:23 2007 Oh, that. That isn't a bug, it's a feature request. Not for kfw 3.2.2. From: To: Time: Fri Oct 5 11:18:34 2007 Its not a feature request. its a bug. From: To: Time: Fri Oct 5 11:18:54 2007 the actual limit is something like 1024 characters From: To: Time: Fri Oct 5 11:19:15 2007 The reason it can't be input is that the EDIT control doesn't have hscroll capability From: To: Time: Fri Oct 5 11:19:16 2007 Index: newcredwnd.c =================================================================== --- newcredwnd.c (revision 20092) +++ newcredwnd.c (working copy) @@ -2426,7 +2426,7 @@ (d->nc->prompts[i]->def ? d->nc->prompts[i]->def : L""), WS_CHILD | WS_TABSTOP | - WS_BORDER | + WS_BORDER | ES_AUTOHSCROLL | ((d->nc->prompts[i]->flags & KHUI_NCPROMPT_FLAG_HIDDEN)? ES_PASSWORD:0), er.left, er.top, From: To: Time: Fri Oct 5 11:19:52 2007 OK, it's a bug. Document it. From: To: Time: Fri Oct 5 11:20:28 2007 how would you like it documented other than in a ticket with the fix? From: To: Time: Fri Oct 5 11:22:11 2007 All right, if its already fixed then lets put it in. And then say no more changes. I'd like to have everything pulled up and tagged by noon. My wife wants me home by 3 to leave for a place where there isn't any cell phone coverage or internet service. From: To: Time: Fri Oct 5 11:22:46 2007 Even if you didn't put it into beta 1, it could still go into final. that is why we have beta periods. From: To: Time: Fri Oct 5 11:23:49 2007 Tom still has to retag, so if you can commit the fix now, we can do it now. From: To: Time: Fri Oct 5 11:24:04 2007 as I said, "incoming" From: To: Time: Fri Oct 5 12:37:34 2007 nobody do anything with the new kfw tag From: To: Time: Fri Oct 5 12:37:34 2007 STOP From: To: Time: Fri Oct 5 12:37:38 2007 something strange happened and i'm not sure what. From: To: Time: Fri Oct 5 12:37:49 2007 k From: To: Time: Fri Oct 5 12:40:26 2007 oh hell From: To: Time: Fri Oct 5 12:40:35 2007 i deleted the kfw-3_2_1-beta1 tag by accident. From: To: Time: Fri Oct 5 12:44:02 2007 i suppose i can resurrect it if necessary but do we need it to be? From: To: Time: Fri Oct 5 12:44:19 2007 Not now. From: To: Time: Fri Oct 5 12:45:21 2007 also, is there some way you can build from the krb5-1-6 branch or whatever so we don't need to repeatedly re-tag? From: To: Time: Fri Oct 5 12:45:43 2007 I don't think a beta tag is all that important. Especially not for kfw 3.2.1 where I don't even think the beta was publicly announced. From: To: Time: Fri Oct 5 12:47:16 2007 bkw.pl needs either a branch or tag. Using a branch makes it vulnerable to pullups after the build. From: To: Time: Fri Oct 5 12:48:22 2007 i wasn't advocating using the branch for the (beta) release build, just for test builds so it's possible to determine that the branch actually builds before we make a tag. From: To: Time: Fri Oct 5 12:48:40 2007 I did that last night ;-). From: To: Time: Fri Oct 5 12:49:24 2007 ok, so you sorted out all the build/install problems before you requested today's pullup? From: To: Time: Fri Oct 5 12:49:31 2007 Yes. From: To: Time: Fri Oct 5 12:51:22 2007 ok, this tag looks sane. From: To: Time: Fri Oct 5 12:52:48 2007 the pismere release notes need to be updated to include 5809 From: To: Time: Fri Oct 5 12:53:04 2007 Something for beta2. From: To: Time: Fri Oct 5 12:53:26 2007 you haven't checked in the new release notes yet From: To: Time: Fri Oct 5 12:53:54 2007 zRight. Something else for beta2! From: To: Time: Fri Oct 5 12:54:08 2007 you haven't tagged the pismere tree yet From: To: Time: Fri Oct 5 12:54:43 2007 When did you look? Also, I only tagged the modules bkw fetches. From: To: Time: Fri Oct 5 12:55:13 2007 I saw no tag message delivered to the pismere-cvs mailing list From: To: Time: Fri Oct 5 12:56:19 2007 I wonder if the tag messages only get sent when the entire repository is tagged From: To: Time: Fri Oct 5 12:58:28 2007 you really need to check in the release notes and update the cvs tag. you shouldn't release a beta that says its 3.2.1 From: To: Time: Fri Oct 5 12:58:38 2007 and that doesn't tell folks what changed From: To: Time: Fri Oct 5 12:59:00 2007 OK. From: To: Time: Fri Oct 5 13:06:15 2007 right then. heading to the office for real this time. From: To: Time: Fri Oct 5 13:22:35 2007 How do I take the sticky tag off of relnotes.html??? From: To: Time: Fri Oct 5 13:28:30 2007 cvs up -H. Look for the -A option From: To: Time: Fri Oct 5 13:32:25 2007 Thanks. Building ... From: To: Time: Fri Oct 5 14:08:18 2007 astaff\project\krbdev\kfw-archive filled up; the zip of the kfw3.2.2 beta1 build is in http://web.mit.edu/kpkoch/Public/build.zip. From: To: Time: Fri Oct 5 14:14:00 2007 aka /afs/athena.mit.edu/user/k/p/kpkoch/Public/build.zip From: To: Time: Fri Oct 5 14:16:05 2007 please remove the zip file in the krbdev locker for now. i'll look into how we can deal with this in the future. From: To: Time: Fri Oct 5 14:18:28 2007 Do you mean the 3.2.0 final zip? From: To: Time: Fri Oct 5 14:20:25 2007 the 3.2.2 beta1 zip, because it might be incomplete, and we need the space for other things as well. From: To: Time: Fri Oct 5 14:20:55 2007 There isn't an incomplete 322B1 zip there. From: To: Time: Fri Oct 5 14:21:09 2007 oh it is complete? From: To: Time: Fri Oct 5 14:21:25 2007 I'm leaving for home. Call my cell 7812547542 if you need me to sign on and do anything once I;m home. From: To: Time: Fri Oct 5 14:22:16 2007 so is the beta ready for announcement? or are we waiting until Tuesday? From: To: Time: Fri Oct 5 14:29:42 2007 did Kevin give you announcement text? From: To: Time: Fri Oct 5 14:31:26 2007 not that i've seen From: To: Time: Fri Oct 5 14:31:54 2007 do you want me to write some and give it to you after I verify the build? From: To: Time: Fri Oct 5 14:31:56 2007 also, that's just the build zip. does it actually contain the output products? From: To: Time: Fri Oct 5 14:32:06 2007 I have no idea From: To: Time: Fri Oct 5 14:32:37 2007 I'm looking From: To: Time: Fri Oct 5 14:33:10 2007 anyway i have heard no clear statement of intentions regarding releasing this beta yet. From: To: Time: Fri Oct 5 14:33:30 2007 I am as in the dark as you are From: To: Time: Fri Oct 5 14:33:51 2007 and from Kevin's previous statements he is gone and will be without net access until tuesday From: To: Time: Fri Oct 5 14:35:04 2007 the build.zip file does include all of the generated installers. under the "public" directory From: To: Time: Fri Oct 5 14:35:25 2007 on a mostly unrelated note, it seems that the build script doesn't do "export", so it's full of .svn and CVS directories. From: To: Time: Fri Oct 5 14:35:48 2007 the build script does do export if you ask it. apparently kevin didn't ask From: To: Time: Fri Oct 5 14:36:09 2007 he specified "co" for checkout From: To: Time: Fri Oct 5 14:36:22 2007 I suggest holding off until tuesday From: To: Time: Fri Oct 5 14:54:03 2007 so the DST fix isn't required for another few weeks, right? From: To: Time: Fri Oct 5 14:58:32 2007 well, the old DST change would have been oct 26 no one has told the world yet that there is a problem with 3.2.1 and most organizations need time to vet the change before pushing it out. the goal was to have the final build out by oct 11th From: To: Time: Fri Oct 5 14:58:44 2007 at least that was the advice I gave Kevin From: To: Time: Fri Oct 5 14:59:56 2007 hm, and i thought the EU and the US were going to align their DST change dates but apparently not. From: To: Time: Fri Oct 5 15:00:30 2007 oct 26 was read off of the 2008 calendar. would have been oct 28 From: To: Time: Fri Oct 5 15:00:45 2007 the new DST date is Nov 4th From: To: Time: Fri Oct 5 15:01:00 2007 the CRT will begin to do the wrong thing on the old date From: To: Time: Fri Oct 5 15:17:21 2007 i called Kevin; we'll wait for Tuesday. From: To: Time: Fri Oct 5 15:18:21 2007 I'm not all that concerned. I've had clients running test builds for a couple of weeks now From: To: Time: Fri Oct 5 15:20:05 2007 also, i just checked the 3.2.0 build archive... it was built using export, but 3.2.1 and 3.2.2b1 were built using checkout. From: To: Time: Fri Oct 5 15:20:23 2007 I built 3.2.0 From: To: Time: Fri Oct 5 15:23:01 2007 ah ok From: To: Time: Fri Oct 5 15:23:30 2007 I suspect that 3.2.2-b1 should be rebuilt From: To: Time: Fri Oct 5 16:07:42 2007 Hm, I'm writing a reply to bbense (why ldap vs db2), but the more I write, the more it sounds like "don't use db2". E.g., this is the only project exercising this version of the code and finding bugs, so if bugs bite, there's a high chance it'll corrupt someone's KDC database instead of trashing something relatively unimportant. We don't have largefile support, so our max size is limited. From: To: Time: Fri Oct 5 16:09:08 2007 I wonder if sqlite or some such might be a good replacement, for 1.8 or so. It might also be a good time to consider fixing any issues in the database structure. From: To: Time: Fri Oct 5 16:12:52 2007 Seema might be hired by Apple From: To: Time: Fri Oct 5 16:13:13 2007 Ah, good for her. From: To: Time: Fri Oct 5 16:13:22 2007 And them. From: To: Time: Fri Oct 5 20:26:16 2007 I am now receiving mail that was stuck on south-station-annex.mit.edu since Monday From: To: Time: Sun Oct 7 02:02:26 2007 This room is not anonymous. From: To: Time: Mon Oct 15 18:55:58 2007 hm, finally got into the chat. From: To: Time: Mon Oct 15 18:56:09 2007 welcome :) From: To: Time: Mon Oct 15 18:56:19 2007 any idea what happened earlier? From: To: Time: Mon Oct 15 18:57:06 2007 It worked when I tried during the meeting, and again when I got downstairs. Were you still having problems after that? From: To: Time: Mon Oct 15 18:57:13 2007 I joined from mit.edu; did you use mit or jis? From: To: Time: Mon Oct 15 18:57:17 2007 i use jis.mit.edu From: To: Time: Mon Oct 15 18:58:13 2007 also, mailman ate a few newbie postings i had approved for krbdev. not sure what's up with that. From: To: Time: Mon Oct 15 18:58:32 2007 Might've been a problem there, then. I don't use my jis account for much because the presence data on my account is broken. (People can't see me, I can't even see myself, and removing and re-adding contacts doesn't help. And Jeff is naturally too busy to investigate.) From: To: Time: Mon Oct 15 18:59:13 2007 Hm, Nico said he didn't get my initial message about a2c. From: To: Time: Mon Oct 15 20:40:23 2007 Do we know if the AFS salt type code works? We've got an open ticket (2545) claiming it's broken for passwords over 8 characters. If that's actually the case, do we want to fix it, or keep it compatible with the current brokenness? From: To: Time: Mon Oct 15 20:41:05 2007 dunno. we might be able to try multiple salts, unless preauth gets in the way. From: To: Time: Mon Oct 15 20:41:38 2007 True. From: To: Time: Mon Oct 15 20:44:26 2007 I'm reasonably sure it works in the etype-info2 path. I thought I tested more than 8 chars. However that was a while ago From: To: Time: Mon Oct 15 20:45:04 2007 I think we want it to be the case that our fakeka when run against openafs's klog does the right thing. From: To: Time: Mon Oct 15 20:50:10 2007 We should get some test cases, then. Salt strings, passwords, and keys. From: To: Time: Mon Oct 15 20:52:04 2007 Hrm.. the fakeka code isn't going to get any help out of the multithreading patches. From: To: Time: Thu Oct 18 09:38:46 2007 Fixed From: To: Time: Sun Oct 21 02:02:27 2007 This room is not anonymous. From: To: Time: Sun Oct 21 04:03:42 2007 More spam in the kfw queue... From: To: Time: Mon Oct 22 17:08:01 2007 Should the stash-file-keytab writeup go to krbdev? From: To: Time: Mon Oct 22 17:08:21 2007 Sure From: To: Time: Mon Oct 22 17:08:29 2007 ok. From: To: Time: Mon Oct 22 17:19:19 2007 how did we agree to deal with the kfw4 release date issue? by just dropping it? From: To: Time: Mon Oct 22 17:26:20 2007 From the release announcement, yes, I think so From: To: Time: Mon Oct 22 17:29:04 2007 Minor details: Do we want to keep the ability to write old format stash files? How about converting from keytab to old format stash file? I'm thinking probably not, but if someone installs a new 1.7 installation, encounters problems, and wants to switch to 1.6.... From: To: Time: Mon Oct 22 17:31:55 2007 maybe. on the other hand, "that's what backups are for" From: To: Time: Mon Oct 22 17:32:34 2007 If the 1.7 install is new, i.e., not an upgrade, there may not be any backups, only the keytab version of the stash file. From: To: Time: Mon Oct 22 17:36:04 2007 The resulting code may be cleanest if we provide conversions (both directions?), and have krb5_db_def_fetch_mkey support only the keytab format. It forces upgrades to be messier though. From: To: Time: Mon Oct 22 17:39:23 2007 Forcing upgrades to be messy sounds like a really bad idea. Personally I don't consider write old stash file to be critical functionality From: To: Time: Mon Oct 22 17:43:43 2007 Yeah, I don't relish the idea of making upgrades messy, but our kdb code will stay messy until we do it. And it'll probably turn into one of those projects that we never do get around to dealing with, because making code pretty isn't high on anyone's list. From: To: Time: Mon Oct 22 17:44:02 2007 (... and it's not something I feel particularly strongly about, in this case.) From: To: Time: Mon Oct 22 17:53:28 2007 gah. out of space. From: To: Time: Mon Oct 22 17:53:34 2007 I think breaking compatibility on reading the stash file will be unacceptable for Debian, Apple, Redhat and Sun. I'm guessing for Redhat and Sun From: To: Time: Mon Oct 22 17:57:04 2007 Probably true. Maybe in a few years. Or in conjunction with some database change that requires a dump and reload or semi-automated conversion... From: To: Time: Mon Oct 22 18:00:19 2007 I'm guessing KDB updates aren't cleverly supported in Sun's incremental propagation code? From: To: Time: Tue Oct 23 14:08:02 2007 Hm, the heimdal-discuss list just reminded me, I was thinking of adding a test program to check that our installed headers remain C++-friendly. (I think k5-int.h flunks the test, but everything we install was okay last I checked.) From: To: Time: Tue Oct 23 15:40:45 2007 i'm kind of puzzled by the pkinit configure script problem. i thought Doug had tested stuff. From: To: Time: Tue Oct 23 17:05:21 2007 src/plugins/preauth/pkinit/configure.in shouldn't exist on the trunk, right? From: To: Time: Tue Oct 23 17:05:49 2007 Correct From: To: Time: Tue Oct 23 17:07:40 2007 Interestingly while I agree the check_funcs is broken, I don't see it actually causing any failure on Debian. and for example http://packages.debian.org/krb5-pkinit exists. From: To: Time: Tue Oct 23 17:08:06 2007 interesting. it is making an empty "for" statement though, which could give some shells indigestion. From: To: Time: Tue Oct 23 17:09:55 2007 does anyone think kfwdev needs to see jaltman's posting of that huge diff? From: To: Time: Sun Oct 28 02:02:30 2007 This room is not anonymous. From: To: Time: Sun Nov 4 01:02:26 2007 This room is not anonymous. From: To: Time: Fri Nov 9 13:36:36 2007 I bet we don't want our weekly meeting in back bay From: To: Time: Sun Nov 11 02:02:30 2007 This room is not anonymous. From: To: Time: Tue Nov 13 12:09:04 2007 I have a question about how the krb5 team uses krbsnap@svn.mit.edu . From: To: Time: Tue Nov 13 12:09:40 2007 I have access to a similar account called athenasnap, but I can't do an svn checkout via it as things stand because /usr/local/bin isn't in the path. krbsnap doesn't appear to be any different; why isn't this a problem for krb5? From: To: Time: Tue Nov 13 12:10:42 2007 (I can just create a .cshrc for the moment, but I prefer to understand.) From: To: Time: Tue Nov 13 12:16:30 2007 Oh, bummer, svn.mit.edu isn't new enough to support replay. From: To: Time: Tue Nov 13 12:38:05 2007 Hmm, I have no idea. Does svn have a client-side option for "pathname to svnserve"? From: To: Time: Tue Nov 13 12:38:30 2007 I see athenasnap has a passwd entry with a homedir of /var/athenasnap, but krbsnap has no entry. From: To: Time: Tue Nov 13 12:38:36 2007 No. Now I'm wondering if you guys are just using rsync, though. From: To: Time: Tue Nov 13 12:41:32 2007 Oh. Hm. If I'm looking at the right script (on dragons-lair), we're checking out snapshots from the mirror in AFS, which is also used by the anonsvn server. From: To: Time: Tue Nov 13 12:42:25 2007 So I'm guessing krbsnap@svn isn't actually used at all now. From: To: Time: Tue Nov 13 12:43:01 2007 How is the mirror in AFS made? From: To: Time: Tue Nov 13 12:44:32 2007 At checkin time some synchronization script is launched. From: To: Time: Tue Nov 13 12:46:11 2007 /svn/krb5/hooks/post-commit launches /svn/krb5/hooks/commit-handler which gets tokens and ...um, does stuff. From: To: Time: Tue Nov 13 12:46:29 2007 Ah, so it's push. From: To: Time: Tue Nov 13 12:46:40 2007 Ah. Grab a lock, svnadmin dump from last synced version, pipe to svnadmin load. From: To: Time: Tue Nov 13 12:46:40 2007 Yes. From: To: Time: Tue Nov 13 16:34:34 2007 Well, that plumber appointment took longer than I expected... From: To: Time: Tue Nov 13 16:35:09 2007 Are you still at home? From: To: Time: Tue Nov 13 16:35:23 2007 Yeah. The plumber just left. From: To: Time: Tue Nov 13 16:48:33 2007 eproject non-support for Gantt charts in firefox is documented in the online help. oh well. From: To: Time: Tue Nov 13 16:50:54 2007 on the other hand, it makes printable Gantt charts successfully, it looks like From: To: Time: Wed Nov 14 17:51:11 2007 did anyone get mail from the eproject system? From: To: Time: Wed Nov 14 17:52:37 2007 don't see it. From: To: Time: Wed Nov 14 17:54:13 2007 everyone already had eproject accounts, actually, so i just added them to the project. i'll try having the system resend invitations. From: To: Time: Wed Nov 14 18:08:17 2007 Ah, google says "krep" is a umich thing. I'm having trouble getting at the umich web servers though. From: To: Time: Wed Nov 14 18:09:48 2007 actually since everyone already has accounts, i wonder what will happen if you just ask it to reset your password. From: To: Time: Wed Nov 14 18:13:45 2007 Well, first you'll have to tell us where it is. I've tried web.mit.edu/eproject, eproject.mit.edu, and mit-google search for eproject, and still have basically no information. From: To: Time: Wed Nov 14 18:13:55 2007 login.eproject.com From: To: Time: Wed Nov 14 18:14:19 2007 Oh, so it's not actually *here*. No wonder... From: To: Time: Wed Nov 14 18:14:26 2007 "hosted app" From: To: Time: Wed Nov 14 18:14:40 2007 also you might have to type your email address in all caps for some reason. From: To: Time: Wed Nov 14 18:18:06 2007 I keep getting told that the letters I'm typing don't match the ones in the image. Only, the images they use are really distorted, and I'm not sure what some of them are supposed to be. Never mind that it's case sensitive, and they're using letters like capital-or-maybe-small-w and capital-i-or-small-ell that would be tough to distinguish with just a little distortion. From: To: Time: Wed Nov 14 18:18:34 2007 hm, ok. i guess i'll poke the admins then. From: To: Time: Wed Nov 14 18:18:51 2007 I think I finally got one. From: To: Time: Wed Nov 14 18:19:16 2007 i don't remember needing a captcha From: To: Time: Wed Nov 14 18:19:18 2007 I think it's deciding whether to send me a new password. :) From: To: Time: Wed Nov 14 18:19:22 2007 heh From: To: Time: Wed Nov 14 18:19:41 2007 of course my account creation sent me a temp password From: To: Time: Wed Nov 14 18:19:41 2007 Ah, it finally decided to do it. Or, so it claims. From: To: Time: Wed Nov 14 18:19:45 2007 ok From: To: Time: Wed Nov 14 18:20:28 2007 Email just arrived. Apparently my name is "Kenneth Raeburn X". From: To: Time: Wed Nov 14 18:20:39 2007 sure, you can change that. From: To: Time: Wed Nov 14 18:21:19 2007 But why preload it with incorrect information? From: To: Time: Wed Nov 14 18:21:31 2007 wasn't my idea. probably someone botched a database load. From: To: Time: Wed Nov 14 18:21:57 2007 e.g., extracted only firstname+lastname from some database and loaded it in a way that caused a middle initial to default to "X". From: To: Time: Wed Nov 14 18:23:33 2007 With both uppercase and lowercase version of my email address, it accepts the password but says I'm not allowed to log in to the Enterprise I'm attempting to access. From: To: Time: Wed Nov 14 18:23:49 2007 weird. From: To: Time: Wed Nov 14 18:24:20 2007 I could see that, but then it would be Kenneth X Raeburn or something more obvious than that. Maybe a Jr./Sr./III/etc field got the X. From: To: Time: Wed Nov 14 18:24:45 2007 hm, maybe the "X" means your account is in a weird state. From: To: Time: Wed Nov 14 18:24:52 2007 you're in there with RAEBURN@MIT.EDU From: To: Time: Thu Nov 15 13:53:36 2007 where is the official Kerberos Extras page now anyway? From: To: Time: Thu Nov 15 13:59:45 2007 http://web.mit.edu/swrt/releases/macosx/installer/mit-kerberos-extras-10.5-b2.dmg From: To: Time: Thu Nov 15 14:00:00 2007 that's for external people as well? From: To: Time: Thu Nov 15 14:03:41 2007 we don't have 2 installers anymore From: To: Time: Thu Nov 15 14:04:09 2007 is the Kerberos Extra info page linked from web.mit.edu/macdev/ the current one? From: To: Time: Thu Nov 15 14:04:45 2007 yes and the link is busted and I'm fixing it right now From: To: Time: Thu Nov 15 14:05:05 2007 they keep changing the name of the file From: To: Time: Thu Nov 15 14:09:51 2007 oh. hm. the complaint we just got to krbcore was about an openafs page. weird. From: To: Time: Thu Nov 15 14:16:04 2007 then again the referenced openafs page does not link to the .dmg From: To: Time: Thu Nov 15 14:19:25 2007 I wonder if they ripped the link off when they saw the email From: To: Time: Thu Nov 15 14:19:53 2007 modtime 14:09, so possibly yes. From: To: Time: Thu Nov 15 14:20:22 2007 but if the problem was with the openafs page, why cc us? From: To: Time: Thu Nov 15 14:26:03 2007 No idea, maybe the user was too lazy to visit the outer directory and didn't realize we'd just changed the file name From: To: Time: Thu Nov 15 14:33:29 2007 hm, the kfm download page has a broken link to the IS KfM page. From: To: Time: Thu Nov 15 14:36:10 2007 the openafs macos.html hasn't had a link to kerberos extras for a long time From: To: Time: Thu Nov 15 14:36:25 2007 I wonder what page that person was really looking at From: To: Time: Thu Nov 15 14:36:50 2007 perhaps he pasted the wrong link From: To: Time: Thu Nov 15 14:38:05 2007 is MIT doing any regression testing against XP SP3, Vista SP1, or Server 2008? From: To: Time: Thu Nov 15 18:08:38 2007 do we really do a load and unload of the kdb plug-in module every time we do a db_get_principal? From: To: Time: Thu Nov 15 18:10:43 2007 Yuck, I hope not. There ought to be a handle on the plug-in kept around. (Though the database may get opened and closed a lot.) But I haven't tried tracing it to be sure. From: To: Time: Thu Nov 15 18:18:03 2007 the truss output kind of suggests that it does get unloaded and reloaded, which puzzles me. From: To: Time: Thu Nov 15 18:27:35 2007 oh joy. it gets refcounted, and i'm not sure we won't end up repeatedly unloaded when refcount hits zero. From: To: Time: Thu Nov 15 18:42:59 2007 actually upon closer inspection krb524d closes the db after 60 sec inactivity From: To: Time: Thu Nov 15 22:38:50 2007 Uh oh. That's just wrong. From: To: Time: Thu Nov 15 22:39:27 2007 Wait, this is krb524d specifically? I was thinking about the KDC. It's possible krb524d is insufficiently clever. From: To: Time: Thu Nov 15 22:41:27 2007 Unloading and reloading after 60s idle is probably okay. It's a waste, but if you're not running on an 8MHz processor it's not really very important. (Maybe when we get to running KDCs on embedded devices, if we haven't completely ditched krb4 by then.) From: To: Time: Mon Nov 19 12:49:06 2007 Ick. I think the disk in my linux box is dying. From: To: Time: Mon Nov 19 15:39:17 2007 So, do you think Venustech are just trying to make a name for themselves without having a great deal of clue, or are they just missing the mark on some of our bugs? From: To: Time: Tue Nov 20 13:59:00 2007 Are we having a holiday party this year From: To: Time: Tue Nov 20 14:00:36 2007 Wed Dec 12 6-9PM at Anthony's Pier 4 in Boston. From: To: Time: Tue Nov 20 14:04:50 2007 Spouses/SOs invited. From: To: Time: Sun Nov 25 02:02:27 2007 This room is not anonymous. From: To: Time: Mon Nov 26 10:55:12 2007 How can I restore a file accidentally deleted from web.mit.edu/kpkoch/Public/... ? From: To: Time: Mon Nov 26 10:56:45 2007 Take a look at web.mit.edu/answers but basically look in OldFiles in the top level of your afs directory. That's a backup from this morning around 4 From: To: Time: Mon Nov 26 11:01:28 2007 Thanks. From: To: Time: Mon Nov 26 12:12:18 2007 I'd like to try out a conference bridge for this afternoon's meeting. Any chance I could get a couple people to call into a bridge and listen to audio quality? From: To: Time: Mon Nov 26 12:14:54 2007 Hmm, kind of sparse set of people here From: To: Time: Mon Nov 26 13:12:18 2007 still need someone to call? From: To: Time: Mon Nov 26 14:48:36 2007 Could I get someone to try calling my office phone of 3-8685. wilson tried to call and got voicemail From: To: Time: Mon Nov 26 14:48:52 2007 sure From: To: Time: Mon Nov 26 14:49:30 2007 voicemail here too From: To: Time: Mon Nov 26 14:49:55 2007 Try again. I want to get a packet capture. I hate this crap From: To: Time: Mon Nov 26 14:50:32 2007 Hmm. Never mind From: To: Time: Mon Nov 26 14:50:35 2007 tried again, still voicemail From: To: Time: Mon Nov 26 14:52:01 2007 Ah, I hit do not disturb or somewsuch From: To: Time: Mon Nov 26 14:52:09 2007 ahhh From: To: Time: Mon Nov 26 14:54:00 2007 btw, is the audience for the board meeting presentations technical or not? Will they want to see function calls? Can I expect them to know what a Kerberos principal or realm is? From: To: Time: Mon Nov 26 14:57:19 2007 They don't need to see function calls but could understand them if your presentation included them. They definitely know what kerberos principals are. The guy from sun has sent us patches before and the guy from Google definitely works with our code directly. And you know Wilson From: To: Time: Mon Nov 26 14:58:56 2007 Is this an OK place to put URL of BOD presentation? From: To: Time: Mon Nov 26 15:02:29 2007 I think so. From: To: Time: Mon Nov 26 15:04:45 2007 Any comments or suggestions about http://web.mit.edu/kpkoch/Public/Consortium/powerpoint/KfW%20Consortium%20presentation%2020071211.ppt are welcome. Thanks. From: To: Time: Mon Nov 26 17:51:52 2007 no SSL for the wiki? From: To: Time: Mon Nov 26 17:53:09 2007 I wonder (again) if we should have minutes from the meetings. From: To: Time: Mon Nov 26 17:53:46 2007 possibly From: To: Time: Mon Nov 26 17:54:14 2007 i think we want to have two sets of minutes given our current meeting format. From: To: Time: Mon Nov 26 17:54:18 2007 I wonder if anyone else will volunteer to take them and mail them out. :-) From: To: Time: Mon Nov 26 17:54:42 2007 what, you're not volunteering? From: To: Time: Mon Nov 26 17:54:51 2007 With the new split meetings, yes, we should. From: To: Time: Mon Nov 26 17:55:38 2007 Nope. Tried it before, it was pretty tedious, and no one seemed to care anyways. Well, notes more than minutes, but still. From: To: Time: Mon Nov 26 17:56:23 2007 Now I think there's somewhat more use for them now that we're involving more people from outside, but I still am disinclined to deal myself. From: To: Time: Mon Nov 26 18:32:55 2007 Ah, Aaron Jaggard was the one I was thinking of, who did the protocol analysis with Andre Scedrov. But it looks like they're not going to be in Vancouver, or at least neither has registered. From: To: Time: Mon Nov 26 18:37:02 2007 the board meeting runthrough is in a weird state in techtime From: To: Time: Mon Nov 26 20:21:15 2007 Yes, I definitely think we want to have minutes for the first part. No, no ssl for the wiki. I'd rather integrate it with some openid thing or something like that and there's not yet any content on the wiki for which security matters much From: To: Time: Mon Nov 26 20:22:10 2007 What, not Kerberos authentication? From: To: Time: Mon Nov 26 20:23:29 2007 We could do that too if we could get enough HTTP keytabs. I don't know if mark would give us those or not. From: To: Time: Mon Nov 26 20:23:43 2007 We'd also need a shared key. More than I want to deal with right now. From: To: Time: Wed Nov 28 13:28:55 2007 The trunk doesn't build on VS2005. From: To: Time: Thu Nov 29 09:09:18 2007 Here is what doesn't build on VS2005: C:\KfW\pismere\athena\util\guiwrap\src\exe>cl -c ... wrap.cxx wrap.cxx wrap.cxx(16) : error C3861: 'strdup': identifier not found C:\KfW\pismere\athena\util\guiwrap\src\exe>diff wrap.cxx wrap.new.cxx 16c16 < CFindItem(char* t, char* w):title(strdup(t)),wclass(strdup(w)) {} --- > CFindItem(char* t, char* w):title(_strdup(t)),wclass(_strdup(w)) {} C:\KfW\pismere\athena\util\guiwrap\src\exe>cl ... -c wrap.new.cxx wrap.new.cxx wrap.new.cxx(16) : warning C4996: '_strdup': The POSIX name for this item is deprecated. Instead, use the ISO C++ conformant name: _strdup. See online help for details. C:\Program Files\Microsoft Visual Studio 8\VC\INCLUDE\string.h(104) : see declaration of '_strdup' C:\KfW\pismere\athena\util\guiwrap\src\exe> From: To: Time: Thu Nov 29 09:11:35 2007 Sounds like your problem to fix. Our source tree requires posix to build. From: To: Time: Thu Nov 29 10:43:58 2007 Prepending c:\Program Files\Platform SDK Server 2003 R2\Include\crt to the INCLUDE path solved it. From: To: Time: Thu Nov 29 10:44:59 2007 Is that really a reasonable solution? From: To: Time: Thu Nov 29 10:46:04 2007 I.E. if what you are saying is that you need to use a sufficiently new SDK, that's fine. If you are saying that you need to use a sufficiently old sdk, that's probably not OK. If you do want to propose moving to a newer required sdk you should discuss on kfwdev From: To: Time: Thu Nov 29 10:47:19 2007 The build environment instructions already say to put the platform sdk path before the VC paths. This just adds one more SDK path. From: To: Time: Thu Nov 29 10:48:47 2007 Right. But we should only depend on one SDK From: To: Time: Thu Nov 29 10:49:19 2007 This is another path in the same platform sdk. From: To: Time: Thu Nov 29 10:50:40 2007 Ah. I understand now. And am completely unqualified to have an opinion on whether that is a good idea From: To: Time: Thu Nov 29 11:29:05 2007 Well, the stdio.h in that directory doesn't define fopen_s, so other things stop building! Back to the drawing board. From: To: Time: Thu Nov 29 16:46:01 2007 Wait, do I understand right that when you use _strdup, it complains that you should be using _strdup instead? From: To: Time: Thu Nov 29 16:46:39 2007 When did it start breaking? We've been using strdup for a while. From: To: Time: Thu Nov 29 17:38:30 2007 It broke when I started trying to build on VS2005. From: To: Time: Thu Nov 29 18:14:57 2007 Oh, was this not tried before? (I don't recall offhand which versions we're using now.) From: To: Time: Thu Nov 29 18:19:05 2007 I'm starting to wonder if client referrals can be done safely at all, without requiring some public key support or something. From: To: Time: Thu Nov 29 18:19:19 2007 And now Paul's got me wondering if there might be some poor interactions with anonymous tickets. From: To: Time: Thu Nov 29 18:54:43 2007 Jeff has been building our code on vs2005 for a while now From: To: Time: Fri Nov 30 11:34:45 2007 I wonder how. For example, in auth/krbcc/src/marshal.hxx/cxx Marshall::Exception::CcError doesn't declare a return type andVS2005 C++ treats that as an error. The leash help files require hcw.exe which was part of VS2003 but does not appear to be in VS2005. Both of these examples come from code that should be going away. Is it time to prune krbcc and leash from the makefiles? From: To: Time: Fri Nov 30 12:20:10 2007 Is the leash dll going away? I think you could make a proposal to do so, yes. From: To: Time: Fri Nov 30 14:34:34 2007 hm, Daptiv shows KIM-based apps starting on 11/24/2008. is this some weird dependency thing? From: To: Time: Fri Nov 30 14:35:47 2007 oh crud did it do that again? From: To: Time: Fri Nov 30 14:35:59 2007 I keep fixing that and it reverts From: To: Time: Fri Nov 30 14:36:12 2007 weird. is it supposed to have any dependencies? From: To: Time: Fri Nov 30 14:36:27 2007 yeah it depends on other projects. lemme look at it From: To: Time: Fri Nov 30 14:37:45 2007 okay that's bizarre it depends on a project that ends 5/9/2008 From: To: Time: Fri Nov 30 14:38:36 2007 okay I fixed it again, we'll see if it sticks From: To: Time: Fri Nov 30 14:38:58 2007 the history log doesn't show you setting the start date to anything like 11/24/2008 either. weird. From: To: Time: Fri Nov 30 14:40:15 2007 I'd swear I tried to fix that one several times too From: To: Time: Fri Nov 30 14:40:28 2007 maybe I was tricked by the Next button again From: To: Time: Fri Nov 30 14:40:55 2007 Is this bad enough that we need to re-evaluate choice of tools? From: To: Time: Fri Nov 30 14:42:07 2007 has anyone else besides me and lxs actually heavily edited stuff in this tool? From: To: Time: Fri Nov 30 14:44:56 2007 I doubt it. From: To: Time: Fri Nov 30 14:45:12 2007 I played with it a bit in firefox but have not made any edits. From: To: Time: Fri Nov 30 15:34:28 2007 I get a 404. From: To: Time: Fri Nov 30 15:34:59 2007 404 to what? From: To: Time: Fri Nov 30 15:35:59 2007 To the most recent context that makes any sense: 'has anyone ... heavily edited stuff ...' From: To: Time: Fri Nov 30 15:36:39 2007 https://login.daptiv.com/ From: To: Time: Fri Nov 30 15:36:49 2007 or what were url were you using? From: To: Time: Fri Nov 30 15:37:21 2007 I had been using theURL in the email from enterprisesupport@eproject.com. From: To: Time: Fri Nov 30 15:37:39 2007 i don't know what that URL is From: To: Time: Fri Nov 30 15:38:08 2007 na04.daptiv.com? From: To: Time: Fri Nov 30 15:38:25 2007 Yes. From: To: Time: Fri Nov 30 15:39:32 2007 for some reason IE gets angry if you try logging in with the SSL enable checkbox selected now. i haven't tracked down what's going on yet. IE gives you a server not found or DNS error page. From: To: Time: Fri Nov 30 15:40:14 2007 Where are we meeting at 4? From: To: Time: Fri Nov 30 15:40:21 2007 199 From: To: Time: Sun Dec 2 02:02:40 2007 This room is not anonymous. From: To: Time: Mon Dec 3 15:37:20 2007 Anyone here who is supposed to be on the conference call? From: To: Time: Mon Dec 3 15:42:14 2007 hm, are people at the ietf supposed to call in? i didn't think we were... From: To: Time: Mon Dec 3 15:42:42 2007 no we're all vvery confused. I just talked to sam From: To: Time: Mon Dec 3 15:42:58 2007 oh. From: To: Time: Mon Dec 3 15:43:07 2007 he thought our slide meeting was next week and so when he told me it conflicted with the call I got confused From: To: Time: Tue Dec 4 15:52:25 2007 How do I change my utilization factor in Daptiv? From: To: Time: Tue Dec 4 16:04:41 2007 you can only do it through the interactive Gantt chart, i think. maybe you can do it by assigning non-project time in your timesheets but you'd have to do that for every week. From: To: Time: Tue Dec 4 16:12:41 2007 In the gantt view of the tasks, I don't see any way to modify resource properties. From: To: Time: Tue Dec 4 16:13:20 2007 do a schedule checkout; double-click on the resource name to change utilization. don't forget to check back in. From: To: Time: Tue Dec 4 16:16:35 2007 Ah, double click the resource name in the chart, not in the resource panel. From: To: Time: Tue Dec 4 16:24:38 2007 What do you do when Daptiv hangs in 'updating resource assignments' ;-) From: To: Time: Tue Dec 4 16:25:31 2007 hm. it's full of javascript tasty goodness so who knows what it's doing From: To: Time: Thu Dec 6 13:26:29 2007 I still have the cold thing. working from home today From: To: Time: Thu Dec 6 16:21:02 2007 Is CALL_INIT_FUNCTION supposed to actually call the function? On Windows, MAKE_INIT_FUNCTION expanded to static k5_init_t cci_thread_init__ran = { 0, 2 }; static int cci_thread_init(void); void cci_thread_init__auxinit() { cci_thread_init__ran.error = cci_thread_init(); cci_thread_init__ran.did_run = 3; } static int cci_thread_init(void); and CALL_INIT_FUNCTION expanded to err = (cci_thread_init__ran.did_run == 3 ? cci_thread_init__ran.error : (abort(),0)); did_run was never set to 3 and CALL_INIT aborts. Manually inserting a call to cci_thread_init__auxinit seems to be necessary. What am I missing? From: To: Time: Thu Dec 6 16:22:18 2007 looks like some platform-specific stuff may be missing but Ken would know for certain From: To: Time: Thu Dec 6 16:23:18 2007 those same macros are used by the krb5 libraries. Look and see what they expand to in your krb5 library builds. Clearly we would have noticed if our krb5 libraries called abort on windows From: To: Time: Thu Dec 6 16:23:29 2007 oh right From: To: Time: Thu Dec 6 16:24:32 2007 for example krb5int_initialize_library() calls it From: To: Time: Thu Dec 6 20:58:57 2007 On Windows, the library init function dllmain should call the init functions, and CALL_INIT_FUNCTION lets you check that the call actually happened. On UNIX, CALL_INIT_FUNCTION does the call the first time only, via pthread_once. From: To: Time: Thu Dec 6 20:59:17 2007 The dllmain stuff is maintained separately, by hand. From: To: Time: Thu Dec 6 21:57:40 2007 Thanks for that explanation. From: To: Time: Thu Dec 6 21:59:55 2007 If it's not written up in doc/implement*, it should be... actually, I thought I described it in comments in k5-platform, but maybe not well enough, and probably not the dllmain parts. From: To: Time: Thu Dec 6 22:00:39 2007 I printed k5-platform out, but it is at work and I'm at home. Tomorrow, I will see the light. From: To: Time: Thu Dec 6 22:01:16 2007 Currently init functions get listed in three places -- the *_INIT_FUNCTION macro uses, the makefile that builds the UNIX library that contains them, and the DllMain support for Windows. It would be nice to reduce that... but the fact that we build libraries in different directories and with different subsets of our code makes that kind of hard. From: To: Time: Sun Dec 9 02:02:27 2007 This room is not anonymous. From: To: Time: Mon Dec 10 12:05:43 2007 I am still sick. :-( From: To: Time: Mon Dec 10 13:35:52 2007 Is there any overview or other documentation for kfwlogon? From: To: Time: Mon Dec 10 15:00:38 2007 I am home sick and need to call into the release meeting. Is the call-in number the same? From: To: Time: Mon Dec 10 15:01:03 2007 ah oops I didn't inc my mail... nevermind From: To: Time: Mon Dec 10 15:38:57 2007 anyone on jabber? I just blew up my Leopard install and can't get at the mail that contains the call in number From: To: Time: Mon Dec 10 15:47:08 2007 gah and then I get the number and the conference system boots me 3 times before it lets me in From: To: Time: Mon Dec 10 15:47:56 2007 (thank goodness Mail.app uses individual files for mail messages) From: To: Time: Mon Dec 10 17:25:58 2007 hmm, meeroh.org nameservers aren't responding; ben fell off the cvs-krb5 list a few days ago. From: To: Time: Tue Dec 11 14:33:06 2007 presentations are all over, you can get healthy now lxs :-) From: To: Time: Tue Dec 11 14:34:35 2007 ugh my cold got worse again :-( From: To: Time: Tue Dec 11 14:34:47 2007 I woke up coughing From: To: Time: Tue Dec 11 14:35:02 2007 Ick. Sorry to hear it. From: To: Time: Tue Dec 11 14:35:25 2007 I'm sorry I missed the presentations. From: To: Time: Tue Dec 11 14:35:27 2007 chicken soup and lying down From: To: Time: Tue Dec 11 14:35:42 2007 Already tried the chicken soup... well chicken ramen From: To: Time: Tue Dec 11 14:35:51 2007 not quite the same curative effect From: To: Time: Tue Dec 11 14:35:57 2007 It's pretty good From: To: Time: Wed Dec 12 12:47:16 2007 Okay, I must be getting cosmic payback for something. This cold has reached new heights of awful From: To: Time: Wed Dec 12 12:47:52 2007 I assume you made it to medical? I'm sorry to hear you are still sick From: To: Time: Wed Dec 12 12:48:18 2007 I haven't gone to medical yet. I felt so bad yesterday I didn't leave the house From: To: Time: Wed Dec 12 12:49:29 2007 Given that my symptoms completely changed on Monday evening I'm guessing that I got what my husband has rather than the sinus thing I had before From: To: Time: Wed Dec 12 13:01:26 2007 WRT loading a DLL and doing a bunch of GetProcPaddress calls at init time -- is there any reason to do this other than to fail early? From: To: Time: Wed Dec 12 13:32:51 2007 Conte xt? From: To: Time: Wed Dec 12 13:33:36 2007 Rather context? From: To: Time: Wed Dec 12 13:37:14 2007 The current Windows CCAPI client. From: To: Time: Wed Dec 12 13:40:15 2007 Aren't windows dll bindings by procedure number not by name? If I'm correct then it seems likely that whoever designed the ccapi interface did not specify procedure numbers and thus there's an issue plugging in dlls from other vendors. From: To: Time: Wed Dec 12 13:41:54 2007 i recall comments (from jaltman?) to the effect that binding by procedure number is one way, but binding by name can also occur. From: To: Time: Wed Dec 12 13:44:23 2007 How was the daptive training? From: To: Time: Wed Dec 12 13:47:58 2007 it was ok; nothing terribly new to me but i think i did get a few questions answered kind of. From: To: Time: Wed Dec 12 13:48:44 2007 apparently custom reports can be made but we don't have access to the report builder tool because it's $$$$ to license. Darlene can supposedly access it to make custom reports for us if we need. From: To: Time: Wed Dec 12 13:49:56 2007 Oh. That's incredibly misleading based on their previous presentations. From: To: Time: Wed Dec 12 13:50:06 2007 how so From: To: Time: Wed Dec 12 13:50:23 2007 They talked about custom reports as if it was easy From: To: Time: Wed Dec 12 13:51:47 2007 easy for those who have permissions to run them, possibly. From: To: Time: Wed Dec 12 13:59:39 2007 oh no. Jeff Blaine's problem isn't as easy as i thought. you are in a maze of twisty preauth workarounds, all different. From: To: Time: Wed Dec 12 14:57:33 2007 I just got this message from Steve claiming w92-wide phone system outages. What happened? From: To: Time: Wed Dec 12 14:58:31 2007 My phone is dead, now that you mention it. It wortked earlier when I was talking to a woman from Coverity. From: To: Time: Wed Dec 12 14:59:04 2007 Define dead? From: To: Time: Wed Dec 12 14:59:20 2007 Is building wide wired network dead? From: To: Time: Wed Dec 12 14:59:31 2007 Hmm, guess not From: To: Time: Wed Dec 12 14:59:50 2007 If justin wants to he should feel free to check my ISDN phone for dial tone/lights From: To: Time: Wed Dec 12 14:59:51 2007 i am getting wired network. haven't checked wireless though. From: To: Time: Wed Dec 12 15:00:08 2007 Dead = no sidetone. From: To: Time: Wed Dec 12 15:00:18 2007 And no dialtone. From: To: Time: Wed Dec 12 15:00:29 2007 and if you need to use a phone and my ISDN phone is working, feel free to use it From: To: Time: Wed Dec 12 15:01:25 2007 3down says: Some VoIP phones on campus are experiencing outages. From: To: Time: Wed Dec 12 15:10:42 2007 Steve said that the phones rebooted and stopped working at 2. I wonder if they did something bad with a firmware image or config change. In particular my phone seems to be working fine From: To: Time: Wed Dec 12 15:13:43 2007 aren't there 2 different voip phone systems deployed in w92? or is that just the management software? From: To: Time: Wed Dec 12 15:14:36 2007 There are. I suspect only the newer one failed From: To: Time: Thu Dec 13 08:29:15 2007 Still no dial tone. From: To: Time: Thu Dec 13 08:29:36 2007 reboot the phone, says the email From: To: Time: Thu Dec 13 08:37:20 2007 I guess I should read all my email first. From: To: Time: Thu Dec 13 08:39:40 2007 never know how people have their email filtered From: To: Time: Thu Dec 13 08:39:51 2007 so i always assume they missed it From: To: Time: Thu Dec 13 12:05:51 2007 I'm working from home, btw. From: To: Time: Thu Dec 13 12:06:05 2007 (for obvious, snow and illness related reasons) From: To: Time: Thu Dec 13 12:58:59 2007 Now I'm glad I didn't come in. They're sending everyone home at 2pm! From: To: Time: Thu Dec 13 12:59:27 2007 :) From: To: Time: Thu Dec 13 13:15:36 2007 well given when I got up I would have arrived and turned around immediately From: To: Time: Thu Dec 13 13:15:53 2007 stupid 45 minute commute From: To: Time: Thu Dec 13 14:18:20 2007 They can't reboot the phones remotely, huh? From: To: Time: Thu Dec 13 14:22:00 2007 Hm, new patch from Novell for the multithreaded KDC. From: To: Time: Fri Dec 14 18:13:19 2007 I think I'm going to need to revise the Windows mutex abstraction, to play nice with condition variables. Probably not a *big* change though... From: To: Time: Sat Dec 15 05:42:55 2007 If Jyotishmaan doesn't stop, we may need to start moderating his messages. From: To: Time: Sun Dec 16 02:02:49 2007 This room is not anonymous. From: To: Time: Sun Dec 16 14:22:55 2007 added "mi5-victim" to kerberos@mit auto-discard list From: To: Time: Sun Dec 16 14:27:00 2007 Not sure how those two messages got through the mailman server. Another one from mi5-victim did get stuck in the queue. I think maybe the "moderate messages from non-members" flag doesn't work on newsgroup submissions? From: To: Time: Sun Dec 16 14:37:26 2007 Added "newsgroups" to suspicious headers for now, we can refine it later. From: To: Time: Mon Dec 17 15:33:00 2007 I assume people will be calling in shortly? From: To: Time: Mon Dec 17 17:38:30 2007 I set the moderate flag for jyotishmaan on the kerberos list. Doug replied to me saying that he'd also sent the guy some info (more useful than mine) on getting help with his problem, so he *really* shouldn't be sending anything more on LDAP to the Kerberos list unless he's really dense. From: To: Time: Tue Dec 18 11:43:35 2007 http://meta.wikimedia.org/wiki/ParserFunctions From: To: Time: Sun Dec 23 02:02:46 2007 This room is not anonymous. From: To: Time: Wed Dec 26 12:52:44 2007 Does anybody want a hot laptop? From: To: Time: Wed Dec 26 12:54:15 2007 IBM replaced the buzzing fan in my thinkpad this morning and I was amazed at how much dust was inside the case. Now it is not only quieter but running 10 degrees C cooler than before. From: To: Time: Thu Dec 27 15:41:05 2007 Adium 1.2b4 boasts "fixed connectivity to (Jabber) servers which require GSSAPI/Kerberos 5" among its improvements, but I don't see how to enable it. From: To: Time: Thu Dec 27 15:42:00 2007 it also boasts bookmarked group chats with no way to enable that From: To: Time: Thu Dec 27 15:43:04 2007 And so far it seems unable to connect to the jis.mit.edu jabber server. From: To: Time: Thu Dec 27 16:05:41 2007 Oh, apparently I can't log in to the mit.edu jabber server either. (I had refused to enter my password before, trying to get it to do GSSAPI.) The bug database indicates they've switched to cyrus-sasl for some authentication support, and it's DIGEST-MD5 is incompatible with the one Java supplies. From: To: Time: Thu Dec 27 16:06:36 2007 adium 1.2b5 says it fixes that From: To: Time: Thu Dec 27 16:08:31 2007 Ah, time to update again. :) From: To: Time: Thu Dec 27 16:09:16 2007 Funny how Adium's update frequency rises with the holidays From: To: Time: Thu Dec 27 16:11:37 2007 Oh, apparently not. The alert I got was about 1.2b4, but the one I downloaded I guess was 1.2b5. ANd it's not working. From: To: Time: Thu Dec 27 16:12:04 2007 ah From: To: Time: Thu Dec 27 16:12:21 2007 (Or rss feed data, or something. I know *something* said 1.2b4...) From: To: Time: Thu Dec 27 16:12:33 2007 they're a little stricter with certificate checking in the newer betas From: To: Time: Thu Dec 27 16:13:10 2007 our openfire server still uses a self-signed cert, and adium hangs at 75% through checking the cert From: To: Time: Thu Dec 27 16:13:48 2007 if it's sitting there trying to connect but not timing out, that's probably what it is From: To: Time: Thu Dec 27 16:21:10 2007 Ah, strict checking is an option you can turn off. I can log in to mit.edu after turning it off. From: To: Time: Thu Dec 27 16:22:21 2007 (with my password, not a desirable combination) From: To: Time: Thu Dec 27 17:34:46 2007 just to confirm... we don't have anything to do with leopard rpcclient do we? From: To: Time: Thu Dec 27 17:41:51 2007 Not that I know of. From: To: Time: Thu Dec 27 17:42:11 2007 sent mail anyway because relevant people aren't logged in at the moment From: To: Time: Fri Dec 28 16:40:29 2007 AFAICT we have nothing to do with leopard's rpcclient From: To: Time: Sun Dec 30 02:02:29 2007 This room is not anonymous. From: To: Time: Mon Dec 31 04:30:54 2007 Hm, Adium 1.2b7 supposedly has fixes to do gssapi in tiger. However, it's trying to get credentials for xmpp/web.mit.edu, which doesn't exist. Not clear to me if that's our fault or not. And if GSSAPI fails, Adium waits and retries, it doesn't fall back to a password prompt. From: To: Time: Mon Dec 31 04:32:36 2007 I assume the issue is mit.edu -> 18.7.22.69 -> web.mit.edu... From: To: Time: Mon Dec 31 04:34:29 2007 And I note that both xmpp/mit.edu and xmpp/jabber.mit.edu exist; I don't know which of those is supposed to be used. From: To: Time: Mon Dec 31 04:53:04 2007 Well, Athena's gaim client uses xmpp/jabber.mit.edu. If that's what the spec requires, then Adium or its libpurple is providing the wrong name somewhere, and fixing that should get things working without having to futz around with the name mapping lossage. From: To: Time: Wed Jan 2 01:16:58 2008 they're probably just parsing out the mit.edu from raeburn@mit.edu instead of using the server's address From: To: Time: Wed Jan 2 15:45:04 2008 An update on the Adium situation: The current code (1.2b7) seems to work *if* you don't list a "contact server" address, letting it look up the SRV RR instead, and if you don't have the Openfire bug present in the old server code we're running on jabber.mit.edu (but not on the more up-to-date wocky.mit.edu). From: To: Time: Wed Jan 2 15:50:06 2008 "Openfire"? sounds like an order to shoot someone... From: To: Time: Wed Jan 2 15:50:12 2008 :) From: To: Time: Wed Jan 2 17:54:58 2008 Steve hasn't sent email yet, but it looks like he's picking up the ball on hiring a doc person ASAP. So if you know of someone, drop him a note. I've mentioned four possibilities to him... From: To: Time: Thu Jan 3 14:06:10 2008 Can I get people to try going to https://wikis.mit.edu/confluence/display/isdasec/lxs I expect lxs to succeed and others to fail From: To: Time: Thu Jan 3 14:07:03 2008 fail From: To: Time: Thu Jan 3 14:07:14 2008 No permission. You cannot view this page. From: To: Time: Thu Jan 3 14:07:32 2008 I get Page Not Found From: To: Time: Thu Jan 3 14:07:33 2008 That was after asking me for my certificate. From: To: Time: Thu Jan 3 14:08:03 2008 i fail From: To: Time: Thu Jan 3 14:08:11 2008 "no permission" From: To: Time: Thu Jan 3 14:08:23 2008 "Page level restrictions have been applied that limits access to this page. " 'Restrictions limits' needs some wordsmithing. From: To: Time: Thu Jan 3 14:11:49 2008 I can go to that page From: To: Time: Thu Jan 3 14:12:37 2008 OK, good From: To: Time: Thu Jan 3 14:24:40 2008 People who do not want to be scheduled for early morning goals review meetings and who have not already done so should have a goals review meeting on my calendar by the time I return this evening. From: To: Time: Thu Jan 3 14:32:42 2008 hehe now that's an incentive ;-) From: To: Time: Thu Jan 3 15:24:47 2008 Um, are we using confluence 2.0? because I found in their docs: "Currently, templates can only be used to create a page. Once a page is created, the template is gone and all further editing is performed as if the template was never used. In the future, templates will be expanded to do more interesting things such as remaining part of the page, having more complex (and even dynamic) fields, being able to search Confluence based on the value of particular fields, and so on." Please tell me that is out of date. :-( From: To: Time: Thu Jan 3 15:25:52 2008 (from http://confluence.atlassian.com/display/CONF20/Working+with+Templates+Overview) From: To: Time: Thu Jan 3 15:36:15 2008 Oh hm I see there is a Scaffolding plugin thing From: To: Time: Thu Jan 3 15:55:48 2008 There are also macros which can be left in the markup. The implementation of the macros can change to add features or whatever. From: To: Time: Thu Jan 3 15:56:10 2008 Is Scaffolding actually installed on the MIT wiki? From: To: Time: Thu Jan 3 17:17:48 2008 We're not using the built in templates thing but instead are using zone-template The problem with macros is that 1) they are written in another language and 2) can only be written by site admins From: To: Time: Thu Jan 3 17:23:07 2008 ah that's not Scaffolding. the Scaffolding plugin creates live-template which is similar to a mediawiki template at least from the demos From: To: Time: Thu Jan 3 17:24:11 2008 Yes, but live-template doesn't seem to be able to take parameters at least as far as we've been able to find From: To: Time: Thu Jan 3 17:24:26 2008 So ask the site admins to do that part of the work. From: To: Time: Thu Jan 3 17:25:45 2008 I think that anyone on the core team needs to be able to create templates. At a minimum. I'd prefer anyone in the community. Ironically making all the core team members site admins defeats some of Steve's access control requirements giving us a better access control solution with mediawiki than Confluence From: To: Time: Thu Jan 3 17:27:34 2008 what do you mean by take parameters? From the demos it looks like you reference the template and then "save layout" and then you get a form entry to fill out. When you fill that out and save it creates the page based on what you entered From: To: Time: Thu Jan 3 17:28:41 2008 Although that assumes you have the Scaffolding plugin installed From: To: Time: Thu Jan 3 17:29:29 2008 The scaffolding plugin looks really cool, although the fact that entering template params is a 2-step process that involves UI will probably drive Sam crazy ;-) From: To: Time: Thu Jan 3 17:30:26 2008 Raise creating macros as an issue and get the way it is implemented or supported by MIT to be changed. From: To: Time: Thu Jan 3 17:30:42 2008 That's not how it works with the live-template macro. From: To: Time: Thu Jan 3 17:31:04 2008 If they say no, then maybe you have enough of a justification that the common tool can't do what a reasonable user wants. From: To: Time: Thu Jan 3 17:34:10 2008 The mode wher you choose one template per page doesn't seem useful to us. From: To: Time: Thu Jan 3 17:34:19 2008 Or rather doesn't seem to meet all of our needs From: To: Time: Thu Jan 3 17:36:49 2008 So with Scaffolding installed you create a template with Scaffolding markup (which is parameterized). Then you put Edit Layout and put {live-template:MyTemplate}, save and then the edit wiki page will have a Scaffolding form where the template was specified. When you fill out the form created by Scaffolding and save the page then you get whatever you specified by the Scaffolding template. From: To: Time: Thu Jan 3 17:37:06 2008 I haven't looked at what zone-template does From: To: Time: Thu Jan 3 17:38:33 2008 Ah. You can just create the page with teh live template directly apparently although I don't understand how it deals with the parameterization From: To: Time: Thu Jan 3 17:40:01 2008 well I assume the plugin expands the template From: To: Time: Thu Jan 3 17:40:38 2008 however I don't know if that plugin is installed From: To: Time: Thu Jan 3 17:40:51 2008 Well you need to expand a template in a manner where if the template changes the expansion changes From: To: Time: Thu Jan 3 17:41:06 2008 I think it is on confab-two From: To: Time: Thu Jan 3 17:41:18 2008 yeah but live-template does that. it's in the scaffolding demos From: To: Time: Thu Jan 3 17:41:29 2008 Which are unfortunately Quicktime movies From: To: Time: Thu Jan 3 17:42:00 2008 Right. What I don't remember is the format of the resulting page after the parameters are filled in with live-template. I do know what the results for zone-template look like From: To: Time: Thu Jan 3 17:43:18 2008 anyway live-template + Scaffolding looks like something that produces nice output for anyone using a GUI From: To: Time: Thu Jan 3 17:44:48 2008 Oh here we go: "Zone templates differ from scaffolds in a few ways: • Template and instance data are stored in the content of a page. So you can use Confluence to manage the data versioning. • Zones only provide a very simple mechanism for managing a dynamic template, scaffolds provide a much richer set of tags to support more dynamic data sets." From: To: Time: Thu Jan 3 17:46:10 2008 yeah zones sounds like it would be easier to use if it does what we want From: To: Time: Thu Jan 3 17:51:45 2008 Where is the instance data stored for scaffolds? From: To: Time: Thu Jan 3 17:59:47 2008 no idea From: To: Time: Fri Jan 4 17:07:22 2008 oddly enough i started searching through RT and found John Hascall's name on a bug on almost exactly the same subject, fixed in 1.4. From: To: Time: Fri Jan 4 17:10:32 2008 back in 2004, even. From: To: Time: Fri Jan 4 17:31:45 2008 Christine Fitzgerald is going to be presenting a slide show at the A-H meeting, and mentioning the launch of the Consortium, with our pictures on a slide. And we're all going to be absent? Hm. From: To: Time: Fri Jan 4 17:33:22 2008 where did you hear this? From: To: Time: Fri Jan 4 17:34:23 2008 Steve included her email to him, in email to me reminding me that I haven't sent him a recent enough photo. From: To: Time: Fri Jan 4 17:35:23 2008 Sounds like among the stuff she's presenting is names & photos of new staff in 2007, and one slide on the consortium launch. From: To: Time: Fri Jan 4 18:14:10 2008 hm, i'm not sure that John's claim of running 1.6.3 is consistent with what i see by code inspection. From: To: Time: Sun Jan 6 02:02:45 2008 This room is not anonymous. From: To: Time: Sun Jan 6 05:49:53 2008 Adium 1.2 is released. Doesn't work with jabber.mit.edu currently, or with Zephyr. *sigh* From: To: Time: Mon Jan 14 12:49:47 2008 going to try to head into work (which may involve some shoveling my way there) From: To: Time: Mon Jan 14 12:49:57 2008 will be there by the meeting From: To: Time: Mon Jan 14 12:50:14 2008 The roads weren't bad at 10AM when I drove in. From: To: Time: Mon Jan 14 14:47:39 2008 Any good reason to have the meeting today? From: To: Time: Mon Jan 14 14:54:18 2008 have we told the sun people we aren't having a meeting? they don't have a snowstorm From: To: Time: Mon Jan 14 14:58:40 2008 I just did From: To: Time: Mon Jan 14 14:58:52 2008 (krbdev-release) From: To: Time: Mon Jan 14 14:58:59 2008 oh okay From: To: Time: Mon Jan 14 15:27:04 2008 So is the team meeting off as well as the release meeting? From: To: Time: Mon Jan 14 15:32:19 2008 Yes, unless you have something that we need to discuss From: To: Time: Mon Jan 14 15:33:48 2008 Nope. Working on vulnerability schedule proposal and writeup in template, should be mailing those to you soon. Already told Mark I expect vendors may get notice as soon as the end of this week or start of next week, so we shouldn't need to delay for him. From: To: Time: Mon Jan 14 15:34:44 2008 I'm not sure you wanted to say that here. From: To: Time: Mon Jan 14 15:35:39 2008 No details, I don't think the fact that we know of a vulnerability is a big deal, is it? If so, I'll remember not to mention the [redacted] here, or the fairly well known [redacted] either. From: To: Time: Wed Jan 16 12:49:36 2008 no details on today's call yet? From: To: Time: Wed Jan 16 13:30:42 2008 ahh no call From: To: Time: Sun Jan 20 02:02:32 2008 This room is not anonymous. From: To: Time: Sun Jan 27 02:02:30 2008 This room is not anonymous. From: To: Time: Mon Feb 4 12:42:28 2008 Where do meeting notes go on the wiki? From: To: Time: Mon Feb 4 12:42:36 2008 Oh, never mind, found tem. From: To: Time: Mon Feb 4 12:42:37 2008 them. From: To: Time: Mon Feb 4 12:43:04 2008 Not by following links, because I couldn't figure out what link would get me there. But "random page" got me there eventually. From: To: Time: Mon Feb 4 12:43:35 2008 search didn't work? From: To: Time: Mon Feb 4 12:44:07 2008 ah, meeting notes doesn't find it, but meeting minutes does From: To: Time: Mon Feb 4 12:44:13 2008 Probably would've. Silly me, though, I assumed there'd be somewhat obvious links visible from the front page. From: To: Time: Mon Feb 4 12:44:46 2008 But, in fact, there are no links to the minutes pages, near as I can tell. From: To: Time: Mon Feb 4 12:49:57 2008 Grr, hatehatehate. From: To: Time: Mon Feb 4 12:51:03 2008 that lack of links is my fault From: To: Time: Mon Feb 4 12:51:26 2008 where should it go, do you think? From: To: Time: Mon Feb 4 12:55:53 2008 Dunno. Main page? From: To: Time: Mon Feb 4 14:05:28 2008 there's an "all pages" special page From: To: Time: Mon Feb 4 14:05:36 2008 yes, they should be linked somewhere more ovious From: To: Time: Mon Feb 4 14:27:17 2008 it's looking like i'll have to call into today's meeting From: To: Time: Mon Feb 4 17:17:21 2008 oh, we should sort out food for tomorrow. From: To: Time: Mon Feb 4 17:19:23 2008 Back to the sandwich place? Or do Bertucci's again? I'd be happy with either. From: To: Time: Mon Feb 4 17:19:39 2008 i'm getting a little tired of pizza myself From: To: Time: Mon Feb 4 17:20:07 2008 I think I'd prefer the sandwich place a bit more, too. From: To: Time: Mon Feb 4 17:20:20 2008 I'm ready for the sandwich place, for at least one time. From: To: Time: Mon Feb 4 17:20:46 2008 I'd do my club sandwich again From: To: Time: Mon Feb 4 17:25:18 2008 I wonder if Bryan still has our orders from N weeks ago. From: To: Time: Mon Feb 4 17:25:19 2008 so that place was Kiraz? people should send their orders to Bryan, i guess. From: To: Time: Mon Feb 4 17:28:28 2008 Okay. From: To: Time: Mon Feb 4 17:43:37 2008 meeting notes are up. If you want to read over them and edit them if I mischaracterized what you said, feel free. I got kindof behind at points and am not so hot at copying what people say verbatim From: To: Time: Tue Feb 5 16:53:19 2008 Ick. sqlite3 is thread-safe only if compiled with the right options. From: To: Time: Tue Feb 5 16:54:08 2008 At least there's a runtime test to find out if it was compiled that way. From: To: Time: Tue Feb 5 16:55:14 2008 Their FAQ says "threads are evil." From: To: Time: Tue Feb 5 17:04:58 2008 not like Berkeley DB is very thread-safe From: To: Time: Tue Feb 5 17:07:25 2008 True. And I'd be skeptical of the thread safety anyways, without reading through some of the code first. If they're mucking about with locks on multiple file descriptors referencing the same file, it could be bad. From: To: Time: Tue Feb 5 18:09:16 2008 Looks like sqlite actually does all the ugly work necessary for dealing with posix locks. Tracking multiple open file descriptors on the same inode, combining locking info, delaying closes until all locks are cleared, etc. From: To: Time: Tue Feb 5 18:26:44 2008 ok, wtf happened to ticket #5800? From: To: Time: Tue Feb 5 18:29:25 2008 The new attachments at the end today? Spam, I'd guess, based on the footers. From: To: Time: Tue Feb 5 18:30:57 2008 looks like krb5.h with 3 lines of spam appended. From: To: Time: Tue Feb 5 18:31:59 2008 Yup. From: To: Time: Tue Feb 5 18:32:45 2008 webform spammer finally found us. From: To: Time: Tue Feb 5 18:32:51 2008 I've seen an approach like that before -- find something that looks like legitimate email, and resend it to random addresses, but with a virus attached. From: To: Time: Tue Feb 5 18:33:10 2008 We've gotten a few before, I think, though not quite this form. From: To: Time: Tue Feb 5 18:42:54 2008 looking through various incarnations of Berkeley DB. much archaeology. From: To: Time: Wed Feb 6 15:18:24 2008 i wonder how much effort we should spend dealing with thwarting defacing of our RT database From: To: Time: Wed Feb 6 15:40:48 2008 spammy comments have experienced a sledgehammer. From: To: Time: Thu Feb 7 17:36:08 2008 tom, thanks for playing Thor with the web form spam From: To: Time: Thu Feb 7 17:37:01 2008 no problem. if it keeps up we may need to block web comments or similar. From: To: Time: Thu Feb 7 17:45:08 2008 I've been running into all sorts of usability issues regarding the behaviors when renewable tickets are either not permitted or when the max renewable lifetime is shorter than the ticket lifetime. From: To: Time: Thu Feb 7 17:46:53 2008 for example, if a client requests a service ticket with the renewable flag set and the service principal is marked to refuse to issue renewable tickets, the KDC issues a policy error. The client then fails hard. A more usable response would be to return a non-renewable ticket. From: To: Time: Thu Feb 7 17:47:58 2008 what does rfc4120 say should happen? From: To: Time: Thu Feb 7 17:48:38 2008 if a client requests a service ticket with the renewable flag set and the service principal has is configured with the max renew lifetime as 0 but it permits the issuance of renewable tickets, the response to the client is a ticket that contains the renewable flag but has the max renew lifetime set to 0. Attempts to renew the ticket fail. From: To: Time: Thu Feb 7 17:49:42 2008 i think there are related bugs already in RT and they may have been fixed already. From: To: Time: Thu Feb 7 17:49:43 2008 I think the policy should be that we do not permit the max renew lifetime to be less than the ticket lifetime. From: To: Time: Thu Feb 7 17:50:05 2008 policy for what? From: To: Time: Thu Feb 7 17:50:20 2008 The policy for the database. From: To: Time: Thu Feb 7 17:51:43 2008 is there a kdb per-principal flag to disable renewable tickets? From: To: Time: Thu Feb 7 17:57:00 2008 I cannot find a reference in 4120 that indicates what the error behavior should be if a client requests RENEWABLE and the KDC cannot issue a RENEWABLE ticket. From: To: Time: Thu Feb 7 17:59:02 2008 I assume there is a per-principal db flag because kadmin has -+allow_renewable From: To: Time: Thu Feb 7 18:02:29 2008 do you think the client or the kdc behavior should change? or both? From: To: Time: Thu Feb 7 18:02:51 2008 I think the KDC behavior should change. From: To: Time: Thu Feb 7 18:03:57 2008 I think that if -allow_renewable is set on a principal, that tickets for that principal should be issued without the RENEWABLE flag even if the client requests one. From: To: Time: Thu Feb 7 18:04:46 2008 I also think that when a RENEWABLE ticket is issued, the renew_till time should never be permitted to be less than the endtime. From: To: Time: Thu Feb 7 18:04:55 2008 Clients just do not handle that case well From: To: Time: Thu Feb 7 18:16:43 2008 yes, lifetime-handling logic in the kdc needs some improvement. From: To: Time: Thu Feb 7 18:18:12 2008 If there is agreement on the behavior I propose I will send patches From: To: Time: Thu Feb 7 18:19:08 2008 how many clients reject a reply if they request renewable and do not receive renewable? From: To: Time: Thu Feb 7 18:20:31 2008 I have no idea. I have no KDC at the moment that implements that behavior. From: To: Time: Thu Feb 7 18:23:32 2008 code inspection indicates that the client checks the returned renew_till to make sure it doesn't exceed a requested renew_till From: To: Time: Thu Feb 7 18:25:59 2008 if a client requests a renew_till that is less than the lifetime I think it is broken From: To: Time: Thu Feb 7 18:26:27 2008 anyway ticket #2602 covers part of this issue From: To: Time: Thu Feb 7 18:26:53 2008 checking From: To: Time: Thu Feb 7 18:37:52 2008 I see that krb5_get_init_creds enforces renew_till >= lifetime From: To: Time: Fri Feb 8 16:42:51 2008 nstar electric shutdown window tuesday; up to 30min interruptions From: To: Time: Sun Feb 10 02:02:28 2008 This room is not anonymous. From: To: Time: Mon Feb 11 18:01:28 2008 Should we consider switching the krbdev list to allow HTML mail, rather than mangling the QP decoding process? Jeff says the HTML to text conversion is done by running lynx, so getting it fixed any time soon seems unlikely. From: To: Time: Thu Feb 14 10:36:55 2008 please see my email From: To: Time: Thu Feb 14 10:40:05 2008 unfortunately not an easy problem to diagnose From: To: Time: Thu Feb 14 10:40:36 2008 what do you need? From: To: Time: Thu Feb 14 10:41:25 2008 can sun help? From: To: Time: Thu Feb 14 11:32:12 2008 I'm asking wyllys about the arch From: To: Time: Thu Feb 14 12:16:26 2008 hm, some Python programmer on the list seems to have a very poor grasp of C From: To: Time: Thu Feb 14 13:56:30 2008 still at home today From: To: Time: Thu Feb 14 14:05:31 2008 and oops, misread the time on the FSTC call; it was an hour ago. From: To: Time: Fri Feb 15 10:24:50 2008 Tom, come see me when you get in From: To: Time: Sun Feb 17 02:02:27 2008 This room is not anonymous. From: To: Time: Sun Feb 24 02:02:27 2008 This room is not anonymous. From: To: Time: Mon Feb 25 16:44:18 2008 maybe we should consider making an internal API for copying realm names that will append a null From: To: Time: Tue Feb 26 13:33:59 2008 Hello From: To: Time: Tue Feb 26 13:35:02 2008 hello From: To: Time: Tue Feb 26 13:41:17 2008 Oops, I'm missing a conference call From: To: Time: Tue Feb 26 14:09:23 2008 So, would now be a good time for me to call in and discuss what all has gone on while I'm away From: To: Time: Tue Feb 26 14:13:20 2008 Fighting with my phone. From: To: Time: Tue Feb 26 15:05:48 2008 ouch. there are complete copies of copy_principal and free_principal in kadm5/srv/svr_principal.c, which appear differ from the libkrb5 version only by calling db_alloc rather than malloc, etc. From: To: Time: Tue Feb 26 15:05:59 2008 why is this necessary? it seems really bogus. From: To: Time: Tue Feb 26 15:06:54 2008 db_alloc and friends are malloc-like but call into the plugins. the plugin doesn't need to free that memory though, or so it seems. From: To: Time: Tue Feb 26 15:08:59 2008 That's certainly not an acceptable way of accomplishing that goal. From: To: Time: Tue Feb 26 15:09:52 2008 it would be great if we had documentation for why they felt it was necessary to do that. From: To: Time: Tue Feb 26 15:17:44 2008 confirmed that it appeared from the DAL merge From: To: Time: Tue Feb 26 15:48:44 2008 i'll have to check a bit more, but it appears that part of the reason for the brain damage is that kadm5_copy_principal calls into the DAL handle to allocate memory from the plugin so that it can store the copy into a kdb entry, which may end up getting freed by a plugin-specific free function. From: To: Time: Tue Feb 26 15:49:08 2008 so broken i hardly know where to start. From: To: Time: Tue Feb 26 15:56:52 2008 https://wince.mit.edu/changepasswd/index.jsp From: To: Time: Tue Feb 26 18:04:37 2008 oh. it looks like kadm5 has mkvno, but kdb doesn't From: To: Time: Thu Feb 28 13:17:56 2008 hello from cupertino! From: To: Time: Sun Mar 2 02:02:28 2008 This room is not anonymous. From: To: Time: Mon Mar 3 15:30:47 2008 Heading up in a second From: To: Time: Mon Mar 3 16:20:31 2008 Oh, my mistake... I forwarded to krbcore some email that had been exchanged on kerberos@. From: To: Time: Sun Mar 9 03:02:30 2008 This room is not anonymous. From: To: Time: Sun Mar 9 11:48:06 2008 Testing. From: To: Time: Mon Mar 10 19:33:23 2008 were we interested in being a summer of code org? From: To: Time: Mon Mar 10 19:33:53 2008 if so, deadline for application is wednesday at noon From: To: Time: Mon Mar 10 19:39:09 2008 what all does it involve? From: To: Time: Mon Mar 10 20:35:21 2008 http://code.google.com/soc/2008/faqs.html#0.1_org_role From: To: Time: Mon Mar 10 20:35:32 2008 looks like the main points of what's involved From: To: Time: Mon Mar 10 20:36:51 2008 basically: a list of project ideas, a contact for google, a mentor for the students, and a backup in case the mentor disappears From: To: Time: Tue Mar 11 11:13:05 2008 i suspect we're too late to get things together for this year's summer of code. From: To: Time: Tue Mar 11 11:32:11 2008 Yeah, given the level of interest when it came up for discussion, I'm not surprised we're going to miss it. (It was pretty much what I expected, which is why I didn't bring up SoC a little earlier.) From: To: Time: Tue Mar 11 14:50:17 2008 This web spam in RT is getting annoying. From: To: Time: Tue Mar 11 14:51:10 2008 we could kill guest commenting From: To: Time: Tue Mar 11 14:53:42 2008 I think a "yes I'm a human" checkbox would help a bit. Or a simple text challenge ... "please enter the value of 3+4 in this text box". ("You must be at least this smart to comment on our bug reports.") From: To: Time: Tue Mar 11 14:55:26 2008 Random checkboxes could be defeated N% of the time with random numbers. Filling in the right text is harder. A captcha would do, for people who can see, but the "fill in the right text" challenge is probably good enough. It's not like we'd expect spammers to be targeting our database; it's not like we give out email accounts or anything. From: To: Time: Tue Mar 11 14:56:33 2008 restricting comment to e-mail only might be reasonable. we can funnel them through the mod queue. From: To: Time: Tue Mar 11 14:56:36 2008 i doubt they actually check what sites they're spamming From: To: Time: Tue Mar 11 15:04:16 2008 Right. Sites like Google that give out email accounts would be targeted; we just get hit when they're spamming the world at large, indiscriminately. So I don't think we need to worry about making our challenge actually be, uh, challenging. From: To: Time: Tue Mar 11 15:06:05 2008 Restricting to email would work, but seems kind of annoying. However many "real" replies we get via guest web access, that's a measure of the inconvenience level, I guess. From: To: Time: Tue Mar 11 15:07:04 2008 I often reply via the web form. From: To: Time: Tue Mar 11 15:09:19 2008 But presumably not as a guest? It's only the guest access we need to worry about, I think; authenticated users are fine. If they want to spam our db, we've got other issues... From: To: Time: Tue Mar 11 15:17:10 2008 SoC might be a good way to find a Jr programmer. There's considerable overhead in finding the right person, interviewing, etc. If we can use SoC to find someone good who is interested in Kerberos, and who we end up liking, it makes life easier From: To: Time: Tue Mar 11 15:22:31 2008 Yeah, but we have to line up projects (ones interesting enough to attract a student who presumably knows little or nothing of Kerberos) and mentors (and we all have so much free time on our hands) well enough in advance. That's what I didn't expect to happen, based on past experience. I'd be happy to be wrong, but Justin said the deadline's tomorrow, so unless we jump on it right now, with nearly half the team off at IETF, we might as well start thinking about next year's SoC instead. From: To: Time: Tue Mar 11 15:29:12 2008 (Though if we're possibly going to hire students this summer, working up projects now would still be useful.) From: To: Time: Tue Mar 11 15:29:48 2008 and the projects we suggest are just suggestions, students are free to propose anything From: To: Time: Tue Mar 11 15:30:08 2008 Didn't we decide not to do this last Tuesday? From: To: Time: Tue Mar 11 15:32:31 2008 I think we meant to decide From: To: Time: Tue Mar 11 15:32:56 2008 You asked me what I thought, and then we went down a rabbit hole From: To: Time: Tue Mar 11 15:33:42 2008 I asked if there was anyone who would be a mentor. No one said they had time From: To: Time: Tue Mar 11 15:34:24 2008 Ah, was that a decision? I thought the discussion just petered out and we talked about other things. From: To: Time: Tue Mar 11 15:35:00 2008 I wouldn't have expected anyone to *have* time, I assumed the issue would be, if we wanted to do SoC, whose schedule would be adjusted to *make* time. From: To: Time: Tue Mar 11 15:35:13 2008 I thought that was a decision; we confirmed we did not have resources. From: To: Time: Tue Mar 11 15:35:18 2008 Anyway, I'm happy to take up a lot of everyone's time with lots of interviews, I'm just suggesting mentoring might be just as time consuming but with a potentially better outcome From: To: Time: Tue Mar 11 15:36:07 2008 Agree with ken, ask me if I have time and I read you my answer From: To: Time: Tue Mar 11 19:10:37 2008 getting to hate daptiv... it didn't record a task i entered last month. and while it seems to have recorded tasks i just entered now, it's adjusted the dates i entered. I specified tasks to end at the board meeting on 4/7, and they list as finishing 4/9 and 4/10. From: To: Time: Tue Mar 11 19:11:00 2008 are there holidays involved? From: To: Time: Tue Mar 11 19:11:58 2008 Oh, I see. Yes, it's holidays. I enter a finish date, it assumes I mean not counting holidays, so it moves the end date based on the holidays. How stupid. I could see if the date I entered was itself a holiday, and we had a "we don't work on holidays" flag set or something. From: To: Time: Tue Mar 11 19:13:10 2008 did you give it a fixed number of hours, or did you just supply start/end dates? From: To: Time: Tue Mar 11 19:13:34 2008 I supplied start and end dates. From: To: Time: Tue Mar 11 19:14:11 2008 also you can apply start/end date constraints which will keep some parts from shifting around quite so much. From: To: Time: Tue Mar 11 19:16:07 2008 I just told it to use the Thursday before the meeting, from which it "adjusted" to the correct end date. From: To: Time: Tue Mar 11 19:16:54 2008 for this sort of thing, try setting the "must complete on ___ date" constraint. From: To: Time: Tue Mar 11 19:17:52 2008 I just tried that. It "adjusted" that date too. From: To: Time: Tue Mar 11 19:18:17 2008 interesting From: To: Time: Tue Mar 11 19:19:18 2008 for some reason the constraint didnt' save From: To: Time: Tue Mar 11 19:19:28 2008 It would be "interesting" if reports weren't being generated tomorrow on this data. :) From: To: Time: Tue Mar 11 19:20:09 2008 like i said, they will only really look at the project-wide status/phase info. From: To: Time: Tue Mar 11 19:20:13 2008 at least that's my impression. From: To: Time: Tue Mar 11 19:20:18 2008 ? I set an end-date constraint on static analysis tools; that seems to have saved. Or maybe it's just showing it to me, and it's going to throw things away on me again. From: To: Time: Tue Mar 11 19:20:33 2008 oh sorry i was looking at the wrong task. From: To: Time: Tue Mar 11 19:20:53 2008 I've been updating all three that I just created. (You do see those too, I hope? :) From: To: Time: Tue Mar 11 19:20:54 2008 anyway the impression that i got was that Steve's message was mostly for my benefit. From: To: Time: Tue Mar 11 19:21:43 2008 ok, the constraint date shifting around like that seems highly bogus. From: To: Time: Tue Mar 11 19:36:18 2008 The bogosity level seems generally high. But I'm trying to get some data entered on my projects (again) as best I can. Not exact hours worked, but rough estimates of progress etc. From: To: Time: Wed Mar 12 14:38:13 2008 Have others gotten this "dynamic post office serivce" email? I saw a copy forwarded to SIPB, but the original supposedly went to ist@mit, yet I can't find a trace of it in my mailboxes. From: To: Time: Wed Mar 12 14:38:52 2008 i think i got a copy somehow. From: To: Time: Wed Mar 12 14:39:33 2008 It went to ip-partners, it-leaders and ist@mit.edu. From: To: Time: Wed Mar 12 14:39:42 2008 That was iT-partners. From: To: Time: Wed Mar 12 14:40:35 2008 Yep. And I should get ist@mit email, via ist->is&t->ist-w92->w92one. But I didn't get it, as far as I can tell. From: To: Time: Wed Mar 12 14:40:42 2008 Checked trash, checked spamscreen.... From: To: Time: Wed Mar 12 14:42:06 2008 It appears that the directions for using this new configuration specifically tell people to use password authentication rather than Kerberos. And the servers have different addresses -- raeburn.mail.mit.edu = po9.mail.mit.edu = 18.7.21.85 but po9.mit.edu = 18.7.21.65. From: To: Time: Wed Mar 12 14:48:33 2008 Oh, hm, maybe not passwords; you need your MIT certificate. You select the option for password authentication, but it doesn't say you need to enter your password anywhere. From: To: Time: Wed Mar 12 14:49:01 2008 (It *does* indicate that you don't use Kerberos for authenticating, though.) From: To: Time: Wed Mar 12 14:51:20 2008 And... it asks for my password. From: To: Time: Wed Mar 12 16:07:04 2008 do you mean for setting up apple mail? From: To: Time: Wed Mar 12 16:55:41 2008 MIT has been telling users to use password over SSL for years now. Since the Eudora addresses in tickets support disaster. From: To: Time: Wed Mar 12 17:35:09 2008 I thought that was just no-krb5, not no-Kerberos. *sigh* From: To: Time: Thu Mar 13 14:54:56 2008 In case it isn't obvious at this point, I'm working from home today From: To: Time: Thu Mar 13 16:14:07 2008 How do .libs find their way into pismere/target/lib/i386/rel? Specifically, krbcc32, which is in athena/auth/krbcc and whose makefiles don't have any *pre.in or *post.in added? From: To: Time: Thu Mar 13 16:18:35 2008 wwdc, june 9 - 13 From: To: Time: Fri Mar 14 12:00:19 2008 unless there's need for me to come in, I'm working from home today From: To: Time: Fri Mar 14 14:31:51 2008 it's tumbleweed country here. I think I should have worked from home :-) From: To: Time: Sun Mar 16 02:02:31 2008 This room is not anonymous. From: To: Time: Wed Mar 19 14:04:58 2008 where are people for the Apple call? From: To: Time: Wed Mar 19 14:05:51 2008 we're having trouble entering the passcode for the conference call because of phone problems... one sec From: To: Time: Wed Mar 19 14:06:05 2008 every time we type a 0 we get 2 From: To: Time: Wed Mar 19 14:06:15 2008 wow From: To: Time: Wed Mar 19 14:06:19 2008 okay we're in From: To: Time: Wed Mar 19 14:44:39 2008 um, why is there an RT user named "fish"? From: To: Time: Wed Mar 19 14:47:17 2008 also an RT user named "pnt" From: To: Time: Wed Mar 19 15:08:18 2008 ok, "fish" was created 2007-09-13 by root; "pnt" was created 2006-03-27 by root. weird. From: To: Time: Wed Mar 19 15:14:09 2008 As in some sort of compromise or something less concerning? From: To: Time: Wed Mar 19 15:15:09 2008 if we've been compromised it was apparently a while ago :-P From: To: Time: Wed Mar 19 15:17:54 2008 not sure if it was a compromise. certainly nothing else appears amiss. From: To: Time: Wed Mar 19 15:19:16 2008 Ooh. A one-line lint bug test case: int bar(int j) { while (/*CONSTCOND*/ 1) { if (foo(j++) == 42) return j+3; } } (Well, okay, two lines if you add the declaration of foo.) Lint says: function falls off bottom without returning value (2) bar From: To: Time: Wed Mar 19 15:20:20 2008 yeah that's something lint should know better than. From: To: Time: Wed Mar 19 15:24:15 2008 Does adding a dead code return statement tend to produce warnings on compilers we care about? If not, then perhaps you should just add a deadcode return statement. From: To: Time: Wed Mar 19 15:25:34 2008 We would probably get unreachable-statement warnings. I can test specific compilers... From: To: Time: Wed Mar 19 15:25:48 2008 Changing while(1) to for(;;) makes the bug go away. From: To: Time: Wed Mar 19 15:30:54 2008 Ah. gcc's unreachable-code warning is not turned on by -Wall. Though it's a warning we would probably want to enable, I would think, unless we decide that satisfying lint is more important. But lint also has an option to turn this warning off, and gcc also has a warning for "control reaches end of non-void function". From: To: Time: Wed Mar 19 15:40:02 2008 Sun's compiler also complains about the dead return statement. Clearly the compiler's getting something right that lint is botching... From: To: Time: Wed Mar 19 15:58:28 2008 i wonder if some obvious goof with the rt command line could have caused this weird user creation. From: To: Time: Thu Mar 20 17:35:25 2008 krbdev.mit.edu certificate expired. going to get a new one. From: To: Time: Thu Mar 20 18:45:21 2008 ok, krbdev.mit.edu cert updated. From: To: Time: Thu Mar 20 18:49:14 2008 forgot that i didn't need to change the key, but whatever. From: To: Time: Fri Mar 21 14:57:23 2008 i figured out why RT sometimes seems slow. it collects all the output before writing it to Apache. From: To: Time: Fri Mar 21 14:59:08 2008 Ken and Kevin, check your TechTime calendars for a test cluster thing on Monday. From: To: Time: Fri Mar 21 15:07:53 2008 Yay it finally happened. I installed the latest version of AppleConnect and now it appears to require the Apple patches From: To: Time: Fri Mar 21 15:08:09 2008 Goodbye Radar access :-( From: To: Time: Fri Mar 21 15:09:58 2008 3/21/08 3:09:34 PM com.apple.launchd[1] (com.apple.dyld) Throttling respawn: Will start in 5 seconds From: To: Time: Fri Mar 21 15:10:26 2008 my dyld is now crashing so often due to lack of Apple patches that launchd is throttling its relaunch ;-P From: To: Time: Fri Mar 21 15:10:36 2008 which Apple patches? i have never successfully updated AppleConnect. From: To: Time: Fri Mar 21 15:11:22 2008 the Apple pkinit support. If I install the MIT version of KfM it doesn't have the Apple pkinit exported functions. So when I test I get lots of 3/21/08 3:09:04 PM com.apple.dyld[10662] update_dyld_shared_cache[10662] for arch=i386 failed: could not resolve _krb5_pkinit_cert_hash_str from /System/Library/PrivateFrameworks/KerberosHelper.framework/Versions/A/KerberosHelper in /System/Library/PrivateFrameworks/KerberosHelper.framework/Versions/A/KerberosHelper From: To: Time: Fri Mar 21 15:11:58 2008 Where krb5_pkinit_cert_hash_str is a function that returns a complicated struct. At least according to Austin trying to stub it out would be difficult and might just make apps crash From: To: Time: Fri Mar 21 15:13:01 2008 The latest version of AppleConnect is crashing when I get tickets because of the lack of krb5_pkinit_cert_hash_str and possibly other pkinit support From: To: Time: Fri Mar 21 15:13:30 2008 interesting. why does it care about calling pkinit support directly? From: To: Time: Fri Mar 21 15:13:41 2008 No idea. From: To: Time: Fri Mar 21 15:14:19 2008 I assume if we reviewed their pkinit patches more thoroughly we'd know :-) From: To: Time: Fri Mar 21 15:15:42 2008 Oh crud. whoever borrowed my leopard disk never returned it From: To: Time: Fri Mar 21 15:15:55 2008 so I can't reinstall from scratch to get the real Kerberos libraries back :-( From: To: Time: Fri Mar 21 15:16:17 2008 cheat by using some standalone updater? From: To: Time: Fri Mar 21 15:16:33 2008 They haven't updated the Kerberos package in an updater yet afaik From: To: Time: Fri Mar 21 15:16:37 2008 oh From: To: Time: Fri Mar 21 15:16:59 2008 or at least I haven't had my busted copy of Kerberos get blown away yet From: To: Time: Fri Mar 21 15:17:42 2008 yay Ken had the Leopard disk! From: To: Time: Fri Mar 21 15:18:06 2008 I will be back online in about an hour. time to reinstall :-) From: To: Time: Fri Mar 21 15:18:22 2008 I'll be on zephyr if you need me From: To: Time: Fri Mar 21 15:32:15 2008 ah there I am connected from iChat From: To: Time: Fri Mar 21 15:34:34 2008 oh hm there is a security update I haven;t taken. I will try that first From: To: Time: Fri Mar 21 15:37:16 2008 I think the latest security update includes Kerberos, dealing with the current advisories and something from last year. From: To: Time: Fri Mar 21 15:37:57 2008 yeah I'm hoping it will blow away the version I was using for testing. Problem is that until I reinstall another busted copy of our kerberos I can't test this CCAPI crash I found From: To: Time: Fri Mar 21 15:38:28 2008 and I don't have a stack trace because it was a build with FORTIFY_SOURCE turned on so all the addresses are scrambled From: To: Time: Fri Mar 21 15:39:15 2008 FORTIFY_SOURCE totally kills my debugging puppy. It is admittedly defined to do so, but still From: To: Time: Fri Mar 21 15:39:38 2008 Hm, that's ... poor. From: To: Time: Fri Mar 21 15:40:37 2008 of course the CCacheServer crash might have just been because of dyld crashing. I can't really tell. the server, AppleConnect and dyld all crashed at the same time From: To: Time: Fri Mar 21 15:41:03 2008 but I'd hate to assume that, especially after checking in a large complicated patch to the server From: To: Time: Fri Mar 21 15:41:37 2008 problem with test cases is that they just do not make up for real dogfood testing with actual applications. AppleConnect does some weird stuff to the server From: To: Time: Fri Mar 21 15:41:57 2008 dogfood testing also does not make up for unit tests, obviously From: To: Time: Fri Mar 21 15:43:52 2008 nope, that security update did not overwrite my Kerberos From: To: Time: Fri Mar 21 15:43:57 2008 dang From: To: Time: Fri Mar 21 15:44:52 2008 Apple should support some kind of chroot or virtual machine arrangement for testing by OS developers. :( From: To: Time: Fri Mar 21 15:45:34 2008 we're not really a normal case. I'm replacing bits of the OS with folgers crystals From: To: Time: Fri Mar 21 15:48:20 2008 that's really funny. I can get AppleConnect tickets, but the AppleConnect application can't see them. Once it has gotten tickets once I have to reboot to be able to get them again From: To: Time: Fri Mar 21 15:50:00 2008 oh hm it's crashing repeatedly inside the KLL. that's why it can't see the tickets From: To: Time: Fri Mar 21 15:50:36 2008 dying inside a principal translation plugin that they are installing From: To: Time: Fri Mar 21 15:51:06 2008 I wonder if this works with their version of Kerberos From: To: Time: Fri Mar 21 15:51:52 2008 bah I can't use AFP to copy stuff from a clean leopard machine to the busted one because it wants to use pkinit. giggle From: To: Time: Fri Mar 21 15:56:34 2008 Ah, stupid apple mail. From: To: Time: Fri Mar 21 15:57:23 2008 All my "smart mailbox" specs are corrupted. All the conditions have turned into "any recipient contains ", and none of the smart mailboxes contain any messages. From: To: Time: Fri Mar 21 15:58:32 2008 Hm, not all of them, just most. And I have two copies of a smart mailbox folder, with duplicated (and mostly broken) versions of the smart mailboxes contained in it. From: To: Time: Fri Mar 21 16:02:16 2008 is this a symptom of SQLite buggery, or just Mail.app being broken on its own? From: To: Time: Fri Mar 21 16:02:40 2008 Could be either. Or breakage in the sync software. From: To: Time: Fri Mar 21 16:06:06 2008 Fortunately, my laptop's configuration is somewhat less broken than the desktop (has the duplicates, but only one set is broken), so maybe I can recover the data. From: To: Time: Fri Mar 21 16:24:50 2008 argh. AppleConnect update popups keep getting lost and i have to use Expose to locate them. From: To: Time: Fri Mar 21 16:25:51 2008 Hmm these AppleConnect crashes don't go away with a stock Kerberos framework From: To: Time: Fri Mar 21 16:26:08 2008 looks like round 2 of no thread safety in CFBundles but I'm not sure yet From: To: Time: Fri Mar 21 16:26:11 2008 maybe it's just as well that AppleConnect updates never succeed for me. From: To: Time: Fri Mar 21 16:26:49 2008 do you have the bug where it fails updating the scripts archive? From: To: Time: Fri Mar 21 16:26:54 2008 yeah From: To: Time: Fri Mar 21 16:27:15 2008 there's an update you can download from the ftp site that will fix that From: To: Time: Fri Mar 21 16:29:20 2008 ok. was it the 2.0 update that broke AppleConnect for you? From: To: Time: Fri Mar 21 16:29:56 2008 yeah From: To: Time: Fri Mar 21 16:30:30 2008 i think i'll wait then :-) From: To: Time: Fri Mar 21 16:31:00 2008 I'd actually be interested to know if you see the same problem as me, but you might not want to install it on your primary machine From: To: Time: Fri Mar 21 16:31:27 2008 you'd get something like: Thread 0 Crashed: 0 libobjc.A.dylib 0x936d36e8 objc_msgSend + 24 1 com.apple.CoreFoundation 0x9161cc69 __CFDictionaryDeallocate + 281 2 com.apple.CoreFoundation 0x9164f7a8 _CFRelease + 216 3 com.apple.CoreFoundation 0x915f32a4 __CFBundleDeallocate + 356 4 com.apple.CoreFoundation 0x9164f7a8 _CFRelease + 216 5 edu.mit.Kerberos 0x200118ca __KLTranslatePrincipal + 2348 6 edu.mit.Kerberos 0x20010b48 __KLTranslateKLPrincipal + 219 7 edu.mit.Kerberos 0x20010450 KLCreatePrincipalFromString + 313 8 ...e.ist.ds.appleconnect2.core 0x1695f0b2 -[ACCKDCUser klPrincipal] + 169 From: To: Time: Fri Mar 21 16:31:40 2008 no other macs i tend to use. any easy way to back out the update if i take it? From: To: Time: Fri Mar 21 16:31:46 2008 Which is it blowing out calling their principaltranslation plugn From: To: Time: Fri Mar 21 16:31:50 2008 (or i could just suffer with WebRadar) From: To: Time: Fri Mar 21 16:32:01 2008 I don't know of a way to back out From: To: Time: Fri Mar 21 16:33:34 2008 actually i'm wondering if AppleConnect will try to jump in on WebRadar's action, because i've seen it do that before. From: To: Time: Fri Mar 21 16:34:31 2008 Disabling the principal translation plugin fixes the problem though now I am "lxs%mit.edu" From: To: Time: Fri Mar 21 16:35:05 2008 what did it translate it to before? From: To: Time: Fri Mar 21 16:35:05 2008 Could be worse, could be "mit!lxs". :) From: To: Time: Fri Mar 21 16:36:05 2008 I am a really old ADC member so my email address is my account name. They didn't realize you could escape "@" in principal names so the Kerberos principals all have % instead of @ From: To: Time: Fri Mar 21 16:36:28 2008 they use the translation plugins to do the mapping From: To: Time: Fri Mar 21 16:36:31 2008 yeah mine is tlyu%mit.edu From: To: Time: Fri Mar 21 16:37:04 2008 though AppleConnect does the % to @ translateion From: To: Time: Fri Mar 21 16:37:18 2008 Anyway you can remove the translation plugin references from the realm entries in /Library/Application Support/AppleConnect/com.apple.ist.ds.sso.APPLECONNECT.APPLE.COM From: To: Time: Fri Mar 21 16:37:32 2008 but then you need to actually type the % From: To: Time: Fri Mar 21 16:38:56 2008 no plugins in my config file but that's probably because i've got an old version. From: To: Time: Fri Mar 21 16:39:40 2008 so do you still want me to try the 2.0 update? From: To: Time: Fri Mar 21 16:57:37 2008 hm, radar download site only has 1.6.4. From: To: Time: Fri Mar 21 16:58:32 2008 it probably needs to be downloaded by the update mechanism in apple connect From: To: Time: Fri Mar 21 16:58:44 2008 yeah you need to use the 1.6.4 installer and then it will download and install 2.0 From: To: Time: Fri Mar 21 16:59:06 2008 their download site lags releases by a few days From: To: Time: Fri Mar 21 17:05:22 2008 do i want to install Apple's IS&T Software Update? From: To: Time: Fri Mar 21 17:05:41 2008 I did but it just offers me AppleConnect ;-) From: To: Time: Fri Mar 21 17:05:58 2008 heh From: To: Time: Fri Mar 21 17:08:31 2008 ok, got 2.0; doesn't crash. From: To: Time: Sun Mar 23 02:02:28 2008 This room is not anonymous. From: To: Time: Mon Mar 24 13:53:16 2008 I thought anonymous web RT submissions were going to be disabled? From: To: Time: Mon Mar 24 13:54:30 2008 We couldn't figure out how to do it From: To: Time: Mon Mar 24 13:54:42 2008 Ow. From: To: Time: Mon Mar 24 13:54:57 2008 Oh, right, the web vs email issue. Bleah. From: To: Time: Mon Mar 24 13:55:50 2008 Well, how about my "you must be at least this intelligent to access RT" test? From: To: Time: Mon Mar 24 13:56:44 2008 Feel free to implement From: To: Time: Mon Mar 24 13:57:03 2008 ... in my copious free time, right? From: To: Time: Mon Mar 24 13:59:06 2008 Exactly From: To: Time: Mon Mar 24 13:59:30 2008 If someone had time to put together a statement of work for a real rt upgrade we have dollars. From: To: Time: Mon Mar 24 13:59:44 2008 And I hear that dollars can be exchanged for RT consulting From: To: Time: Mon Mar 24 14:01:34 2008 We should probably make the time. But I can say that pretty easily, when Tom's the one who could probably come up with the statement of work most efficiently. All I have is a list of gripes. :) From: To: Time: Mon Mar 24 15:28:15 2008 catherine has globs of RT work she needs to have done, so we can bundle our stuff with her proposal if anyone can make time to do even a rudimentary writeup From: To: Time: Mon Mar 24 15:28:45 2008 might not have time to work on it today; probably tomorrow. From: To: Time: Mon Mar 24 15:29:24 2008 could just prepend the work "Fix" onto each of the items on Ken's list From: To: Time: Mon Mar 24 15:30:07 2008 we do need to let Jesse know what he's going to get into, which is more than "fix x,y,z". From: To: Time: Mon Mar 24 15:31:31 2008 ok, i am dialed in. From: To: Time: Mon Mar 24 15:31:40 2008 (to the meeting) From: To: Time: Mon Mar 24 16:20:53 2008 ON top of that we'd want to write up migration to rt3.x. So, we'd need to port the gnats gateway, our subversion stuff (or hack on the existing rt3 subversion stuff) etc etc From: To: Time: Mon Mar 24 16:21:31 2008 also getting input from Kevin and lxs on their respective RT requirements would be good. From: To: Time: Mon Mar 24 16:50:04 2008 I wonder if svk support would be practical. Or at least getting someone to maintain a locker version for Athena. From: To: Time: Mon Mar 24 16:58:42 2008 re RT work: I'm currently whining in an email buffer. Will inflict the result on you all soon. :) From: To: Time: Mon Mar 24 16:59:51 2008 On a seemingly unrelated note, I'd like to see fuse, sshfs, and encfs in Athena... From: To: Time: Mon Mar 24 17:11:54 2008 i'm moderately annoyed at the postings gatewayed through Nabble. From: To: Time: Mon Mar 24 17:12:39 2008 The footers added, or something else? From: To: Time: Mon Mar 24 17:13:13 2008 partly that, partly that they seem more confused than most list posters. From: To: Time: Mon Mar 24 17:13:44 2008 The New AOL :) From: To: Time: Mon Mar 24 17:56:56 2008 results of rambling sent off... not all can have "fix" prepended trivially. :) From: To: Time: Mon Mar 24 18:01:27 2008 would you like some cheese with your whine? From: To: Time: Mon Mar 24 18:02:22 2008 mmm, cheese... From: To: Time: Mon Mar 24 18:02:47 2008 remember to place your lunch orders for tomorrow ;-) From: To: Time: Mon Mar 24 18:02:54 2008 oh yeah... From: To: Time: Tue Mar 25 08:36:52 2008 I don't have any particular opinions about RT. From: To: Time: Wed Mar 26 20:05:52 2008 ouch. the users "fish" and "pnt" are superusers. fixing. From: To: Time: Wed Mar 26 20:11:27 2008 Are we sure we didn't have something very unfortunate happen? From: To: Time: Wed Mar 26 20:15:15 2008 unclear. i see no other evidence. both were created by "root", at times separated by a year or so. i think both were created before the disk crash. From: To: Time: Wed Mar 26 20:15:35 2008 it may be that someone did password-guessing on the web login for "root". From: To: Time: Wed Mar 26 20:16:23 2008 correction: "pnt" created before the disk crash; "fish" created after. From: To: Time: Wed Mar 26 20:17:45 2008 i'm going to smash root's entry to disable its password, just in case. From: To: Time: Wed Mar 26 20:24:45 2008 oh look, we have apache logs. From: To: Time: Wed Mar 26 20:30:37 2008 anyway, it looks like someone in Hong Kong logged in as root on the web interface this last time. From: To: Time: Wed Mar 26 20:54:23 2008 mail forthcoming. From: To: Time: Thu Mar 27 14:08:45 2008 bought a new toy^H^H^Hvery useful tool last night at the mac store. now i guess i get to play with leopard for real. the "low" end mac pro stock configuration they had comes with dual quad-core processors. dunno how i'm going to keep 'em all busy, but i guess i'll have to work on it... From: To: Time: Fri Mar 28 21:19:33 2008 do we really want to pull more changes into 1.6.4 now that we have a beta out? From: To: Time: Fri Mar 28 22:15:02 2008 Probably not. It's a minor thing, I had only noted it for 1.6.4 back when I wrote it and committed locally. I should figure out how to go back and change log messages in svk for stuff I haven't pushed to the main repository... From: To: Time: Sun Mar 30 02:02:32 2008 This room is not anonymous. From: To: Time: Mon Mar 31 12:39:17 2008 I'm not sure if it's the krb4 stubs or how libzephyr calls stuff, but the Zephyr support in Adium crashes for me rather than simply failing, on Leopard. From: To: Time: Mon Mar 31 12:49:42 2008 Is there any reason not to start updating my Macs to Leopard now? From: To: Time: Mon Mar 31 12:51:03 2008 I'm personally not using it yet From: To: Time: Mon Mar 31 12:51:25 2008 but at this point that's mainly because I haven't found the time to upgrade From: To: Time: Mon Mar 31 14:08:10 2008 I wonder if we can resolve the test cluster issue today. Specifically, at least: What should I do about the machines there now? Get 'em working again? Toss 'em out? Keep only working ones? From: To: Time: Mon Mar 31 14:35:40 2008 emergency moderation on for krb5-bugs From: To: Time: Mon Mar 31 18:56:59 2008 Do we have Sun incremental propagation patches sitting around somewhere? From: To: Time: Mon Mar 31 19:09:36 2008 Do we need emergency moderation on, or just moderating messages from rt-comment@ and maybe rt@ ? From: To: Time: Mon Mar 31 19:09:51 2008 same difference From: To: Time: Mon Mar 31 19:10:44 2008 Does email out for comments from RT accounts like ours go out as from rt-comment@ or from us? From: To: Time: Mon Mar 31 19:11:25 2008 from rt-comment From: To: Time: Mon Mar 31 19:11:39 2008 Oh. Oh well. From: To: Time: Mon Mar 31 19:12:16 2008 oh for some reason i was getting an ipv6 address routed via limekiller and it was making my ftp access to netbsd.org suck a lot. From: To: Time: Mon Mar 31 19:12:35 2008 so i just turned of ipv6 and it got better. and people wonder why ipv6 adoption isn't so great... From: To: Time: Mon Mar 31 19:15:20 2008 If you're using ipv6 from here, yeah, limekiller would be the normal route. I'm seeing 100ms now, vs 80ms in IPv4. I'm not surprised it's mediocre sometimes, especially if some tunnel is down. From: To: Time: Mon Mar 31 19:15:46 2008 probably throughput and packet loss are more of a problem than latency, but i hadn't bothered to measure. From: To: Time: Mon Mar 31 19:16:15 2008 True. From: To: Time: Mon Mar 31 19:16:42 2008 It's better than when limekiller was down, and my machine would try to send traffic out that way anyways. :) From: To: Time: Mon Mar 31 19:19:45 2008 also wound up getting what i needed via torrent, which was probably faster than an overworked ftp server. From: To: Time: Sun Jul 6 02:02:31 2008 This room is not anonymous. From: To: Time: Mon Jul 7 14:09:50 2008 okay that's totally busted. the MIT jabber server can't connect to this chat room, but googletalk can :-P From: To: Time: Mon Jul 7 14:10:16 2008 weird. i seem to get in ok. From: To: Time: Mon Jul 7 14:10:20 2008 hmm, my client is connected to MIT and I saw you... From: To: Time: Mon Jul 7 14:10:46 2008 I can log into jabber, adium just can't join this chat room with my MIT Jabber ID From: To: Time: Mon Jul 7 14:11:01 2008 and I can chat with people From: To: Time: Mon Jul 7 14:11:34 2008 Justin is having the same problem, but he's also using adium From: To: Time: Mon Jul 7 14:11:47 2008 and you're not using v1.2.6 of doom? From: To: Time: Mon Jul 7 14:12:11 2008 1.2.5 From: To: Time: Mon Jul 7 14:12:22 2008 there's also a 1.2.7 but it can't connect to MIT's server at all From: To: Time: Mon Jul 7 14:12:38 2008 i'm currently running 1.2.7 From: To: Time: Mon Jul 7 14:12:55 2008 odd I downloaded 1.2.7 and I got endless reconnects From: To: Time: Mon Jul 7 14:13:08 2008 1.2.6 was the one that had endless reconnects for me From: To: Time: Mon Jul 7 14:13:14 2008 some "XMPP parse error" garbage From: To: Time: Mon Jul 7 14:26:25 2008 ah, 1.3b7 on my desktop can connect... From: To: Time: Mon Jul 7 14:30:28 2008 I'm seeing reconnects with 1.3b7 and 1.2.7. Near as I can tell, it's an error processing XML from the server with control characters (that are invalid there). Ironically, the control characters are coming from broken versions of Adium run by other people. Like, over the weekend, Wilson's Adium process was sending a version string with "" in it, and the XML parser choked and never recovered, so *I* got disconnected. From: To: Time: Mon Jul 7 14:30:42 2008 It might help if the MIT server validated the XML... From: To: Time: Mon Jul 7 15:10:34 2008 ah so it's someone on my buddies list that Tom doesn't have on his buddies list From: To: Time: Mon Jul 7 15:11:21 2008 Probably. Or someone who was online/offline at just the right times. From: To: Time: Mon Jul 7 15:12:20 2008 Over the weekend, I saw bogus version strings from three contacts -- Wilson, Justin, and I forget who the third was... From: To: Time: Mon Jul 7 15:13:05 2008 heh, Justin is on my buddies list From: To: Time: Mon Jul 7 15:13:14 2008 Curse you, Justin! :D From: To: Time: Mon Jul 7 15:13:29 2008 Only Wilson's included the control characters; the rest looked like random non-ASCII stuff. But now Wilson and Justin are online and both 1.2.7 and 1.3b7 are happy for me. From: To: Time: Mon Jul 7 15:13:41 2008 I can try 1.2.7 again From: To: Time: Mon Jul 7 15:13:50 2008 brb From: To: Time: Mon Jul 7 15:14:47 2008 But earlier (a little before meeting time, while I was away from my desk) I got messages from Paul Hoffman telling me he'd noticed I was using one of the unhappy versions of Adium, so I guess I was getting disconnect loops then. From: To: Time: Mon Jul 7 15:15:30 2008 Ah there we go. And now I can connect here with my MIT Jabber ID From: To: Time: Mon Jul 7 15:15:57 2008 Is 1.3b7 worth using? From: To: Time: Mon Jul 7 15:16:27 2008 doesn't seem to do anything special From: To: Time: Mon Jul 7 15:16:50 2008 it can connect to facebook's chat server From: To: Time: Mon Jul 7 15:16:59 2008 that's about it for differences with 1.2.7 From: To: Time: Mon Jul 7 15:29:56 2008 Ah, found the -dead_strip option, guess I overlooked that in the man page before. It shrinks libkrb5.3.3.dylib by almost 3%. Might shrink the Kerberos framework by a bit more, if you're not already using it, though I'd hope you are... From: To: Time: Mon Jul 7 15:32:19 2008 what's the motivation for #6010? From: To: Time: Mon Jul 7 15:34:10 2008 memcpy of leading common elements of two different structure types. seems kind of iffy... From: To: Time: Mon Jul 7 15:35:28 2008 it's still not doing a deep copy... or are we certain that there will be no use of the source structure after the copy? From: To: Time: Mon Jul 7 15:36:21 2008 I think that's the idea, yeah. From: To: Time: Mon Jul 7 15:37:15 2008 But lacking some union hackery, I don't think you're guaranteed you can just do the memcpy and have everything work. Even with the union, I'm not sure if memcpy (vs individual member access) is guaranteed safe. From: To: Time: Mon Jul 7 16:21:21 2008 I believe it was specifically causing them problems on 64-bit platforms From: To: Time: Mon Jul 7 16:21:59 2008 I'm guessing alignment issues. I left the patch names alone so there might be Radar numbers in there you can look at From: To: Time: Mon Jul 7 16:24:56 2008 For those of us with access... From: To: Time: Mon Jul 7 16:30:36 2008 Yes, well, we've been told they won't interact with our bug database. They want us to absorb the "2 bug databases" problem From: To: Time: Mon Jul 7 16:31:07 2008 Even though this doesn't make sense since we don't have access to all the bugs since some aren't in the Kerberos queue From: To: Time: Mon Jul 7 16:31:28 2008 (whereas they have full access to our database) From: To: Time: Mon Jul 7 16:31:36 2008 *grumble* :-) From: To: Time: Mon Jul 7 16:32:17 2008 So, how tough would it be for me to get access to radar? (And, make it general policy on their end that anyone on the MIT Kerberos team who wants it should be able to get that access too?) From: To: Time: Mon Jul 7 16:32:20 2008 what's the radar number for #6010? From: To: Time: Mon Jul 7 16:32:53 2008 oh I committed that... one sec From: To: Time: Mon Jul 7 16:33:23 2008 5839308 and 5902576 From: To: Time: Mon Jul 7 16:33:48 2008 there are 3 patches merged together in the patch file we got.... From: To: Time: Mon Jul 7 16:38:13 2008 ahhh I'm guessing it is 5863501 which is not in the Kerberos component From: To: Time: Mon Jul 7 16:39:26 2008 not that we can tell since we can't read the source changes.... From: To: Time: Mon Jul 7 16:39:49 2008 Ken, I think you can just ask at the conference call From: To: Time: Mon Jul 7 16:40:14 2008 come prepared with your ADC account name and ID From: To: Time: Mon Jul 7 16:40:46 2008 although they'll probably just want you to mail it From: To: Time: Mon Jul 7 16:41:27 2008 "account name and ID"? They're different things? From: To: Time: Mon Jul 7 16:41:36 2008 yeah you have an ID # as well From: To: Time: Mon Jul 7 16:42:02 2008 if you log into your account at connect.apple.com it's listed somewhere there From: To: Time: Mon Jul 7 16:42:38 2008 Ah, found it in the "profile" section. Which was not listed in the first page I got when signing on, but there was a link when I went off to the downloads section... From: To: Time: Mon Jul 7 16:49:25 2008 so the fact that memcpy was causing problems worries me. it implies that we actually did break ABI compatibility. From: To: Time: Mon Jul 7 16:56:46 2008 It is interesting... the only difference is an added pointer at the end; 9 (64-bit) words vs 10. There are already pointers in the shorter (public) structure. I don't expect there to be alignment issues there. From: To: Time: Mon Jul 7 16:59:13 2008 My guess is putting a union of the two structure types in scope might help, too. Or perhaps the extended version of the structure should *contain* the public one, instead of extending it. From: To: Time: Mon Jul 7 17:16:56 2008 I recommend sending mail to the Apple list asking them what the specific problem was if you want to know From: To: Time: Mon Jul 7 17:17:25 2008 does the relevant patch appear in e-mail anywhere? From: To: Time: Mon Jul 7 17:22:35 2008 there were three distinct patches in the patchfile I got from austin. (1) was to add x86_64 to all the application processor targets (ie: 64-bit KDC, apps, etc) (2) was the 64-bit changes to the big endian stashfile which you and I fixed up. (3) was RT 6010 From: To: Time: Mon Jul 7 17:23:02 2008 if you want the patchfile I can email it, but it's 90% xcode project changes From: To: Time: Mon Jul 7 17:23:25 2008 (ie diffs on a big plist file that isn't human-readable) From: To: Time: Mon Jul 7 17:25:36 2008 AJ-5839308+5902576-x86_64.patch is the name of the patch, which is where I got those Radar #s from From: To: Time: Mon Jul 7 17:28:03 2008 actually the patches were all emailed out. Love sent them to the Apple list. "Re: Question about Mach Type checking" on June 27th. "apple-patches.tar.gz" is the attachment which is a tarball of all the patches From: To: Time: Mon Jul 7 17:28:27 2008 you can find AJ-5839308+5902576-x86_64.patch in there From: To: Time: Mon Jul 7 17:39:44 2008 Mailed out a summary to the staff list From: To: Time: Mon Jul 7 17:43:26 2008 ok From: To: Time: Mon Jul 7 17:56:09 2008 Hm, yeah, encapsulation would've been a better approach than copy-and-extend, definitely. From: To: Time: Mon Jul 7 18:13:32 2008 The Common Crypto digest functions look like they'd cut maybe 11K of code, almost 10% of the crypto library. Though the shim layer would add back a little bit of that. Looks like we could probably do away with most of our HMAC and low-level encryption code too. (Over 32K in AES, probably another 8-10K in DES.) We'd still need string-to-key, CTS, DK, etc. From: To: Time: Mon Jul 7 18:15:29 2008 Of course, we could probably do the same with OpenSSL's crypto code. From: To: Time: Mon Jul 7 20:27:28 2008 Know how I keep saying that the more time I spend looking at the referrals draft, the more subtle security issues I seem to find? Well, guess what? *sigh* From: To: Time: Wed Jul 9 15:34:25 2008 i'm dealing with enc_provider/aes.c copyright From: To: Time: Wed Jul 9 17:12:28 2008 argh, a diff inside a diff! From: To: Time: Thu Jul 10 14:21:11 2008 Sigh, I've been trying to reproduce this CCacheServer bug for 2 days now. I've tried everything and it just doesn't happy From: To: Time: Thu Jul 10 14:21:15 2008 er happen From: To: Time: Thu Jul 10 14:24:05 2008 If you can't reproduce the bug, it "does happy". :) (And if you can reproduce it, it "does sad"...) From: To: Time: Thu Jul 10 14:24:12 2008 heh From: To: Time: Thu Jul 10 14:24:39 2008 I'm just concerned because they have "fixed" it by introducing a memory leak.... one which they reported against us in an earlier bug. :-P From: To: Time: Thu Jul 10 15:51:46 2008 i think part of why RT can get slow is that it stores the results of the most recent search in the sessiondata. From: To: Time: Thu Jul 10 15:53:03 2008 Ow. From: To: Time: Thu Jul 10 15:53:40 2008 I suppose there are cases where that actually improves performance. From: To: Time: Thu Jul 10 15:54:06 2008 yes, but writing it out to disk and reading it back in has got to slow things down. From: To: Time: Thu Jul 10 15:54:22 2008 so if you do a big search, clear it.... From: To: Time: Thu Jul 10 15:54:58 2008 Is it using a tmpfs or a real file system? From: To: Time: Thu Jul 10 15:55:40 2008 real filesystem From: To: Time: Thu Jul 10 15:57:06 2008 Eh. If it's just caching for performance(?), and the disk i/o is actually hurting performance, not just for the user in question but for everyone in general, maybe it should move to tmpfs, or be eliminated. From: To: Time: Thu Jul 10 15:57:31 2008 well if it's not preserved, the prev/next buttons on the search listing won't work. From: To: Time: Thu Jul 10 15:58:46 2008 but it's not the only reason RT is slow. running the command line stuff is similarly slow for tickets with many transactions. From: To: Time: Thu Jul 10 15:59:18 2008 Oh, I suppose. :) I don't think I ever use them. Might be worth checking if it's faster to redo the search and supply an offset into the list in the prev/next buttons. In your copious free time. From: To: Time: Thu Jul 10 16:00:19 2008 well it looks easy enough to just implement a "use tmpfs" plan. From: To: Time: Thu Jul 10 16:00:20 2008 (In fact, I'm pretty sure I never use them, but I do sometimes change the number of results to display "per page" and resubmit. That might use the cached results too.) From: To: Time: Thu Jul 10 16:00:25 2008 stand by for brief outage. From: To: Time: Thu Jul 10 16:02:13 2008 Hm, I'm still getting the "unparsable dictionary" message from .Mac, excuse me, MobileMe, system preferences, even after taking the software update. From: To: Time: Thu Jul 10 16:03:43 2008 (And the name "MobileMe" invariably reminds me of RMS's POSIX_ME_HARDER hack.) From: To: Time: Thu Jul 10 16:04:47 2008 ok, some further corroborating evidence. doing a search bumps my sessiondata file up to 24k, while just after clearing the search it's more like 8k From: To: Time: Thu Jul 10 16:05:03 2008 anyway, sessiondata now stored in tmpfs. it might make things very slightly faster. From: To: Time: Thu Jul 10 16:28:34 2008 What's the software I need to access radar? From: To: Time: Thu Jul 10 16:31:08 2008 radar From: To: Time: Thu Jul 10 16:31:17 2008 i'll find you a url From: To: Time: Thu Jul 10 16:31:34 2008 Yeah, I should've said "where". :) Thanks... From: To: Time: Thu Jul 10 16:32:01 2008 ftp://ftp.apple.com/.Shared From: To: Time: Thu Jul 10 16:32:20 2008 you'll need radar.dmg and AppleConnect.dmg From: To: Time: Thu Jul 10 16:32:28 2008 installed in the opposite order From: To: Time: Thu Jul 10 16:37:54 2008 Thanks. Now I just have to remember my password. :) From: To: Time: Thu Jul 10 16:38:20 2008 And someday I still need to figure out how to get my swap space on a different partition. Or I'll need to reinstall this machine. From: To: Time: Thu Jul 10 16:38:59 2008 Or repartition without reinstalling... that'd be pretty nice... From: To: Time: Thu Jul 10 16:40:27 2008 you can repartition into two without installing if you're ok with the other being an ntfs partition From: To: Time: Thu Jul 10 16:40:35 2008 using the boot camp tool From: To: Time: Thu Jul 10 16:41:59 2008 I have three partitions now. The root partition is where Mac OS X insists on putting the swap files, and with OS growth and random applications, it's getting too small. One of the partitions (used to be the old OS version) is not currently in use. I'd like to merge that with the root, and increase the file system size. From: To: Time: Thu Jul 10 18:24:39 2008 what defines TARGET_OS_MAC? From: To: Time: Thu Jul 10 18:30:08 2008 nevermind; found it. From: To: Time: Thu Jul 10 18:30:09 2008 TargetConditionals.h From: To: Time: Fri Jul 11 13:27:02 2008 I turned on dead code stripping on darwin builds the other day. It does make some of our libraries a little smaller; we might want to investigate in our copious free time. From: To: Time: Fri Jul 11 13:27:39 2008 GNU binutils linker has a "gc-sections" option that'll remove unreferenced sections, but it's not supported when building shared libraries in the version on Athena Linux. A later release supposedly does support it. From: To: Time: Fri Jul 11 13:29:35 2008 The binutils option can't separate functions within a section (i.e., normally, within the same object file), but gcc -ffunction-sections will put each function in its own section. I think it may increase code size a little, though; not clear it'd be worthwhile, though we might be able to use it to figure out which functions are dead, and remove them in the source. From: To: Time: Fri Jul 11 17:00:47 2008 re 20512: shouldn't we get TargetConditionals.h via krb5.h already? From: To: Time: Fri Jul 11 17:43:00 2008 re TargetConditionals.h, k5-int.h is supposed to be included before krb5.h, due to some issues with time_t on Windows. From: To: Time: Fri Jul 11 17:46:41 2008 Right, if you include both of them, but k5-int.h also includes krb5.h, fairly early on, after doing whatever about the time_t stuff. From: To: Time: Fri Jul 11 17:47:46 2008 oh, i see. but it's a little less fragile to be slightly redundant here, i think. From: To: Time: Fri Jul 11 18:04:42 2008 True. From: To: Time: Sun Jul 13 02:02:41 2008 This room is not anonymous. From: To: Time: Mon Jul 14 14:54:08 2008 Ah, looks like http://isda-maven1.mit.edu:8060/changelog/krb5/?cs=[REVISION#] is all we need to pull out diffs for one revision. From: To: Time: Mon Jul 14 14:54:53 2008 (And, logically enough, we don't need a pathname within the repository, unless you only want to look at a subset of the changes, since the revision numbers are repository-wide...) From: To: Time: Mon Jul 14 15:27:07 2008 food preferences for tomorrow? From: To: Time: Mon Jul 14 15:27:33 2008 Pizza? From: To: Time: Mon Jul 14 15:27:54 2008 I'm fine with that From: To: Time: Mon Jul 14 15:27:58 2008 me too From: To: Time: Mon Jul 14 15:29:05 2008 Will's changes update the DAL, without version number checks. I think that's still one of our private APIs for now, so it's probably okay. From: To: Time: Mon Jul 14 15:32:07 2008 opengrok appears to focus on per-file changes, not entire tree revision numbers. anyone have evidence to the contrary? From: To: Time: Mon Jul 14 15:34:10 2008 That was my impression. From: To: Time: Mon Jul 14 15:38:07 2008 hm. Bryan is out tomorrow. From: To: Time: Mon Jul 14 17:22:46 2008 what's up with r20514? it doesn't seem to make sense in ticket #6019 at first glance. From: To: Time: Mon Jul 14 17:26:52 2008 It was a simple, clearly-correct piece of the Apple patch. I want to examine other ways of doing the rest of it, though. From: To: Time: Mon Jul 21 16:05:44 2008 that's quite the flurry of mail going on. From: To: Time: Mon Jul 21 16:39:59 2008 Can __KLInternalAcquireInitialTicketsForCache change the default ccache name? Or can I assume the default name before the call is still the default afterwards? From: To: Time: Mon Jul 21 16:41:09 2008 Actually, never mind, I think I should just keep the extra call and not think about it too hard... From: To: Time: Mon Jul 21 17:15:39 2008 __KLAcquireInitialTicketsForCache can change the ccache name (if the dialog pops and the user selects a different principal) From: To: Time: Mon Jul 21 18:41:56 2008 why does r20561 delete the os_context assignment? From: To: Time: Mon Jul 21 18:43:05 2008 It wasn't used. From: To: Time: Mon Jul 21 18:44:33 2008 commit message didn't say so, but i guess that's just something to keep in mind next time. From: To: Time: Mon Jul 21 18:45:38 2008 Sorry, for a fix intended for the branch I should've been more specific (or just left out the cleanup). From: To: Time: Sun Jul 27 02:02:56 2008 This room is not anonymous. From: To: Time: Sun Aug 3 02:02:35 2008 This room is not anonymous. From: To: Time: Mon Aug 4 16:23:37 2008 oops. forgot to ask for lunch prefs. From: To: Time: Mon Aug 4 16:26:38 2008 I lean toward pizza From: To: Time: Mon Aug 4 16:26:40 2008 Yeah sorry, I think I interrupted you with a question From: To: Time: Mon Aug 4 16:26:43 2008 pizza is good From: To: Time: Mon Aug 4 16:26:56 2008 pizza's fine, sure... From: To: Time: Mon Aug 4 16:27:16 2008 ok, i'll ask steve if he will coordinate. From: To: Time: Mon Aug 4 17:58:19 2008 For the Coverity downloads... any reason we should care about ia64-linux, or freebsd, or pa-hpux? From: To: Time: Mon Aug 4 17:58:35 2008 In fact, do we have any 10.4 Macs around, or should I just punt the Mac downloads too? From: To: Time: Mon Aug 4 17:59:22 2008 i have a 10.4 mac From: To: Time: Mon Aug 4 17:59:35 2008 ppc or intel? eh, i can just get both. From: To: Time: Mon Aug 4 17:59:39 2008 intel From: To: Time: Mon Aug 4 18:00:06 2008 are we constrained in a narrow time window for downloading these dists? From: To: Time: Mon Aug 4 18:00:30 2008 Not as far as I know, but since I'm doing it now anyways... From: To: Time: Mon Aug 4 18:13:07 2008 Hm, this is the 4.0.0 release, apparently *just* put out (July 31). From: To: Time: Tue Aug 5 17:09:56 2008 was someone mucking with the apt sources.list on opteron-prime recently? like around jul 10? From: To: Time: Tue Aug 5 17:11:01 2008 oh nevermind that was last year :-) From: To: Time: Tue Aug 5 17:28:59 2008 ok, let's see if this totally hoses opteron-prime From: To: Time: Tue Aug 5 18:09:55 2008 oops. gssapi code is passing int values where void* needed. (util_validate.c) From: To: Time: Wed Aug 6 13:51:26 2008 oh look more nameserver vuln notices From: To: Time: Wed Aug 6 14:31:03 2008 So, I was thinking a bit more about the idea I brought up here a little while back, about keeping track of when threads are active in the Kerberos libraries, and not running finalization code if other threads are active. I think it can be simplified a bit: Keep a sort of "ref count" on the library, where for libkrb5 code the reference can be a krb5_context -- that is, we keep track of how many contexts there are active. If the finalization code gets invoked and the refcount is nonzero, that means either the application didn't clean up before stopping use of the krb5 code, or it's not done despite (probably) being in an exit call, so we just punt. Of course, there are locking issues for the counter, and that approach may not suffice for parts of GSSAPI or com_err. And I haven't figured out what to do about a thread that enters the library after the finalization code has decided that it should in fact start cleaning up. But the refcount approach would mean not having to instrument every entry point into the krb5 library. From: To: Time: Wed Aug 6 14:31:14 2008 It's still a half-baked idea, but it's still in the oven. :-) From: To: Time: Wed Aug 6 15:12:22 2008 why not just associated the refcount with the call to k5_setspecific? From: To: Time: Wed Aug 6 15:13:28 2008 (ie: increment on the first call to k5_setspecific for a given thread, decrement when the destructor is called) From: To: Time: Wed Aug 6 15:14:21 2008 I guess also decrement if k5_setspecific is called with NULL From: To: Time: Wed Aug 6 15:29:16 2008 There's more than per-thread data to clean up. We could have some global state needing cleanup, without any thread-specific data. Also, we don't do anything to set the thread-specific data to NULL when we finish using Kerberos in a given thread. From: To: Time: Wed Aug 6 15:34:43 2008 well looking at how k5_setspecific is implemented you don't have to special case NULL anyway From: To: Time: Wed Aug 6 15:35:56 2008 The only reason I was suggesting associating it with the thread structures is so it works with the GSSAPI global krb5 context From: To: Time: Wed Aug 6 15:36:19 2008 if you're using GSSAPI you always have one krb5_context From: To: Time: Wed Aug 6 15:46:59 2008 Oh, hm. From: To: Time: Wed Aug 6 15:47:28 2008 I was starting to think maybe it needed to be done per library, i.e., separately for gssapi and krb5; cleanup in libgssapi would get rid of that krb5_context. From: To: Time: Wed Aug 6 15:47:51 2008 Is libsmbclient relevant for the symbol list? From: To: Time: Wed Aug 6 15:48:00 2008 It uses some "server" functions. From: To: Time: Wed Aug 6 18:22:02 2008 rev 20625 knocks ~53K off libgssapi_krb5 + libkrb5 + libkrb5support text sections, about 9%. not sure what it'll do to the framework size. (it's maybe 5% off the total text size of all the libraries in the darwin build.) From: To: Time: Thu Aug 7 11:11:42 2008 knocked off a few more k last night, measuring by the linux build. and i've got aclocal.m4 patches to add a configure option to define CONFIG_SMALL and use -Os, when we want to optimize for space. (most of my tests were without -Os, so the numbers may be quite different from the kfm build.) From: To: Time: Thu Aug 7 12:52:47 2008 Oh, wow. The old kadmin/passwd program is even more lame than I thought. There's an old ticket Sam filed suggesting we get rid of it. But the test cases for that program involve things like looking at reports about character classes needed and such, which we don't do elsewhere as far as I know. From: To: Time: Thu Aug 7 12:53:31 2008 Turns out, the kadmin/passwd program fetches the principal record, and looks to see if the policy is set. If so, it fetches the policy record and prints out the info. Then, it asks for a new password. From: To: Time: Thu Aug 7 12:53:46 2008 That's it. It doesn't actually use the new password. No policy enforcement checks, either. From: To: Time: Sun Aug 10 02:02:27 2008 This room is not anonymous. From: To: Time: Mon Aug 11 17:16:49 2008 Should we consider adding null pointer checks to some of our API functions? From: To: Time: Mon Aug 11 17:17:17 2008 There's also an annotation gcc provides for 'argument N must not be null', so the compiler could warn... From: To: Time: Mon Aug 11 19:59:22 2008 Uhh... our KRB5_INT16_MAX/MIN values are wrong; +/- 64K is not right for a signed 16-bit type. Hmm. From: To: Time: Wed Aug 13 18:23:36 2008 Is there any reason to build the PKINIT-related ASN.1 routines if we're not going to build the PKINIT plugin because the configure script can't find a suitable OpenSSL library? From: To: Time: Wed Aug 13 18:53:25 2008 you planning to conditionalize the stuff in lib/krb5/asn.1 based on that? From: To: Time: Wed Aug 13 18:54:44 2008 I was looking at testing a new preprocessor macro, maybe adding a configure option, but then I was wondering if we should still build the ASN.1 bits if the configure option isn't passed but configure decides not to build the plugin anyways. From: To: Time: Wed Aug 13 19:00:02 2008 hard to say, i guess From: To: Time: Wed Aug 13 19:00:30 2008 I'm testing a patch to disable it now. From: To: Time: Wed Aug 13 19:08:05 2008 Hm, there's also some LDAP-related stuff we could punt if not building the LDAP kdb module. From: To: Time: Wed Aug 13 19:23:19 2008 Looks like svn.mit.edu may be offline. From: To: Time: Wed Aug 13 19:24:08 2008 I can reach the router and .0.2 on that net, but not svn.mit.edu. From: To: Time: Wed Aug 13 19:31:55 2008 known issues with w91 switch From: To: Time: Wed Aug 13 19:41:01 2008 Conditionalizing stuff in the accessorr seems like a bad idea because it makes that ABI dependent on the conditions. You should make sure that any conditionalization of the accessor influences the accessor version. Depending on the size is not good enough if you can run into a case for example where base+pkinit has the same size as base+ldap From: To: Time: Wed Aug 13 19:42:04 2008 If you set the functions to null pointers that might be OK From: To: Time: Thu Aug 14 11:59:11 2008 actual approach used was setting to null as far as i can tell from the patch From: To: Time: Thu Aug 14 18:02:54 2008 Yes, it's null pointers. Actually, I'm sort of wondering if the accessor stuff is really a good idea, for ABI-variant reasons. But in theory we could just assert that in 1.7 part of the ABI is that you're supposed to check for null pointers. From: To: Time: Thu Aug 14 18:04:31 2008 Also, using the accessor function in gssapi on the Mac is kind of silly, since it's all bound up in one lib. From: To: Time: Thu Aug 14 18:04:49 2008 s/on the Mac/in KfM/ From: To: Time: Thu Aug 14 18:05:01 2008 (For Darwin builds it still makes sense.) From: To: Time: Fri Aug 15 11:24:40 2008 The gcc folks are doing some interesting stuff relating to code size. There's an option "rtl abstract sequences" that looks for repeated subsequences of RTL (approximately, machine instructions), and generates calls to a single copy, sort of a "reverse inline-functions" option. Too bad it's horribly broken at the moment. :( From: To: Time: Sun Aug 17 02:02:55 2008 This room is not anonymous. From: To: Time: Tue Aug 19 18:41:13 2008 trunk build blows out with unref symbols in the asn1 library From: To: Time: Tue Aug 19 18:41:26 2008 most of them look pkinit-related. building on solaris. From: To: Time: Tue Aug 19 19:09:35 2008 dnl After beta6 this functionality will be integrated with aclocal.m4 From: To: Time: Tue Aug 19 19:09:51 2008 That was in appl/bsd/configure.in. From: To: Time: Tue Aug 19 19:12:40 2008 yes we have cruft in the source tree. From: To: Time: Tue Aug 19 19:34:19 2008 Hmm.. from Schneier's blog: At this moment, Adi Shamir is giving an invited talk at the Crypto 2008 conference about a new type of cryptanalytic attack called "cube attacks." He claims very broad applicability to block ciphers, stream ciphers, hash functions, etc. But supposedly AES is immune. From: To: Time: Tue Aug 19 21:30:00 2008 Ah, apparently other commonly used ciphers, including DES, are safe. I'm curious about the hash function issue though... From: To: Time: Tue Aug 19 21:33:33 2008 And reading some further comments in the blog, it'd only be LFSR-based hash functions. Rather, anything based on a low-degree polynomial equation. LFSRs are used in GSM and Bluetooth, but the algorithms are already known to be weak. From: To: Time: Thu Aug 21 12:44:40 2008 hm it is 75 degrees according to the thermostat in my house and I am enjoying hot tea. brrrrrr From: To: Time: Thu Aug 21 12:45:30 2008 Being sick is annoying From: To: Time: Thu Aug 21 15:01:36 2008 So we are removing the following symbols from the krb5 export list for lite? krb5_cc_get_flags krb5_cksumtype_to_string krb5_enctype_to_string krb5_free_cksumtypes krb5_get_fallback_host_realm krb5_get_init_creds_keytab From: To: Time: Thu Aug 21 15:03:03 2008 And these from gssapi? gss_export_sec_context gss_import_sec_context krb5gss_oid_array From: To: Time: Thu Aug 21 16:31:15 2008 hm. on second thought, try just applying the deletions that were made to libcollected.exports From: To: Time: Thu Aug 21 17:21:58 2008 Oh yay, KIM depends on the keytab functions. whee From: To: Time: Thu Aug 21 17:23:34 2008 Ouch. From: To: Time: Thu Aug 21 18:29:25 2008 I'm going to grab some dinner so I don't feel worse from lack of food. Will try to get this more working tonight From: To: Time: Thu Aug 21 18:37:55 2008 Gee, only 6 people registered for IETF-73 so far. :) From: To: Time: Fri Aug 22 11:50:24 2008 Actual size of the new lite framework is 476K (file size, i386) From: To: Time: Fri Aug 22 12:20:53 2008 We need some kind of "expected failure" handling for our non-dejagnu tests. From: To: Time: Fri Aug 22 13:04:52 2008 krbdev host renaming request is in one of the netops queues. dunno when they will get to it; hopefully in a few days. From: To: Time: Fri Aug 22 15:10:33 2008 so am i right in assuming that having ticket:new in commit logs get transformed to a real ticket number would sufficiently improve people's quality of life that i should see about getting that done before any other RT improvements? From: To: Time: Fri Aug 22 15:13:09 2008 it would certainly be nice for associating logs with tickets From: To: Time: Fri Aug 22 15:13:22 2008 i don't know about 'any other', but it'd be high on my list From: To: Time: Fri Aug 22 15:16:48 2008 some of the changes involve tweaking the svn server software to have scripting bindings (perl or python) so to make it easier to modify svn transactions in-flight. Garry says that ops will probably not get to it until early September. i can work around that but it will be quite irritating because i'd have to call into the svn C API... From: To: Time: Fri Aug 22 15:19:13 2008 What Justin said. I think it could be tough to do if you want to automatically deal with certain failure cases, and I don't necessarily want that to take precedence over other possibly easier things. (E.g., when I'm looking at a ticket with a checkin listed, could there be a hyperlink to view or download the relevant patch? Implemented in a way that's easily updated globally if the fisheye/opengrok/whatever server URL changes, of course.) From: To: Time: Fri Aug 22 15:20:46 2008 If ops probably is going to get to it in September, I think waiting would be reasonable. But lxs may need it more than I do... From: To: Time: Fri Aug 22 15:26:08 2008 I think adding a link to the diff to the ticket may be far easier than adding the ticket to the log From: To: Time: Fri Aug 22 15:26:55 2008 we would have to hack RT to do something like pre-assign a ticket number From: To: Time: Fri Aug 22 15:27:42 2008 It'd be easier, but helps less if you're starting from the log and want to get the ticket. From: To: Time: Fri Aug 22 15:28:21 2008 I think getting "ticket: ###" into the log for new tickets is more useful. From: To: Time: Fri Aug 22 15:29:32 2008 Hm, well, maybe. Depends on your usage. For outside parties wanting to collect some bugfixes via our database, maybe the link from RT to diff would be much more important. From: To: Time: Fri Aug 22 15:31:58 2008 Note that you could search for a ticket that referred to a given log revision. From: To: Time: Fri Aug 22 15:35:04 2008 true, but if you have a lot of logs you're looking through, that gets very cumbersom. From: To: Time: Fri Aug 22 16:18:18 2008 we find having an active link to viewsvn from a ticket to be hugely useful for bug triage and release-management - "is there *really* a test for this? *click* oh, yeah, that seems reasonable", whereas logs of changes usually are self explanatory (by policy) and the link to the bug is more about "oh, yeah, that's why this had some priority". But that's commercial-product workflow... From: To: Time: Fri Aug 22 16:20:18 2008 in our case linking to fisheye might be most useful From: To: Time: Fri Aug 22 17:28:38 2008 i sometimes wonder if we should just make krb5_data use a void* rather than a char* From: To: Time: Fri Aug 22 17:46:16 2008 I've thought about it. I think in all or almost all of the use cases, we have either "character data" or "octets" ("bytes"), though, so all void* gets us is sidestepping the signedness question. And if someone wants to treat some non-char data as a byte array, maybe we should make them jump through some hoops. From: To: Time: Fri Aug 22 17:46:43 2008 But making the compiler shut up about our inconsistent code would be something. From: To: Time: Fri Aug 22 17:46:56 2008 Of course, that's not the same as *fixing* our code... From: To: Time: Fri Aug 22 17:48:46 2008 :) From: To: Time: Fri Aug 22 17:48:57 2008 curing the symptom From: To: Time: Fri Aug 22 17:49:43 2008 the primary problem is that encoded "stuff" is naturally unsigned char, but some of it is conceptually string data on which we might want to use string functions that take char* parameters... From: To: Time: Fri Aug 22 17:50:15 2008 Maybe we want helper functions or macros that do the appropriate translation. From: To: Time: Sun Aug 24 02:02:30 2008 This room is not anonymous. From: To: Time: Mon Aug 25 18:13:01 2008 oh look, there's a const impedance mismatch. i'm not sure it's possible to resolve, actually. From: To: Time: Mon Aug 25 18:18:19 2008 which are you looking at? there are some addressed in lxs's patch... From: To: Time: Mon Aug 25 18:19:49 2008 it's a great effort, but it pushes the impedance mismatch to a slightly different place... From: To: Time: Mon Aug 25 18:19:50 2008 I'm not sure how we should address stuff like set/getspecific. For cases like error messages where we create the thing and pass it to the app, and the app is supposed to pass it back to us to release, I think casting away the const inside our free_foo() routine is probably okay. From: To: Time: Mon Aug 25 18:20:43 2008 is there any reason for the set/getspecific stuff to deal with pointers to const other than the const-ness of the output of error_message? From: To: Time: Mon Aug 25 18:21:32 2008 Probably not. It's internal, so we could just throw away the constness in set/getspecific, and fix the mismatch in the error_message code. From: To: Time: Mon Aug 25 18:22:54 2008 you mean have error_message return a non-const? From: To: Time: Mon Aug 25 18:24:05 2008 No, I mean have the APIs use const when the caller shouldn't be changing things, and if we need to use setspecific/getspecific, cast as necessary in the implementation where we know what's going on. From: To: Time: Mon Aug 25 18:27:19 2008 there are two related issues: APIs returning pointers to const, and APIs taking pointers to const. From: To: Time: Mon Aug 25 18:34:30 2008 hm. tests now fail in some of the libdb2 stuff due to being unable to find the support lib From: To: Time: Mon Aug 25 18:41:14 2008 Weird. Works for me. (linux/x86) From: To: Time: Mon Aug 25 18:42:11 2008 not on solaris From: To: Time: Mon Aug 25 18:44:37 2008 Looking at the command line, I think maybe the library path isn't set right; if you haven't installed the support library, that may be the difference, since I have. From: To: Time: Mon Aug 25 18:46:07 2008 Though i'm not sure why the library shouldbe depending on the support lib. From: To: Time: Mon Aug 25 18:46:45 2008 dunno From: To: Time: Mon Aug 25 18:48:15 2008 libdb depends on the support lib; looking for undefs From: To: Time: Mon Aug 25 18:50:00 2008 ah, krb5int_mkstemp, platform-specific From: To: Time: Mon Aug 25 18:50:19 2008 r19600 | raeburn | 2007-06-19 23:53:37 -0400 (Tue, 19 Jun 2007) | 10 lines From: To: Time: Mon Aug 25 18:51:39 2008 And I probably haven't done check-without-install on Solaris since before that, because it tends not to work for me anyways. From: To: Time: Mon Aug 25 18:53:52 2008 i only see an undef for mkstemp, not krb5int_mkstemp, but that may be due to renaming. From: To: Time: Mon Aug 25 18:54:24 2008 May be buried in one of the headers -- include this header, get some flavor of mkstemp, though you may have to link against the support lib. From: To: Time: Mon Aug 25 19:03:16 2008 % grep mkstemp */*.[ch] btree/bt_open.c:#include "k5-platform.h" /* mkstemp? */ btree/bt_open.c: if ((fd = mkstemp(path)) != -1) % grep -in mkstemp ../../../../include/k5-platform.h 978:#ifndef HAVE_MKSTEMP 979:extern int krb5int_mkstemp(char *); 980:#define mkstemp krb5int_mkstemp From: To: Time: Mon Aug 25 19:14:14 2008 error_message is a public API though isn't it? From: To: Time: Mon Aug 25 19:14:36 2008 Yes. From: To: Time: Mon Aug 25 19:19:09 2008 so, how about we make a header defining macros for "decorators" such as __attribute__((stuff))? it would tidy up the headers somewhat. From: To: Time: Mon Aug 25 19:20:22 2008 Sure, either a new one or in a section of k5-platform.h. From: To: Time: Tue Aug 26 11:44:26 2008 was there a food order? From: To: Time: Tue Aug 26 12:07:13 2008 steve says chinese from royal east From: To: Time: Tue Aug 26 16:44:09 2008 #6096: Another pesky little issue: Stuff in the support library can't use krb5.h or k5-int.h because krb5.h isn't built until after util/et, in the unix build. (That could probably be changed, but it'd take a little build system tweaking.) From: To: Time: Tue Aug 26 16:49:08 2008 what stuff would it need from krb5.h? From: To: Time: Tue Aug 26 16:50:42 2008 k5-int.h declares krb5int_gmt_mktime; the patch added #include k5-int.h to gmt_mktime.c From: To: Time: Tue Aug 26 16:51:07 2008 where does other stuff from the support lib get declared? From: To: Time: Tue Aug 26 16:53:06 2008 fake-addrinfo.h, k5-thread.h, k5-platform.h, k5-err.h... we don't have a general k5-support.h. From: To: Time: Tue Aug 26 16:53:44 2008 We have a k5-util.h, but the existing stuff there (krb5_sete[ug]id macros) is for the appl code. From: To: Time: Tue Aug 26 16:54:34 2008 I suppose this could go into k5-platform.h, but it's not really a platform porting issue. From: To: Time: Tue Aug 26 16:55:14 2008 i think this conundrum is one consequence of monolithic headers... From: To: Time: Tue Aug 26 16:55:49 2008 Actually one big header would make it easy ;-) From: To: Time: Tue Aug 26 16:56:03 2008 it's trying to modularize that means you have to come up with names for things From: To: Time: Tue Aug 26 16:56:15 2008 yeah but the one big header we do have gets built in a really roundabout way From: To: Time: Tue Aug 26 16:56:53 2008 what headers does k5-int.h require? From: To: Time: Tue Aug 26 16:57:12 2008 k5-int.h includes krb5.h From: To: Time: Tue Aug 26 16:57:30 2008 (and probably other stuff, but that's the key problem) From: To: Time: Tue Aug 26 16:58:07 2008 fine. make a k5-gmt_mktime.h and have k5-int.h include it for now. don't install it. From: To: Time: Tue Aug 26 17:00:32 2008 Oh heh I just scrolled up and saw the original problem. Yeah KfM builds all the autogenerated files first before any sources From: To: Time: Tue Aug 26 17:01:08 2008 Which we might want to change to doing for UNIX... From: To: Time: Tue Aug 26 17:02:06 2008 Using the in-tree compile_et might make it a little clunky, but then we control the makefile for it, so we can make sure that compile_et can be built without building the library.... From: To: Time: Tue Aug 26 17:24:00 2008 Were we going to hold off on the set/getspecific const changes, or put them in? (And the wrapper function idea?) From: To: Time: Tue Aug 26 17:24:26 2008 hold off on pointer-to-const changes for now From: To: Time: Tue Aug 26 17:25:14 2008 Okay. And the wrappers too? From: To: Time: Tue Aug 26 17:28:03 2008 wrappers were not in original patch, right? From: To: Time: Tue Aug 26 17:28:13 2008 Right, separate idea. From: To: Time: Tue Aug 26 17:28:24 2008 But easy enough to add. From: To: Time: Tue Aug 26 17:29:31 2008 (as a separate piece of work, not integrating this patch) From: To: Time: Wed Aug 27 11:46:42 2008 *sigh* switching to the g5 certainly hasn't eliminated the need to sit and wait while stuff gets paged in. From: To: Time: Wed Aug 27 12:04:57 2008 Does anonsvn serve the krb5 repository off of a local disk copy of the repository or off an AFS copy? And (the real question), does the name imply that the team might be willing to serve another repository for anonymous access from that machine? From: To: Time: Wed Aug 27 12:05:25 2008 AFS, I believe. From: To: Time: Wed Aug 27 12:06:32 2008 (/mit/krbdev/svn/krb5/...) From: To: Time: Wed Aug 27 12:07:35 2008 answer to (2) is probably "no", depending on whose repository. if other ISDA or IS&T folk want this sort of service, i think we should operationalize it through ops. From: To: Time: Wed Aug 27 12:07:50 2008 As for serving up a second repository, I think it'd be Tom's call, but IMNSHO ops should be pushed into doing this if more teams want it... From: To: Time: Wed Aug 27 12:08:12 2008 Okay, thanks. From: To: Time: Wed Aug 27 12:08:14 2008 in practice i suspect if we ask Garry he'll do it, and we'd have one fewer service to maintain internally From: To: Time: Wed Aug 27 12:10:06 2008 There is a plan to make drugstore do anonymous svn as well as what it currently does, but the resourcing has disappeared. (Partly me, partly ops has been busy.) From: To: Time: Wed Aug 27 12:10:35 2008 when there used to be an anoncvs, it was running on a separate host from drugstore. From: To: Time: Sun Aug 31 02:02:31 2008 This room is not anonymous. From: To: Time: Tue Sep 2 18:30:13 2008 i changed the subject on #5947 because it was being a pain to search for From: To: Time: Wed Sep 3 15:44:44 2008 Ah, from Love's test I see what's going on, I think -- they're supplying minor status code 19777 and "just know" that it's supposed to be a certain error. But it was never returned by any of the GSSAPI routines. That was never part of the error-mapping design. From: To: Time: Wed Sep 3 17:05:23 2008 So I guess an obvious question would be if we want to extend the error code mapping to support what Love's doing in his test case. I think there may be some issues about the behavior to work out. Like, if I call display_status on a mech oid and minor status, should that call still give the same result again later if, in the meantime, I invoke another mechanism that wants to use the same status code? That'd mean putting a table entry in so that the other mechanism's status code would have to get mapped to something else. But what if I call display_status on a minor status value with two different mech oids? Should either end up in the table? (Currently the "application-visible status code" side of the mapping is only the status code, no oid.) From: To: Time: Wed Sep 3 17:05:59 2008 Simpler would be to say it's not supported, or that we'll pass the call through (per Love's patch) but the behavior can change over the life of the process if another mech reuses the value. From: To: Time: Wed Sep 3 17:06:12 2008 s/it's not supported/it won't work/ From: To: Time: Wed Sep 3 19:36:34 2008 We really should catch up on Nalin's patches at some point. From: To: Time: Wed Sep 3 19:38:12 2008 Hm, jis story hour for the froshlings is in ~20 min. I wonder if there'll be anything I haven't already heard. From: To: Time: Wed Sep 3 20:26:07 2008 realloc inside a loop, or loop-count/malloc/loop-write? From: To: Time: Wed Sep 3 20:27:58 2008 how expensive is the loop? From: To: Time: Wed Sep 3 20:29:19 2008 not very, but i like to avoid code duplication From: To: Time: Wed Sep 3 20:32:22 2008 Then go ahead and realloc. If it's a performance issue we can change it later. From: To: Time: Wed Sep 3 20:33:25 2008 if the realloc turns out to be a problem, i can run the loop twice by putting it in an aux function and passing a count-vs-write flag. From: To: Time: Wed Sep 3 20:34:44 2008 Yup. From: To: Time: Wed Sep 3 20:35:33 2008 main downside with realloc-in-loop is that it requires replacing walking-pointer idiom with array indexing. From: To: Time: Wed Sep 3 20:36:45 2008 That's what the array::append() method is for. Oh, wait. From: To: Time: Thu Sep 4 13:13:54 2008 Oh, great... I forgot some mech-specific minor status codes are part of the spec. So I'd say that yes, passing gss_display_status the krb5 mech oid and GSS_KRB5_S_G_NOUSER should work, even if it wasn't returned from a gssapi call. The only wiggle room I see is that "Each implementation should make available, though include files or other means, a facility to translate these symbolic names into the concrete values which a particular GSS-API implementation uses to represent the minor_status values specified in this section." That *doesn't* mean we have to have preprocessor macros expanding to numeric constants. From: To: Time: Thu Sep 4 13:16:43 2008 Sure; that text implies you could have a get_minor_status_value and expect people to call it to get the numeric values they're looking for. But if you did that, no code that expects to compare to preprocessor constants would compile, and lots of people would hate you. I suspect it's wiggle room intended to allow an enum instead of macros From: To: Time: Thu Sep 4 13:16:53 2008 Of course, this is also the mechanism spec that lets you select between partial-md5(text), des-mac(md5(text)), and des-mac(text) for your integrity protection. Bleah. From: To: Time: Thu Sep 4 13:18:51 2008 Yeah, but it doesn't work so well for a mechglue layer that has to cope with (a) applications not being able to know where a status code was generated and thus not always being able to come up with the right mech oid, and (b) multiple mech implementations that may choose conflicting values for their "public" status codes. (a) sort of implies ignoring the supplied mech oid in display_status, and keeping track internally... From: To: Time: Thu Sep 4 13:19:48 2008 And the general sloppiness in these specs doesn't help much. Like gss_create_empty_oid_set returning a "mechanism specific status code", when there's no specific mechanism choice anywhere in sight. From: To: Time: Thu Sep 4 13:25:38 2008 Oh, if you don't know what mechanism owns a minor_status, you are screwed. Admittedly, the spec doesn't do very well at allowing for mechglues to return their own minor_status values in addition to those of the underlying mech, but I think any code-remapping is doomed to fail. From: To: Time: Thu Sep 4 13:26:04 2008 Well, you know, these specs suck. Anyway, I'm off to a meeting. From: To: Time: Thu Sep 4 13:26:23 2008 I forget the exact cases -- if it was some of the importing functions, or spnego, or mechglue -- but I'm pretty sure there are cases where the application cannot know what mechanism owns a status code. From: To: Time: Thu Sep 4 13:26:53 2008 And yes, we're doing code remapping. :( From: To: Time: Thu Sep 4 13:31:21 2008 I wonder if it would work to define GSS_KRB5_G_S_WHATEVER to gssint_map_status_code(krb5 mech oid, 12345)... preprocessor conditional evaluation would fail, and it wouldn't work in case statements or static initializers, but non-constant expression evaluation would work, and we still get the mappings. Of course, that could be considered an ABI change. From: To: Time: Thu Sep 4 13:33:45 2008 Maybe the mechglue interface should register the status codes that need to be mapped directly for the mechanism. Then we just reuse them in the mapping. In the case of conflict, have display_status prefer the passed-in mech if it's one of the ones listing that status code, ignore it otherwise. And if a reused status code gets returned from a call where the application can't tell, oh well, we just lose. From: To: Time: Thu Sep 4 15:21:10 2008 Aahhh... the SPKM mechanism spec dictates whether bits 30 and 31 of the minor status code are set or clear for various classes of codes. From: To: Time: Thu Sep 4 17:59:54 2008 > I wonder if it would work to define GSS_KRB5_G_S_WHATEVER to... That seems reasonable, as long as the code does not change over the life of the process. Even #ifdef would work. I agree it would be an ABI change, if the values it returns are not constant. From: To: Time: Thu Sep 4 18:21:14 2008 For it not to be an incompatible ABI change, they'd not just have to be constant, but the same values as were in the headers before. And I doubt people would like the API change (inability to use "case GSS_WHATEVER:"), but maybe it wouldn't be too bad. From: To: Time: Thu Sep 4 18:30:05 2008 Writing up some email to kitten to ask if anyone's tackled this problem already... From: To: Time: Sun Sep 7 02:02:30 2008 This room is not anonymous. From: To: Time: Mon Sep 8 14:13:12 2008 Weird. I'm getting Could not create xauth directory /tmp/xauth-raeburn-11775: File exists Disabling X forwarding. from svn.mit.edu. Even when I'm not trying to forward X11 connections. From: To: Time: Mon Sep 8 14:15:24 2008 i'm not getting anything like that. From: To: Time: Mon Sep 8 14:17:31 2008 Well, it's user-specific, and I did try mirroring the entire repository with svk recently, with I guess an ssh connection per revision or something, so it's way more likely for me. But I don't think the server end should be trying to do any xauth stuff. From: To: Time: Mon Sep 8 14:18:05 2008 are you sure that X forwarding is disabled? From: To: Time: Mon Sep 8 14:19:37 2008 It's not specifically disabled in my config here, and I haven't tried "-v", but it ought to be disabled by default. But from home over the weekend, yes, it's disabled, and "-v" shows some extra output if I do try forwarding X connections, and the xauth problem is reported whether or not I'm forwarding. From: To: Time: Mon Sep 8 14:23:43 2008 In /tmp I find: 117 xauth-athenasnap-# 164 xauth-obrown-# 170 xauth-stellarcvs-# 1347 xauth-isdasnap-# 24348 xauth-raeburn-# ... and only a couple for you, Tom. From: To: Time: Mon Sep 8 14:24:24 2008 dated when? From: To: Time: Mon Sep 8 14:25:24 2008 Cleanup of ccache files is a little better, though: 1 krb5cc_13334 1 krb5cc_52343 1 krb5cc_72763 57195 krb5cc_7882 (That's the complete list.) From: To: Time: Mon Sep 8 14:28:16 2008 So I have a function (error_message) which I don't want to call itself. However because of code reuse, it now calls a bunch of functions which may call it. Rather than special casing the code paths it uses (which seems fragile), I'd like it to detect it is being called from inside itself in a thread. What mechanism should I use? My two options seem to be a thread-specific variable saying whether or not we are currently in the function or depending on the fact that k5_mutex_lock returns an error if called on a locked mutex. (the mutexes are already used by the function but I don't know if I shouldn't just have an additional bit of thread-specific data to avoid reentry) From: To: Time: Mon Sep 8 14:28:18 2008 I assume cleanup happens after a couple of days or something. Your xauth directories are dated today, for example, and are empty. The oldest stuff there is xauth directories and goes back to 04:33 on the 6th. From: To: Time: Mon Sep 8 14:29:50 2008 i would not assume that attempting to lock a mutex twice in the same thread will return an error. From: To: Time: Mon Sep 8 14:29:51 2008 Don't rely on k5_mutex_lock detecting recursion. With the debug code, it would've aborted; now, it depends on the platform. Besides, a mutex would prevent different threads from using it at once. The thread-specific variable sounds reasonable. From: To: Time: Mon Sep 8 14:30:41 2008 yeah I just noticed that the mutex seemed to work now. I was suspicious that it wouldn't be good to depend on it though, I will use the thread-specific data From: To: Time: Mon Sep 8 14:31:09 2008 yeah, posix guarantees very little about mutex error handling in the default mutex attributes case. From: To: Time: Mon Sep 8 14:31:25 2008 Basically I'm trying to have one place in the code where we look up bundle strings. However the best place to put that code is in KIM and the KIM versions of those functions call error_message on error ;-) From: To: Time: Mon Sep 8 14:34:49 2008 I'm just going to shove a static string in the com_err library to the effect of "Cannot generate error string. Re-entered error_message". The only thing that should ever see it is if you are looking up a localized error string and the bundle lookup calls fail. Even then it will only appear in the debugging log because the call to error_message inside KIM is for the debug logging From: To: Time: Mon Sep 8 14:36:30 2008 hm, ok. i guess it won't be localized, then? or will it use system localization? From: To: Time: Mon Sep 8 14:39:18 2008 It won't be localized From: To: Time: Mon Sep 8 14:40:30 2008 One icky thing I just realized about using the keys as the English strings is that we'll have to make sure that all our source files use a specific encoding in case people want to use strings with non-ASCII characters. From: To: Time: Mon Sep 8 14:41:54 2008 At the moment I'm pretty sure all the krb5-tree sources are ASCII only. Maybe a few control characters like ^L but nothing > 127. From: To: Time: Mon Sep 8 14:42:02 2008 (This might be a problem for source files which are currently using the copyright symbol or whose authors have non-ASCII characters in their names) From: To: Time: Mon Sep 8 14:42:44 2008 I don't think we do either in krb5. Possibly for author names in comments, but I don't recall seeing any such cases. Dunno about the kfm tree though. From: To: Time: Mon Sep 8 14:42:52 2008 I'm pretty sure KfM developers are responsible for the MacRoman © symbols. From: To: Time: Mon Sep 8 14:48:05 2008 in leopard annoyances news, i am having trouble setting up keyboard-triggered screensaver activation. From: To: Time: Mon Sep 8 14:48:51 2008 specifically, it seems that i can have two copies running at once, and somehow that causes coreservicesd to leak lots (gigabytes) of memory. From: To: Time: Mon Sep 8 14:50:08 2008 how are you doing it via keyboard? From: To: Time: Mon Sep 8 14:51:32 2008 used to use quicksliver to trigger an applescript that was basically 'activate application "ScreenSaverEngine"', but after reading that people were having trouble with that, switched to using quicksilver to run an automator app that used the automator action. both cause double screensaver activations when the timeout-based screensaver kicks in. From: To: Time: Mon Sep 8 14:53:11 2008 this seems to be a solution that works http://www.allyourpixel.com/post/screen-saver-function-key/ From: To: Time: Mon Sep 8 14:54:43 2008 hm, source code would be nice :-) From: To: Time: Mon Sep 8 14:55:13 2008 source code: http://forums.macosxhints.com/archive/index.php/t-30968.html From: To: Time: Mon Sep 8 14:55:18 2008 4th comment From: To: Time: Mon Sep 8 14:55:28 2008 thanks, found it :-) From: To: Time: Mon Sep 8 14:56:18 2008 so what does it do, declare a bunch of private interfaces of ScreenSaver.framework? From: To: Time: Mon Sep 8 14:56:34 2008 looks that way From: To: Time: Mon Sep 8 15:49:26 2008 hm, our usual order is like 4 large pizzas and i think there are only going to be 5 of us tomorrow. should i drop the margarita or the shrimp? From: To: Time: Mon Sep 8 15:49:46 2008 shrimp From: To: Time: Mon Sep 8 15:51:11 2008 who was the shrimp fan? i'm not remembering. From: To: Time: Mon Sep 8 15:51:29 2008 steve and kevin, i think From: To: Time: Mon Sep 8 15:51:34 2008 and sam to a lesser extent From: To: Time: Mon Sep 8 15:51:41 2008 ah ok. From: To: Time: Mon Sep 8 17:30:01 2008 Hm, I don't think we have any programs that test the setpw routines. That makes changing the asn.1 encoding function a little riskier. :) From: To: Time: Mon Sep 8 18:05:06 2008 Oh. No wonder. I don't think we have the server-side setpw support. From: To: Time: Thu Sep 11 16:31:13 2008 Heading out to take my car to the garage. Should be online later. I'm planning to get in late tomorrow, after the md6 talk at csail. From: To: Time: Sun Sep 14 02:02:33 2008 This room is not anonymous. From: To: Time: Mon Sep 15 12:56:26 2008 did our repeating meeting for the apple conference call stop repeating after last week? From: To: Time: Mon Sep 15 12:57:35 2008 looks like From: To: Time: Mon Sep 15 13:13:23 2008 so if the MS call ends up being 13:30, we can't get 212 straight through 13:30-15:00, which is somewhat less convenient. From: To: Time: Mon Sep 15 13:15:28 2008 So we're done talking to Apple? :) From: To: Time: Mon Sep 15 13:16:08 2008 no, we just don't have the room booked :-) From: To: Time: Mon Sep 15 13:16:53 2008 and really, i'd like a somewhat less reverberant room than 212 for the Apple call. From: To: Time: Mon Sep 15 13:20:56 2008 Helpdesk just asked me to fill in a survey to give feedback on their performance in handling my techtime problem. "You took almost a week to get back to me, and then I figured it out myself" isn't going to look too good. From: To: Time: Mon Sep 15 13:21:25 2008 oh well From: To: Time: Mon Sep 15 13:21:46 2008 anyway has anyone had meetings in 240 (Riverside)? how is the space? From: To: Time: Mon Sep 15 13:22:35 2008 (In case anyone cares, the mac Migration Assistant doesn't seem to copy Kerberos Extras when you copy applications and accounts and stuff across machines; Oracle Calendar doesn't warn you when you have gssapi authentication selected but no Kerberos Extras installed, it just fails; and the TechTime installer doesn't check for Kerberos Extras.) From: To: Time: Mon Sep 15 13:23:39 2008 (And Oracle Calendar fails with a bogus error message that suggests you got the hostname wrong, not the authentication type.) From: To: Time: Mon Sep 15 13:37:07 2008 riverside is the tiny closet upstairs, no? From: To: Time: Mon Sep 15 13:39:22 2008 not much smaller than 212. it's 278 "North Station" that is the awkwardly shaped one at the rear of the building. From: To: Time: Mon Sep 15 13:41:46 2008 240 seems to be in the middle of the floor, and about the same size as 212. From: To: Time: Mon Sep 15 13:41:53 2008 (https://facilities-db.mit.edu/pdfs/W92_2.pdf) From: To: Time: Mon Sep 15 15:35:14 2008 food preferences/anti-preferences for tomorrow's meeting? i'm likely to default to Bertucci's again. From: To: Time: Mon Sep 15 15:35:40 2008 i ask for something other than pizza From: To: Time: Mon Sep 15 15:36:04 2008 ok From: To: Time: Mon Sep 15 15:37:33 2008 other default seems to be kiraz, i'd be fine with that again. From: To: Time: Mon Sep 15 15:57:22 2008 no objections to kiraz? From: To: Time: Mon Sep 15 16:48:41 2008 belately (was at MIT Medical) Kiraz is fine with me From: To: Time: Mon Sep 15 17:45:07 2008 RT migration in progress. you may feel a disturbance in the force. From: To: Time: Mon Sep 15 17:48:58 2008 commit handler disabled for now From: To: Time: Mon Sep 15 18:20:00 2008 web interface online, but please don't make changes yet. From: To: Time: Mon Sep 15 19:25:56 2008 ok, now mostly up. dns may take a while to propagate, or you can thwack your local cache if you like. From: To: Time: Mon Sep 15 19:27:13 2008 Hm, other web stuff didn't move over? http://krbdev.mit.edu/nightly/ no longer works. From: To: Time: Mon Sep 15 19:29:27 2008 haven't transferred it. what is needed to migrate it? From: To: Time: Mon Sep 15 19:30:40 2008 Just copy the tree, preserving ownership. I may need to do a little more to update it again, but just copying will get the current data visible again. From: To: Time: Mon Sep 15 19:31:01 2008 who currently depends on this? From: To: Time: Mon Sep 15 19:31:45 2008 Anyone who wants to see how well our builds are working. Quite possibly no one but me, given that it's not automated and only updates when I remember to do it. From: To: Time: Mon Sep 15 19:46:54 2008 can it wait until tomorrow? From: To: Time: Mon Sep 15 19:51:27 2008 Yeah, easily. From: To: Time: Tue Sep 16 15:27:53 2008 ok, bumped DBIx::SearchBuilder to a more recent version. hopefully that works out better. searches on requestor address work now. From: To: Time: Tue Sep 16 16:19:46 2008 the searching on multiple "ticket content matches" criteria still fails, but that was true before as well. From: To: Time: Tue Sep 16 17:08:11 2008 oh right, must remember to change the hostname in all the right places. GSS logins to krbdev-old should work now. From: To: Time: Tue Sep 16 18:55:00 2008 btw, nightly stuff is copied. ownerships did not get preserved for some reason, perhaps due to lack of raeburn's uid on the target machine. From: To: Time: Tue Sep 16 18:58:01 2008 That'd probably do it. It'll stop me from updating, too. :) Until I go fix it. From: To: Time: Tue Sep 16 20:15:21 2008 So weird... in tcl, unset isn't removing environment variables; it's changing them to have empty values. And our code doesn't like having KRB5CCNAME set to "". I wonder why it didn't blow up on me before. From: To: Time: Wed Sep 17 10:27:22 2008 that is not what i see, from experimenting with tcl8.4 From: To: Time: Wed Sep 17 11:10:48 2008 I see it in 8.4 on my mac laptop. (Correction from our earlier conversation: This build tree is testing Love's IP_RECVDSTADDR patch, and I probably haven't run this test on my laptop in at least a week.) However, on Linux it works fine, in 8.4. From: To: Time: Wed Sep 17 11:11:49 2008 I run in tclsh: array names env unset env(MANPATH) array names env ... and MANPATH is listed both before and after, on the Mac, and only before, on Linux. From: To: Time: Wed Sep 17 11:13:01 2008 is the unsetenv libc function broken on the Mac? From: To: Time: Wed Sep 17 11:13:29 2008 No idea, maybe. From: To: Time: Wed Sep 17 11:14:23 2008 Er... it also occurs to me that, because of the rpc test lossage on the mac, maybe it's been even longer since I've run that test. (I often do "make check", it blows out in RPC because the server couldn't register itself, and then I run "make -C tests/dejagnu check"... oops.) From: To: Time: Wed Sep 17 11:15:24 2008 nope, just ran the kadmin tests (where this is blowing up on the laptop) on my desktop in my asn.1 hacking tree, and they ran fine. From: To: Time: Wed Sep 17 11:35:18 2008 running fine on your desktop mac? From: To: Time: Wed Sep 17 11:36:27 2008 The dejagnu test ran fine on the desktop mac. But testing with tclsh showed the problem. From: To: Time: Wed Sep 17 11:38:52 2008 interesting. From: To: Time: Wed Sep 17 11:39:02 2008 Annoying. :) From: To: Time: Wed Sep 17 11:41:05 2008 interestingly enough, tclsh8.4 from pkgsrc built on a mac doesn't show that problem, but /usr/bin/tclsh8.4 does. From: To: Time: Wed Sep 17 11:43:04 2008 Ooh... I wonder if there's something weird in how I'm getting tcl/expect in some of these cases. From: To: Time: Wed Sep 17 11:44:36 2008 On both machines (the Macs), the only version of expect I have is in /usr/bin. So I don't see why this would ever succeed... From: To: Time: Wed Sep 17 11:51:07 2008 Note to self: Never add a spam filtering 'hold' rule that matches the administrative messages the server sends out. From: To: Time: Wed Sep 17 11:52:12 2008 Not all of the 2000+ messages in the krb5-bugs-incoming queue are because of this little mistake, but most of them are. From: To: Time: Wed Sep 17 11:55:22 2008 ouch. which rule was that? and what messages? From: To: Time: Wed Sep 17 11:55:46 2008 btw, did people register for codeplex accounts? From: To: Time: Wed Sep 17 11:55:54 2008 I registered. From: To: Time: Wed Sep 17 11:59:39 2008 I'd been experimenting with patterns to match the bogus subjects that show up as "????? ???????? ???30???" etc. Patterns to match subject lines containing no letters, along the lines of "subject: [^a-zA-Z ]*[\n\r] weren't working, and I made the mistake of testing a pattern that didn't look for end-of-line, and the "*" would match a zero-length start-of-subject string obviously. And then when the moderation notification went out, that apparently gets run through the filters too; there's a filter to approve x-list-administrivia (where "approve" at this stage means it goes on to the rest of the mailman processing) but apparently that wasn't good enough. From: To: Time: Wed Sep 17 12:00:43 2008 Matching a single non-alphabetic character at the start of the subject might've been better... From: To: Time: Wed Sep 17 12:02:06 2008 From what I've read, the version of mailman we're running is just *before* the changes necessary for "^" and "$" to work in the spam filter rules. So you have to check for the line breaks, and offhand I don't know if that's \n or \r\n or what. From: To: Time: Wed Sep 17 12:06:29 2008 Hm. CMU finally mentioned to me that we joined the consortium From: To: Time: Wed Sep 17 15:02:12 2008 are people here interested in clicky IBM-style keyboards? From: To: Time: Wed Sep 17 15:04:05 2008 I am, if no one else wants them. From: To: Time: Wed Sep 17 15:10:53 2008 i found the manufacturer who makes new clicky keyboards to the old IBM design. From: To: Time: Wed Sep 17 15:11:18 2008 Oh, new ones? With or without windows keys? From: To: Time: Wed Sep 17 15:11:23 2008 yes From: To: Time: Wed Sep 17 15:11:34 2008 http://pckeyboards.stores.yahoo.net/ From: To: Time: Wed Sep 17 15:12:42 2008 pricey, though (compared to swapfest :-) The "linux" layout is cute From: To: Time: Wed Sep 17 15:12:49 2008 I think I found them at least once before. I'm an avid Model-M user. From: To: Time: Wed Sep 17 15:15:46 2008 (they also don't make one like the Type M Compact.) http://clickykeyboards.com/ is a good source of vintage ones... From: To: Time: Wed Sep 17 15:17:37 2008 I don't understand. Why is putting the esc key in the wrong place "linux"? From: To: Time: Wed Sep 17 15:18:45 2008 Also, they seemed to get that the key to the left of the 'a' should be control, but failed to understand that the key at the lower left should _also_ be control, and "caps lock" has no place anywhere near a keyboard From: To: Time: Wed Sep 17 15:19:01 2008 esc key location better for vi users maybe? From: To: Time: Wed Sep 17 15:19:17 2008 I use vi extensively. esc should be the upper-left-most key, so it is easy to find. From: To: Time: Wed Sep 17 15:19:43 2008 maybe some people like it better nearer to home row. From: To: Time: Wed Sep 17 15:20:05 2008 maybe, but (a) those people are Wrong(tm) (b) why is that "linux" ? From: To: Time: Wed Sep 17 15:22:08 2008 someday I want one of these http://www.clickykeyboards.com/index.cfm/fa/categories.main/parentcat/12675 but they only show up rarely and get auction prices From: To: Time: Wed Sep 17 16:39:09 2008 hm, the codeplex repository for gssmonger appears to not have trunk or branches From: To: Time: Wed Sep 17 17:22:04 2008 Um, I think I was mistaken earlier. My desktop mac test was in a window remotely logged in to linux. Testing on the mac blows out in the kadmin/passwd tests, same as on the laptop. At least it's consistent... From: To: Time: Wed Sep 17 17:24:14 2008 Re: gettes's email, and the chat rooms being deprecated: When were they announced? From: To: Time: Wed Sep 17 17:30:13 2008 i'm not sure when they were announced. they may not have been announced to isda at large. From: To: Time: Thu Sep 18 11:11:15 2008 I've been thinking about some ways of dealing with the mac tcl problem: 1) make the dejagnu tests check if unset worked, skip some tests if not 2) in libkrb5 treat KRB5CCNAME="" same as unset 3) treat KRB5CCNAME="" as default type, make cc_file treat empty filename specially (except the FILE:/tmp/krb5cc_%d default isn't implemented at that layer) Any thoughts? From: To: Time: Thu Sep 18 11:29:18 2008 Testing with the default ccache name seems to be part of the plan, specifically. They set KRB5CCNAME in places and unset it in others. But maybe that's not too important and I can just change it... From: To: Time: Fri Sep 19 11:38:04 2008 Am I confused or are there multithreading issues with the global variable that stores the plugin data for the authdata and preauth plugins? From: To: Time: Fri Sep 19 11:38:38 2008 load_preauth_plugins () and load_authdata_plugins() are the functions that have these globals From: To: Time: Fri Sep 19 11:44:11 2008 hmmm From: To: Time: Fri Sep 19 11:45:07 2008 Oh, this is in the KDC? From: To: Time: Fri Sep 19 11:45:41 2008 oh yeah they are. I guess the KDC isn't multithreaded yet From: To: Time: Fri Sep 19 11:45:42 2008 Yeah, there would be multithreading issues, if/when we make the KDC multithreaded. From: To: Time: Fri Sep 19 13:59:17 2008 heh. Nico's most recent krbdev posting got flagged as spam for no discernible reason. From: To: Time: Sun Sep 21 02:02:40 2008 This room is not anonymous. From: To: Time: Mon Sep 22 10:53:17 2008 Running a little late... heading in now From: To: Time: Mon Sep 22 16:33:31 2008 food? From: To: Time: Mon Sep 22 16:35:54 2008 for tomorrow? already ordered. hana sushi. From: To: Time: Mon Sep 22 16:36:02 2008 ok From: To: Time: Sun Sep 28 02:02:27 2008 This room is not anonymous. From: To: Time: Mon Sep 29 15:28:23 2008 preferences for lunch? From: To: Time: Mon Sep 29 15:29:52 2008 not pizza From: To: Time: Mon Sep 29 15:31:09 2008 how about mixmenu->royal east? From: To: Time: Mon Sep 29 15:34:20 2008 or lucky garden From: To: Time: Mon Sep 29 15:34:42 2008 passage to india? From: To: Time: Mon Sep 29 15:36:19 2008 is that where we got the indian food from last time? From: To: Time: Mon Sep 29 15:36:40 2008 don't recall From: To: Time: Mon Sep 29 15:37:19 2008 have an appt across campus; back later From: To: Time: Mon Sep 29 16:43:59 2008 so are we getting some lunch tomorrow, or what? :) From: To: Time: Mon Sep 29 16:54:35 2008 probably chinese From: To: Time: Mon Sep 29 16:57:04 2008 which place? From: To: Time: Mon Sep 29 17:02:06 2008 royal east. i need to ask steve to set up the order because he is the keeper of the mixmenu account. From: To: Time: Mon Sep 29 17:37:21 2008 Oh, hey, I am a vested stakeholder in this now. From: To: Time: Mon Sep 29 17:39:15 2008 Do people send in individual orders or do you just order a bunch of stuff? From: To: Time: Mon Sep 29 17:40:42 2008 Depends. For some places like cafe kiraz I think it's all individual orders. For Bertucci's it's a group order. And who collects the individual orders varies; sometimes Steve, sometimes Bryan. From: To: Time: Mon Sep 29 17:41:29 2008 It's not at all clear to me which way it'll happen for tomorrow's order. From: To: Time: Mon Sep 29 17:41:56 2008 Okay, thanks. From: To: Time: Mon Sep 29 19:42:59 2008 > Oh, hey, I am a vested stakeholder in this now. you are? From: To: Time: Mon Sep 29 20:17:27 2008 Yes, I'm on the Kerberos team as of this week. From: To: Time: Tue Sep 30 13:25:51 2008 interrupting one another is a lot harder in a phone conference :) From: To: Time: Tue Sep 30 13:26:13 2008 yeah From: To: Time: Tue Sep 30 14:01:53 2008 I don't want to have to wait for a full make check for every commit. So, I agree with the goal, but not really automated enforcement. From: To: Time: Tue Sep 30 14:03:44 2008 Continuous testing would be a good thing. I think there are probably packages out there that'll even try to track down which checkin broke things and yell at you. From: To: Time: Tue Sep 30 14:04:13 2008 CruiseControl is the classic (but it's java), that integrates well with svn From: To: Time: Tue Sep 30 14:04:48 2008 (the "track down" part is simpler than that - it just yells at everyone who committed between the last run and the current) From: To: Time: Tue Sep 30 14:05:21 2008 We do nominally have nightly test runs. Continuous would in fact be better From: To: Time: Tue Sep 30 14:06:13 2008 git and hg do actually have the track down where foo broke option. It's not particularly VC specific, so obviously if you wanted to implement it for svn you could From: To: Time: Tue Sep 30 14:10:37 2008 The nightly test runs tend to get ignored. I'd happily put time into improving it, or spewing thoughts at someone else to improve it, but it's never been high enough on our priority list. From: To: Time: Tue Sep 30 14:12:31 2008 we actually do tiered tests - there's a fast run that operates on any change that is supposed to take about 30 minutes and cover a lot of things; there's a set of one-hour tests that get picked from if there have been no commits in over an hour; then there's a "long" tests (2-8 hours) that gets run if there have been no commits in 6 hours or so. From: To: Time: Tue Sep 30 14:13:04 2008 and yes, repeated unfixed failures prevent people from caring, don't do that :-) From: To: Time: Tue Sep 30 14:14:27 2008 Yeah, we were discussing in a phone conference an unfixed failure I'd checked in (since tweaked to ignore the exit status). We don't really have a way to handle expected failures generally. From: To: Time: Tue Sep 30 14:15:36 2008 for "git bisect" to be useful you have to have a strong expectation of consistency (ie. that most builds other than the specific failure you're testing actually work.) but really, if you need to run it, your smoke-tests are too expensive :-) From: To: Time: Tue Sep 30 14:15:46 2008 If we cleaned up our test suite a bit, it wouldn't take horrendously long to run, but using a pass per enctype configuration whether or not the multiple passes make sense for a given test is really wasteful. From: To: Time: Tue Sep 30 14:16:32 2008 Running tests in parallel would kinda be nice too. *sigh* From: To: Time: Tue Sep 30 14:18:23 2008 well, you can certainly run a continuous builder on each architecture you care about From: To: Time: Tue Sep 30 14:18:56 2008 (s/builder/tester but of course you need the builder to feed the tester :-) From: To: Time: Tue Sep 30 14:18:58 2008 I was thinking of looking at buildbot; have you looked at it before? From: To: Time: Tue Sep 30 14:20:44 2008 I think buildbot is more recent than the stuff we cooked up by hand (CruiseControl is where we stole most of the ideas from.) but it has *nice* visual reporting, if you're into that. From: To: Time: Tue Sep 30 14:21:59 2008 (I'd definitely look at buildbot before writing stuff from scratch, today) From: To: Time: Tue Sep 30 14:22:48 2008 (and it looks like it had solaris and osx versions, which might cover enough of what you care about, and is actively maintained...) From: To: Time: Tue Sep 30 14:24:22 2008 We may even be able to get some Windows support. Much of our test suite wouldn't work, but some stuff would, and we could at least ensure that builds work. From: To: Time: Tue Sep 30 14:27:00 2008 It looks like it has the unfortunate drawback of all slaves being driven by a master, so the master has to be always running and have network connectivity etc, or testing may temporarily stop. But I may be wrong. And even if that's the case, we just set up a master at MIT and we'll be fine most of the time. From: To: Time: Wed Oct 1 13:01:35 2008 Do we have a depot for patches other than RT? From: To: Time: Wed Oct 1 13:02:36 2008 Not currently. Well, occasionally someone will create a branch and stuff a patch there. From: To: Time: Wed Oct 1 13:03:55 2008 Security patches are handled specially as well. From: To: Time: Wed Oct 1 13:04:19 2008 True. From: To: Time: Wed Oct 1 13:04:53 2008 No specific place for security patches, just "not any place public until we're ready". From: To: Time: Wed Oct 1 13:05:13 2008 Okay. At the meeting yesterday it was suggested that I review a zeroconf patch. Does anyone have a pointer to that? From: To: Time: Wed Oct 1 13:07:11 2008 Ticket 6031 has the patch I've got in mind. It's not about figuring out the local realm, but about better heuristics for hostname->realm mapping. From: To: Time: Wed Oct 1 13:11:33 2008 Hm, it looks sketchy. From: To: Time: Wed Oct 1 13:12:01 2008 (Specifically, in the way it does DNS resolution.) From: To: Time: Wed Oct 1 13:12:56 2008 "handling encrypted transactions" might be an interesting pony for an RT upgrade. From: To: Time: Wed Oct 1 13:13:01 2008 Is this model compatible with the Sun model or something else? From: To: Time: Wed Oct 1 13:13:41 2008 The patch is from Sun. From: To: Time: Wed Oct 1 13:15:25 2008 Basically, walk the parent chain of the hostname until you hit two labels. At each step, uppercase the DNS name and attempt a realm lookup. From: To: Time: Wed Oct 1 13:16:18 2008 The heuristic looks okay, I think, if decoupled from DNS. From: To: Time: Wed Oct 1 13:16:24 2008 OK, yes that is exactly the Sun model:-) From: To: Time: Wed Oct 1 13:16:41 2008 Decoupled from DNS? From: To: Time: Wed Oct 1 13:16:55 2008 From a political standpoint, we've reviewed that model and told Sun at multiple points the basic model is OK. We've made no commitments about any specific implementation From: To: Time: Wed Oct 1 13:18:33 2008 I.e., don't call the DNS resolver routines, but do try to figure out if there's a realm by name X. (Certainly the heuristic is tied to using DNS-style host and realm names.) From: To: Time: Wed Oct 1 13:23:28 2008 What does it need dns resolver routines for at all? From: To: Time: Wed Oct 1 13:25:51 2008 Two things. From: To: Time: Wed Oct 1 13:26:11 2008 Well, first, let me say that the submitted patch does a lot more than change the way domain->realm lookups are done. From: To: Time: Wed Oct 1 13:26:41 2008 Skimming the patch again (first part, I've got a phone call to get to) it's mapping address->hostname->realm, and using res_* for the first part, for no obvious reason. From: To: Time: Wed Oct 1 13:27:18 2008 It also changes how the default realm is looked up, and introduces a new way of looking up realms. (Yeah, I also need to get on that conference call.) From: To: Time: Wed Oct 1 13:27:19 2008 Hm, maybe I need to look more closely then... I was going largely off the description. From: To: Time: Wed Oct 1 13:30:09 2008 It seems like new reverse resolution is not a good thing:-) From: To: Time: Wed Oct 1 13:31:32 2008 It's reverse resolution of the interface IP addresses, I think, to get domains to look up to determine the default realm. From: To: Time: Wed Oct 1 13:31:55 2008 So, I guess I need to figure out how to make long distance calls on MIT's dime if I'm going to be doing conference calls to area code 712 once a week. From: To: Time: Wed Oct 1 13:34:54 2008 Do you have a voip phone at home? If not, consider getting one. From: To: Time: Wed Oct 1 13:35:07 2008 That's how I handled the problem while working from home From: To: Time: Wed Oct 1 13:35:12 2008 ... yes, I do. I wonder if it works. From: To: Time: Wed Oct 1 13:35:40 2008 I'll try to get that online for next week. From: To: Time: Wed Oct 1 13:37:10 2008 Anyway, it uses DNS in two ways: 1. Reverse resolve local IP addresses to get domains to look up for default realm; 2. Grovel the DNS search path to get domains to look up for default realm. From: To: Time: Wed Oct 1 13:37:22 2008 I thought it was also adding a _kerberos.domain TXT lookup, but that was just reindentation of existing code. From: To: Time: Wed Oct 1 13:37:28 2008 So that part isn't a concern. From: To: Time: Wed Oct 1 13:54:00 2008 (Conference call over.) From: To: Time: Wed Oct 1 13:54:13 2008 What's wrong with either of those uses of DNS? From: To: Time: Wed Oct 1 13:58:39 2008 Portability concerns, mostly. From: To: Time: Wed Oct 1 14:00:52 2008 I don't know how to portably get to the DNS resolver search path. However it's an incredibly useful heuristic for default realm From: To: Time: Wed Oct 1 14:02:10 2008 If I were designing it I'd probably just canonicalize gethostname() and use that as the only domain to hang the lookup off of, but I'm not religious. There's also a bit of a mystery in the IP adress reverse resolution, in that they use res_gethostbyaddr() instead of just plain gethostbyaddr(). From: To: Time: Wed Oct 1 14:03:49 2008 Possibly to work around /etc/hosts having the unqualified name first? From: To: Time: Wed Oct 1 14:04:41 2008 Actually another thing to consider here is that we've changed the definition of default_realm in 1.6. In 1.6+, default_realm also controls where we expect services to be registered. Previously, it was easy to argue that default_realm has no security implications. I'm not entirely sure that's true any more. From: To: Time: Wed Oct 1 14:04:47 2008 Mark (from Sun) said that res_gethostbyaddr would still use /etc/hosts on Solaris, which would mean no. But he could be wrong; that seems odd to me. From: To: Time: Wed Oct 1 14:05:42 2008 In particular, once we fix the bug Russ opened regarding krb5_verify_initcreds and ksu not respecting the 1.6 style default realm it seems like you can make a machine not expect a keytab if you can change its default realm From: To: Time: Wed Oct 1 14:06:38 2008 However if I was writing the code I'd definitely just use gethostbyaddr. From: To: Time: Wed Oct 1 14:08:07 2008 I'm still pondering how canonicalizing gethostname compares to looking at the search order. Right now, it sounds like that's good enough and certainly more portable. I'd ask Nico before making the change as this is to a large extent his idea From: To: Time: Wed Oct 1 14:10:26 2008 This might need to be a meeting discussion topic, especially if there are new security concerns about the heuristic in the first place. From: To: Time: Wed Oct 1 14:13:18 2008 I don't think the right people are at the meeting. I bet you get everything you need with mail to krbdev and Nico. He's on krbdev but that will actually get his attention From: To: Time: Wed Oct 1 14:13:30 2008 Okay. From: To: Time: Wed Oct 1 14:13:52 2008 I realize Nico is no longer involved on the Sun end, but the question about dropping the search stuff is mostly "why was it there in the first place." From: To: Time: Wed Oct 1 14:49:42 2008 Well, from the security perspective, it looks like we're already in the soup, since we do these _kerberos TXT lookups. From: To: Time: Wed Oct 1 14:50:04 2008 (If configuration allows for DNS lookups.) From: To: Time: Wed Oct 1 14:52:01 2008 Do we make a practice of casting our NULLs everywhere or is that just in the code I'm looking at? From: To: Time: Wed Oct 1 14:52:09 2008 The TXT lookups are supposed to be off by default. The SRV records should be on by default From: To: Time: Wed Oct 1 14:53:21 2008 And yes, the txt lookups are a security issue. IT should be discussed in the admin docs (I believe it is) and is definitely discussed in our whitepapers. From: To: Time: Wed Oct 1 14:58:42 2008 Okay, on further inspection, the Sun patch does the _kerberos TXT lookups if _krb5_use_dns_realm is true, and does the new style of DNS lookups if it's false. From: To: Time: Wed Oct 1 14:58:45 2008 That doesn't seem right at all. From: To: Time: Wed Oct 1 15:16:40 2008 So what are you doing for the kerberos team, greg? From: To: Time: Wed Oct 1 15:17:41 2008 Apparently, trying to improve the development process. From: To: Time: Wed Oct 1 15:17:58 2008 But at this moment I'm reviewing a patch I was asked to look at. From: To: Time: Wed Oct 1 15:25:34 2008 Usually null doesn't get cast, except in variadic argument lists, but sometimes people have put in needless casting anyways (and not just for null). From: To: Time: Wed Oct 1 15:30:51 2008 what was the pointer casting thing referring to? From: To: Time: Wed Oct 1 15:31:47 2008 message from ghudson at 14:52 asking if casting null was our standard practice From: To: Time: Wed Oct 1 15:31:57 2008 (or did you mean what was greg referring to?) From: To: Time: Wed Oct 1 15:32:52 2008 oh right. i see it now. it was stuff that was there to begin with. From: To: Time: Wed Oct 1 15:33:40 2008 I noticed the patch introduced new code which casted NULLs, and then noticed that it was just copying the style of existing code in hst_realm.c and def_realm.c, and was wondering if we did that everywhere by policy or just some places by lameness. From: To: Time: Wed Oct 1 15:47:53 2008 i think all the casted NULLs are moving code around. From: To: Time: Wed Oct 1 15:50:41 2008 Yeah, it's just something I noticed, not something really related to this patch. From: To: Time: Wed Oct 1 15:50:54 2008 What's our reporting address for security issues? (No, I don't have one.) From: To: Time: Wed Oct 1 15:52:41 2008 krbcore-security@mit.edu From: To: Time: Wed Oct 1 15:52:48 2008 preferrably pgp-encrypted From: To: Time: Wed Oct 1 15:57:14 2008 (Right, making a PGP key. I'm such a luddite. I'll add that to my list.) From: To: Time: Wed Oct 1 16:05:44 2008 Where do people send mail saying they're taking vacation days, besides ist-vac-reporting? I don't remember if I've seen notes like that to mitkc-staff. ("Nowhere" is a fine option if it's the case.) From: To: Time: Wed Oct 1 16:06:34 2008 sending to the staff list is usual From: To: Time: Wed Oct 1 16:07:36 2008 Thanks. From: To: Time: Wed Oct 1 16:15:01 2008 anyway, my preference is to avoid casting pointers at all except for things like variadic arguments. to do otherwise is to potentially hide coding errors. From: To: Time: Wed Oct 1 16:20:26 2008 heading home early, will be online from there... From: To: Time: Thu Oct 2 12:41:36 2008 Alright, I have a trivial commit to make. It's pursuant to an existing ticket (6121). What's the magic procedure; just put the ticket number in the log message in the format I see other people using? From: To: Time: Thu Oct 2 12:45:34 2008 yeah. details of how that works are in doc/procedures.txt and on the wiki From: To: Time: Thu Oct 2 12:45:36 2008 Yes. I think the magic-token scanning may stop at the first blank line or something like that, so collect rt headers together. If you don't want the default action of setting the state to "review", add a "state: foo" line. From: To: Time: Thu Oct 2 12:46:44 2008 I couldn't find it on the wiki, but doc/procedures.txt is easy enough. From: To: Time: Thu Oct 2 12:47:44 2008 hm, i thought it was in there, but we do need to do something about the "can't find it in the wiki" problem. From: To: Time: Thu Oct 2 12:48:13 2008 When I'm a bit more settled I expect to be fairly aggressive about fleshing out the wiki. From: To: Time: Thu Oct 2 12:48:29 2008 ... the sort of problem Elizabeth would've actually wanted to work on. :) From: To: Time: Thu Oct 2 12:55:30 2008 I'm about to tweak the krbdev apache configuration to try to make it possible to read the nightly-testing log files again. From: To: Time: Thu Oct 2 12:55:37 2008 That changed the status from "new" to "review"; the theory is that someone will review the commit and close the ticket? From: To: Time: Thu Oct 2 12:56:06 2008 That's the theory, yes. From: To: Time: Thu Oct 2 12:56:26 2008 (I'll add to my plate: look over the tickets marked as "review" and review some.) From: To: Time: Thu Oct 2 12:58:05 2008 heh. i just cleared Greg's moderation flag on cvs-krb5. From: To: Time: Thu Oct 2 13:00:29 2008 What components of krb5 use the RPC library? From: To: Time: Thu Oct 2 13:01:00 2008 kadmin From: To: Time: Thu Oct 2 13:01:51 2008 Okay. umich wants to change the default timeout from 25s to 120s; doesn't seem like a comprehensive solution but it seems harmless enough. From: To: Time: Thu Oct 2 13:02:08 2008 (Well, someone at umich.) From: To: Time: Thu Oct 2 13:03:34 2008 Well, that was easy. And looking at the log files and status reports, my quick assessment of the current results is: alpha-netbsd3: works solaris: keeps reactivating and detaching required lockers x86-linux: complains of tcl initialization problems?? sparc64-netbsd3: works x86_64-linux: has been breaking in ftp and kadmin tests for a long time From: To: Time: Thu Oct 2 13:04:06 2008 solaris: install stuff locally to avoid reactivation-related problems From: To: Time: Thu Oct 2 13:04:51 2008 Actually, looking further, it was only the Sun cc test that failed that way; an rcp test failed for no obvious reason under the gcc build. From: To: Time: Thu Oct 2 13:05:07 2008 Yeah, I should look at how to do that. I assume it's pretty easy... From: To: Time: Thu Oct 2 13:12:58 2008 Ah, rcp failed because of "logins currently disabled", probably another reactivation issue. From: To: Time: Thu Oct 2 13:13:48 2008 (Those log files are big. Takes safari quite a while to load them. Only 1M+ on the server, but uncompresses to ~43M.) From: To: Time: Thu Oct 2 13:15:01 2008 I've been known to chmod a-x reactivate on Solaris Athena machines. From: To: Time: Thu Oct 2 13:15:43 2008 I used to tweak the cron job to not reactivate during the wee morning hours. But now I just try to leave a window remotely logged in to the machine. From: To: Time: Thu Oct 2 13:22:44 2008 i used to have a hack to disable reactivation From: To: Time: Thu Oct 2 13:24:54 2008 ok, in our RT code, it looks like there are CCs and AdminCCs. AdminCCs get BCCed but CCs get normal CCs. this makes it a bit annoying to hide the public redist list name. From: To: Time: Thu Oct 2 13:29:12 2008 Add that to the list. :) Maybe a flag on the AdminCC to indicate whether it should be public or not. Or separate AdminCC and SeekritAdminCC entries. From: To: Time: Thu Oct 2 13:30:47 2008 well currently the seekrit redist list name is on the AdminCCs, but i am thinking of having separate AdminCCs and CCs so that the public list gets the correspondence and comments while the AdminCCs are krbcore and get more spewage like state changes. From: To: Time: Thu Oct 2 13:32:46 2008 I'd be tempted to reject #6119 (strftime expansion of log filenames in kadmin) if I weren't the new guy. From: To: Time: Thu Oct 2 13:32:56 2008 Greg, you should set a realname for yourself in RT :-) From: To: Time: Thu Oct 2 13:33:18 2008 i don't like 6119 either because datestring suffixes belong to log rolling software From: To: Time: Thu Oct 2 13:33:45 2008 I don't see how to do that. From: To: Time: Thu Oct 2 13:34:00 2008 Under "Preferences" I can set a signature, but that's it. From: To: Time: Thu Oct 2 13:34:19 2008 Ah, configuration. From: To: Time: Thu Oct 2 13:34:26 2008 configuration -> users -> ghudson ... From: To: Time: Thu Oct 2 13:34:50 2008 I guess setting real names is an admin option. From: To: Time: Thu Oct 2 13:36:35 2008 Agreed on 6119, though it does tie in to the desire for more structured and controllable logging for auditing purposes, if you assume a plugin interface may be part of that. From: To: Time: Thu Oct 2 13:38:00 2008 And we want to keep Marcus encouraged to contribute. See if you can find some pending patch of his to incorporate. :) From: To: Time: Thu Oct 2 13:39:37 2008 I think I just did two of them. From: To: Time: Thu Oct 2 13:40:32 2008 There's also #6118 (rename implementation) but it appears to need work. From: To: Time: Thu Oct 2 13:40:33 2008 Good. We have quite a lot of contributed patches sitting around in the bug database. I'm glad we're (you're) finally starting to catch up a bit. From: To: Time: Thu Oct 2 15:31:50 2008 plumbing to the new coffee machine looks sketchy From: To: Time: Thu Oct 2 15:36:01 2008 also, Category:Lore is new on k5wiki and i'm starting to add some stuff to it. From: To: Time: Thu Oct 2 18:39:13 2008 I just put together a little bookmarklet that I think might be handy; it prompts for an RT ticket number and then jumps to the page, where I used to have a bookmark to a page where (after it loaded) I could type a ticket number into a form. From: To: Time: Thu Oct 2 18:39:16 2008 javascript:void(t=prompt('RT%20ticket%20number'));if(t!=null&&t!=%22%22){location.href='https://krbdev.mit.edu:444/rt/Ticket/Display.html?id='+t} From: To: Time: Thu Oct 2 18:40:18 2008 oh because you want to be able to open a ticket in a new tab or such? From: To: Time: Thu Oct 2 18:41:48 2008 Well, it uses the current window/tab, but that might be a new window/tab, or one where I'm viewing some non-RT page no longer of interest. The bookmarklet should let me jump right to the ticket page, without indirecting through a bookmark for another RT page, and without having to type in the whole URL. From: To: Time: Thu Oct 2 18:42:50 2008 I'd been using a bookmark for the "configuration" page because it loads relatively quickly, and has a form for displaying a supplied ticket number. Now I shouldn't need to load that page first. From: To: Time: Thu Oct 2 18:46:25 2008 On a less fluffy note, I think I need to create a bunch of new test cases for ASN.1 encoders and decoders we currently don't test at all, like PKINIT stuff, and the LDAP key-sequence type. From: To: Time: Fri Oct 3 22:15:10 2008 ... but always exOrW=0 ? I believe you have found a bug; that message indicates a write on something we don't think is open, more or less. You're using memcache? From: To: Time: Sat Oct 4 10:56:23 2008 And Jeff Altman teaches me not to ask questions in the negative. From: To: Time: Sat Oct 4 10:57:00 2008 ("Is there any reason not to do X?" "Yes." Does that mean it would be good to do X, or that there's a reason not to do it but he didn't bother to say what it is?) From: To: Time: Sat Oct 4 10:57:18 2008 it would be good to do X From: To: Time: Sat Oct 4 10:58:26 2008 the domain to realm mapping in the profile has explicit support for this case From: To: Time: Sat Oct 4 10:59:07 2008 as does the srv record lookup specification From: To: Time: Sat Oct 4 11:14:15 2008 Can people comment on what a "join-realm" facility would do? I get the general idea: join a client machine to a realm, configure it to use Kerberos for login, etc.. Is one of the goals to get a keytab? Is the idea that you would enter an admin password in order to be able to create the keytab? From: To: Time: Sat Oct 4 11:16:52 2008 a join realm facility would create one or more service principals in the realm's KDB and install keytabs, configure krb5.conf, the pam configuration, as well as kerberos/gss aware services to make use of kerberos. From: To: Time: Sat Oct 4 11:19:06 2008 It seems risky to enter a Kerberos admin password at each endpoint machine. From: To: Time: Sat Oct 4 11:52:14 2008 there are many models you can use to reduce the risk. it depends on what you want. AD has a mode that permits any user in the domain to add their machine to the domain even though that user may not be a domain administrator. From: To: Time: Sat Oct 4 12:17:44 2008 AD also has a feature that lets you configure specific accounts that can add computers to the domain but have no other privileges. From: To: Time: Sun Oct 5 02:02:54 2008 This room is not anonymous. From: To: Time: Mon Oct 6 13:07:27 2008 I was looking into various options for a join-realm facility a while back, and one we were looking at implementing would allow a machine to register its own host key (comparing IP address vs host name in requested principal, requiring that it not already exist in the database, and maybe checking against a separate hostname allow/deny list) without any special authentication needed (using the KDC's public key and anon pkinit to secure the session). The magic add-computer-only-privilege account would work fine too. From: To: Time: Mon Oct 6 13:07:54 2008 And for other service, you could, for example, let host/foo register service/foo for service in a specific list configured on the server. From: To: Time: Mon Oct 6 13:17:53 2008 Someone should add me to the krbcore discuss acl. From: To: Time: Mon Oct 6 13:18:47 2008 done From: To: Time: Mon Oct 6 13:18:59 2008 Thanks. From: To: Time: Mon Oct 6 13:19:36 2008 It looks like a lot of former-krbcore people are explicitly listed as having no access. Odd. From: To: Time: Mon Oct 6 13:20:19 2008 Best guess, someone used the wrong command when removing their access. From: To: Time: Mon Oct 6 13:20:47 2008 Yeah. From: To: Time: Mon Oct 6 15:51:18 2008 lunch preferences? is there still an anti-preference for pizza? From: To: Time: Mon Oct 6 15:52:20 2008 I think I'm in the mood for (my usual salad from) cafe kiraz. From: To: Time: Mon Oct 6 15:57:09 2008 No preference. From: To: Time: Mon Oct 6 17:54:55 2008 i'd like a sanity check... the mkey migration project page: does it match what you understand the consensus of the krbdev discussion is? From: To: Time: Mon Oct 6 18:21:25 2008 Looks about right, I think. Though I think we want a test case to make sure enough old K/M keys are kept around, and there isn't some bad interaction with normal key history processing. From: To: Time: Mon Oct 6 18:22:11 2008 (And on a vaguely related note, do we want a way to change the key for kadmin/history without reloading the entire database? Separate project, probably...) From: To: Time: Mon Oct 6 18:23:14 2008 ok, please post about the test case suggestion. From: To: Time: Mon Oct 6 18:23:35 2008 writing the email now From: To: Time: Mon Oct 6 19:43:04 2008 Ow. Generating recursive type-comparison functions for all the pkinit structures is a bit hard on the hands. Even with some fancy regexp hacking to transform the type definitions into code instead of writing everything out by hand. And I haven't gotten to the actual writing of encoder/decoder test cases yet. From: To: Time: Tue Oct 7 10:46:46 2008 Will there be lunch today? (I can eat before heading over if not.) From: To: Time: Tue Oct 7 10:47:57 2008 i believe Steve is getting us indian food. From: To: Time: Tue Oct 7 10:48:29 2008 Sounds good. From: To: Time: Tue Oct 7 16:57:38 2008 the domaindirect.com "edit zone file" is a lie. From: To: Time: Tue Oct 7 18:43:30 2008 supported platforms page now on wiki From: To: Time: Tue Oct 7 21:55:39 2008 Ick. I think we may have a few bugs in the PKINIT ASN.1 code. From: To: Time: Wed Oct 8 15:12:22 2008 ok, that was weird. firefox on my sun was opening https connections by only sending tcp syn and nothing else From: To: Time: Wed Oct 8 15:17:34 2008 Strange. I didn't think the kernel would let you do that. Is anything else behaving that way? From: To: Time: Wed Oct 8 15:27:01 2008 no. i think firefox got confused somehow. From: To: Time: Wed Oct 8 15:27:18 2008 could i get a volunteer to have their krbweb rights revoked temporarily for a test? From: To: Time: Wed Oct 8 15:27:28 2008 Sure, go for it. From: To: Time: Wed Oct 8 15:28:44 2008 actually temporarily revoking sysop as well. see if you can access the Krbweb_test page and if you can edit it. From: To: Time: Wed Oct 8 15:29:22 2008 (wow, I just pulled up the outline_of_work page on my desktop browser right after sending that last message, nad the header looks bad; huge font, title wraps to a second line, and the lines overlap) From: To: Time: Wed Oct 8 15:29:26 2008 reloading the page... From: To: Time: Wed Oct 8 15:29:44 2008 oh, test page. hang on... From: To: Time: Wed Oct 8 15:30:29 2008 Yep, just edited it. From: To: Time: Wed Oct 8 15:31:44 2008 hm, ok. From: To: Time: Wed Oct 8 15:32:26 2008 can you also see the outline_of_work page still? From: To: Time: Wed Oct 8 15:32:55 2008 Yes, and the header still looks ugly. :) From: To: Time: Wed Oct 8 15:33:03 2008 oh. that's kind of bad. From: To: Time: Wed Oct 8 15:34:43 2008 The top-level page gives me an 'edit' link but the edit page says sysop privileges are needed (but still has all the text fields etc). From: To: Time: Wed Oct 8 15:47:33 2008 oh, looks like kerbweb_outline got removed from krbweb From: To: Time: Wed Oct 8 15:56:10 2008 i think things might have gotten untangled now. Krbweb_test should be invisible except to krbweb; Kerbweb_test_public should be readable to all but writable by krbweb. From: To: Time: Wed Oct 8 15:56:29 2008 ok, checking... From: To: Time: Wed Oct 8 15:58:26 2008 test gets me an error about not having access; test_public appears but there's no "edit" tab. From: To: Time: Wed Oct 8 15:59:12 2008 If I forge the edit url for test_public, it still tells me I can't edit it, but shows me the source. Some other pages I apparently still do have edit access to. From: To: Time: Wed Oct 8 16:00:45 2008 what software are you using? From: To: Time: Wed Oct 8 16:01:02 2008 mediawiki From: To: Time: Wed Oct 8 16:06:26 2008 Oh; I think you're going to have pain trying to keep pages non-public in mediawiki. It sounds like you're going for something very similar to what I'm trying to do, and I gave up and started looking for something else. From: To: Time: Wed Oct 8 16:06:32 2008 it looks like things are working correctly then. From: To: Time: Wed Oct 8 16:12:51 2008 anyway it looks like i can de-sysop myself and test stuff while retaining bureaucrat, which is useful. From: To: Time: Wed Oct 8 16:27:42 2008 Do we have any kind of runbook or other mechanism for making stuff on krbdev reproduceable, or do we just do stuff and back it up? (Not trying to create process where there isn't any, just trying to follow process where there is.) From: To: Time: Wed Oct 8 16:29:18 2008 stuff in /var/rt2 is mostly directly from "make install" out of the krbdev (not krb5) cvs tree in tracking/rt and tracking/rt-cvs, with some exceptions. i have rsync backups on my desktop for now, until i can make sure that i have tuned the exclusions to keep key data out of things. From: To: Time: Wed Oct 8 16:34:26 2008 Okay. Since Coverity involves installing a binary blob, I think I'll just keep notes on what I did to set it up. And I'll make a note to think about backups if there aren't comprehensive machine backups. From: To: Time: Wed Oct 8 16:34:57 2008 we theoretically have ops-provided backups that occur by means of snapshots of the VMs. From: To: Time: Wed Oct 8 16:35:27 2008 Is ops helping to administer krbdev-xen, then? From: To: Time: Wed Oct 8 16:35:53 2008 or asst. From: To: Time: Wed Oct 8 18:23:13 2008 It looks like Coverity remote commits use obfuscated plaintext passwords. They suggest using an encrypted ssh tunnel for better security. I wonder if that will be feasible on Windows. From: To: Time: Wed Oct 8 18:26:52 2008 Time to dig up my notes on getting a signed server certificate. From: To: Time: Wed Oct 8 18:29:23 2008 (Oh, I bet I can just use the existing one.) From: To: Time: Wed Oct 8 18:45:36 2008 Yay, that was easy. From: To: Time: Wed Oct 8 18:46:21 2008 you just used the existing one? From: To: Time: Wed Oct 8 18:46:25 2008 Yes. From: To: Time: Wed Oct 8 18:46:36 2008 Had to make a copy of it readable by the coverity user, of course. From: To: Time: Wed Oct 8 18:48:26 2008 it runs a standalone web server? From: To: Time: Wed Oct 8 18:49:05 2008 Yes, on a different port. We could redirect to it from httpd, presumably, but it would still need to be able to read the certificate. From: To: Time: Wed Oct 8 18:51:20 2008 It's weird that there's user-controlled cron jobs but not user-controlled boot scripts. From: To: Time: Wed Oct 8 18:53:13 2008 you could have the boot script exec su -c .... From: To: Time: Wed Oct 8 18:58:41 2008 Oh, sure. I was just noticing the inconsistency. From: To: Time: Wed Oct 8 21:02:55 2008 There is ssh for windows, certainly. (There's even a server.) I assume it does tunnels. I know I've done a tunnel for remote desktop access before, but I don't remember on which side I initiated the connection. From: To: Time: Wed Oct 8 21:08:40 2008 The coverity web server appears to be apache based. I wonder if it needs anything more than running a CGI script with a few variables set; does the web server do the SSL bits and pass cleartext through to the CGI script in a configuration like that? From: To: Time: Wed Oct 8 22:56:23 2008 I believe so. From: To: Time: Wed Oct 8 22:58:47 2008 Then we might be able to run it in the same web server as serves up RT and the nightly testing result pages I generate. (I assume the CGI script could be run in another process with a different uid?) It probably wouldn't even need a separate port number. From: To: Time: Wed Oct 8 22:59:40 2008 It's possible, but if it's not documented, I'm not sure it would be a good idea. From: To: Time: Wed Oct 8 23:00:00 2008 True. I haven't looked at that part of the Coverity docs. From: To: Time: Wed Oct 8 23:00:33 2008 I have. I don't see any acknowledgement that it runs out of an Apache httpd, so I think that's treated as an implementation detail. From: To: Time: Wed Oct 8 23:01:25 2008 (That's not strictly true; I just found acknowledgement of the fact, but still no discussion of how you might use an existing httpd installation.) From: To: Time: Wed Oct 8 23:02:33 2008 I was under the impression there was sort of a generic CGI interface for web servers (maybe not), so apache could be an implementation detail but the CGI setup something we're allowed to adapt. But if you haven't seen anything about it, yeah, I wouldn't try it. Running a secondary web server for this isn't that big a deal. From: To: Time: Wed Oct 8 23:05:53 2008 I mean, we could probably do it. They ship something called cov-internal-httpd which I think is just a standard build of Apache httpd (though it could be modified, I suppose), and there's a cgi-bin subdir in their tarfile. When you run cov-install-gui, it creates an httpd.conf file. We could munge that into a configuration include for our existing httpd and it might work. I'm just not very optimistic that it would be simple, since they don't document it at all. From: To: Time: Wed Oct 8 23:08:12 2008 And even if it does Just Work, there's no guarantee it would in the next release. It seems like an annoyance that this unprivileged user would need access to a certificate for our RT server, but a minor one for now, and probably not worth the effort. From: To: Time: Wed Oct 8 23:08:53 2008 All the certificate says is that the owner is allowed to claim to be krbdev.mit.edu. From: To: Time: Wed Oct 8 23:08:59 2008 I don't think RT cares about it particularly. From: To: Time: Wed Oct 8 23:09:05 2008 (Beyond that.) From: To: Time: Wed Oct 8 23:10:15 2008 (I guess there are some potential attacks on the SSL datastreams going to and from RT.) From: To: Time: Wed Oct 8 23:10:17 2008 Well, no, but it sounds like someone breaking into the coverity-testing account could claim to be our RT server to web clients. From: To: Time: Wed Oct 8 23:10:50 2008 Sure, certificates aren't specific to anything other than hostnames. From: To: Time: Wed Oct 8 23:16:33 2008 From previous work, I could launch into an extensive discussion of problems with separate security domains on the same host using Apache httpd, particularly with SSL. The upshot is: there's no easy or good way to get good security isolation between applications without using separate domains and separate httpd installations. I don't see any plausible attack scenarios where someone would care to use one of RT or Coverity against the other, which is why I'm comfortable running both on the same host. From: To: Time: Wed Oct 8 23:18:00 2008 I'd believe it. And I don't anticipate it being a problem either. From: To: Time: Thu Oct 9 06:32:04 2008 > It's weird that there's user-controlled cron jobs but not > user-controlled boot scripts. vixie cron supports an extension where instead of the usual min hour mday mon wday, you can say "@reboot" From: To: Time: Thu Oct 9 06:34:17 2008 > I was under the impression there was sort of a generic CGI interface > for web servers There is. It's called "CGI". The 'C' stands for "common". From: To: Time: Thu Oct 9 11:00:20 2008 Yeah, I thought it was something like that. Not exactly an expert in that area though... From: To: Time: Thu Oct 9 12:09:55 2008 I think we've only got one case where the implicit tag handling is botched. From: To: Time: Thu Oct 9 12:23:09 2008 I wish you could give cov-build a path prefix to ignore when computing filenames. Having the full path to the build directory show up in defect reports is a little disconcerting. From: To: Time: Thu Oct 9 12:23:46 2008 On the bright side, scp'ing over the intermediate directory and running cov-commit-defects on krbdev works fine. Possibly not the most efficient use of bandwidth, but it's simpler than using an ssh tunnel. From: To: Time: Thu Oct 9 13:04:06 2008 Okay, if I do a second build in a different place, the defect db is smart enough to realize that the files are still the same. (Not sure how.) The new absolute paths show up in the defect listing. From: To: Time: Thu Oct 9 13:04:44 2008 Ah. Our ASN.1 pretty-printer has a "context shortcut" option that produces slightly abbreviated output, but assumes that a context tag will always be followed by another tag. Not true in cases of implicit tagging in PKINIT. From: To: Time: Thu Oct 9 13:05:07 2008 Checking for constructed rather than primitive form seems to fix it... From: To: Time: Thu Oct 9 13:45:51 2008 Thanks for the pointer to @reboot in crontabs. From: To: Time: Thu Oct 9 15:32:52 2008 looks like GeoTrust only does code signing certificates through Verisign From: To: Time: Fri Oct 10 13:29:50 2008 Wow. Getting radar access really seems to make the bugreport.apple.com experience *worse* than it was. I used to be able to save the password; now, it's still the same password, but I can't save it. I used to get a popup menu with the component names; now I have to guess, and can't submit a bug report if I get it wrong. From: To: Time: Fri Oct 10 15:58:32 2008 The errors in our PKINIT encoders and decoders fill one with wonder. As in, I wonder how this ever worked? From: To: Time: Sun Oct 12 02:02:29 2008 This room is not anonymous. From: To: Time: Tue Oct 14 10:08:57 2008 did Thunderbird on Athena support GSS? there's a thread on the kerberos list about getting Thunderbird GSS to work. From: To: Time: Tue Oct 14 10:11:21 2008 and wow, bertuccis.com makes firefox segfault. From: To: Time: Tue Oct 14 11:32:47 2008 I don't know; Athena has never supported Thunderbird in the release. From: To: Time: Tue Oct 14 16:56:38 2008 Yay, new toys. I mean, workstations. From: To: Time: Tue Oct 14 17:07:10 2008 re kdc replay/lookaside caches: since os vendors ship our stuff in binary form, actually, having it be run-time selectable (with configure-time selection of the default perhaps) might be best. From: To: Time: Tue Oct 14 17:08:12 2008 why add knobs that are going to be of dubious use? From: To: Time: Tue Oct 14 17:09:36 2008 (weird, the question-mark stopped working on my keyboard for a bit. not the slash, just (shifted) question mark.) From: To: Time: Tue Oct 14 17:12:32 2008 It sounded like we were talking about changing the default, not hardcoding it to always behave one way or the other; maybe I misunderstood. If we're keeping both options, and catering to integrators that ship binaries, the options that might be wanted on a per-site basis (e.g., depending on whether lame hardware token support is in use) should be run-time selectable as well as (or instead of) configure-time selectable. From: To: Time: Tue Oct 14 17:14:40 2008 sure. but it sounds like whether we keep both will depend on the hw-token based security issues. From: To: Time: Tue Oct 14 17:16:55 2008 ...which we don't have much information on. My guess is kenh and others on krbdev (Matt Crawford if he's still following) may be able to help with that. From: To: Time: Tue Oct 14 17:17:22 2008 If we do keep them, though, I think run-time selection (config-file based) is a good idea. From: To: Time: Wed Oct 15 10:57:34 2008 Matt is no longer working on Kerberos and hasn't for years. KenH isn't either. Ken Renard is currently responsible for the NRL environment. From: To: Time: Wed Oct 15 10:58:21 2008 Fermi and NRL are using the CryptoCard implementation the KenH wrote years ago. From: To: Time: Wed Oct 15 10:58:40 2008 Ken Renard is moving NRL to PKINIT From: To: Time: Wed Oct 15 11:02:49 2008 By "CryptoCard implementation", you mean a KDC that supports some private protocol for using CryptoCard cards for initial authentication? From: To: Time: Wed Oct 15 11:03:46 2008 based upon the hardware initial authentication drafts that KenH edited years ago From: To: Time: Wed Oct 15 11:04:13 2008 If he's moving to pkinit, he should look at what deengert has done, since it is likely doug has solved several of the problems he'll end up having. From: To: Time: Wed Oct 15 11:05:15 2008 I wonder if non-PK, non-OTP hardware tokens are enough a thing of the past that we can just punt on hardware preauth. I've seen no interest in that draft in some time. From: To: Time: Wed Oct 15 11:05:29 2008 Sorry, by "we" there I mean krb-wg From: To: Time: Wed Oct 15 11:05:51 2008 I don't think the lack of participation in IETF is an indication of lack of interest From: To: Time: Wed Oct 15 11:06:21 2008 Orgs that have implementations are not represented there. From: To: Time: Wed Oct 15 11:07:22 2008 I've seen no one with any interest in working on that draft. I'm inclined to doubt that many people are interested in new deployments of non-PK, non-OTP hardware preauth. I'm also inclined to doubt that people with existing deployments are interested in standardization; I'd expect them to be interested in continuing to run what they're already running. But I might be wrong. From: To: Time: Wed Oct 15 11:07:50 2008 pkinit doesn't work with web interfaces From: To: Time: Wed Oct 15 11:08:20 2008 huh? From: To: Time: Wed Oct 15 11:10:35 2008 if you are kerberos-authenticating to a web server, then the web-ness is irrelevant. So I must assume you are talking about some situation in which a user does initial authentication to a web server. Since web servers demonstrably do support PK authentication of clients, even though ~no one actualy does it, you must mean something else. ... From: To: Time: Wed Oct 15 11:11:03 2008 explain to me how PKINIT can be used to login via a web gateway when there is no Kerberos on the terminal hosting the web browser From: To: Time: Wed Oct 15 11:11:41 2008 because that is one of the cases that JPL worries about From: To: Time: Wed Oct 15 11:12:06 2008 What does "via a web gateway" mean? You want to prove your identity to a web server? Or do you also want it to end up with tickets as you? From: To: Time: Wed Oct 15 11:12:45 2008 I don't have time for this conversation right now. From: To: Time: Wed Oct 15 11:13:09 2008 OK From: To: Time: Wed Oct 15 11:13:32 2008 the only reason I replied was to point the mit folks at the right people to talk with From: To: Time: Wed Oct 15 11:15:40 2008 I'm not sure what you replied to; I saw nothing before your message. From: To: Time: Wed Oct 15 11:16:06 2008 it was from last night From: To: Time: Wed Oct 15 11:17:05 2008 Oh, I see. Nevermind. From: To: Time: Wed Oct 15 13:39:59 2008 Hm, we actually don't appear to support putting FILE: (or WRFILE:) in the key_stash_file spec in the config file. Some bit of code someplace sticks "WRFILE:" on the front of it. From: To: Time: Wed Oct 15 14:20:01 2008 String handling in C is a much more religious area than I would have guessed. (I'm reading stuff from the Linux libc maintainers on strlcpy.) From: To: Time: Wed Oct 15 15:23:29 2008 yes... including some prime examples of why people dislike Theo and vice versa. From: To: Time: Wed Oct 15 15:36:27 2008 When you start running across anything from djb, run screaming From: To: Time: Wed Oct 15 15:54:51 2008 so using truncating string functions means shutting up the analyzers and manual reviewers, even if it introduces vulnerabilities from the truncation. the consequences of truncation are probably not as severe as those from buffer overflows. when using counted length strings, you can miscode. then again you can also miscode when using truncating string functions. maybe the answer really is to make purpose-built wrappers that use "acceptably safe" functions to accomplish specific tasks. From: To: Time: Wed Oct 15 15:56:57 2008 also, various alleged inconsistencies in strlcpy implementations imply that we should use it cautiously if at all. From: To: Time: Wed Oct 15 15:57:22 2008 (unrelatedly, i really want focus-follows-gaze that somehow takes into account KVM switchers and the like.) From: To: Time: Wed Oct 15 16:00:01 2008 if you make all your string buffers have both a buffer size and a current string size, and do all manipulation with custom functions/macros that operate on those objects, you can concentrate the error handling in one place. Of course, that more or less assumes you are willing any time the buffer is too short to have the string function either grow the buffer or fail an assertion. From: To: Time: Wed Oct 15 16:01:15 2008 The problem with focus-follows-gaze is that it makes it harder to type into one window based on the contents of another. That, and it'd need a lot of hysteresis. From: To: Time: Wed Oct 15 16:01:32 2008 Yeah, we can't really use a string buffer module without being willing to abort on allocation failure. From: To: Time: Wed Oct 15 16:01:51 2008 and aborting in a library is not very friendly... From: To: Time: Wed Oct 15 16:03:18 2008 The string-buffer-handle-with-size approach is something I'd thought about before. A simple enough representation and simple manipulation functions should make it practical to review and eliminate overrun concerns. From: To: Time: Wed Oct 15 16:04:30 2008 Yeah, aborting in a library fairly well sucks. From: To: Time: Wed Oct 15 16:11:30 2008 Return a "failed to allocate" token akin to a null pointer. Use simple, carefully reviewed building blocks to eliminate other failures, and either make those building block check for "failed to allocate" tokens and return similar, or assert that it's the caller's responsibility and go ahead and let the app crash. From: To: Time: Wed Oct 15 16:16:04 2008 An interesting idea. Then you can defer error handling until you're done constructing the string. From: To: Time: Wed Oct 15 16:22:15 2008 Sure. Mark describe such a technique to me a long time back -- construct an object and do a bunch of operations on it, but the operators check for an error state and don't do anything in that case. It doesn't need to be efficient because it's not the common case. From: To: Time: Wed Oct 15 16:23:05 2008 You do have to make sure that the error checks happen. At the very least, get a null pointer back when you ask for the (const-qualified) string data portion. From: To: Time: Wed Oct 15 16:23:35 2008 Oh, indeed, if you use a magic token, or some sort of flag in the buffer structure (I'm thinking that such string buffers are mutable, so might transition from a good state to a bad one), you can design the blocks so that string operations with failure buffers as input return failure buffers as output. Obviously it would eventually be up to the caller to check. For the coerce-to-C-string op, you probably want one version that turns failure buffers into NULL pointers, and another that turns them into pointers to some constant string. From: To: Time: Wed Oct 15 16:25:26 2008 my that's a voluminous debate going on... From: To: Time: Wed Oct 15 16:26:02 2008 It's a bikeshed issue. From: To: Time: Wed Oct 15 16:26:31 2008 Everyone is qualified to comment, at least on the general issue if not how it relates to the code base. From: To: Time: Wed Oct 15 16:30:22 2008 re memcpy and string literals... sizeof works reasonably on a string literal From: To: Time: Wed Oct 15 16:31:02 2008 With a good compiler, so does strlen, and less prone to accidental breakage if you replace the literal with a variable reference or expression. From: To: Time: Wed Oct 15 16:32:16 2008 I was imagining some macro which expands to memcpy(a, b, sizeof(b)). From: To: Time: Wed Oct 15 16:32:53 2008 I advise strongly against that. If you do that, someone will see the macro, and call it on something that is not a string literal, and it will compile, but do decidedly the wrong thing. From: To: Time: Wed Oct 15 16:34:04 2008 Personally I'd go for an (inline?) function using strlen. It avoids evaluating twice if the operand is an expression, and doesn't make the sizeof(ptr) mistake if it's anything other than a string literal or array. From: To: Time: Wed Oct 15 16:37:23 2008 one thing that could throw a very large wrench into the works is suggestions that involve using asprintf and friends to concatenate strings. that may involve locale-specific interactions; i'd have to check. From: To: Time: Wed Oct 15 16:41:56 2008 it doesn't help that the C standard sometimes uses "character" to mean "byte" From: To: Time: Wed Oct 15 16:43:38 2008 Yes, I think there are locale issues. Anything where you might have shift states etc. Probably a good argument against incorporating our own snprintf that reimplements it all, as was suggested at one point. From: To: Time: Wed Oct 15 16:44:24 2008 you are so doomed From: To: Time: Wed Oct 15 16:45:39 2008 oh. it was the precision specifier for %s that was the issue, on solaris at least. From: To: Time: Wed Oct 15 16:46:43 2008 Precision? Oh. Ouch. Yeargh. From: To: Time: Wed Oct 15 16:47:12 2008 so situations like where we use "%.*s" to deal with non-null-terminated strings we could get screwed. From: To: Time: Wed Oct 15 16:47:35 2008 Really, we should probably try setting up an environment using shift states or something, and play around and see what actually works reliably. From: To: Time: Wed Oct 15 16:48:33 2008 Yeah, %.*s is supposed to limit the number of output bytes. If *printf is clever about shift states, the number of bytes output for (effectively) sticking two strings together could be different from the combined lengths of the strings. From: To: Time: Wed Oct 15 16:48:36 2008 Wait, why are precision specifiers relevant? They operate in not-bytes? From: To: Time: Wed Oct 15 16:48:53 2008 Oh. Ew. From: To: Time: Wed Oct 15 16:48:58 2008 they operate in non-bytes on solaris under some compilation environments. From: To: Time: Wed Oct 15 16:49:33 2008 Then there's also the question of incomplete and invalid UTF-8 codes. Like I said, you are so doomed. From: To: Time: Wed Oct 15 16:50:32 2008 C99 says maximum number of bytes to write. What we actually care about in most of these cases is maximum number of bytes to read, which could theoretically be different. From: To: Time: Wed Oct 15 16:54:40 2008 in a multibyte character locale, interpretation of %.*s in terms of multibyte characters instead of bytes could read more bytes than expected. consider the gss_buffer_t case. From: To: Time: Wed Oct 15 16:57:31 2008 Perhaps we should convert the gss_buffer_t to a null-terminated string (allocating temporary space) for printing. That doesn't help us when we want to truncate, but most of the time we don't need to. From: To: Time: Wed Oct 15 16:57:38 2008 Outside of syslog calls I think? From: To: Time: Wed Oct 15 17:02:26 2008 actually the solaris printf family counts screen columns, not mbcs From: To: Time: Wed Oct 15 17:02:50 2008 who knows what it actually does with zero-width characters. From: To: Time: Wed Oct 15 17:02:58 2008 Or tabs?? From: To: Time: Wed Oct 15 17:05:04 2008 Maybe we should punt on %.*s then, and use two tactics: (1) %s only and make a copy if we need to ensure null termination, and (2) [whatever we need to do to implement "substring" or "truncate" in cases with localization etc]. From: To: Time: Wed Oct 15 17:08:21 2008 ouch From: To: Time: Wed Oct 15 17:08:28 2008 or we beat up on sun for having such a broken printf From: To: Time: Wed Oct 15 17:09:59 2008 In what cases do we actually *require* truncation? Broken syslog implementations? (Are they still common?) Anything else? From: To: Time: Wed Oct 15 17:10:49 2008 maybe some admin wants long strings truncated in their log messages to avoid DoS attacks on their logging infrastructure. From: To: Time: Wed Oct 15 17:11:40 2008 What the admin wants is one thing, but we're hardcoding truncation, or not, currently. From: To: Time: Wed Oct 15 17:14:47 2008 good point. i guess part of the hardcoding is to get around limitations in our own syslog-like stuff. From: To: Time: Wed Oct 15 17:17:26 2008 I wouldn't necessarily expect other syslog implementations not to have built-in limits. Say, UDP packet size or something. From: To: Time: Wed Oct 15 17:17:53 2008 so we can make that limit configurable, or attempt to determine what the OS syslog limitations are at build time. From: To: Time: Wed Oct 15 17:26:48 2008 Sometimes we're constructing an error string with a variable component which gets stuffed into a fixed-length buffer. From: To: Time: Wed Oct 15 17:27:08 2008 For that I'd use snprintf. From: To: Time: Wed Oct 15 17:29:29 2008 snprintf sounds like a great idea for many things if we know it's implemented correctly From: To: Time: Wed Oct 15 17:32:47 2008 If you don't use precision specifiers and don't use the return value, I'm not aware of any implementation flaws we should worry about. From: To: Time: Wed Oct 15 17:33:12 2008 (Our asprintf fallback uses the return value, but I think is clever about the different implementations.) From: To: Time: Wed Oct 15 17:41:54 2008 AFAIK the return value always complies with one of the two specs. If the string got truncated, either you get a negative value or you get the length it would've had. From: To: Time: Wed Oct 15 17:42:58 2008 Heading out to a meeting. Back online later... From: To: Time: Wed Oct 15 18:04:28 2008 argh my menubar is twitching because my battery charge is alternating between 99% and 100% From: To: Time: Wed Oct 15 18:09:17 2008 If someone from here winds up responding to Stephen Ince, you might mention that his message got lost amidst the strcpy debate because he did reply-and-change-subject. From: To: Time: Wed Oct 15 18:09:28 2008 (Depending on people's mode of reading the list, of course.) From: To: Time: Wed Oct 15 18:09:34 2008 I don't know the answer to his question myself. From: To: Time: Wed Oct 15 18:10:25 2008 does your mail reader promote that sort of thing to a thread root? From: To: Time: Wed Oct 15 18:12:30 2008 hm, looks like he's an Outlook user. is that sort of user behavior promoted by some of Outlook's UI? From: To: Time: Wed Oct 15 18:15:43 2008 SUSv3 is XBD/XPG-6? From: To: Time: Wed Oct 15 18:15:56 2008 Outlook probably does not have a UI for "figure out what mailing list this message is from and post a new non-reply message to that list". It seems likely, that most people, regardless of MUA, habitually start new mail both to lists and personally by replying to some existing message. From: To: Time: Wed Oct 15 18:15:59 2008 No, my mail reader puts the message in the thread, even though it was on an entirely different topic. I don't think that behavior is promoted by any specific mail client; anything with a "reply" function allows it. From: To: Time: Wed Oct 15 18:16:49 2008 It looks like the vast majority of strcpy/strcat usages in krb5 can be replaced with either strdup or asprintf. From: To: Time: Wed Oct 15 18:16:51 2008 that user behavior is kind of problematic for those of us who get lots of mail. ah well. From: To: Time: Wed Oct 15 18:28:53 2008 Greg, does your mail reader at least show the new subject? From: To: Time: Wed Oct 15 18:43:10 2008 Yes and no. The subject was indented far enough to the right due to the threaded message display that it didn't appear in the message list. From: To: Time: Wed Oct 15 18:44:10 2008 ah. i use gnus and at some point configured it so that it would at least promote the message having the new subject to a top level so it is more visible. From: To: Time: Wed Oct 15 20:39:43 2008 The only inconsistency I know of for strlcpy/strlcat is the return value of strlcat when the destination buffer has no terminator (which is invalid input). From: To: Time: Thu Oct 16 10:59:00 2008 power shutdown originally scheduled for tomorrow morning has been cancelled From: To: Time: Thu Oct 16 12:07:04 2008 working from home, btw From: To: Time: Thu Oct 16 12:43:17 2008 Ron Rivest is talking tonight on security in voting systems. From: To: Time: Thu Oct 16 13:05:39 2008 tests/misc/test_cxx_krb5 isn't building for me due to an inability to find libcom_err in the rpath when it links libkrb5. Adding -lcom_err to the link line makes it build. Familiar to anyone? From: To: Time: Thu Oct 16 13:06:40 2008 Yeah, a bit... From: To: Time: Thu Oct 16 13:07:27 2008 On at least some of the systems, the linker wants to check all the dependencies, but apparently library dependencies not directly listed on the command line may not be sought in the -L directories. Or something like that. From: To: Time: Thu Oct 16 13:07:48 2008 If you install the libraries before building the test program, it'll probably work fine too. From: To: Time: Thu Oct 16 13:07:56 2008 looks like the link lines don't use the various macros we usually use for "bunches of library names" From: To: Time: Thu Oct 16 13:08:21 2008 Probably true, I don't remember if that was intentional, probably not. From: To: Time: Thu Oct 16 13:09:38 2008 ok, perhaps someone here knows. when windows displays a popup about signed code, etc., does it only display the CommonName on the cert? From: To: Time: Thu Oct 16 13:09:43 2008 The -rpath-link linker option can apparently be used to provide a path to use for library dependencies only while linking, but that's almost certainly gnu-specific. From: To: Time: Thu Oct 16 13:10:13 2008 (Vaguely related to that, we should eventually make krb5-config *not* list all the indirect dependencies. It means among other things that we can never get rid of libkrb5support.0 even though no application (outside of maybe stuff in the krb5 tree) needs to directly use anything in it.) From: To: Time: Thu Oct 16 13:10:47 2008 That would probably be an improvement anyways. We could add it in shlib.conf, which is platform-dependent anyways. From: To: Time: Thu Oct 16 13:10:48 2008 whether or not krb5-config lists the indirect dependencies really depends on specifics about the linker operation on a platform. From: To: Time: Thu Oct 16 13:11:24 2008 True, but I think on most of them we don't need to list them. From: To: Time: Thu Oct 16 13:11:43 2008 What platform doesn't have shared library dependencies? From: To: Time: Thu Oct 16 13:12:24 2008 i don't recall. at some point while putting together the current shared library support, at least one platform required that all dependencies be listed explicitly at link time. From: To: Time: Thu Oct 16 13:16:04 2008 Solaris I think? It might've been due in part to the not-checking--L-directories thing. So you could link against -lkrb5 if the library was installed, or -L.../lib -lkrb5 -lk5crypto -lblahblahblah. From: To: Time: Thu Oct 16 13:19:18 2008 Looks like tests/misc/Makefile.in is inconsistent with the rest of tests, and should be using KRB5_BASE_LIBS. I'll fix. From: To: Time: Thu Oct 16 13:59:51 2008 Tom, where did you say RT gets installed from? (I just want to put the Coverity run book near there.) From: To: Time: Thu Oct 16 14:00:57 2008 Nevermind, I'll just put it in /mit/krbdev/coverity since that's where the tar files are. From: To: Time: Thu Oct 16 14:15:09 2008 cvs repository cvs.mit.edu:/cvs/krbdev is where our RT source lives, under tracking/rt From: To: Time: Fri Oct 17 14:18:01 2008 I'm back. From: To: Time: Fri Oct 17 15:59:41 2008 On windows, can I expect that the various krb5 dlls use the same C runtime? (ie: krb5, gss, etc) From: To: Time: Fri Oct 17 15:59:52 2008 (I know I can't expect the caller and krb5 libs to use the same ones) From: To: Time: Fri Oct 17 16:01:02 2008 i think so but i haven't seen it documented From: To: Time: Fri Oct 17 16:01:04 2008 The reason I'm asking is that I want to use krb5_build_principal_va in KIM but krb5_build_principal_va doesn't allocate the krb5_principal_data struct. I want to know if I can safely malloc the struct in kim and have krb5_free_principal DTRT From: To: Time: Fri Oct 17 16:01:31 2008 wait one of the build_principal functions allocates the struct and one doesn't? From: To: Time: Fri Oct 17 16:01:44 2008 lxs, it was considered a requirement that gss, krb5, and support libs (not including wshelp32, leash, ...) to be from the same distribution From: To: Time: Fri Oct 17 16:02:27 2008 krb5_error_code KRB5_CALLCONV_C krb5_build_principal (krb5_context, krb5_principal *, unsigned int, const char *, ...) krb5_error_code KRB5_CALLCONV krb5_build_principal_va (krb5_context, krb5_principal, unsigned int, const char *, va_list); note the lack of a * on the krb5_principal argument in krb5_build_principal_va From: To: Time: Fri Oct 17 16:02:56 2008 also: krb5_principal pr_ret = (krb5_principal)malloc(sizeof(krb5_principal_data)); if (!pr_ret) return ENOMEM; va_start(ap, realm); retval = krb5_build_principal_va(context, pr_ret, rlen, realm, ap); va_end(ap); is how krb5_build_principal calls krb5_build_principal_va From: To: Time: Fri Oct 17 16:03:20 2008 and there's no krb5_free_principal_contents From: To: Time: Fri Oct 17 16:03:25 2008 oh. that seems kind of broken. From: To: Time: Fri Oct 17 16:03:41 2008 tlyu++ From: To: Time: Fri Oct 17 16:03:56 2008 anyway, I will call malloc from KIM since it sounds like that is safe for Windows From: To: Time: Fri Oct 17 16:03:57 2008 And build_principal_ext allocates too. From: To: Time: Fri Oct 17 16:04:24 2008 (but the weirdness with krb5_build_principal_va is why KIM had its own implementation From: To: Time: Fri Oct 17 16:04:28 2008 I would prefer to see that any object malloc'd from a library be free'd from a function in that library From: To: Time: Fri Oct 17 16:04:45 2008 the mixed C runtime problem is still prevalent in windows? From: To: Time: Fri Oct 17 16:04:45 2008 Me too. From: To: Time: Fri Oct 17 16:05:08 2008 well once we have a krb5_build_principal_va_doesnt_suck, I can switch to that. I will put a comment in there talking about it. From: To: Time: Fri Oct 17 16:05:29 2008 Go ahead and create it. From: To: Time: Fri Oct 17 16:05:43 2008 mixed C runtime problem will always be true on Windows. C runtime is not part of the OS. From: To: Time: Fri Oct 17 16:06:08 2008 what should I name it? From: To: Time: Fri Oct 17 16:06:24 2008 (clearly my example name is not really... professional) From: To: Time: Fri Oct 17 16:06:37 2008 krb5_build_principal_va2? From: To: Time: Fri Oct 17 16:06:48 2008 build_principal_alloc_va? From: To: Time: Fri Oct 17 16:06:50 2008 krb5_build_principal_va_alloc ? I dunno. From: To: Time: Fri Oct 17 16:07:31 2008 List all permutations of "build_principal", "va", and "alloc" on a sheet of paper, stick it on a dartboard, .... From: To: Time: Fri Oct 17 16:08:31 2008 the quarter in my pocket says krb5_build_principal_alloc_va From: To: Time: Fri Oct 17 16:08:35 2008 i think build_principal_va is the only example of a stdarg function in our API so we can't really build upon an existing pattern. From: To: Time: Fri Oct 17 16:09:13 2008 we should also have comments clarifying that the other build_principal functions do allocate despite the lack of "alloc" in their names. From: To: Time: Fri Oct 17 16:09:40 2008 krb5_vset_error_message From: To: Time: Fri Oct 17 16:09:49 2008 pattern? what pattern? From: To: Time: Fri Oct 17 16:10:05 2008 i'm sorry, i'll have to report you to the API naming police. From: To: Time: Fri Oct 17 16:10:22 2008 that's why I was suggesting krb5_build_principal_va_2 (which does match our naming conventions) From: To: Time: Fri Oct 17 16:10:57 2008 or did we get rid of those functions? From: To: Time: Fri Oct 17 16:11:05 2008 which? From: To: Time: Fri Oct 17 16:11:07 2008 ah wait no, it's _ext From: To: Time: Fri Oct 17 16:11:16 2008 krb5_build_principal_va_ext ;-) From: To: Time: Fri Oct 17 16:11:48 2008 Except build_principal_ext takes {int, char *} pairs, so it'd be misleading if _va_ext wanted just char*... From: To: Time: Fri Oct 17 16:11:50 2008 it can go with krb5_build_principal_ext From: To: Time: Fri Oct 17 16:12:06 2008 ah true From: To: Time: Fri Oct 17 16:12:17 2008 what are the extra ints for? From: To: Time: Fri Oct 17 16:12:37 2008 length/ptr pairs. in case you have \0 in your principal names i guess. From: To: Time: Fri Oct 17 16:12:39 2008 character counts From: To: Time: Fri Oct 17 16:12:53 2008 ahh From: To: Time: Fri Oct 17 16:12:55 2008 or if you're using unterminated strings. From: To: Time: Fri Oct 17 16:13:06 2008 true, from gss buffers or krb5_data... From: To: Time: Fri Oct 17 16:13:09 2008 or if you want to do some weird zero-copy thing by taking an initial substring. From: To: Time: Fri Oct 17 16:13:15 2008 yeah the kim version of these functions only takes nul terminated strings From: To: Time: Fri Oct 17 16:20:09 2008 vkrb5_build_principal :-) From: To: Time: Fri Oct 17 16:21:39 2008 or krb5_vbuild_principal From: To: Time: Fri Oct 17 16:22:08 2008 relatedly, do we have function names indistinguishable in the first 31 characters? From: To: Time: Fri Oct 17 16:22:22 2008 should I deprecate krb5_build_principal_va? From: To: Time: Fri Oct 17 16:22:44 2008 I suspect kim has sone From: To: Time: Fri Oct 17 16:22:46 2008 ur some From: To: Time: Fri Oct 17 16:23:47 2008 actually counting it looks like kim is okay From: To: Time: Fri Oct 17 16:23:56 2008 maybe some of the internal functions, but nothing in the export list From: To: Time: Fri Oct 17 16:24:32 2008 (and internal functions can always be fixed when we port to a compiler that has the problem. I assume it will complain about conflicting prototypes) From: To: Time: Fri Oct 17 16:26:35 2008 krbv5_build_pvincival From: To: Time: Fri Oct 17 16:27:30 2008 should I deprecate krb5_build_principal_va? I can;t see how you can use it reasonably From: To: Time: Fri Oct 17 16:27:37 2008 there's no way to free the contents From: To: Time: Fri Oct 17 16:28:56 2008 or add a krb5_free_principal_contents... :-) From: To: Time: Fri Oct 17 16:29:04 2008 that seems more wrong From: To: Time: Fri Oct 17 16:29:06 2008 :-) From: To: Time: Fri Oct 17 16:30:25 2008 We have free_*_contents for lots of other things already. From: To: Time: Fri Oct 17 16:33:28 2008 oh crud, I failed to realize that the patch I got was wrong. I can't use krb5_build_principal_va to implement kim_identity_create_from_components From: To: Time: Fri Oct 17 16:33:29 2008 First _31_ characters? What happened to "first 6 characters" ? :-) From: To: Time: Fri Oct 17 16:33:49 2008 first 6 was a c89 limitation From: To: Time: Fri Oct 17 16:34:30 2008 unless you can tack another argument onto the front of the va_list From: To: Time: Fri Oct 17 16:34:34 2008 First 6 was a pre-c89 limitation. Was it still there in 89; I don't remember. From: To: Time: Fri Oct 17 16:34:53 2008 Sadly, you cannot. From: To: Time: Fri Oct 17 16:35:11 2008 fairly sure that c89 had 6 for external symbols From: To: Time: Fri Oct 17 16:36:08 2008 I'm going to skip on committing these changes until after KfM 6.5b1. This is way more complicated than just "taking a patch". From: To: Time: Fri Oct 17 16:38:22 2008 No, no portable way to change a va_list. You're *very* limited in what you can do with it. From: To: Time: Fri Oct 17 16:39:05 2008 And unfortunately, there's also no portable way to _construct_ one. From: To: Time: Fri Oct 17 16:40:37 2008 Oh, BTW, in heimdal, krb5_build_principal_va takes a krb5_principal * From: To: Time: Fri Oct 17 16:44:22 2008 yeah I figured heimdal would have gotten that right From: To: Time: Fri Oct 17 16:44:32 2008 I'm sure the lack of * was a typo that got out From: To: Time: Fri Oct 17 16:44:46 2008 Why isn't there krb5_build_principalv (that takes a char**) ? From: To: Time: Fri Oct 17 16:45:10 2008 Or maybe that should be krb5_build_principav :-) From: To: Time: Fri Oct 17 16:47:19 2008 anyway c89 said that the 6-character case-insensitive restriction is a concession to obsolescent implementations even back then. From: To: Time: Fri Oct 17 17:33:58 2008 hm kfM 5.6b1 has issues. there's going to be a KfM 6.5b2 From: To: Time: Fri Oct 17 17:34:18 2008 I guess I haven't shipped it so I could delete the tags From: To: Time: Fri Oct 17 17:34:54 2008 that's fine From: To: Time: Fri Oct 17 18:05:44 2008 fix for 6016 applied. From: To: Time: Fri Oct 17 18:14:58 2008 okay that will end up in KfM 6.5b1 From: To: Time: Sun Oct 19 02:02:27 2008 This room is not anonymous. From: To: Time: Mon Oct 20 14:02:44 2008 It looks like our repository could use some svn:ignore properties at some point. From: To: Time: Mon Oct 20 14:03:50 2008 I think we have some, though probably mainly for handling temp files created in the source tree during offset builds, not stuff generated while building in the source tree. Feel free to update... From: To: Time: Mon Oct 20 14:06:20 2008 Yeah, I'll get around to it at some point. From: To: Time: Mon Oct 20 14:10:00 2008 I'm going to create an umbrella ticket for getting rid of SECURE_CODING defects (strcpy/strcat/etc.) and make commits pursuant to that reference the ticket but keep it open until the last one. If that's sane. From: To: Time: Mon Oct 20 15:01:01 2008 does anyone have a clue what's up with Stephen Ince's situation? From: To: Time: Mon Oct 20 15:03:32 2008 Is there some reason to think it isn't what you already hypothesized? From: To: Time: Mon Oct 20 15:08:13 2008 Ooh, hey, we have the same misconception about #include "foo" as Subversion does. (Harmless.) From: To: Time: Mon Oct 20 15:13:18 2008 which misconception? From: To: Time: Mon Oct 20 15:15:24 2008 So, there's #include and #include "foo". The real effect of #include "foo" is to try the current directory before the include path. From: To: Time: Mon Oct 20 15:15:44 2008 Yes, what else would it do? From: To: Time: Mon Oct 20 15:15:45 2008 But it's common in multi-directory projects to use #include "foo" for all project-specific headers. It may even be a useful documentation foible. From: To: Time: Mon Oct 20 15:15:55 2008 But it has nothing to do with the behavioral difference between "foo" and To: Time: Mon Oct 20 15:15:58 2008 Er, and . From: To: Time: Mon Oct 20 15:16:36 2008 It does in a single-directory project where you don't bother to -I. From: To: Time: Mon Oct 20 15:17:02 2008 there may be a handful of .c files where we actually do mean to use #include "foo" because we don't build with a -I directive pointing to the current directory. From: To: Time: Mon Oct 20 15:17:12 2008 Which is to say, it likely came about because of the behavioral difference. From: To: Time: Mon Oct 20 15:18:03 2008 Yeah, it's just an extension of the habit from single-directory projects. It's completely harmless. From: To: Time: Mon Oct 20 15:18:38 2008 It's mostly harmless From: To: Time: Mon Oct 20 15:19:22 2008 relatedly, i have in the past thought of a good argument for sorting #include directives From: To: Time: Mon Oct 20 15:19:31 2008 Oh, oops. For the sake of precision, the effect of #include "foo" is to try the source directory before the include path. (Not the current directory as I said about.) From: To: Time: Mon Oct 20 15:19:52 2008 Er, above. Maybe precision is not in the cards today. From: To: Time: Mon Oct 20 15:20:57 2008 in most unix-like environments, #include "foo" means try the directory in which the file with that statement lives first. i think the standard allows it to be completely implementation-defined. From: To: Time: Mon Oct 20 15:21:32 2008 I believe Tom is correct, though POSIX might have something to say about it. From: To: Time: Mon Oct 20 15:52:01 2008 preferences on food tomorrow? From: To: Time: Mon Oct 20 15:53:22 2008 No preference. From: To: Time: Mon Oct 20 15:53:31 2008 pizza or chinese; i had salad today. From: To: Time: Mon Oct 20 16:03:09 2008 src/util/ss/utils.c:str_concat3 is... puzzling. From: To: Time: Mon Oct 20 16:04:27 2008 that's kind of special. From: To: Time: Mon Oct 20 16:05:12 2008 that code obviously predates asprintf From: To: Time: Mon Oct 20 16:06:00 2008 by quite a while. go ahead and trash it... From: To: Time: Mon Oct 20 16:06:11 2008 why are we still using ss? From: To: Time: Mon Oct 20 16:06:13 2008 (1) It allocates two bytes for the terminating nul, not one, and (2) it concatenates the arguments in a-c-b order without mentioning that in the header. From: To: Time: Mon Oct 20 16:06:34 2008 From looking at the callers, (2) seems intentional if bizarre, and (1) seems irrelevant. From: To: Time: Mon Oct 20 16:07:42 2008 What would you like to replace ss with? I'd be happy to see it go. From: To: Time: Mon Oct 20 16:09:25 2008 I'm sure perl, python, ruby, etc., all have modules for reader loops of that sort, somewhere. With tclsh you could perhaps do it directly. From: To: Time: Mon Oct 20 16:10:00 2008 Love pointed me at something that he invented for heimdal. it looks like it is a superset of the ss functionality and also ties in with a command line parser and manpage generator. From: To: Time: Mon Oct 20 16:10:27 2008 python's is probably cmd: "cmd - A generic class to build line-oriented command interpreters." From: To: Time: Mon Oct 20 16:10:31 2008 sl? From: To: Time: Mon Oct 20 16:10:36 2008 yeah i think it was sl From: To: Time: Mon Oct 20 16:11:20 2008 from ubunutu: "libsl0-heimdal - Heimdal Kerberos - SL support library" From: To: Time: Mon Oct 20 16:11:37 2008 (I'd kind of like to see us move in the direction of making kadmin, ktutil, etc., scriptable.) From: To: Time: Mon Oct 20 16:11:55 2008 (Maybe not those programs, specifically, but make the functionality available.) From: To: Time: Mon Oct 20 16:11:56 2008 yeah, that could be useful. Note that the name is a swedish railfan joke. From: To: Time: Mon Oct 20 16:12:00 2008 having a real admin API first would be nice but i imagine some people aren't going to wait for that. From: To: Time: Mon Oct 20 16:12:16 2008 And like its namesake, sl works as a drop-in replacement for ss. From: To: Time: Mon Oct 20 16:13:14 2008 We could put together a package with a fairly simple API, say we're only going to support that API, and the primitives we export from C to implement it can be changed later. From: To: Time: Mon Oct 20 16:14:25 2008 In fact most of that API could be derived from the current CLI if you want to keep the process simple. From: To: Time: Mon Oct 20 16:14:28 2008 and use that as leverage to promote our new world order KDB interface? From: To: Time: Mon Oct 20 16:46:45 2008 I think Stephen Ince's problem is either that he has no clue what he's doing, or that he is unable to explain what he's doing, or both. From: To: Time: Mon Oct 20 17:02:11 2008 Yup, he definitely has no clue what he's doing. From: To: Time: Mon Oct 20 17:06:54 2008 i still can't tell what he's trying to do. From: To: Time: Mon Oct 20 17:08:26 2008 He's either trying to be an initiator or an acceptor, or both, or neither, in IE, or IIS, or apache, he's calling init_sec_context twice without sending the first output token anywhere, being confused that it returhed GSS_S_CONTINUE_NEEDED, and that it generates no network traffic. From: To: Time: Mon Oct 20 17:08:45 2008 And he doesn't understand what the req_flags mean From: To: Time: Mon Oct 20 17:10:45 2008 right. too much trouble to bother helping until he becomes less confused or less confusing. From: To: Time: Mon Oct 20 17:11:06 2008 Well, someone could ask him "what are you trying to do" and see where it goes From: To: Time: Mon Oct 20 17:11:17 2008 i thought i already asked. From: To: Time: Mon Oct 20 17:11:43 2008 Oh, maybe you did. From: To: Time: Mon Oct 20 17:12:07 2008 Well, good luck, if you care to keep trying. GONE From: To: Time: Tue Oct 21 17:45:28 2008 Does Apple use strlcpy? From: To: Time: Tue Oct 21 17:45:52 2008 unknown. From: To: Time: Tue Oct 21 17:46:13 2008 Okay. From: To: Time: Tue Oct 21 17:46:21 2008 it's present in libc on Leopard, so probably something uses it. From: To: Time: Tue Oct 21 17:46:48 2008 Okay. From: To: Time: Tue Oct 21 17:51:42 2008 some stuff in /bin uses strlcpy and strlcat. From: To: Time: Wed Oct 22 13:58:26 2008 i see no agenda from Love. are we having a call? heading upstairs shortly anyway. From: To: Time: Wed Oct 22 14:00:43 2008 there should be a call From: To: Time: Wed Oct 22 14:00:46 2008 likely he forgot From: To: Time: Wed Oct 22 16:42:30 2008 Should we implement my "refcount" idea for delaying the library fini functions? From: To: Time: Wed Oct 22 16:47:58 2008 did you describe this in mail somewhere? From: To: Time: Wed Oct 22 16:50:43 2008 (on phone, just a minute...) From: To: Time: Wed Oct 22 16:56:23 2008 I don't remember if I put it in email or just spouted some ideas here. The basic idea was, having the library loaded is one "reference" (after the init function runs, until the fini function runs), and certain existing objects like krb5_context or GSSAPI contexts would be additional references. When the ref count goes to zero, invoke the destructors. So if an app cleans up properly and then unloads the library, destructors run; if a multithreaded app exits (running fini functions) in one thread while another is messing around with a krb5 or gssapi context or other objects, then maybe they don't get run before the process exits. From: To: Time: Wed Oct 22 16:56:53 2008 If an app is sloppy and unloads a library while context objects exist but are no longer used, well, it's already leaking memory, now it would just leak some more. From: To: Time: Wed Oct 22 16:57:59 2008 The idea needs fleshing out (e.g., what if one thread is exiting, has run fini functions, but is delayed in exiting, while another thread destroys its krb5_context, causing destructors to run, and then it creates another), but I think the basic idea can fix some of our exiting-multithreaded-process issues. From: To: Time: Wed Oct 22 17:01:07 2008 we know there are already programs that have threads in our library when another thread is causing process termination. From: To: Time: Wed Oct 22 17:01:52 2008 Yes. I think this may fix those crashes. From: To: Time: Wed Oct 22 17:04:17 2008 A recent commit broke the KfM build: d: duplicate symbol _gss_mech_spnego in /Volumes/Ragna-Blade/Users/lxs/KfM/Build/KerberosLite/Kerberos.roots/Kerberos~sym/BuiltProducts/libgssapi_krb5.a(g_glue.o) and /Volumes/Ragna-Blade/Users/lxs/KfM/Build/KerberosLite/Kerberos.roots/Kerberos~sym/BuiltProducts/libgssapi_krb5.a(krb5_gss_glue.o) Was there a build system change I missed? From: To: Time: Wed Oct 22 17:06:56 2008 no, a code change, but that shouldn't have caused that. From: To: Time: Wed Oct 22 17:08:13 2008 is that a clean build? gssapiP_spnego.h changed in a way that might have caused that if some things didn't get rebuilt properly. From: To: Time: Wed Oct 22 17:08:21 2008 yes From: To: Time: Wed Oct 22 17:08:33 2008 One sec, I have a theory From: To: Time: Wed Oct 22 17:10:00 2008 hm no, that's not it. What I don't get is why gss_mech_spnego is being defined in g_glue.c. It only appears once in the file and it's a comparison. And there's no warning about missing definition From: To: Time: Wed Oct 22 17:10:35 2008 oh wait, where is it being defined? From: To: Time: Wed Oct 22 17:10:43 2008 gssapiP_spnego.h used to have a definition (not just declaration) of gss_mech_spnego, but now it's just a declaration and getting defined in mech_spengo.c From: To: Time: Wed Oct 22 17:10:51 2008 yeah, you need an extern in the header file and to have it be defined in one of the source files From: To: Time: Wed Oct 22 17:11:04 2008 oh is this the tentative definition stuff biting us? From: To: Time: Wed Oct 22 17:11:07 2008 okay, just an extern From: To: Time: Wed Oct 22 17:11:10 2008 yeah From: To: Time: Wed Oct 22 17:11:40 2008 it's treating the header prototype as a definition not a prototype. need an extern From: To: Time: Wed Oct 22 17:11:46 2008 ok, will fix. From: To: Time: Wed Oct 22 17:12:19 2008 probably on the second one too From: To: Time: Wed Oct 22 17:12:27 2008 ie: /* SPNEGO oid declarations */ extern const gss_OID_desc * const gss_mech_spnego; extern const gss_OID_set_desc * const gss_mech_set_spnego; From: To: Time: Wed Oct 22 17:12:34 2008 yeah i was going to do that too. you've confirmed that change works for you? From: To: Time: Wed Oct 22 17:12:37 2008 running a test build with that change From: To: Time: Wed Oct 22 17:13:04 2008 It probably wouldn't hurt us to use -fno-common on some other platforms. From: To: Time: Wed Oct 22 17:13:22 2008 so it would catch stuff like this? From: To: Time: Wed Oct 22 17:15:20 2008 I think so. From: To: Time: Wed Oct 22 17:15:47 2008 Maybe not for .a libraries, but for .so libraries I think it ought to. From: To: Time: Wed Oct 22 17:16:55 2008 A possible down side is, some variables might move from .bss to .data, depending on the tool chain. From: To: Time: Wed Oct 22 17:17:44 2008 well that may not be a big deal, depending on platform. From: To: Time: Wed Oct 22 17:19:34 2008 committed From: To: Time: Wed Oct 22 17:21:57 2008 it works From: To: Time: Wed Oct 22 17:25:03 2008 Yeah. And we don't have to add it for all platforms, but adding it for at least some will improve our chances of catching such things earlier. From: To: Time: Wed Oct 22 17:33:09 2008 Darn it, where's that foreign-language spam when you want it? From: To: Time: Wed Oct 22 17:34:53 2008 I'm trying to test a filter on the kerberos list to catch the spam using (I presume) 8-bit characters in subject lines, that show up in the moderation queue as "????????". But since I tweaked the rules a couple hours ago, nothing has shown up in the moderation queue. From: To: Time: Wed Oct 22 17:46:51 2008 forward some of your own spam to it ;-) From: To: Time: Wed Oct 22 17:48:02 2008 yeah but won't that train the spam filters to score all mail from Ken as spam? :-) From: To: Time: Wed Oct 22 17:48:02 2008 I could... I'd have to moderate myself first, but that's no big deal... gotta go for a prod staff meeting though. From: To: Time: Wed Oct 22 20:30:32 2008 still plowing through the patch list. a few more to go, but prob. not tonight. From: To: Time: Thu Oct 23 11:34:32 2008 looks like lxs has already gotten to some of the KIM patches, so i should go through and find those tickets to link up From: To: Time: Thu Oct 23 12:24:34 2008 Oh sorry, since we released KfM 6.5a5 I've been dealing with the patches. I need to keep them all in since to do release notes. I didn't realize you were still doing them From: To: Time: Thu Oct 23 12:24:55 2008 it was only when we were working really hard on KIM that I needed help From: To: Time: Thu Oct 23 12:25:39 2008 it's ok... i made one RT ticket per patch so we can keep track of them that way. it looks like you might have applied some equivalent patches in a few places. From: To: Time: Thu Oct 23 12:26:06 2008 just merge them in From: To: Time: Thu Oct 23 12:27:06 2008 can you send me your list with all the patches and their equivalent RT ticket numbers? I need to keep everyting in sync for release notes. Otherwise I won't give Love the right list From: To: Time: Thu Oct 23 12:28:49 2008 Basically as soon as a patch gets committed I need to know and what the ticket that fixed it is. At least one of the patches was also committed without a ticket and Love had to figure that one out himself when patch complained From: To: Time: Thu Oct 23 12:30:17 2008 i haven't been committing that many patches. they're mostly just pasted into RT so we can track them. could possibly update the subject lines with the Radar numbers if that helps. From: To: Time: Thu Oct 23 12:30:50 2008 I just don't see the RT tickets when they get created. I need to know what they are From: To: Time: Thu Oct 23 12:31:11 2008 otherwise when I make the release notes I won't realize they are a patch being applied. From: To: Time: Thu Oct 23 12:31:14 2008 oh, you're not on the bugs list? From: To: Time: Thu Oct 23 12:31:16 2008 no From: To: Time: Thu Oct 23 12:31:27 2008 current patch list is all tickets that are children of #6204 From: To: Time: Thu Oct 23 12:35:39 2008 okay From: To: Time: Thu Oct 23 12:47:49 2008 How do you match the ticket numbers with the patches? From: To: Time: Thu Oct 23 12:48:18 2008 if the ticket names were the patch names that would be a lot more useful From: To: Time: Thu Oct 23 12:48:35 2008 now I can't figure out which ones are patched From: To: Time: Thu Oct 23 12:51:13 2008 hm I need the big monitor to fix this. I think I'm going to have to come into work From: To: Time: Thu Oct 23 12:54:35 2008 i can update the ticket subjects with either Radar numbers or patch names, whichever is easier From: To: Time: Thu Oct 23 12:55:00 2008 he changes the numbers sometimes From: To: Time: Thu Oct 23 12:55:12 2008 at least having the patch name in each ticket would help a lot From: To: Time: Thu Oct 23 12:55:21 2008 probably also the patch From: To: Time: Thu Oct 23 12:55:43 2008 each patch is an attachment to the ticket From: To: Time: Thu Oct 23 12:56:07 2008 oh for some reason rt isn't doing them inline like it usually does From: To: Time: Thu Oct 23 12:56:41 2008 oh okay the patch names are there, just in tiny text in the lower right. I think I can deal with that From: To: Time: Thu Oct 23 12:56:57 2008 i attached them as files From: To: Time: Thu Oct 23 12:57:35 2008 Sorry, I didn't realize you had done all this work so I've been maintaining my own separate list. Now this is all out of sync and messed up and there are two tickets for half the patches. I'm going to have to spent today fixing this From: To: Time: Thu Oct 23 12:58:24 2008 (I'm also coming down with a cold and have a pounding headache, so sorry if I'm cranky) From: To: Time: Thu Oct 23 12:58:35 2008 are there some patches that you committed different versions of? i see some commits of things that might have similar functionality but don't have apple patch names on them. From: To: Time: Thu Oct 23 12:59:19 2008 yeah that's because my list on my computer is what I've been using to track the relationship between the patches and the tickets. When we last talked you said you would maintain a similar list not something in RT From: To: Time: Thu Oct 23 12:59:29 2008 Since I never saw such a list, I assumed it did not exist From: To: Time: Thu Oct 23 13:00:00 2008 yeah, sorry. i had been keeping a parallel list but decided that just plain putting the patches in RT would help to keep them from getting lost. From: To: Time: Thu Oct 23 13:00:04 2008 because we usually don't apply the patches verbatim. In fact for the KIM ones I never do because they usually are hacks, not correct architectural fixes. From: To: Time: Thu Oct 23 13:00:19 2008 okay, it would have been useful to know when that happened From: To: Time: Thu Oct 23 13:00:49 2008 That happened yesterday and the day before, I think. From: To: Time: Thu Oct 23 13:00:57 2008 could you send me your list and i can see if i can help sort them out? From: To: Time: Thu Oct 23 13:01:00 2008 So you're not *that* far behind the information curve. I think Tom assumed you would find out via the bug list. From: To: Time: Thu Oct 23 13:01:15 2008 I think two people working on the same thing is what got us into this mess. I will deal From: To: Time: Thu Oct 23 13:01:45 2008 we're duplicating work in different ways From: To: Time: Thu Oct 23 13:06:18 2008 The real problem here is that people are fixing the patches and committing with ticket: new so having the RT ticket numbers doesn't help. I've been getting the lists back in sync when I put out releases. Now I have to perform an extra step of merging two tickets together rather than just cutting and pasting a ticket number From: To: Time: Thu Oct 23 13:07:07 2008 yeah, the PO to get Best Practical to help us with the ticket number thing went through, so that particular pain could stop soon. From: To: Time: Thu Oct 23 13:13:55 2008 Greg, could you check #6247 to see if Coverity caught it? From: To: Time: Thu Oct 23 13:14:11 2008 Checking. From: To: Time: Thu Oct 23 13:16:37 2008 I don't think Coverity has a checker for that class of bug. From: To: Time: Thu Oct 23 13:16:55 2008 ok, it was producing a double-free down the road From: To: Time: Thu Oct 23 13:17:21 2008 It does have a double-free checker. But I think it would be reported in a caller. Do you know the caller in this case? From: To: Time: Thu Oct 23 13:18:43 2008 krb5_get_as_key_password in gic_pwd.c, i think. From: To: Time: Thu Oct 23 13:20:41 2008 Hm, that still doesn't have the entire double-free path. From: To: Time: Thu Oct 23 13:20:59 2008 oh right that goes through a callback somewhere in get_init_creds. From: To: Time: Thu Oct 23 13:21:25 2008 Callbacks are generally too complicated for Coverity to analyze. From: To: Time: Thu Oct 23 13:21:44 2008 (Anything that calls through a function pointer.) So, it's possible that this was caught, but I'm not sure where I'd look for it. From: To: Time: Thu Oct 23 13:25:44 2008 get_as_key_password is passed as a gak_fct argument to get_init_creds, and puts the generated key into the as_key variable in get_init_creds. From: To: Time: Thu Oct 23 13:26:33 2008 I don't see any USE_AFTER_FREE checker results in gic_* files; I doubt this was caught. From: To: Time: Thu Oct 23 13:26:55 2008 right, so this is a case where we need a dynamic checker From: To: Time: Thu Oct 23 13:28:20 2008 Yeah, and ideally a test suite with good code coverage. From: To: Time: Thu Oct 23 13:53:02 2008 Ezra was examining code coverage at one point, wasn't he? From: To: Time: Thu Oct 23 13:55:59 2008 okay, I think I have more of this in sync From: To: Time: Thu Oct 23 13:56:25 2008 sorry about not noticing the new bugs. I didn't realize I needed to be on that list From: To: Time: Thu Oct 23 13:57:32 2008 one of the problems with putting the patches in the bugs is that he changes the patches sometimes From: To: Time: Thu Oct 23 13:57:47 2008 so we may end up committing an out of date version of the patch From: To: Time: Thu Oct 23 13:58:17 2008 I know that the CommonCrypto patch has changed at least once. I think there was another one that is no longer open From: To: Time: Thu Oct 23 13:58:52 2008 looks like you have the most up to date version of the CommonCrypto patch there From: To: Time: Thu Oct 23 14:00:32 2008 I'm just a little concerned that tracking the uncommitted patches in RT means we now have two authoritative versions of the same information. Namely Love's submissions and our bug database. Since he doesn't really look at our bug database they could easily get out of sync if we don't constantly look at the open bugs From: To: Time: Thu Oct 23 14:01:36 2008 Also do you want me to merge the related bugs? there are several pairs of patches where one patch is a bug fix to the other and should really either both be committed or neither From: To: Time: Thu Oct 23 14:02:03 2008 For example: LHA-6293196-release-more.patch LHA-5926820-announce-realms.patch and DVG-manpage_fixes.patch LHA-5849353-no-ref-to-Kerberos.app.patch From: To: Time: Thu Oct 23 14:02:30 2008 LHA-3506795-start-renew-on-first-cred.patch LHA-3506795-kinit-bg-renew.patch are also a pair and depend on LHA-3506795-cc-gset-config.patch From: To: Time: Thu Oct 23 14:03:34 2008 I count 5 pair/triplets total From: To: Time: Thu Oct 23 14:03:38 2008 in my notes From: To: Time: Thu Oct 23 14:04:27 2008 I could imagine a case where the first patch looks mostly okay except for a minor bug, and the bug fix patch is ugly and not acceptable. But I expect that'll be rare, probably not worth worrying about too much. From: To: Time: Thu Oct 23 14:04:56 2008 most of them are "big patch" and "tiny bug fix to patch" From: To: Time: Thu Oct 23 14:05:19 2008 there are also some "big patch" and "config file support for patch" where the latter is necessary to make the former work From: To: Time: Thu Oct 23 14:06:11 2008 And if we don't like the approach they used for the config file changes, then we get to rewrite the second, and there may be little point in applying the first until that's done. From: To: Time: Thu Oct 23 14:06:29 2008 I could imagine that situation coming up... From: To: Time: Thu Oct 23 14:06:41 2008 well for the most part the config file changes are modifications to the KfM Makefile From: To: Time: Thu Oct 23 14:06:50 2008 they are "install this file only on Mac" From: To: Time: Thu Oct 23 14:07:55 2008 Also it seems to me that if we apply part of the functionality he wants we should open a new bug and let him know. In some cases we've had two patches that apply functionality and we've taken 50% of each patch From: To: Time: Thu Oct 23 14:08:15 2008 So I don't think keeping them separate keeps us from falling into that traP From: To: Time: Thu Oct 23 14:08:22 2008 Ah. Hm. Well, if the main patch is KfM-only, combining would make sense. If it applies to our "darwin-ish" builds, maybe not... From: To: Time: Thu Oct 23 14:08:32 2008 we took part of LW_net_trans.patch From: To: Time: Thu Oct 23 14:08:37 2008 (for example) From: To: Time: Thu Oct 23 14:09:08 2008 Hm, yeah. From: To: Time: Thu Oct 23 14:09:42 2008 And I took part of LHA-5168336-split-build.patch at least 3 times ;-) From: To: Time: Thu Oct 23 14:09:51 2008 Line by line, really From: To: Time: Thu Oct 23 14:11:28 2008 Folks need to look at LHA-3506795-start-renew-on-first-cred.patch LHA-3506795-kinit-bg-renew.patch and decide if they like the design. Russ Allberry's equivalent functionality creates a new program krenew instead of overloading kinit with extra functionality. I prefer that solution but would like team input From: To: Time: Thu Oct 23 14:11:43 2008 they are RT 6239] Apple patch: kinit background renewal job [RT 6237] Apple patch: start renewal task out of launchd From: To: Time: Thu Oct 23 14:11:58 2008 (for those looking at RT) From: To: Time: Thu Oct 23 14:12:42 2008 I'm also a little disturbed that it uses the functionality in launchd to restart crashed servers to poll From: To: Time: Thu Oct 23 14:13:11 2008 (and the fact that it polls in the first place is upsetting since we specifically added functionality to the CCAPI so it wouldn't have to poll) From: To: Time: Thu Oct 23 15:09:49 2008 Yeah, overall the design looks poor... Russ's idea is probably better, especially if it waits for expiry time or cred cache changes (in case new tickets were acquired with a different, possibly shorter, lifetime). From: To: Time: Thu Oct 23 15:17:31 2008 the issue is that they seem to have a requirement that there be no long running processes. the thing I don't get is how having a long running process that is sleeping is worse than launching and quitting a process every 10 minutes From: To: Time: Thu Oct 23 15:18:38 2008 That patch appears to be against a different version of the kinit source than ours. From: To: Time: Thu Oct 23 15:18:47 2008 yeah it's against the KIM kinit From: To: Time: Thu Oct 23 15:18:54 2008 which is in the KfM tree From: To: Time: Thu Oct 23 15:19:10 2008 obviously the KIM kinit is useless to regular krb5 until KIM gets ported From: To: Time: Thu Oct 23 15:19:18 2008 Understood. From: To: Time: Thu Oct 23 15:19:36 2008 (That also explains the use of KIM and CCAPI functions which would have been rather out of place in the regular krb5 kinit.) From: To: Time: Thu Oct 23 15:19:37 2008 there are KIM versions of all the tools, as well as a kswitch, which is a CCAPI thing From: To: Time: Thu Oct 23 15:20:06 2008 kswitch changes the default ccache used by the CCAPI. it is the moral equivalent of setting KRB5CCNAME From: To: Time: Thu Oct 23 15:21:15 2008 they all live in KerberosClients at the top level of the KfM tree From: To: Time: Thu Oct 23 15:22:29 2008 Yeah, I see them. From: To: Time: Thu Oct 23 15:34:33 2008 With KIM living in the krb5 tree, I think the krb5 tree would be a reasonable place for the KIM kinit, unless it's also KfM-specific in other ways; we just wouldn't build it for UNIX. Like how we include some command-line programs that we only build on Windows. But, whatever, not a big deal. From: To: Time: Thu Oct 23 15:39:46 2008 it's in the KfM tree because that's where the tools always were. They also depend on the CCAPI From: To: Time: Thu Oct 23 15:40:42 2008 Obviously they can be moved as soon as another platform is using KIM. Before that I'd prefer not to open the "where do they go in the tree" can of worms ;-) From: To: Time: Thu Oct 23 15:42:53 2008 If you tell me where they should go, I'm happy to move them, of course From: To: Time: Thu Oct 23 16:09:16 2008 Anyone sitting on thoughts about the string-handling stuff before I go back to krbdev? From: To: Time: Thu Oct 23 16:10:29 2008 You are doomed. From: To: Time: Thu Oct 23 16:10:41 2008 That's a good thought! From: To: Time: Thu Oct 23 16:16:05 2008 No more thoughts here. Well, not about string handling. I need to move a bunch of furniture out of my living room tonight and tomorrow night. Leaves are starting to fall, and will clog gutters. Andrew should be done with his meeting already, or soon. RSI sucks. Apple's iCal has some weird UI quirks. I had a question to ask Paul about Touchstone but have forgotten it. (Etc.) From: To: Time: Thu Oct 23 17:37:01 2008 Would krb5int_buf_add_len or following calls get horribly confused if there's a \0 in the LEN bytes at DATA? From: To: Time: Thu Oct 23 17:38:10 2008 And we might want a krb5int_buf_add_data(....., krb5_data data). From: To: Time: Thu Oct 23 17:39:06 2008 _add_buf() too. From: To: Time: Thu Oct 23 18:06:12 2008 I'll see if it helps any existing code. From: To: Time: Thu Oct 23 18:06:48 2008 NULs in counted data would probably not be a problem if you can handle it in the result. From: To: Time: Fri Oct 24 13:29:46 2008 gic_pwd.c line 124 doesn't look right. From: To: Time: Fri Oct 24 13:33:49 2008 A zero-length string indicates no password being passed, but it still supplies the buffer for use by the prompter function for the reply. (I think... just took a quick look.) From: To: Time: Fri Oct 24 13:37:08 2008 So a krb5_data's length field sometimes means "the length of the string" and sometimes means "the size of the allocated data"? And in the case of that specific use of pw0, it can mean either, depending on the value? From: To: Time: Fri Oct 24 13:43:15 2008 i think there is no explicit contract about krb5_data.length being usable to indicate "max length" From: To: Time: Fri Oct 24 13:49:01 2008 or maybe we actually use it in the case of prompter functions, it looks like. From: To: Time: Fri Oct 24 13:51:42 2008 My real concern here is that pw0's length is sometimes being set to the length of the supplied password and sometimes being set to the size of the buffer, in the same code block. Even if that results in the correct behavior from krb5_get_initial_creds, it's insane. From: To: Time: Fri Oct 24 13:55:41 2008 "Oh, that." Yeah, it's unfortunate... From: To: Time: Fri Oct 24 13:58:33 2008 i wonder if heimdal is any more sane about that interface. From: To: Time: Fri Oct 24 15:53:14 2008 I think -Wconversion may be going overboard. From: To: Time: Fri Oct 24 15:53:34 2008 (After a bit of experience with it.) From: To: Time: Fri Oct 24 15:55:58 2008 Probably. To make things more annoying, different versions of gcc have changed the meaning of it, though the specifics escape me. From: To: Time: Fri Oct 24 15:58:10 2008 "-Wconversion is designed to help moving K&R to ISO C, nothing more." From: To: Time: Fri Oct 24 15:58:33 2008 (From a 2003 mail thread.) From: To: Time: Fri Oct 24 16:01:10 2008 i think it might be in there from when we had some issues with narrow types showing up in K&R function definitions. From: To: Time: Fri Oct 24 16:03:55 2008 I think I'm seeing a zillion more warnings than most people because my build platform has 64-bit long and size_t. From: To: Time: Fri Oct 24 16:04:20 2008 You think that is uncommon? From: To: Time: Fri Oct 24 16:04:44 2008 If other people on the team are building on 32-bit platforms, yes. From: To: Time: Fri Oct 24 16:08:37 2008 Yeah, I think both the linux and mac platforms default to building in 32-bit mode. (Mac can build universal, which makes things interesting, but by default does native only.) From: To: Time: Fri Oct 24 16:11:04 2008 Actually, in unix-style builds, we can't do universal binaries, because configure wants to run cpp, and you can't do preprocessing in multiple-arch mode. (Which set of predefined macros would you use?) From: To: Time: Fri Oct 24 16:12:04 2008 Oh, maybe I'm wrong. I was changing CC, which didn't work, but maybe via CFLAGS... From: To: Time: Fri Oct 24 16:12:58 2008 The mac build system builds 64 bit by default From: To: Time: Fri Oct 24 16:13:05 2008 if you run the full builds From: To: Time: Fri Oct 24 16:13:34 2008 KfM, you mean, not the UNIX-style builds. From: To: Time: Fri Oct 24 16:13:37 2008 yes From: To: Time: Fri Oct 24 16:14:16 2008 oh actually nevermind. It only builds 64 bit at Apple From: To: Time: Fri Oct 24 16:14:30 2008 though you can ask it to do so pretty easily from the Makefile From: To: Time: Fri Oct 24 16:15:21 2008 Just edit the part that says: # determining the architecture: ifeq ($(shell arch), i386) ARCH_ARGS = -arch i386 -arch ppc else ARCH_ARGS = -arch ppc endif From: To: Time: Fri Oct 24 16:15:37 2008 I think it's named x86_64 From: To: Time: Fri Oct 24 16:18:58 2008 In the UNIX builds, configuring with CFLAGS="-arch i386 -arch ppc64 -O2 -g -Wthis -Wthat" seems to work. The various -W flags are automatically added only if you don't set CFLAGS though. From: To: Time: Fri Oct 24 16:19:37 2008 are you going to want an option to request adding the battery of extra warning flags even if CFLAGS is set? From: To: Time: Fri Oct 24 16:22:34 2008 btw, in bld_pr_ext.c is it just my imagination or should the freeing code while (i-- >= 0) krb5_xfree(princ_data[i].data); really be: while (--i >= 0) krb5_xfree(princ_data[i].data); From: To: Time: Fri Oct 24 16:24:40 2008 (or actually maybe something more complicated if i is the last element since my suggestion will skip the last element) From: To: Time: Fri Oct 24 16:25:16 2008 while(i-- > 0)  krb5_xfree(princ_data[i].data); should work From: To: Time: Fri Oct 24 16:27:31 2008 We could also do the reverse -- make "--enable-universal" (a mac/darwin-only option) add -arch options to CFLAGS along with -O2 -g -Wthis -Wthat... From: To: Time: Fri Oct 24 16:28:44 2008 Hm, yeah, looks wrong, I think. From: To: Time: Fri Oct 24 16:29:02 2008 As is I think the code does a krb5_xfree(princ_data[-1].data); From: To: Time: Fri Oct 24 16:30:17 2008 I noticed that when I was rewriting the krb5_build_principal non-ext functions From: To: Time: Fri Oct 24 16:32:49 2008 Depends. If i starts out as the number of entries, then the original is wrong and both of your rewrites are correct (and equivalent). If i starts out as the highest index, then all three versions are wrong. From: To: Time: Fri Oct 24 16:40:32 2008 ah yeah, you're right. I'm spacing From: To: Time: Fri Oct 24 16:40:50 2008 it looks like it is the highest index based on the code From: To: Time: Fri Oct 24 16:43:21 2008 Right, so you need something like while (i >= 0) krb5_xfree(princ_data[i--].data); From: To: Time: Fri Oct 24 16:43:31 2008 yeah From: To: Time: Fri Oct 24 16:45:32 2008 oh hm wait no i is the number of entries but this is all silly because there is a "count" variable too From: To: Time: Fri Oct 24 16:46:14 2008 for (i = 0; i < count; i++) krb5_xfree(princ_data[i].data); is a lot more readable From: To: Time: Fri Oct 24 16:46:30 2008 Yes From: To: Time: Fri Oct 24 16:48:07 2008 ah wait except it can get there from when it fails to malloc. I think "i" is the number of entries. Whatever is in i is invalid (either malloc failed or it finished and the i To: Time: Fri Oct 24 16:48:11 2008 arrgh From: To: Time: Fri Oct 24 16:52:10 2008 I think while (--i >= 0)     krb5_xfree(princ_data[i].data); Is the best I'm going to get without introducing more variables From: To: Time: Fri Oct 24 16:53:09 2008 So i is the count? From: To: Time: Fri Oct 24 16:54:13 2008 i is the index. count is the count. From: To: Time: Fri Oct 24 16:54:38 2008 at the point where it jumps to free_out, i is the index of the element being malloced From: To: Time: Fri Oct 24 16:54:54 2008 Which makes it the count of elements that need to be freed. From: To: Time: Fri Oct 24 16:55:52 2008 All this memory management crap just sucks. There's no excuse for running out of memory these days. If you manage to do so, your machine should just crash. :-) From: To: Time: Fri Oct 24 16:56:00 2008 yeah I committed a fix [RT 6254] krb5_build_principal_ext walks off beginning of array the current value of i doesn't need to be freed so my first suggestion should work From: To: Time: Fri Oct 24 16:56:36 2008 I'm guessing this bug was never found because malloc never failed From: To: Time: Fri Oct 24 16:56:48 2008 lots of bugs are never found because malloc never fails From: To: Time: Fri Oct 24 16:56:59 2008 no reason to not fix it tho From: To: Time: Fri Oct 24 16:57:23 2008 once upon a time we built on a platform where malloc failed on a regular basis. So many krb5 bugs were found that way. From: To: Time: Fri Oct 24 16:57:36 2008 (Mac OS 9) From: To: Time: Fri Oct 24 16:57:46 2008 run under a test environment where you can force malloc to fail in controlled ways From: To: Time: Fri Oct 24 16:57:46 2008 coverage testing should really include random malloc failures. Or perhaps, systematic malloc failures. From: To: Time: Fri Oct 24 16:59:38 2008 like "make malloc fail at this line" but really you want something more like "make malloc fail at this line when these variables have the specified values"... From: To: Time: Fri Oct 24 17:00:38 2008 Once again, stuff Ezra was testing for us for a little while.... From: To: Time: Fri Oct 24 17:37:39 2008 I'd been considering making it possible to divert the network layer so that we can do unit tests of code that ordinarily talks to the net. Diverting malloc to introduce failures could also be exciting. From: To: Time: Fri Oct 24 17:38:04 2008 (But of limited practical value, so I probably won't ever do it.) From: To: Time: Fri Oct 24 17:39:12 2008 Somewhere I have code that diverts enough of the network layer to simulate an active attacker who is trying to break into a workstation using the attack that initial ticket validation is intended to prevent. From: To: Time: Fri Oct 24 17:39:53 2008 hmm, doesn't cmockery do that already? (it was at least alleged to be useful for that, but I haven't actually looked) http://code.google.com/p/cmockery/ From: To: Time: Fri Oct 24 17:40:26 2008 /afs/cs.cmu.edu/misc/aaa/src/aaa-head/tests/kdcfake.c From: To: Time: Fri Oct 24 17:42:37 2008 Hm. I wonder if there's unattributed heimdal in that. I should check. From: To: Time: Fri Oct 24 21:52:13 2008 Darwin (non-KfM Mac OS X) builds are broken. The support library now depends on the KIM library, which we don't build. And the KIM library uses thread-specific data through the support-library interface, so we've got a dependency loop. From: To: Time: Fri Oct 24 21:57:09 2008 Also, I guess I'm confused... I thought the KfM approach was for localization to happen within the error_message() call, but the change to util/support/errors.c applies localization to the value returned from error_message(). I think that's going to be the wrong approach on UNIX, where error_message() can return a value from strerror(), which is supposed to return a locale-dependent message; error_message() can also return "unknown error krb5 123", for which we should be localizing the format string "unknown error %s %d". From: To: Time: Fri Oct 24 21:59:48 2008 (preparing to send email) From: To: Time: Sun Oct 26 02:02:25 2008 This room is not anonymous. From: To: Time: Sun Nov 2 01:02:32 2008 This room is not anonymous. From: To: Time: Sun Nov 2 14:44:10 2008 krb5int_buf_add_kdata could be an inline function in k5-int.h or someplace, or an internal function in libkrb5, calling _add_len. void krb5int_buf_add_kdata(struct k5buf *buf, krb5_data d) { krb5int_buf_add_len(buf, d.data, d.length); } From: To: Time: Sun Nov 2 14:44:52 2008 (Maybe a range check for the unlikely case of SIZE_MAX To: Time: Sun Nov 2 15:08:03 2008 Our choices for com_err support are internal, where we know how we invoke the scripts and can tweak things, and external where the compile_et program exists before we start building. Either way, we could arrange for error tables (at least those involved in krb5.h) to be processed at the start of the build, and we could make krb5.h (and k5-int.h) available earlier, if we wanted. Start with "(cd util/et&&make compile_et)", etc. From: To: Time: Mon Nov 3 14:51:17 2008 test From: To: Time: Mon Nov 3 14:53:36 2008 Opinions on whether we're having a meeting tomorrow? It looks like 3/7 of us are out. From: To: Time: Mon Nov 3 14:54:14 2008 I was just talking with lxs. The error-message localization stuff is still misplaced. We need the caller to do it, because only the caller knows which domain/message catalog/whatever is needed, and we export the interface (indirectly) to the application. From: To: Time: Mon Nov 3 14:54:20 2008 Aren't 4/7 out? From: To: Time: Mon Nov 3 14:55:11 2008 Steve, Zhanna, Tom in NYC; Justin on vacation; Robert presumably busy. You, me, lxs I think would be it. From: To: Time: Mon Nov 3 15:01:44 2008 Guessing no, then. I'm always happy to have the extra work time. From: To: Time: Mon Nov 3 15:02:22 2008 (And, Barnowl is not showing messages here. Fooey.) From: To: Time: Mon Nov 3 15:03:59 2008 I didn't see anything after Tom's email... From: To: Time: Mon Nov 3 15:44:01 2008 t_k5buf doesn't build on solaris, needs krb5int_vasprintf From: To: Time: Mon Nov 3 15:48:01 2008 Checking. From: To: Time: Mon Nov 3 15:48:20 2008 I've got a fix ready to go. From: To: Time: Mon Nov 3 15:48:29 2008 Just needs to add $(PRINTF_ST_OBJ) to the object list. From: To: Time: Mon Nov 3 15:48:42 2008 Oh, okay, then. From: To: Time: Mon Nov 3 15:48:50 2008 Oh, and I had just hit return on the svk command, so it's checked in already. :) From: To: Time: Mon Nov 3 15:49:18 2008 I did the build system stuff before I added add_fmt(), so didn't think about the dependency too hard. From: To: Time: Mon Nov 3 15:51:15 2008 Yeah, it's easy to overlook. From: To: Time: Mon Nov 3 15:59:11 2008 Upgraded Barnowl; maybe it's happy now and I won't have to run Pidgin. From: To: Time: Mon Nov 3 22:01:23 2008 think about a strategy for testing it in a realistic way and we can talk about it... From: To: Time: Wed Nov 5 12:40:34 2008 I added a test case that sets +needchange and makes sure a password change is done by kinit. Nalin's change is in; it may suffice for Apple for IPv4+IPv6 environments, but the real bug (our lack of IPv6 support) still needs fixing. From: To: Time: Wed Nov 5 12:51:48 2008 ... and just checked in a patch to not even try IPv6 addresses, for now. From: To: Time: Wed Nov 5 12:54:48 2008 Is it RT itself that turns "http://blahblahblah" text into links? If so, can we get "rdar://" added to the list of supported patterns? From: To: Time: Wed Nov 5 13:02:08 2008 Are people still out of town or are people back today? From: To: Time: Wed Nov 5 13:02:45 2008 Zhanna's in. I assume Tom and Steve would be back but I haven't seen them. From: To: Time: Wed Nov 5 13:03:18 2008 (And yes, I'm looking over the project write-up...) From: To: Time: Wed Nov 5 13:05:35 2008 I'm confusing myself with the next project /last night Luke finished code for that project and has been moving on to the GSS-API side. I'm trying to wrap my head around what we're actually doing on the GSS side to infer a design. From: To: Time: Wed Nov 5 13:07:46 2008 Is there an actual, you know, spec, for the AEAD stuff and how it should be applied to future cryptosystems, beyond "figure out what Windows does"? From: To: Time: Wed Nov 5 13:08:58 2008 To the extent that any will exist, we're writing it. From: To: Time: Wed Nov 5 13:10:29 2008 Note that calling this an AEAD project is kind of misleading. . . I'm not really sure what to call it; the scatter-gather and in-place seems to have more of an affect than the AEAD. From: To: Time: Wed Nov 5 13:12:27 2008 Yeah. It seems kind of weird to have scatter-gather for AEAD but not for any other interface. Then again, the others can be implemented as degenerate cases of AEAD, though I've no idea if they'd be compatible. From: To: Time: Wed Nov 5 13:13:21 2008 They are compatible. I'll go add that as a functional requirement. From: To: Time: Wed Nov 5 13:15:31 2008 The functional requirement would be "do it like Microsoft does", and if MS makes them compatible, then compatibility for us falls out of that. From: To: Time: Wed Nov 5 13:16:07 2008 (Or did you mean scatter-gather for the encrypt-only or checksum-only interfaces?) From: To: Time: Wed Nov 5 13:17:10 2008 Oh, I see, I hadn't gotten down to the APIs. So s-g APIs are on the list. Good. From: To: Time: Wed Nov 5 13:17:22 2008 I mean that if there are no sign_only chunks the resulting ciphertext needs to be compatible with RFC 3961. If there are, it needs to be compatible with MS. Basically all that you seem to do is have a separate checksum pass and a separate encrypt pass and control what data gets included in each From: To: Time: Wed Nov 5 13:18:38 2008 Wait, no, I was confused. I'm guessing the "checksum_iov" functions are the integrity checking bits and the "encrypt_iov" and "decrypt_iov" functions just encrypt/decrypt without integrity checking? From: To: Time: Wed Nov 5 13:19:54 2008 No. checksum_iov is for producing a krb5 checksum using sg. krb5_c_encrypt_iov produces encrypted data including integrity protection. From: To: Time: Wed Nov 5 13:20:21 2008 If MS defines a way of encrypting multiple chunks with no sign-only chunks and it's not compatible with encrypting one chunk, or with encrypting multiple chunks independently, we need to be compatible with that. From: To: Time: Wed Nov 5 13:21:14 2008 Oh, I see. I should really finish reading this before commenting. :) From: To: Time: Wed Nov 5 13:22:23 2008 I'm not actually sure that MS supports more than one encrypted chunk. If they do I think it is compatible. From: To: Time: Wed Nov 5 13:22:56 2008 The code certainly assumes compatibility From: To: Time: Wed Nov 5 13:24:44 2008 One question I have for you is whether you think forcing in-place operation is good. From: To: Time: Wed Nov 5 13:26:18 2008 Allowing it has benefits, certainly, but I have my doubts about forcing it. From: To: Time: Wed Nov 5 13:30:49 2008 Making in-place optional significantly complicates the API of course From: To: Time: Wed Nov 5 13:32:06 2008 Yeah, optional may be the worst of the possibilities. From: To: Time: Wed Nov 5 13:33:51 2008 I'm writing up my understanding of the differences in service model between SSPI and GSS-API in an attempt to hopefully understand what we're trying to do. From: To: Time: Wed Nov 5 13:39:24 2008 Do we have an Apple call today? From: To: Time: Wed Nov 5 13:46:22 2008 Not sure. We were talking about going to every other week maybe. I'd ask Tom or Steve, but don't see either of them in the office today. From: To: Time: Wed Nov 5 13:48:25 2008 Steve's schedule says "board meeting, conference, meetings 8:00 to 18:00" for the entire week. Tom's only shows the Apple call, that I can see. From: To: Time: Wed Nov 5 13:53:49 2008 I didn't see an agenda from Love, but he didn't send one 2 weeks ago either. From: To: Time: Wed Nov 5 13:55:50 2008 We could try calling in and see... From: To: Time: Wed Nov 5 14:12:27 2008 Ken, if you are not on a call can I get you to look at Projects/GSSAPI AEAD From: To: Time: Wed Nov 5 14:22:06 2008 Well, apparently there's no call... From: To: Time: Wed Nov 5 14:33:50 2008 Wow, SSPI couldn't support AES-CBC if it might need more than 8 bytes of padding? How broken. From: To: Time: Wed Nov 5 14:35:18 2008 I'm reasonably sure DCE RPC could not. I may mean that SSPI has had to guarantee that no more than 8 bytes of padding are used mostly because applications assume that if they have 8-byte alignment they won't need padding. From: To: Time: Wed Nov 5 14:35:56 2008 But no, it's reasonably obvious how more than 8 bytes of padding would work if it existed From: To: Time: Wed Nov 5 15:25:49 2008 Looks like the degenerate case of associated-data-only (nothing to encrypt) will not map to the existing checksum schemes. From: To: Time: Wed Nov 5 15:28:25 2008 That's true. AD-only is a different kind of checksum than we have today From: To: Time: Wed Nov 5 15:45:28 2008 oh oops, i had forgotten to modify my calendar to reflect that today was mostly travel for me. From: To: Time: Wed Nov 5 16:15:26 2008 Hm, our proposed move is the Monday after Thanksgiving weekend. Which presumably would mean shutting down and packing up before T-day and being entirely offline for the weekend. I don't think I like that.... From: To: Time: Wed Nov 5 16:15:53 2008 i should talk to Bryan about logistics From: To: Time: Wed Nov 5 16:18:23 2008 At least when we moved from E40 to W92 we didn't have to pack the computers. So you could pack everything but the computers you use remotely beforehand and just shut them off remotely sunday night From: To: Time: Wed Nov 5 16:21:38 2008 Where are you moving to? From: To: Time: Wed Nov 5 16:22:53 2008 That's true, if the logistics are handled the same. Though I did have a UPS get damaged in that move. From: To: Time: Wed Nov 5 16:24:37 2008 movers always damage something. Just take it as an upgrade opportunity ;-) From: To: Time: Wed Nov 5 16:25:00 2008 (and if you have any fragile stuff that belongs to you personally, move it yourself) From: To: Time: Wed Nov 5 16:25:52 2008 We just *did* upgrade the computers, at least some of them. I still have a couple of the boxes though, so at least theoretically they can be packed well. From: To: Time: Wed Nov 5 16:26:27 2008 But to be sure, I'd want to pack 'em up myself the day/night before. From: To: Time: Wed Nov 5 16:27:08 2008 Yeah, I've got some personal stuff to either pack up well, or take home, or something. Already moved a couple old computers snarfed from reuse home. And I'm building up a pile of stuff to reuse-ify. From: To: Time: Wed Nov 5 16:27:21 2008 I'd just come in on sunday night then. it shouldn't take too long. You can use the wednesday before to pack most stuff From: To: Time: Wed Nov 5 16:27:49 2008 if you're putting out a reuse pile, let me know. I have some things From: To: Time: Wed Nov 5 16:27:52 2008 Which means cutting short my T-day visit to my folks. From: To: Time: Wed Nov 5 16:27:59 2008 oh bummer From: To: Time: Wed Nov 5 16:28:35 2008 were you going to take monday off? From: To: Time: Wed Nov 5 16:28:44 2008 actual move date is not written in stone From: To: Time: Wed Nov 5 16:29:01 2008 I'm building a pile on Kevin's desk, if you want to just add some stuff. I'm already going to need a cart or something to move it outside. I was waiting until I add a couple more machines, after wiping disks, but maybe I should just put out what I have. When the weather's going to be good -- rain is forecast now. From: To: Time: Wed Nov 5 16:29:21 2008 Yeah, I know we could move it. I would prefer it if we do, but we haven't talked much about it. From: To: Time: Wed Nov 5 16:37:18 2008 i'll see what i can do From: To: Time: Wed Nov 5 16:41:05 2008 please try to make sure your techtime calendars near the beginning of dec. are kept up to date, as this will help the planning somewhat. From: To: Time: Wed Nov 5 16:42:30 2008 So is Steve really out for the rest of the week, like his techtime schedule indicates? From: To: Time: Wed Nov 5 16:43:50 2008 at least through the rest of today, i think. From: To: Time: Thu Nov 6 13:04:41 2008 Does anyone have time to talk today about the GSS stuff Luke and I are working on? From: To: Time: Thu Nov 6 13:05:49 2008 It sounds like I'm going to need input on an API in the next day or so. The current direction does not make me entirely happy, but I'm concerned that I'm being too picky. From: To: Time: Thu Nov 6 13:09:12 2008 The eventual goal is API-level compatibility with Microsoft, and the intermediate goal is a krb5_c_* API which enables that? From: To: Time: Thu Nov 6 13:12:25 2008 No. I think API compatibility is not on the table. This is actually a discussion of gss_wrap_iov, rtather than krb5_c_*_iov. One of my problems here is that I don't entirely know what the goal is and it's making it harder for me to think about API design because of that. From: To: Time: Thu Nov 6 13:14:01 2008 That was my reaction to the conversation. (Exacerbated because I'm not as knowledgeable about the field.) From: To: Time: Thu Nov 6 13:15:51 2008 I think the goals may be: * Make it possible/easy to implement DCE-style RPC in terms of our GSS API. * Make it possible/easy for people to get AEAD with GSS-API. I'm not sure that point 2 is actually a goal. From: To: Time: Thu Nov 6 13:17:39 2008 DCE-style RPC apparently has a different model for security mechanisms. It assumes that the ciphertext is the same size as the input, that some padding bytes go somewhere else, and that some security gunk (called a trailer or token depending on which document you're reading) goes somewhere else. All these are fixed size. The token must protect more than just the ciphertext. From: To: Time: Thu Nov 6 13:18:31 2008 I *think* that's all we care about in terms of DCE-style RPC. (Well, it also makes the context establishment exchange longer, but I'm ignoring that at this level) From: To: Time: Thu Nov 6 13:18:32 2008 This feels very mechanism-oriented. Why would someone want to have DCE-style RPC as opposed to some other sort of RPC? From: To: Time: Thu Nov 6 13:19:07 2008 Because that's the RPC Windows uses From: To: Time: Thu Nov 6 13:19:53 2008 Aha. So the goal is network-level compatibility with some unspecified thing Microsoft does with a vague name? From: To: Time: Thu Nov 6 13:20:16 2008 As I mentioned on the WIKI page, the architecture of GSS-API does not align that well with the architecture of microsoft's security API, SSPI even though they basically use the same wire protocol. GSS-API exposes less of the packet layout to the application and reserves more flexibility for the mechanism. From: To: Time: Thu Nov 6 13:20:19 2008 There's been a bunch of stuff about "DCE-style RPC" discussed, and a flag for GSSAPI implementing it, and some kind of extended gss_wrap, but I don't know the specifics of what that means. I do think the GSSAPI changes are the important bit, not any new (exposed) crypto-library APIs. From: To: Time: Thu Nov 6 13:21:23 2008 It's the extended gssapi wrap we're discussing now. (BTW, we don't actually have to expose krb5_c_*_iov if we don't want to) From: To: Time: Thu Nov 6 13:21:57 2008 Yeah, I'd rather not, at this time. Not when redesigning the crypto API is on our roadmap. From: To: Time: Thu Nov 6 13:22:25 2008 If we're not exposing the new krb5_c_* interfaces then it's much less important that the API be general or pretty or good. From: To: Time: Thu Nov 6 13:23:27 2008 When I last looked (which is out of date as it seems to have been rewritten last night), if you wanted to wrap something using the extended wrap, you'd find out the size of the header chunk and the padding chunk. Then you'd lay out buffers for the header, padding, your to-be-encrypted data and any signed data. You'd set these up in a gss iov structure which is similar to the krb5_crypto_iov structure. Then you'd call gss_wrap_iov which would do an in-place wrap From: To: Time: Thu Nov 6 13:26:41 2008 I think it should be exposed unless there is a good reason not to do so given that we do expose the existing crypto API. None of the comments so far seem to be in that category. It seems clear that we need a way to allow especially decryption to work if you don't know where the boundaries are based on your feedback and Nico's. We also may need to look into des. I also want to look into how different the wire protocol for rc4+aead is than for normal rc4 From: To: Time: Thu Nov 6 13:29:01 2008 The GSS api is basically what we want for DCE-style. My concern is that when we expose it, people who want aead may end up using it too. That's probably OK. However in the current API it would be very easy to use it in a non-general manner where your code will not work with arbitrary mechanisms--it's not even clear to me there is a way to use it that is mechanism-neutral. So, I'm concerned that if we do not explicitly think about AEAD design we'll get into a situation where that's hard or impossible to do right and so people do it wrong. From: To: Time: Thu Nov 6 13:30:19 2008 What I want to try and figure out is if AEAD outside of DCE-style is not actually a goal for our support, do we care that people might try to do it anyway and thus end up with a protocol that looks like DCE-style instead of something general. From: To: Time: Thu Nov 6 13:30:23 2008 If we weren't thinking of revising the crypto API soon, I'd say go ahead and expose it. But if we do come up with a significant revision to the crypto API, an AEAD interface we expose now will be one more backwards-compatibility shim we have to keep around going forward, and one that currently has no users (since it doesn't exist). From: To: Time: Thu Nov 6 13:32:10 2008 Has the consortium actually proposed a crypto api revision to krbdev or on the wiki? From: To: Time: Thu Nov 6 13:35:22 2008 It's been presented to the board, I think it's been mentioned in meeting minutes, I don't know if there are any other notes written up anywhere. And there are a couple sides to it -- the application programming aspect, and the "how do I plug in my OS crypto package" aspect. From: To: Time: Thu Nov 6 13:41:55 2008 OK. I'm going to argue that basing krbcore decisions on stuff that you haven't even tried to build a consensus out of the consortium members on is very close to spreading FUD. If you want to bring that into this discussion, I think you need to actually propose it on krbdev. Otherwise you're basically saying "trust us--don't do this now because we have this plan you haven't seen for what we'll do later." From: To: Time: Thu Nov 6 13:52:17 2008 So, do you have any thoughts on the GSS issue? From: To: Time: Thu Nov 6 13:55:58 2008 My thoughts are that there seems to be a very specific goal here, which has not been articulated very well, and instead there has been a design for a general-but-ugly API which might accomodate the specific goal, but (as you said) might have issues with mechanism-neutrality. Without being educated on the real requirements, my preference is for a more narrowly tailored API targeted at the specific goal. From: To: Time: Thu Nov 6 13:57:59 2008 Obviously I'm working on trying to understand the goal. From: To: Time: Thu Nov 6 13:58:44 2008 However as you can tell, I do not yet have that understanding. From: To: Time: Thu Nov 6 14:01:09 2008 (sorry, called away for a minute) krbdev wouldn't be the communication channel for dealing with the sponsors in general, or board members in particular. I know the idea has been discussed with certain of the sponsors, and presented to the board, but I don't know what feedback there has been from the board. As for not discussing on krbdev, though, point taken... From: To: Time: Thu Nov 6 14:04:55 2008 My understanding of the current work is that there are very specific goals (like Microsoft RPC interoperability), and beyond that, things are not well defined... I think Tom would be the point person for clarifying, but he said he'd be in late today. From: To: Time: Thu Nov 6 14:50:12 2008 WTF is "IIS preauthentication"? From: To: Time: Thu Nov 6 14:51:07 2008 Of course in 21012 it sounds like Luke is saying that Windows gets handling of rrc wrong. I'm kind of dubious though that they would screw that up given our testing and given that I don't understand why ec is ever non-zero with aes or rc4 From: To: Time: Thu Nov 6 14:51:29 2008 (revision 21012) From: To: Time: Thu Nov 6 15:10:51 2008 Ken, is it strictly correct that we set ec to 0 in our CFX code? wouldn't that break des cfx if someone caused our code to try and use it? From: To: Time: Thu Nov 6 15:11:26 2008 Also, there's not actually a way to find out ec from our API, is there? From: To: Time: Thu Nov 6 15:16:46 2008 Hmm. I guess there's no way to get into a state where we send a cfx des token From: To: Time: Thu Nov 6 15:19:32 2008 Except for some normally-disabled testing code, yes, we always set EC=0 when encoding. I don't recall enough of the detail to know if that'd be a problem for new cryptosystems, but I think for DES and 3DES we shouldn't be using cfx, and for AES and RC4 I think 0 is correct. From: To: Time: Thu Nov 6 15:20:17 2008 I don't think we export EC, but it might be computable from other data. From: To: Time: Thu Nov 6 15:21:30 2008 I can't find a way to compute it. From: To: Time: Thu Nov 6 15:21:39 2008 Trying to figure that out now... From: To: Time: Thu Nov 6 15:24:29 2008 Oh, on the sending or receiving side? When receiving, I think you can just look at bytes 4..5. When sending, if we always use 0, you're all set... From: To: Time: Thu Nov 6 15:25:22 2008 This is sending. I mean compute what ec ought to be in full generality based on what the crypto system is capable of. From: To: Time: Thu Nov 6 15:25:30 2008 Hm, yeah, without assuming we always set EC=0, I think you'd have to know about the specific cryptosystem to figure out the confounder size or whatever else is done. From: To: Time: Thu Nov 6 15:26:36 2008 And our current code probably wouldn't handle properly a new cryptosystem that can add padding. From: To: Time: Thu Nov 6 15:28:55 2008 It's not confounder size. . . It's padding requirements. And yes. From: To: Time: Thu Nov 6 15:29:42 2008 I'm writing up a bug to Luke; I think kg_translate_iovs could be refactored to be simpler and if he fixes a bug in krb5_crypto_length then the need for r27012 goes away From: To: Time: Thu Nov 6 15:29:53 2008 Rather the need for the windows ec work around. From: To: Time: Thu Nov 6 15:43:03 2008 Right, but I think if it weren't for the confounder (block size) you could probably assume any other difference between plaintext size and ciphertext size would be EC plus some cryptosystem-independent size. I could be wrong. From: To: Time: Thu Nov 6 15:44:57 2008 If I recall correctly, the requirement is that plaintext+EC not need any extra padding. That doesn't mean, for example, that EC is required to match the minimal padding that would be needed to round out the final block; it could be bigger. So knowing the cryptosystem padding requirements wouldn't be enough to guess EC. From: To: Time: Thu Nov 6 15:45:26 2008 No, it's also a factor of the block-size. From: To: Time: Thu Nov 6 15:46:07 2008 I'm not talking about guessing ec on receive, I'm talking about guessing an ec that will result in no padding on send. From: To: Time: Thu Nov 6 15:47:18 2008 I don't think I understand. You mean, having the caller guess and supply an EC value? Or guess the padding size that would be needed? From: To: Time: Thu Nov 6 15:50:31 2008 I'm a CFX implementation I must pick an ec such that no padding is required. Doing so means I need to understand what input lengths result in no padding. From: To: Time: Thu Nov 6 15:56:17 2008 I thought we gave 3961 cryptosystems an abstraction for that. From: To: Time: Thu Nov 6 15:56:19 2008 Ah, okay. I think the best MIT's crypto API gives you is krb5_c_encrypt_length and maybe krb5_c_block_size. You could keep incrementing the pad size (or do a binary search between 0 and block size), and when the output size increases, assume you've just added another block to the output and back off one byte. That should work for all our current cryptosystems, but we don't provide any explicit guarantees that they'll all work that way. From: To: Time: Thu Nov 6 15:57:51 2008 Or we can just use 0:-) From: To: Time: Thu Nov 6 15:57:51 2008 We specify that it has to be doable, but don't recommend any specific kind of interface for finding the value. From: To: Time: Thu Nov 6 15:58:22 2008 Ah. For enctypes using the simplified profile, the message block size is a parameter of the profile. From: To: Time: Thu Nov 6 15:58:54 2008 We also don't explicitly say that you should be able to do krb5_c_encrypt_length. But we weren't defining a programming API. From: To: Time: Thu Nov 6 15:59:04 2008 Right. From: To: Time: Thu Nov 6 16:02:05 2008 Yes, but for example aes claims to have a block size of 16 but never needs padding From: To: Time: Thu Nov 6 16:03:01 2008 If it never needs padding, it should be claiming a message block size of 1 From: To: Time: Thu Nov 6 16:03:01 2008 Right. CTS broke the tie between cipher block size and padding. As would a counter mode etc. From: To: Time: Thu Nov 6 16:03:37 2008 RFC 3962 says the message block size is 1... From: To: Time: Thu Nov 6 16:04:18 2008 I don't think the MIT code distinguishes cipher block size and message block size. From: To: Time: Thu Nov 6 16:04:29 2008 But the blocksize in our api is not really the message block size. For example it is the confounder length From: To: Time: Thu Nov 6 16:04:43 2008 Yes. From: To: Time: Thu Nov 6 16:05:30 2008 There were various conceptual things in RFC 3961 not reflected in our API. And conversely, a bunch of things our API has to do (like raw encryption) that are outside of RFC 3961. From: To: Time: Mon Nov 10 10:17:13 2008 btw for those of you considering new Mac Books or Mac Book Pros, the rev A bug this season is trackpad issues. From: To: Time: Mon Nov 10 10:17:33 2008 (with the new multitouch trackpad) From: To: Time: Mon Nov 10 11:03:16 2008 Fun. I wasn't thinking about getting one, but a friend of mine did 2-3 weeks ago. From: To: Time: Mon Nov 10 11:06:10 2008 Have there been trackpad issues with the Macbook Pro before? I had issues with mine, but I was running Linux. From: To: Time: Mon Nov 10 11:08:19 2008 yeah the first rev of the previous multitouch trackpad had similar problems. From: To: Time: Mon Nov 10 11:08:31 2008 basically defective units miss clicks From: To: Time: Mon Nov 10 11:08:45 2008 apparently driving people with them crazy From: To: Time: Mon Nov 10 11:09:12 2008 supposedly they're trying to come up with software fix From: To: Time: Mon Nov 10 11:53:37 2008 did we confirm that the kadmind leak patch from Sun was more complete than the one from Apple? From: To: Time: Mon Nov 10 11:57:40 2008 Yes. From: To: Time: Mon Nov 10 11:57:48 2008 (I mentioned that in the ticket.) From: To: Time: Mon Nov 10 12:10:58 2008 I assume the meeting tomorrow is canceled, given the holiday... From: To: Time: Mon Nov 10 13:31:16 2008 I'm not sure, but I think r21001 (strlcpy) may have broken rsh ticket forwarding. Still looking.. From: To: Time: Mon Nov 10 13:33:11 2008 The server side complains that \003/bin/sh isn't found. (The client side tries to run /bin/sh -c blahblah...) From: To: Time: Mon Nov 10 13:34:02 2008 Peering at the krshd changes, then. From: To: Time: Mon Nov 10 13:34:48 2008 Oh, no, it would be the client changes. From: To: Time: Mon Nov 10 13:36:05 2008 I see the problem. From: To: Time: Mon Nov 10 13:36:57 2008 Ah, okay. I'll leave it for you then; I haven't spotted it yet (in the krshd changes, apparently the wrong place...). From: To: Time: Mon Nov 10 13:37:46 2008 Well, can you test it for me? In krsh.c, after args is allocated on line 323, add *args = '\0'; From: To: Time: Mon Nov 10 13:38:36 2008 Testing... From: To: Time: Mon Nov 10 13:40:44 2008 Looks good so far. From: To: Time: Mon Nov 10 13:41:29 2008 Were you using krsh without encryption? From: To: Time: Mon Nov 10 13:42:22 2008 I believe the tests try both. From: To: Time: Mon Nov 10 13:42:52 2008 How do you run these tests? From: To: Time: Mon Nov 10 13:43:32 2008 In this instance, "make -C tests/dejagnu check". With dejagnu installed at configure time. From: To: Time: Mon Nov 10 13:44:07 2008 (Or "make -C tests/dejagnu check RUNTESTFLAGS=rsh.exp") From: To: Time: Mon Nov 10 13:44:10 2008 Ah, okay, I installed tcl but not dejagnu. From: To: Time: Mon Nov 10 13:44:37 2008 Okay, it's run through several passes of the rsh tests. Looks good. From: To: Time: Mon Nov 10 13:44:43 2008 --> lunch truck... From: To: Time: Mon Nov 10 13:46:13 2008 So, do you run make install before make check in your auto-builds? From: To: Time: Mon Nov 10 13:48:01 2008 make install before make check is somewhat necessary on linux due to the RPATH problems you mentioned on zephyr. From: To: Time: Mon Nov 10 13:48:43 2008 Yeah, I guess that's the workaround for now. I don't think anything short of converting to libtool would solve that. From: To: Time: Mon Nov 10 13:49:26 2008 the last few times i looked at libtool, it still did not fit our requirements in various ways. From: To: Time: Mon Nov 10 13:50:20 2008 It also has the usual autotools problem: if anything goes wrong, it's a pain to solve. From: To: Time: Mon Nov 10 13:50:38 2008 oh, it still depends on automake, right? From: To: Time: Mon Nov 10 13:51:48 2008 Love's 79.3 has 4 new patches but only 3 of them are applied by the makefile. did someone look at them yet? if not, i will put them into RT shortly. From: To: Time: Mon Nov 10 13:52:13 2008 No, it works fine without automake, but its documentation isn't very friendly to doing so. (I'm not seriously suggesting using it.) From: To: Time: Mon Nov 10 13:58:43 2008 tomorrow is an MIT holiday, so no meeting. From: To: Time: Mon Nov 10 14:02:43 2008 Hm, kadmin's env-setup uses "ps -auxww" if it thinks ps is BSD-style. That's not valid BSD ps syntax, I believe. From: To: Time: Mon Nov 10 14:06:56 2008 i thought most modern BSDs accept it though. From: To: Time: Mon Nov 10 14:08:58 2008 Maybe, but it has a meaning under the POSIX syntax (-a -u xww) and the Linux PS only treats it as "auxww" if the specified user (xww in this case) doesn't exist, as a compatibility measure. From: To: Time: Mon Nov 10 14:09:29 2008 I think I'm out of modern BSD systems to check on. From: To: Time: Mon Nov 10 14:09:56 2008 what MIT holiday is tomorrow? From: To: Time: Mon Nov 10 14:10:20 2008 Veteran's Day. From: To: Time: Mon Nov 10 14:12:24 2008 Gee, you people take off at the drop of a hat, don't you? From: To: Time: Mon Nov 10 14:13:26 2008 We have eleven holidays. From: To: Time: Mon Nov 10 14:13:44 2008 also when doing make check other than at the top, "make fake-install" is often needed. From: To: Time: Mon Nov 10 14:14:49 2008 Combined with four weeks of vacation, we get 31 days off. Not quite enough to work four-day weeks the entire year, unless you get "mysteriously ill" on Fridays 21 times per year. From: To: Time: Mon Nov 10 14:15:14 2008 What does fake-install do? From: To: Time: Mon Nov 10 14:16:28 2008 Installs a separate tree that many of the "make check" tests will point LD_LIBRARY_PATH and other variables at, alleviating some but not all of the issues requiring installation. From: To: Time: Mon Nov 10 14:17:37 2008 Ah. (The binaries built with tcl would still find the system libraries in /usr/lib on my machine, I think.) From: To: Time: Mon Nov 10 14:17:37 2008 I think something libtool-like would be an improvement, but libtool itself doesn't do everything we need. In particular, it doesn't seem to handle library init/fini functions or export lists. From: To: Time: Mon Nov 10 14:19:31 2008 I guess this would work: for any program we want to run in the test suite, have a separate foo.test executable which is built without the -R options. From: To: Time: Mon Nov 10 14:21:08 2008 Hm, no, that doesn't work for finding the tcl libraries. (We could exclude /usr/lib from the runpath to help with that, as we do with /usr/include and the include path.) From: To: Time: Mon Nov 10 14:23:04 2008 Excluding /usr/lib is probably the right answer. From: To: Time: Mon Nov 10 14:24:44 2008 I forget if I mentioned it before: We had one person suggest that we shouldn't use search paths for headers and libraries, especially if we provide options like --with-foobar=/path/to/foobar, we should instead explicitly reference them at the indicated locations. So /path/to/foobar/lib/libfoobar.so.2 goes into the executable, not /path/to/foobar/lib:/path/to/other/lib and libfoobar.so.2 separately. Contrary to common practice, but interesting. From: To: Time: Mon Nov 10 14:25:36 2008 I'm not even sure that's possible, and it's certainly not common practice. From: To: Time: Mon Nov 10 14:26:19 2008 actively not recommended in quite a few places, as i recall From: To: Time: Mon Nov 10 14:26:28 2008 I could believe that. From: To: Time: Mon Nov 10 14:27:16 2008 In fact, I'm pretty sure it's not easily possible. However, you tell ld to reference a shared library, it will find the library and look up its soname to decide what to put into the executable headers. From: To: Time: Mon Nov 10 14:27:55 2008 (Extra comma there, sorry.) From: To: Time: Mon Nov 10 14:28:27 2008 Ah, good point. From: To: Time: Mon Nov 10 14:31:00 2008 if there is no soname, that's a somewhat different story, i think. From: To: Time: Mon Nov 10 14:31:55 2008 Just tried a quick test on linux, it doesn't seem to work. From: To: Time: Mon Nov 10 14:33:43 2008 Avoiding search paths and specifying the file you mean may be appropriate for libraries and headers found at build time. For finding shared libraries at runtime, you really want to have the soname and trust the runtime loader's searching to do the right thing. If it doesn't do the right thing, then the system is arguably misconfigured. From: To: Time: Mon Nov 10 14:37:19 2008 It's more logical given the way things work, but conceptually it's not really consistent with configure taking options like --with-foo=/path/to/foo --with-bar=/path/to/bar when what winds up happening is that the indicated directories are added to the search path used to find *everything*, not just the specific package. Which is why I now tend towards --with-foo --with-bar CFLAGS="-I/path/to/foo -I/path/to/bar" etc. It makes things clearer. Though it does mean the package can't tweak the search paths based on what headers or libraries are actually needed in a given instance. From: To: Time: Mon Nov 10 14:44:42 2008 I'll put in the standard plug that it would be really nice for us OS integrators to be able to turn off runpaths completely From: To: Time: Mon Nov 10 14:46:34 2008 Agreed. From: To: Time: Mon Nov 10 14:47:27 2008 OS integrators are pretty much always installing into /usr/lib, right? So if we avoid putting /usr/lib in the runpath, that should be enough for practical purposes. From: To: Time: Mon Nov 10 14:47:53 2008 (I was only thinking of avoiding it for the tcl-linked binaries, but it also makes sense for ${libdir}.) From: To: Time: Mon Nov 10 14:49:09 2008 Yes, that's a bit more complicated, since it may mean dropping the -R/-rpath option altogether, instead of just tweaking how the path is built. From: To: Time: Mon Nov 10 14:49:52 2008 At least for Debian, I'll still need to maintain a patch until I can get to a point where there is not a runpath set in the resulting executable. So, depending on how you avoid putting /usr/lib in, that might be sufficient. From: To: Time: Mon Nov 10 14:50:03 2008 I still think either using a script for building libraries, or using gnu make rules where we can do some conditional tests etc., would make this a whole lot easier... From: To: Time: Mon Nov 10 14:54:32 2008 This would be a place where "nmake for Windows and gmake for UNIX" would work just fine, I think, since we don't have to address this issue for Windows. From: To: Time: Mon Nov 10 14:58:40 2008 OK, I think Luke and I understand what we're proposing on the gss-front. There are two goalrs basically. The first is to provide support for DCE-style RPC. We expect that API to be used by applications who care explicitly about token structure and no one else. The second goal is to get AEAD in gss. We think that it is important to create a gss_wrap_aead independent of gss_wrap_iov for that case so that people don't go to the DCE API just to get AEAD From: To: Time: Mon Nov 10 15:00:27 2008 wrap_iov is the DCE API? is it documented somewhere? i know the MSFT stuff is readily available. From: To: Time: Mon Nov 10 15:00:27 2008 Why do you want these things? From: To: Time: Mon Nov 10 15:00:34 2008 If we're going to support AEAD for non-DCE-mode, I'd like to see it proposed at the IETF. From: To: Time: Mon Nov 10 15:02:39 2008 there is a strong desire from vendors to implement these things for Microsoft compatibility. to the extent that we can push this through the IETF, we should, but it should not delay our implementation. From: To: Time: Mon Nov 10 15:03:15 2008 Isn't #1 (including DCE-mode AEAD) enough for MS compatibility? From: To: Time: Mon Nov 10 15:04:29 2008 DCE-mode actually means a number of things, as i recall. "acceptor-first" context establishment is one of them, as is AEAD. "bare" mechanism tokens (without ASN.1-ish wrapper) inside SPNEGO is another. From: To: Time: Mon Nov 10 15:04:58 2008 *gack* From: To: Time: Mon Nov 10 15:07:39 2008 it's out there and people need compatibility with it. please direct your distaste in the direction of working out how we can do better in the future. :-) From: To: Time: Mon Nov 10 15:07:58 2008 I'll object as a krbcore member to an API that forces an application to pay attention to token structure in order to get AEAD but that makes AEAD available. So, basically, Ken, I believe that we need #2 today because #1 implies a new feature that is not just useful for DCE and coupling them will force people to write apps that make our extensibility story difficult in the future. From: To: Time: Mon Nov 10 15:09:07 2008 wait which is #1 and #2 again? From: To: Time: Mon Nov 10 15:09:09 2008 Okay. But see above re IETF. :) I don't think this should be an MIT extension. From: To: Time: Mon Nov 10 15:09:23 2008 #1 = DCE, #2 = AEAD without DCE From: To: Time: Mon Nov 10 15:10:00 2008 #2 is generac aead #1 is dce-style. I don't think we should block on the IETF. Proposing this in the IETF is not within my current SOW, although I'd be delighted to help you guys out if you want to do that. From: To: Time: Mon Nov 10 15:10:01 2008 so is Sam's statement backwards? it doesn't seem to make sense without switching #1 and #2 From: To: Time: Mon Nov 10 15:11:26 2008 I intended to say that if you provide dce without a generic aead, you force people to use the dce style interface. From: To: Time: Mon Nov 10 15:11:26 2008 No. DCE-including-AEAD gives a new feature, AEAD, which would be generally useful, but requires you pay attention to token structure. Separately providing AEAD without that requirement would be a win. From: To: Time: Mon Nov 10 15:11:58 2008 Is there a reason why AEAD is of more general interest than just MS compatibility? From: To: Time: Mon Nov 10 15:12:06 2008 ok, so the question is how much of the iovec-style thing to put into AEAD? From: To: Time: Mon Nov 10 15:13:02 2008 Greg, i think there is a case for it, but mostly in places (filesystems?) that need high throughput by authenticating everything but only encrypting what they absolutely have to. From: To: Time: Mon Nov 10 15:14:36 2008 oh wow mailhubs are slow today From: To: Time: Mon Nov 10 15:14:47 2008 Luke is proposing none. He proposes that gss_wrap_aead takes only a wrap buffer, an associated data buffer and produces a token. This is not entirely general. IN particularly the Microsoft apis gives you multiple associated data buffers and with existing enctypes the ordering matters so assoc|data|assoc has different encoding than assoc|assoc|data. As a result, you cannot simply concatinate the associated data buffers. From: To: Time: Mon Nov 10 15:15:44 2008 There are some places in the Kerberos protocol where we could use AEAD but I get shouted down every time I suggest it. :-) From: To: Time: Mon Nov 10 15:16:19 2008 You could always encode something like that using SSPI. It's also general in that it allows you to express anything you need. It simply has the problem that there may be SSPI apps that produce encodings you cannot reproduce. That's true today though. From: To: Time: Mon Nov 10 15:16:20 2008 hm. do we think that the MSFT style AEAD is cryptographically sound? From: To: Time: Mon Nov 10 15:16:58 2008 so the SSPI interface *is* the DCE interface? or just similar? From: To: Time: Mon Nov 10 15:17:12 2008 Probably, if you define the "desired" properties correctly. :) From: To: Time: Mon Nov 10 15:18:22 2008 I believe that gss_wrap_iov supports a superset (possibly not a strict superset) of the SSPI encodings. From: To: Time: Mon Nov 10 15:19:06 2008 I'm not entirely clear that SSPI correctly supports a CFX-style mechanism without RRC. gss_wrap_iov does, although obviously you couldn't use that in DCE land. From: To: Time: Mon Nov 10 15:28:02 2008 So, I'm expecting to bring the krb5_c_iov project to a vote after filling it out some more and do the same to the gss project relatively soon. Since we're not having a meeting tomorrow I'm definitely hoping we can discuss next week. I realize that people have not had a credible project proposal for the gss side and there are details missing from the krb5_c_crypto_iov project that need to be filled in. [more] From: To: Time: Mon Nov 10 15:29:29 2008 On an unrelated note, I've tweaked a couple of the dejagnu tests to run only once instead of once in each of the dozen passes (with varying enctype configs) that we do. (And I killed one of the passes.) I'd like to do that to a few more, if no one thinks they should be tested per enctype-config: kadmin, pwchange, pwhist, gssftp (we still have gssapi per-enctype), telnet (after checking for DES), v4gssftp (after checking for DES, and with v4standalone testing v4 kinit in each config). From: To: Time: Mon Nov 10 15:30:01 2008 The feedback I'm getting from the development comunnity is that I should include a pointer to the Microsoft docs in the project write-up and that we need to support a way so that applications can decrypt without knowing token structure. From: To: Time: Mon Nov 10 15:30:13 2008 Is "WARNING: Couldn't find tool init file" in the test output expected? From: To: Time: Mon Nov 10 15:30:16 2008 Some of those are enctype-dependent, but either they're filtering for DES, or there's another test that should also cover the enctype-dependent variations. From: To: Time: Mon Nov 10 15:30:31 2008 Yes, that's normal. From: To: Time: Mon Nov 10 15:30:53 2008 Sam: Steve said we probably have the protocol docs on the kerberos.org web site. From: To: Time: Mon Nov 10 15:31:46 2008 I know we have a pointer. I didn't realize we had copied them. But I'll definitely include an appropriate pointer. Tom, when would be a reasonable time to talk to you about testing plans for this stuff From: To: Time: Mon Nov 10 15:32:21 2008 Um, it's probalby just a pointer. But we do have a handle, which I didn't recall when I was complaining last week. :) From: To: Time: Mon Nov 10 15:33:08 2008 (Overall, I think I'd kind of like to see copies of the protocol docs in our doc/ tree, but that's just me.) From: To: Time: Mon Nov 10 15:33:26 2008 (Maybe not the ASN.1 specifications...) From: To: Time: Mon Nov 10 15:34:10 2008 I bet Sam would prefer we not do that with IETF docs. :) From: To: Time: Mon Nov 10 15:34:12 2008 I'm feeling much less worried about the protocol doc issue because it really is as simple as include all data in the checksum pass. Include only the data you're going to encrypt in the encryption pass. Which brings me to an earlier question of whether the protocol is sound. From: To: Time: Mon Nov 10 15:35:02 2008 Greg, we already do, and I strip them. From: To: Time: Mon Nov 10 15:36:05 2008 I think that has been one of Simon's more dubious contributions to the free software community From: To: Time: Mon Nov 10 15:40:53 2008 I think that the Microsoft stuff is sound if it is difficult to find either preimages for the mac or to find the new mac given an alteration to the message. It makes me a bit nervous though because it does not include the length of the integrity protected data nor does it include some marker to distinguish the integrity protected data from the confidential data in the integrity stream. From: To: Time: Mon Nov 10 15:41:40 2008 I cannot think of ways to exploit those weaknesses against sha-1 or md5. From: To: Time: Mon Nov 10 15:42:23 2008 So, the RPC dejagnu tests are failing for me, and I *think* the first relevant error message is "unable to register (RPC_TEST_PROG, RPC_TEST_VERS_1, tcp)". Do I need to be running a portmapper or something? From: To: Time: Mon Nov 10 15:46:06 2008 you need to run a portmapper listening on UDP/TCP, not just local UNIX sockets. From: To: Time: Mon Nov 10 15:46:26 2008 it can listen to loopback, but it hast to be an honest IPv4 socket. From: To: Time: Mon Nov 10 15:55:05 2008 Yeah, I was trying to figure out if there was a way to shift the boundary between encrypted and associated data if you could predict the plaintext and the associated data was a variable-length blob included with the message... or if it would really matter. From: To: Time: Mon Nov 10 15:55:50 2008 Okay, installing portmap (no configuration required) makes the rpc test output much prettier so far. Thanks. From: To: Time: Mon Nov 10 15:55:53 2008 you could end up with a PGP-type situation From: To: Time: Mon Nov 10 15:56:45 2008 What do you mean pgp-style? From: To: Time: Mon Nov 10 15:56:47 2008 (re RPC) It's kind of annoying. The use of portmapper should probably be one more test, instead of fundamental to being able to run any of the tests. From: To: Time: Mon Nov 10 15:57:18 2008 actually in the PGP case it was signed data not being sufficiently well quoted when verified, so it was possible to insert some unsigned content that the receiver would interpret as having been signed. From: To: Time: Mon Nov 10 15:57:21 2008 Note too that on the Mac you need to jump through some more hoops to get portmapper running. From: To: Time: Mon Nov 10 15:57:46 2008 this RPC lossage is partly because we don't integrate well with the system RPC. From: To: Time: Mon Nov 10 15:58:30 2008 So, basically what you'd need to do is to trim the receiver's idea of how long the ciphertext is and then expand the receiver's idea of how long the plaintext is. If you could do that, I think you could move things out of the ciphertext. However I don't think you could modify them. From: To: Time: Mon Nov 10 16:00:20 2008 I think that allows you to expose confidential information you know or can guess and still have the message go through. You could potentially use this as an oracle for guessing whether your decryption is correct. From: To: Time: Mon Nov 10 16:01:25 2008 Right, assuming no sha1 cracks, shifting the boundary is probably all you could do. But if making one field shorter and another longer doesn't break the app protocol, it could make for an interesting attack. From: To: Time: Mon Nov 10 16:02:08 2008 but the length of the segments are not authenticated anywhere? From: To: Time: Mon Nov 10 16:02:21 2008 Also, if you can make multiple attempts, you could shift one byte at a time, making on average 128 attempts for each position, and figure out more of the plaintext you couldn't predict. From: To: Time: Mon Nov 10 16:03:08 2008 Ken, the lengths of the segments need not be protected. I suspect that they tend to be protected by most consumers of this mechanism. From: To: Time: Mon Nov 10 16:03:11 2008 The various AEAD modes being proposed these days don't have such quirks. The two sections are treated separately. From: To: Time: Mon Nov 10 16:03:39 2008 I would hope so. From: To: Time: Mon Nov 10 16:03:44 2008 but modern AEAD modes don't allow for multiple cipher/plain segments in arbitrary order? From: To: Time: Mon Nov 10 16:04:43 2008 No, most of them have one input of each type; one proposal I saw allowed for multiple associated-data segments but I think still only one encrypted one. From: To: Time: Mon Nov 10 16:04:44 2008 Tom, correct. I think we should make it clear in the API that we do not guarantee that aead|conf|aed is different from conf|aead|aed or aead|aead|conf I.E. cipher and aead may be reordered internally. From: To: Time: Mon Nov 10 16:05:55 2008 Keep in mind that this protocol was designed prior to 2000. Now, I think it was really irresponsible for MS not to come forward either during RFC 4121 or 3962 and say they are *using* aead in shipping code and so we should do it right. From: To: Time: Mon Nov 10 16:06:34 2008 did they have any staff involved with IETF who were in a position to do that? From: To: Time: Mon Nov 10 16:06:54 2008 i.e. were not only aware but had authority to disclose? From: To: Time: Mon Nov 10 16:07:38 2008 The API was public at the time and was shipping in Windows 2000. From: To: Time: Mon Nov 10 16:07:48 2008 oh. From: To: Time: Mon Nov 10 16:07:50 2008 So, for example, ideally Jeff Altman would have known. From: To: Time: Mon Nov 10 16:08:08 2008 Yes, like our own crypto mechs, it's got its "issues" that we could avoid if we could redesign from scratch now, but we can't. From: To: Time: Mon Nov 10 16:08:09 2008 Or we could have been better Windows developers and known ourselves From: To: Time: Mon Nov 10 16:08:49 2008 Exactly. I don't think the MS AEAD stuff has any flaws so significant as to recommend against its use; it can always be upgraded to ccm or gcm in the future From: To: Time: Mon Nov 10 16:10:17 2008 Agreed. But if these "quirks" are real it might be wise to document them for app protocol designers, even if they're minor. (Kind of like how Kerberos crypto should apply to self-describing messages so you know where they end, since we can't tell how much padding was added.) From: To: Time: Mon Nov 10 16:11:00 2008 I'll do that in the project writeup. If you ever get API docs you can move it there. From: To: Time: Mon Nov 10 16:15:35 2008 Well, that's annoying. expect is hanging at exit time trying over and over again to fcntl a closed file descriptor. So the rpc tests finish and the test suite hangs. From: To: Time: Mon Nov 10 16:15:52 2008 There were discussions of MS AEAD on the Kitten list in Sept 2004 which was nearly 9 months before 4121 was published. From: To: Time: Mon Nov 10 16:16:23 2008 Yeah, I think we just failed to be convinced. :( From: To: Time: Mon Nov 10 16:16:35 2008 adopting AEAD extensions as part of the Kitten Charter was rejected by the working group From: To: Time: Mon Nov 10 16:17:06 2008 Too bad. It would've been logical, I think. From: To: Time: Mon Nov 10 16:17:45 2008 I remember the kitten aead discussions as a charter item; I fail to remember that the MS stuff came up in that context. But that just means I failed to understand what was going on in 2004. Which is not good at all. From: To: Time: Mon Nov 10 16:51:08 2008 > I think that has been one of Simon's more dubious contributions to > the free software community The whole "it's more important to have only free documentation than to have documentation" meme? From: To: Time: Mon Nov 10 17:15:01 2008 Well, his contribution was specifically forcing Debian to apply it to ietf docs From: To: Time: Wed Nov 12 03:20:37 2008 Windows has added CCM mode for Kerberos? From: To: Time: Wed Nov 12 08:59:50 2008 No, windows does not use ccm From: To: Time: Wed Nov 12 09:10:33 2008 So why did Luke add CCM? From: To: Time: Wed Nov 12 09:41:13 2008 Luke wrote ccm on his own time because he thought it would be cool and interesting... Did he check it in? That seems unclear if so. (I have not read log messages today) From: To: Time: Wed Nov 12 09:42:36 2008 He checked it in at 22:13 last night. I haven't checked whether he used an experimental enctype number, etc. From: To: Time: Wed Nov 12 09:44:15 2008 I do not plan to be migrating that to the trunk at this time at least. From: To: Time: Wed Nov 12 09:45:33 2008 It ended up being a very useful exercise for the crypto_iov discussion. According to Luke, CCM has the property that the encoding of the length of associated data is variable. Which kind of breaks krb5_crypto_length, as well as all sorts of things that cascade from that. From: To: Time: Wed Nov 12 09:47:25 2008 Huh, I didn't realize that. Good thing he did it, then. From: To: Time: Wed Nov 12 09:47:46 2008 I think I really need to talk to Luke real-time on a number of points. Sadly, that's kind of incompatible with my schedule. Perhaps I need to take a nap or wake up around 3-4 AM. From: To: Time: Wed Nov 12 09:48:45 2008 My schedule has me getting to work just after he goes to bed and going out for evening plans just about the time he starts working. From: To: Time: Wed Nov 12 09:49:29 2008 Hm, glancing quickly at RFC 3610, it looks like the size of the length field is a parameter you choose. From dealing with the truncated HMAC length for AES earlier, though, since we have no way to negotiate it, I would think you'd just pick a size and have it fixed for a given cryptosystem type. From: To: Time: Wed Nov 12 09:49:59 2008 Ow, yeah, working with someone on the opposite side of the planet can be a little tricky. :) From: To: Time: Wed Nov 12 09:50:36 2008 He's using 5116 not 3610 From: To: Time: Wed Nov 12 09:51:37 2008 Hmm, which claims to be ccm not gcm. So, I wonder which ccm spec he's using. From: To: Time: Wed Nov 12 09:51:53 2008 Rather claims to be GCM not CCM From: To: Time: Wed Nov 12 09:52:08 2008 5116 has both GCM and CCM. Looking at section 5.3 now... From: To: Time: Wed Nov 12 09:52:21 2008 And includes ccm in 5.3 so I'll assume that From: To: Time: Wed Nov 12 09:53:02 2008 "... ciphertext is exactly 16 octets longer than its corresponding plaintext." From: To: Time: Wed Nov 12 09:53:24 2008 Hmm, as I'm reading this, Luke may be wrong. From: To: Time: Wed Nov 12 09:53:35 2008 The main CCM reference is external, but it looks like 5116 fixes the size parameters to specific values. From: To: Time: Wed Nov 12 09:55:52 2008 So, I definitely need to have a real-time chat with Luke at this point. From: To: Time: Wed Nov 12 10:03:31 2008 Oh, I see... the variable-length part is in how the length of associated data is encoded. But that encoding is (I think) put on the front of the actual associated data for computing the CBC-MAC. So you need some temporary storage for it, but it shouldn't affect output length or padding sizes or anything, as far as I can tell. From: To: Time: Wed Nov 12 10:04:26 2008 (A.2.2 of SP800-38C) From: To: Time: Wed Nov 12 10:07:36 2008 Yeah, Luke seems to have some confusion there. From: To: Time: Wed Nov 12 13:21:25 2008 This guy is clearly confused. I'm pretty sure neither IE nor IIS has ever done krb4 From: To: Time: Tue Nov 18 13:24:45 2008 could someone take a look at Damian Hazen's message to kerberos of 10/30? (IPv6 chan bindings)? i think the answer is "no" for our impl at the moment. From: To: Time: Tue Nov 18 14:44:43 2008 There's one place where accept_sec_context looks for GSS_C_AF_INET, but otherwise I think our GSSAPI code doesn't care about the address family in the channel bindings. However, we haven't defined GSS_C_AF_INET6, so unless the app decides on a value for itself, no, you can't do IPv6 channel bindings. From: To: Time: Tue Nov 18 16:30:41 2008 We should probably put through a document defining GSS_C_AF_INET6 and get it over with. I don't think there's one pending. From: To: Time: Wed Nov 19 17:10:30 2008 I seem to have run into an Adium bug that causes it to crash in jabber xml parsing code. Weird thing is, now it crashes a lot. Probably some new data on one of the servers is causing the failure, every time I connect. From: To: Time: Wed Nov 19 17:11:16 2008 which version of adium? From: To: Time: Wed Nov 19 17:12:14 2008 1.3.2, the newest. I've been using it for a while, but it just started failing today. Well, crashing. I recognized three issues in the recent bug reports -- crashing in the jabber parsing code, crashing while viewing chat logs, and "frequent disconnects/reconnects" which might be the problem I was having earlier in the week... From: To: Time: Wed Nov 19 17:13:15 2008 interesting, I think 1.3.2 is the release that fixed the disconnect/reconnects for me From: To: Time: Wed Nov 19 17:13:19 2008 heh. From: To: Time: Wed Nov 19 17:13:41 2008 And of course it's really annoying to get ichat to connect to the MIT server, thanks to our self-signed cert (grumble grumble). From: To: Time: Wed Nov 19 17:13:48 2008 yeah From: To: Time: Wed Nov 19 17:14:06 2008 are you using adium's krb5 support? From: To: Time: Wed Nov 19 17:15:15 2008 Yeah, that seems to work fine. Well, unless the Kerberos code has randomly decided that my active identity is raeburn@RAEBURN.ORG [mailto:raeburn@RAEBURN.ORG], in which case my only option is to fix that, then quit and restart adium. Once Kerberos sign-on has failed, it doesn't seem to retry it. From: To: Time: Wed Nov 19 17:16:21 2008 whatever custom build of KfM I'm running now disagrees with adium's krb5 support, so perhaps that's where our difference lies From: To: Time: Wed Nov 19 17:17:29 2008 my adium quietly gives up on GSSAPI with a console message of "Symbol not found: _apple_gss_krb5_export_authdata_if_relevant_context" From: To: Time: Wed Nov 19 17:18:18 2008 Oh. Bleah. From: To: Time: Wed Nov 19 17:21:01 2008 Oh, this is new... I'm trying signing adium on to one account at a time so I can see which is breaking things. I get the usual "can't verify the identity of 'jabber.mit.edu" notification, but -- this is new -- it wants my password to change system certificate settings. And while I was typing this, those windows went away and it signed on anyways. (And hasn't crashed in the first 10 seconds, which is a good sign.) From: To: Time: Wed Nov 19 17:22:19 2008 I changed the cert settings in ichat to get it to connect, so now the cert is in my keychain. Maybe that's why adium is prompting me now? From: To: Time: Wed Nov 19 19:40:56 2008 Anyone remember why we wanted to use strengthen reply key not replace reply key for fast encrypted challenge? From: To: Time: Wed Nov 19 19:41:07 2008 I have that in my notes from Dublin. From: To: Time: Wed Nov 19 19:41:54 2008 i'm not recalling those details From: To: Time: Wed Nov 19 19:42:59 2008 I'm not either. I'm wondering if it was eclipsed by the huge attack and if the huge attack solution fixes it. From: To: Time: Thu Nov 20 12:37:36 2008 I don't recall either. Was there a greater vulnerability if the host key used for armoring was later compromised? From: To: Time: Fri Nov 21 14:09:52 2008 I just set the moderation flag for rao.rao.d@gmail on kerberos@mit; he just spammed us. From: To: Time: Fri Nov 21 14:56:49 2008 wait, how did that message get through? From: To: Time: Fri Nov 21 14:59:04 2008 He subscribed. From: To: Time: Fri Nov 21 14:59:26 2008 but that address wasn't in the from header From: To: Time: Fri Nov 21 14:59:30 2008 Oh, hm, but the sender is invitation@mydailyflog.com, not rao.rao.d@gmail. From: To: Time: Fri Nov 21 14:59:47 2008 it had a reply-to of the gmail account From: To: Time: Fri Nov 21 15:00:09 2008 I wonder if that's checked. Or maybe the envelope-from was his address. From: To: Time: Fri Nov 21 15:01:25 2008 not sure that would be the case. it looks like it might have come from a click-to-promote-to-friends web form From: To: Time: Fri Nov 21 15:05:14 2008 Yeah, it probably did. And it came from the mydailyflog.com mail system to us... From: To: Time: Fri Nov 21 15:05:46 2008 A copy also went to kerberos-owner. From: To: Time: Fri Nov 21 15:06:06 2008 yeah. From: To: Time: Fri Nov 21 15:07:49 2008 I've never heard of mydailyflog before, and I'm not sure if we should try the opt-out link or if that would just get us spammed... From: To: Time: Fri Nov 21 15:08:14 2008 just filter messages that have that address in the received lines? From: To: Time: Fri Nov 21 15:09:00 2008 But this guy has sent legitimate mail to the kerberos list before, so maybe he doesn't need moderation. Just to be told not to click on such links... From: To: Time: Fri Nov 21 15:09:14 2008 Yeah. I'll add a filter. From: To: Time: Fri Nov 21 15:10:03 2008 i'm wondering if the envelope-from was actually the gmail address. maybe the archive knows. From: To: Time: Fri Nov 21 15:13:51 2008 No, the raw mbox shows invitation@mydailyflog as the sender, and in the Sender: field. My guess is mailman is checking reply-to... From: To: Time: Fri Nov 21 15:14:56 2008 ick From: To: Time: Fri Nov 21 15:16:08 2008 received:mydailyflog added to spam filter (hold, not discard) From: To: Time: Fri Nov 21 15:16:26 2008 ok From: To: Time: Fri Nov 21 15:19:44 2008 (looks like it's about time to check the moderation queues again, too...) From: To: Time: Fri Nov 21 15:20:51 2008 Spammers have found krb5-bugs@pch ... From: To: Time: Fri Nov 21 15:21:16 2008 oh well From: To: Time: Fri Nov 21 15:22:46 2008 Yeah, it just means when I open 11 tabs on moderation pages, one fewer is now likely to come up with no messages. C'est la vie. From: To: Time: Fri Nov 21 15:25:03 2008 i generally let stuff fester if i haven't seen a notification of something that looks like a legit message. From: To: Time: Fri Nov 21 15:26:34 2008 I don't generally bother reading the notifications. :) From: To: Time: Fri Nov 21 15:27:36 2008 If I can figure out the non-ASCII-subject filter rules, we should be able to auto-discard more of the spam coming in. From: To: Time: Fri Nov 21 15:28:02 2008 non-ascii subject lines occasionally are legit messages From: To: Time: Fri Nov 21 15:30:19 2008 Subject lines with a couple non-ASCII characters, sure, but subject lines that are primarily non-ASCII? None that I recall. Unfortunately, even one means encoding the subject with =?charset?... and base64, making the matching a real pain. From: To: Time: Fri Nov 21 15:34:37 2008 We can probably work out, for example, having the high bit set on each of the set of three characters means the four base64 encoding characters will fall in these sets. And there are some patterns that seem common, like "?40", that should be relatively easy to match against and kill. From: To: Time: Fri Nov 21 15:37:53 2008 Oops. kfw-announce wasn't in my list of bookmarks to open... From: To: Time: Sun Nov 23 02:02:33 2008 This room is not anonymous. From: To: Time: Mon Nov 24 11:22:16 2008 Ah, or I can wait for "?40" to show up in the moderation summary, and then go examine the actual message headers and copy the magic string out... From: To: Time: Mon Nov 24 14:53:15 2008 food preferences for tomorrow? From: To: Time: Mon Nov 24 14:53:56 2008 kiraz From: To: Time: Mon Nov 24 17:12:59 2008 The meeting is tomorrow at 1? From: To: Time: Mon Nov 24 17:14:00 2008 By meeting I mean the release meeting, not any internal staff meeting you may have From: To: Time: Mon Nov 24 17:22:28 2008 Yes. From: To: Time: Mon Nov 24 17:22:54 2008 Ah, just saw your email. Oops... From: To: Time: Mon Nov 24 18:14:03 2008 Yeah, I'm really sorry about that. Nomcom is a bit of a madhouse as we're trying to finish off the IESG From: To: Time: Mon Nov 24 18:14:51 2008 so given that both you and Luke will miss the 13:00 time, how useful would it be to reschedule this one? From: To: Time: Mon Nov 24 18:41:45 2008 I'd love it if you could reschedule. However I didn't think we ever expected Luke to make these. From: To: Time: Mon Nov 24 18:43:24 2008 So, if I'm understanding Love's mail, this is both unimportant and he really wants to know about it? From: To: Time: Mon Nov 24 19:03:22 2008 my interpretation of Love's e-mail is that (a) the important API is gss-api and (b) you should ask for feedback on the Heimdal list as well as krbdev@mit.edu because it impacts that community as well. From: To: Time: Mon Nov 24 19:44:01 2008 Anyway, if you do choose to reschedule, I'm available any time except for 1 tomorrow. From: To: Time: Tue Nov 25 14:07:21 2008 I've been having trouble dialing in; trying again From: To: Time: Tue Nov 25 18:28:38 2008 Strange; when I create a kdc database on my linux box, the ".ok" lock file gets created with a timestamp in the future by about 15 seconds. From: To: Time: Tue Nov 25 18:29:31 2008 Oh, I see... if the existing timestamp is "now" or in the future, it's set to N+1. I bet that gets done repeatedly... From: To: Time: Tue Nov 25 18:29:53 2008 sounds like a workaround for systems without high-res timestamps From: To: Time: Tue Nov 25 18:30:42 2008 Which is, what, most of them, still? At least in default configurations. From: To: Time: Tue Nov 25 18:31:02 2008 I wonder if we really need to move it into the future if it was "now"... From: To: Time: Sun Nov 30 02:02:45 2008 This room is not anonymous. From: To: Time: Mon Dec 1 13:47:45 2008 food preferences for tomorrow? From: To: Time: Mon Dec 1 13:52:55 2008 sushi? From: To: Time: Mon Dec 1 13:53:59 2008 kiraz or pizza. but if everyone else wants sushi, there's probably a chicken teriyaki or something i can get. From: To: Time: Mon Dec 1 13:54:50 2008 I'm also ok with pizza and kiraz From: To: Time: Mon Dec 1 14:03:16 2008 I'm okay with anything mentioned so far. From: To: Time: Mon Dec 1 14:04:56 2008 If we're canceling the collab session tomorrow, we should let Sam, Sun, etc., know. From: To: Time: Mon Dec 1 14:05:15 2008 i think we will have the dev meeting and then leave after that From: To: Time: Mon Dec 1 14:07:24 2008 Okay. From: To: Time: Mon Dec 1 14:14:41 2008 has anyone mentioned the lack of reference to wrapex on the GSSAPI_DCE proposal? From: To: Time: Mon Dec 1 14:17:30 2008 Not that I saw. From: To: Time: Mon Dec 1 14:19:14 2008 i think it should at least be explained why we are choosing to implement gss_wrap_aead instead of gss_wrapex From: To: Time: Mon Dec 1 15:05:19 2008 yuranlu is a TA for 6.857. how appropriate, or something. From: To: Time: Mon Dec 1 15:07:44 2008 Um. From: To: Time: Mon Dec 1 15:07:57 2008 yeah From: To: Time: Mon Dec 1 15:14:44 2008 Any idea what he's been like since that little incident of his? From: To: Time: Mon Dec 1 15:14:54 2008 no idea From: To: Time: Mon Dec 1 15:15:41 2008 apparently well-behaved enough to be some semblance of a grad student though. From: To: Time: Mon Dec 1 15:17:01 2008 That's not quite enough to reassure me... From: To: Time: Mon Dec 1 15:17:02 2008 Either he's been behaving, or he's been bothering other people, or he's been bothering us so subtly that we haven't noticed yet. From: To: Time: Mon Dec 1 15:17:41 2008 If he's just behaving other people for now, I wouldn't want his attention drawn to any new issues affecting the Athena environment, or specifically Kerberos. From: To: Time: Mon Dec 1 15:17:49 2008 I mean, I can't complain too much. His last incident netted me a small bonus, I think. From: To: Time: Mon Dec 1 15:17:50 2008 er, bothering From: To: Time: Mon Dec 1 15:18:30 2008 eh, as long as he has an official MIT affiliation, if he does misbehave in our direction, substantial smackdown can be applied. From: To: Time: Mon Dec 1 15:19:07 2008 True. From: To: Time: Mon Dec 1 15:21:32 2008 and his last incident of misbehavior was more annoying than clever From: To: Time: Mon Dec 1 16:13:51 2008 so is it just me, or are the lecture notes of 6.857 not accessible to non-registrants? From: To: Time: Mon Dec 1 16:17:13 2008 It looks like it. From: To: Time: Mon Dec 1 16:19:49 2008 Previous years handouts seem available. From: To: Time: Mon Dec 1 16:20:34 2008 handouts maybe, but i was trying to look for lecture outlines more complete than just their titles From: To: Time: Mon Dec 1 16:24:04 2008 doing a bunch of merges gives me a strong hatred for our make depend system. It would be much easier if the dependency information were not in the same Makefile as the source of the build system. From: To: Time: Mon Dec 1 16:25:05 2008 we could have dependencies be in a file of their own and concatenate it at configure time From: To: Time: Mon Dec 1 16:25:33 2008 Or depend on gnumake and use include. Yes, both of those would fix the problem From: To: Time: Mon Dec 1 16:32:20 2008 While I've said before that using gnumake would probably be a big win in the long run, Tom's idea wouldn't be that hard to implement, I think. Hmm... From: To: Time: Mon Dec 1 16:38:52 2008 In r21120, Luke makes it so that the non-iov crypto apis are implemented on top of the iov apis He does not actually remove any of the non-iov implementations, although he could do that. From: To: Time: Mon Dec 1 16:39:20 2008 Do we want that change? negatives: not very well tested. positives: harmless From: To: Time: Mon Dec 1 16:39:22 2008 at the krb5 level or the gss level? From: To: Time: Mon Dec 1 16:39:40 2008 krb5 level. From: To: Time: Mon Dec 1 16:40:23 2008 Not at the k5crypto level? From: To: Time: Mon Dec 1 16:41:01 2008 i meant k5crypto From: To: Time: Mon Dec 1 16:42:00 2008 As did I From: To: Time: Mon Dec 1 16:42:32 2008 Okay. Without actually reading the change (starting to skim now), it sounds like a reasonable idea. From: To: Time: Mon Dec 1 16:43:16 2008 I assume we want to get to the point of not having code duplication. If that means doing something that's not well-tested, we should start testing it. From: To: Time: Mon Dec 1 16:43:38 2008 i tend to agree From: To: Time: Mon Dec 1 16:44:07 2008 Oh, I see. He makes it possible for you to implement the aead functions, and leave out the simple encrypt and decrypt functions, and the library will implement the latter in terms of the former. So, no removal of code duplication, because the existing cryptosystems all still have simple encrypt/decrypt functions. From: To: Time: Mon Dec 1 16:44:20 2008 O, if you go remove the duplication you'll test it good and hard:-) From: To: Time: Mon Dec 1 16:44:52 2008 But it is a valid step on the path to removing duplication From: To: Time: Mon Dec 1 16:45:02 2008 Yes, it looks that way. From: To: Time: Mon Dec 1 16:46:25 2008 OK, I'll review and pull it up to mskrb-integ-crypto-iov From: To: Time: Mon Dec 1 16:46:46 2008 I have so many branches running around:-) From: To: Time: Mon Dec 1 16:47:01 2008 how many branches that are not in svn? From: To: Time: Mon Dec 1 16:47:41 2008 3 or 4 From: To: Time: Mon Dec 1 16:48:37 2008 You're using svk for that? (Just curious. Some people use git-svn.) From: To: Time: Mon Dec 1 16:48:40 2008 Cherry-picking for partial merges in svn can get that way, it seems. Though I've never had it get that bad. From: To: Time: Mon Dec 1 16:49:39 2008 So far though I have not spent much wasted time based on branching. I have had to resolve conflicts but that is mostly inherent. I've asked Luke to hold off on Love's argument order change even if he is eventually going to do it because I think that would cause my universe to explode right now. From: To: Time: Mon Dec 1 16:49:46 2008 At most I tend to get a branch for merging, and then simple checkouts for small, independent changes I want to fast-track around the merging branch back into the upstream base and bring them back down into the merging branch... still icky. From: To: Time: Mon Dec 1 16:50:31 2008 i'm trying to gain enough git clue to start using it more From: To: Time: Mon Dec 1 16:50:49 2008 Greg, git-svn. The workflow that seems to work best for Luke benefits from me having cherry-pick and rebase From: To: Time: Mon Dec 1 16:51:03 2008 Interesting to know. From: To: Time: Mon Dec 1 16:52:25 2008 Now, as a result, we kind of lose author information on mskrb-integ-crypto-iov. I think that if you were running svn 1.5 using svn merge would have been something to seriously think about From: To: Time: Mon Dec 1 16:52:56 2008 did svn grow some better merge support at 1.5? From: To: Time: Mon Dec 1 16:53:55 2008 It grew merge tracking. I don't know if it tends to create more conflicts or the same number of conflicts as git. From: To: Time: Mon Dec 1 17:09:12 2008 Nico, please understand what the API actually does before explaining to Love how to use it. *sigh* From: To: Time: Tue Dec 2 10:22:00 2008 did someone nuke Stephen Ince's bug report from the mod queue? From: To: Time: Tue Dec 2 10:44:11 2008 I wish I knew whether these gssrpc test case failures were introduced by Luke's code or are just random From: To: Time: Tue Dec 2 10:44:35 2008 what do they look like? do the same tests pass on the trunk? From: To: Time: Tue Dec 2 10:45:47 2008 Haven't gotten as far as running on the trunk. Using ../../../../src/lib/rpc/unit-test/config/unix.exp as tool-and-target-specific interface file. TOP=/home/hartmans/luke-krb5/build/kadmin ERROR: didn't get ok back ERROR: didn't get ok back ERROR: didn't get ok back ERROR: didn't get ok back ERROR: didn't get ok back ERROR: didn't get ok back Running pass `tcp' ... Running ../../../../src/lib/rpc/unit-test/rpc_test.0/expire.exp ... Running ../../../../src/lib/rpc/unit-test/rpc_test.0/fullrun.exp ... Running ../../../../src/lib/rpc/unit-test/rpc_test.0/gsserr.exp ... FAIL: tcp: gss err: timeout waiting for server output Running pass `udp' ... Running ../../../../src/lib/rpc/unit-test/rpc_test.0/expire.exp ... Running ../../../../src/lib/rpc/unit-test/rpc_test.0/fullrun.exp ... Running ../../../../src/lib/rpc/unit-test/rpc_test.0/gsserr.exp ... FAIL: udp: gss err: timeout waiting for server output === rpc_test Summary === # of expected passes17 # of unexpected failures2 # of unresolved testcases1 ./client version ./server version From: To: Time: Tue Dec 2 10:46:27 2008 could be race conditions, but i thought i got rid of most of those. on Debian/x86? From: To: Time: Tue Dec 2 10:46:49 2008 And I'm trying to figure out if it is now hung. From: To: Time: Tue Dec 2 10:47:13 2008 debian with an x86_64 kernel and ia32 userspace From: To: Time: Tue Dec 2 10:49:11 2008 Not so promising: from dbg.log runtest completed at Tue Dec 2 10:41:16 2008 write() failed to write anything - will sleep(1) and retry... From: To: Time: Tue Dec 2 10:49:37 2008 great. maybe there is a pty driver bug on Linux too. From: To: Time: Tue Dec 2 10:50:41 2008 expect was not taking sigterm, but sigkill was helpful. Let's checkout the trunk From: To: Time: Tue Dec 2 10:50:55 2008 Will this work better on solaris? From: To: Time: Tue Dec 2 10:51:16 2008 possibly. this is the iov branch? From: To: Time: Tue Dec 2 10:52:09 2008 No. this is a local branch which is effectively the merge of trunk after iov branch integration + mskrb-integ. I.E. me trying to avoid breaking Luke's work From: To: Time: Tue Dec 2 10:52:45 2008 i don't have git installed on solaris so pulling from you might be difficult. From: To: Time: Tue Dec 2 10:53:09 2008 I wonder how fast git checkout foo&&make clean&&make all would be on this system with compilercache. From: To: Time: Tue Dec 2 10:53:37 2008 Do the dialups have an expect and dejagnu? From: To: Time: Tue Dec 2 10:54:15 2008 not a useful version. i keep local builds because the gnu locker versions suck. also, they're a bit tricky to build from source. From: To: Time: Tue Dec 2 10:54:29 2008 Ken might have some prebuilt ones in the krbdev locker. From: To: Time: Tue Dec 2 10:57:46 2008 The system I'm running on does run a kadmind if that breaks things. From: To: Time: Tue Dec 2 10:58:40 2008 it might. it might also not play nicely with a running kdc. From: To: Time: Tue Dec 2 10:58:45 2008 i hate our test suite. From: To: Time: Tue Dec 2 11:00:11 2008 It has a couple things going for it--like being better than none and catching problems. From: To: Time: Tue Dec 2 11:01:58 2008 Trunk seems to have the same behavior From: To: Time: Tue Dec 2 11:02:59 2008 Ooh. Four of the five spam messages in the kerberos@mit moderation queue matched the filter rule I set up last night. If that keeps up, switching that rule to "discard" will probably cut out quite a chunk of the moderation work. From: To: Time: Tue Dec 2 11:03:19 2008 doing build on iov branch now. will check trunk as well. From: To: Time: Tue Dec 2 11:03:28 2008 Ken, did you punt Stephen Ince's message from krb5-bugs-incoming? From: To: Time: Tue Dec 2 11:03:54 2008 or more usefully, have you touched that moderation queue in the past day or two? From: To: Time: Tue Dec 2 11:04:00 2008 Not intentionally, I remember seeing it and meant to accept it. From: To: Time: Tue Dec 2 11:04:13 2008 Did it not come through? From: To: Time: Tue Dec 2 11:04:19 2008 oh. did you ever do a "discard deferred" though? From: To: Time: Tue Dec 2 11:04:53 2008 I'm trying now with kadmind and krb5kdc disabled. I wish I knew why expect is spinning on exit. From: To: Time: Tue Dec 2 11:05:03 2008 Yeah, but I (try to) only do that after making a full sweep through and marking stuff to be accepted. Maybe I botched it this time. From: To: Time: Tue Dec 2 11:05:07 2008 spinning on exit smells like pty issues. From: To: Time: Tue Dec 2 11:05:17 2008 ok, please ask him to resubmit then. From: To: Time: Tue Dec 2 11:07:58 2008 I may have the moderation message still. I'll just file it. From: To: Time: Tue Dec 2 11:09:41 2008 Same behavior without daemons running on the machine From: To: Time: Tue Dec 2 11:10:18 2008 ok. when my build finishes running i'll see if i can rep on iov branch From: To: Time: Tue Dec 2 11:12:07 2008 The iov branch should be the same as the trunk: there are no rpc changes there. There are rpc changes on mskrb-integ From: To: Time: Tue Dec 2 11:12:36 2008 In dbg.log: **** CODE 43787566 (GSS-API (or Kerberos) error) ***^M ERROR UNKNOWN {GSS-API (or Kerberos) error}^M^M % ^M Now to see if that is com_err or gss status From: To: Time: Tue Dec 2 11:14:22 2008 do we have an ovk error table? From: To: Time: Tue Dec 2 11:14:35 2008 possibly From: To: Time: Tue Dec 2 11:15:19 2008 Ah, we do and it's a completely useless kadm5 gss-api error. From: To: Time: Tue Dec 2 11:15:47 2008 #define KADM5_GSS_ERROR (43787566L) From: To: Time: Tue Dec 2 11:15:58 2008 (catching up) separate daemons shouldn't be a problem if they're not using up the same ports, and the test suite tries hard to avoid using the standard ports. From: To: Time: Tue Dec 2 11:16:39 2008 iov branch works fine for me. will try trunk. From: To: Time: Tue Dec 2 11:18:08 2008 er, iov branch in lib/rpc/unit_tests works on solaris for me From: To: Time: Tue Dec 2 11:18:51 2008 I realize I failed to make install before this last trunk run. Since this is linu x, that probably matters. From: To: Time: Tue Dec 2 11:20:00 2008 yeah. i wish there were an easy way to work around that problem. From: To: Time: Tue Dec 2 11:21:28 2008 Avoid rpaths. From: To: Time: Tue Dec 2 11:22:10 2008 OK, trunk seems to succeed for the tcp pass. So, I'll let Luke know he should take a look From: To: Time: Tue Dec 2 11:22:28 2008 Hm, an "I'm never going to install this, only check it, so don't use rpaths" configure option might be good. From: To: Time: Tue Dec 2 11:23:09 2008 Plus an I'm the OS vendor so I don't want rpaths or I'm going to install this in ld.so.conf so I don't want rpaths option. From: To: Time: Tue Dec 2 11:23:34 2008 Well, and we had previously discussed not putting /usr/lib into rpath. From: To: Time: Tue Dec 2 11:23:41 2008 === rpc_test Summary === # of expected passes20 However it still hangs. From: To: Time: Tue Dec 2 11:25:50 2008 It's in a tight loop doing fcntl64(9, F_GETFL) = -1 EBADF (Bad file descriptor) fcntl64(9, F_SETFL, O_ACCMODE|O_CREAT|O_EXCL|O_NOCTTY|O_TRUNC|O_APPEND|O_SYNC|O O_ASYNC|O_DIRECT|O_LARGEFILE|O_DIRECTORY|O_NOFOLLOW|O_NOATIME|O_CLOEXEC|0xfff000 03c) = -1 EBADF (Bad file descriptor) fcntl64(9, F_GETFL) = -1 EBADF (Bad file descriptor) From: To: Time: Tue Dec 2 11:28:23 2008 That's a tcl bug in the exit path. From: To: Time: Tue Dec 2 11:28:53 2008 Although I'm not sure exactly what circumstances trigger it; there might also be an expect bug. I can provide a patch or a link to the tcl issue. From: To: Time: Tue Dec 2 11:29:33 2008 ... except I have to run off to W92 for the meeting. It's tcl bug 2270477. That bug only covers tcl spinning endlessly on exit; any other errors you saw were something else. From: To: Time: Tue Dec 2 11:32:45 2008 All other problems I saw happened on Luke's branch but not on the trunk. Confirming that the iov branch also works From: To: Time: Tue Dec 2 11:37:16 2008 and trunk doesn't build on solaris anymore due to a raw asprintf From: To: Time: Tue Dec 2 11:41:34 2008 oops. missing k5-platform.h somewhere it sounds like From: To: Time: Tue Dec 2 11:41:42 2008 found it From: To: Time: Tue Dec 2 11:57:57 2008 Sorry about that. I tried to ensure that k5-platform was included everywhere I used asprintf, but I probably should have done a build test on Solaris. From: To: Time: Tue Dec 2 15:14:51 2008 hm. does fisheye need kicking? From: To: Time: Tue Dec 2 15:22:32 2008 ok, asked for it to be kicked. From: To: Time: Tue Dec 2 15:22:53 2008 Did it have indigestion on my commit? From: To: Time: Tue Dec 2 15:23:09 2008 no, it stopped almost a week ago From: To: Time: Tue Dec 2 15:23:38 2008 the updated commit handler happily fabricates nonexistent fisheye URLs now :-) From: To: Time: Tue Dec 2 15:24:26 2008 or more precisely, as-yet-nonexistent URLs From: To: Time: Tue Dec 2 15:29:00 2008 theory from amb is resource exhaustion. newer releases of fisheye might be better. From: To: Time: Tue Dec 2 15:45:45 2008 (bye, lxs. hi, lxs.) From: To: Time: Tue Dec 2 15:50:09 2008 Am I bouncing again? From: To: Time: Tue Dec 2 15:50:36 2008 yup From: To: Time: Tue Dec 2 15:50:43 2008 sigh From: To: Time: Tue Dec 2 15:50:55 2008 not a lot From: To: Time: Tue Dec 2 15:50:57 2008 I see they did a good job at fixing that bug From: To: Time: Tue Dec 2 15:51:01 2008 ;-) From: To: Time: Tue Dec 2 16:10:28 2008 anyway fisheye should be catching up From: To: Time: Tue Dec 2 16:32:17 2008 A possible reason not to supply diffs as attachments in commit emails: it makes it harder to reply to the email message with comments inline. From: To: Time: Tue Dec 2 16:32:51 2008 (This came up on the Subversion dev list, because their list software was upgraded and diffs started being supplied as attachments.) From: To: Time: Tue Dec 2 16:33:03 2008 Greg, good point. From: To: Time: Tue Dec 2 16:34:11 2008 also the fisheye changeset page has a link for the raw patch From: To: Time: Tue Dec 2 16:45:48 2008 Yes, good point... From: To: Time: Wed Dec 3 11:32:22 2008 The rpc unit test failure was caused by the issue I brought up on krbdev in case it was not obvious. From: To: Time: Wed Dec 3 13:43:26 2008 So my test suite runs are now failing in rlogin.exp with 'can not find channel named "exp13"'. Do we have any information on this before I build a debugging expect and break out gdb? From: To: Time: Wed Dec 3 14:11:30 2008 Oops, the commit handler changes produce krb5 fisheye URLs even for commits to the kfm repository ;-) From: To: Time: Wed Dec 3 14:11:44 2008 see RT 6275 From: To: Time: Wed Dec 3 14:11:54 2008 oops. i should fix that. :-) From: To: Time: Wed Dec 3 14:12:06 2008 Click on the URL to see diffs! They have nothing to do with the commit, but they're diffs! From: To: Time: Wed Dec 3 14:12:13 2008 yay diffs! From: To: Time: Wed Dec 3 14:12:58 2008 My kfm commit appears to correspond to some sort of Changelog file cleanup commit from 1995 From: To: Time: Wed Dec 3 14:24:42 2008 should be fixed now; awaiting confirmation making its way through our sluggish mail system. From: To: Time: Wed Dec 3 14:25:37 2008 also, the commit handler is a bit untidy and should get cleaned up, probably about the time we implement diffs (if we do that) From: To: Time: Wed Dec 3 14:31:50 2008 oh oops, typo. that was why it wasn't making it. From: To: Time: Sun Dec 7 02:02:29 2008 This room is not anonymous. From: To: Time: Mon Dec 8 13:17:39 2008 I wonder if our bsdi shlib.conf fragment even vaguely works. (It doesn't put CFLAGS or LDFLAGS into the link commands.) From: To: Time: Mon Dec 8 14:41:51 2008 it has probably bit-rotted From: To: Time: Tue Dec 9 09:59:23 2008 I'm trying to figure out whether I'm better off pulling parts off the mskrb-integ branch like the 3244 code or whether I want to get set to merge everything that is there now. The only thing on the branch that I hope we never want is the case insensitive principal compare code etc. From: To: Time: Tue Dec 9 10:00:18 2008 However various bits are in various levels of testedness. From: To: Time: Tue Dec 9 10:01:46 2008 I think that the 3244 code is ready now, I think that I could get the rd_req change into shape fairly soon. I think that the GSS-API stuff will require significant testing. I suspect the PAC APIs just need to be code reviewed. From: To: Time: Tue Dec 9 10:03:24 2008 I guess asking Luke is a reasonable approach here.:-) From: To: Time: Tue Dec 9 10:36:17 2008 Is the whole collaboration meeting cancelled? From: To: Time: Tue Dec 9 10:36:31 2008 (ie: should I grab lunch on the way in?) From: To: Time: Tue Dec 9 10:38:12 2008 did anyone arrange for lunch? From: To: Time: Tue Dec 9 10:40:59 2008 not me ;-) From: To: Time: Tue Dec 9 10:41:25 2008 I thought we'd cancelled the whole thing last week but I don't remember From: To: Time: Tue Dec 9 10:42:15 2008 i think we left it up to people who were still in town. if no one has sent mail about lunch i would assume that at least lunch is not arranged. From: To: Time: Tue Dec 9 10:42:34 2008 kk From: To: Time: Tue Dec 9 12:24:37 2008 Should the krb4 code removal extend to the libkrb5 API functions related to krb4? (krb5_524_conv_principal, krb5_425_conv_principal, krb5_524_convert_creds) From: To: Time: Tue Dec 9 12:29:47 2008 I think that's still an open question. Some of them might be in use by stuff that needs krb4 names in some places, like the krb5-ish AFS code. From: To: Time: Tue Dec 9 12:35:54 2008 Okay. From: To: Time: Tue Dec 9 12:38:30 2008 Preserving convert_creds would mean preserving the whole krb524 framework, I think. From: To: Time: Tue Dec 9 12:40:41 2008 I think that you want to preserve the ABI, so you at most want to stub them out. Note that if you build --without-krb4 then they are mostly already stubbed. I assume you're doing a projec writeup that will cover questions like this so we can review them? From: To: Time: Tue Dec 9 12:42:53 2008 Yes; just getting initial reactions first. I don't know how many of these issues people thought of when they decided to remove krb4 in the first place. From: To: Time: Tue Dec 9 12:44:37 2008 If they're already stubbed out when building without krb4 support, they can just remain stubbed out. Thanks. From: To: Time: Tue Dec 9 12:45:43 2008 (The conv_princ functions don't get stubbed out, but they don't pull in any other pieces of the krb4 pie.) From: To: Time: Tue Dec 9 12:45:54 2008 But people can build with the krb4 support enabled, and if what they need is just the name translation, they may still want to have that enabled. I think last time we discussed it the conclusion was that we needed to find out what people still needed.... From: To: Time: Tue Dec 9 12:46:30 2008 Ah, that's not surprising. So maybe keeping those and dumping the rest will be the way to go. From: To: Time: Tue Dec 9 12:47:40 2008 Certainly there are environments where you want name translation. For example AFS From: To: Time: Tue Dec 9 12:48:44 2008 how is the AFS timeline for migrating away from krb4? and is the naming of AFS principals going to remain krb4-style indefinitely? From: To: Time: Tue Dec 9 12:49:46 2008 Interestingly, the v4lifetime internal functions are compiled in regardless of whether krb4 support is enabled, even though they are only used by convert_creds. From: To: Time: Tue Dec 9 12:52:46 2008 ok, latency here sucks and i have a session to go to. From: To: Time: Tue Dec 9 12:53:13 2008 Well, AFS is migrated away from krb4 although not really DES already. So far I have not seen a push away from krb4 principal names. From: To: Time: Tue Dec 9 13:14:23 2008 des-cbc-crc:v4 and des-cbc-md5:v4 are the names of legacy ciphers used in v4, yes? I assume those need to stick around. From: To: Time: Tue Dec 9 13:18:01 2008 No, they are krb5 ciphers with v4 salting. That definitely needs to stick around, although perhaps not as part of the default supported_enctypes for the kdc From: To: Time: Tue Dec 9 13:18:13 2008 "v4" is the salt type, there. It needs to stick around for backwards compatibility. From: To: Time: Tue Dec 9 14:08:09 2008 Huh. If you build without krb4 support, the srvtab keytab type is compiled in, but the ktutil srvtab support is compiled out. From: To: Time: Tue Dec 9 14:08:44 2008 Though presumably you can just rkt SRVTAB:pathname. From: To: Time: Tue Dec 9 14:11:19 2008 Still, that seems wrong. From: To: Time: Tue Dec 9 14:12:01 2008 The rst and wst functions could be rewritten to use the keytab interface to avoid the extra code there. From: To: Time: Tue Dec 9 14:13:31 2008 Or removed. I'm not sure which is right. From: To: Time: Tue Dec 9 14:14:48 2008 Many of the kadmin references to v4 are centered around a "setv4key" command. What does it do? From: To: Time: Tue Dec 9 14:15:58 2008 I've never heard of it. From: To: Time: Tue Dec 9 14:17:08 2008 Looking in svr_principal.c From: To: Time: Tue Dec 9 14:17:58 2008 * Set only ONE key of the principal, removing all others. This key * must have the DES_CBC_CRC enctype and is entered as having the * krb4 salttype. This is to enable things like kadmind4 to work. Is there even still a kadmind4? From: To: Time: Tue Dec 9 14:18:59 2008 Ah, so it is an interface that kadmind4 could use in order to set a des-cbc-crc:v4 keyp on a principal. It's probably best to leave it there because it is exposed in an RPC API, although if it depends on the v4 library you could turn it into a stub From: To: Time: Tue Dec 9 14:19:19 2008 No, we dropped that in 1.6 or 1.5 From: To: Time: Tue Dec 9 14:20:11 2008 It doesn't depend on the v4 library, and is compiled in with krb4 support disabled. I'll plan to leave it in. From: To: Time: Tue Dec 9 14:25:50 2008 There are three symbols defined in osconf.hin which are apparently unused elsewhere in the tree, and are tagged as "krb4 kadmin stuff". That's never a public header, right? I'm guessing that's just garbage to be GC'd at some point. From: To: Time: Tue Dec 9 14:26:53 2008 I believe you are correct From: To: Time: Tue Dec 9 14:27:54 2008 I think I'll just remove those now for simplicity. From: To: Time: Tue Dec 9 14:37:38 2008 Any thoughts on the KDC fakeka code? (I assume it's an AFS shim.) From: To: Time: Tue Dec 9 14:40:12 2008 No idea. Russ seems to be using it, or at least reported bugs earlier this year. From: To: Time: Tue Dec 9 14:41:53 2008 I think it's pretty deeply tied into krb4 compat, so it'll probably go. From: To: Time: Tue Dec 9 14:41:59 2008 It emulates kaserver From: To: Time: Tue Dec 9 14:52:29 2008 Ken and I were just discussing something similar in personals. What should the behavior of the iov apis be in cases where rrc is not well aligned with what's going on. It's clear what the behavior should be for the stream buffer type. However what should the code do if the caller provides explicit header|data|trailer? From: To: Time: Tue Dec 9 14:59:15 2008 I guess the question is whether using the "right" RRC value when wrapping a message through this API is a requirement of the (suitably updated) mechanism spec. If it is, then an application giving us obviously-wrong data is just an error. But absent such a requirement, we need to handle it. From: To: Time: Tue Dec 9 14:59:59 2008 (where by "obviously-wrong data" I mean something it claims to have broken down into different fields but RRC doesn't match what is supposed to happen) From: To: Time: Tue Dec 9 15:01:42 2008 Well, It's not clear to me what the different buffer types mean on decrypt. Is it the case that the virtual token is header|data*|pad|trailer? Or is it the case that the token header always goes in the header buffer? From: To: Time: Tue Dec 9 15:08:45 2008 I'd been assuming the latter, but I'm not 100% certain either. If it's the former, I'd question whether we actually need all the various different types for reasons other than "this is how the API was already set up". From: To: Time: Tue Dec 9 15:10:47 2008 Hmm. I didn't realize that we had added Luke to krbcore. Do we expect him to be involved in the product long-term? From: To: Time: Tue Dec 9 15:13:14 2008 Well, all the different types have distinct behaviors. trailer: optional data that is not set on input to wrap header: non-optional data not set on input to wrap data: fairly obvious pad: data with specific alignment and verification requirements not set on input to wrap From: To: Time: Tue Dec 9 15:14:44 2008 If the header always goes in the header, what does that say about legal values for the rrc? From: To: Time: Tue Dec 9 15:22:17 2008 Not that I'd heard about. AFAIK it's just this current contract... From: To: Time: Tue Dec 9 15:22:56 2008 Too bad. He'd be a good krbcore member if he were willing to dedicate time From: To: Time: Tue Dec 9 15:25:11 2008 I'm just thinking if the "spec" is that the combined token header|data*|pad|trailer is all that matters and you can effectively slide the dividing points around, sure we need something for pad and trailer but I'm not convinced we actually need both. Combine them, or always push the trailer into the header and get rid of the separate trailer field and type... From: To: Time: Tue Dec 9 15:25:43 2008 Yeah, I don't know if he'd be interested though. Maybe Tom and Steve have talked to him and he is; I dunno... From: To: Time: Tue Dec 9 15:29:00 2008 Well, it's not clear you need both pad and trailer, but MS has pad but not trailer, so it makes it a bit easier if we have both. The crypto iov API assumes that the krb5 crypto header fits within one buffer. doing something else got kind of ugly. From: To: Time: Tue Dec 9 15:29:26 2008 If the encrypted header winds up in the header field, I think that fixes us to one specific value of RRC. Well, no... only if we also require that the encryption of the rest be, in fact, done in place, instead of just providing a lot of hooks to let the implementation optimize it that way. From: To: Time: Tue Dec 9 15:30:21 2008 But if you have a trailer the encrypted header need not be in the header. From: To: Time: Tue Dec 9 15:31:44 2008 Right. And if you're not requiring in-place operations, the encrypted header doesn't need to wind up in the trailer field either. RRC could be set randomly, and ciphertext far offset from the corresponding plaintext. From: To: Time: Tue Dec 9 15:32:45 2008 (Of course it doesn't matter if an implementation does it in place, actually, it's whether the data and other fields are set up to allow for doing in-place operations efficiently.) From: To: Time: Tue Dec 9 15:33:54 2008 I'm sort of tempted to say that if the rrc is strange, we re-arrange the data in memory with a special rrc-fixup pass Which I guess is what we do for stream. From: To: Time: Tue Dec 9 15:34:14 2008 Yeah, I'm fine with that. From: To: Time: Tue Dec 9 15:35:20 2008 I feel kind of uncomfortable not supporting arbitrary rrc. From: To: Time: Tue Dec 9 15:35:56 2008 As it seems like a spec violation. It takes application behavior plus that implementation choice to actually get a spec violation, but it seems like it will decrease interop. From: To: Time: Tue Dec 9 15:37:57 2008 O, ugh. And how does this interact with sign_only data buffers? I.E. if you rrc things so that ordering between data buffers changes? From: To: Time: Tue Dec 9 15:38:15 2008 hahahaha From: To: Time: Tue Dec 9 15:38:17 2008 sorry. From: To: Time: Tue Dec 9 15:41:14 2008 expn rrc? From: To: Time: Tue Dec 9 15:41:56 2008 "right rotation count" -- a hack put into RFC 4121 to make the use of SSPI easier, so they could do in-place encryption and not have to add a trailing field. From: To: Time: Tue Dec 9 15:42:07 2008 Thanks. From: To: Time: Tue Dec 9 15:42:14 2008 RFC 4121 4.2.5 right rotation count. Possibly the worst hack I've ever inflicted on the world From: To: Time: Tue Dec 9 15:46:04 2008 Actually, ignore sign_only. It's not clear what the semantics of this are just with data buffers. From: To: Time: Tue Dec 9 15:48:15 2008 Let l be the length of the krb5 trailer and the GSS trailer. If I set rrc = l+1 then that means I'm moving one byte of data into the header buffer. I guess that's actually fairly well defined assuming I'm not mucking with both the rrc count and the buffer lengths at the same time From: To: Time: Tue Dec 9 15:49:39 2008 Actually, I guess semantics with regard to sign_only are also well defined. rrc is applied logically after encryption, ignoring the sign_only buffers . From: To: Time: Tue Dec 9 15:50:13 2008 I think that sounds right. From: To: Time: Tue Dec 9 15:53:15 2008 i think RRC is fine and dandy if you are working under the constraint that excessive copies must be eliminated at almost any cost. From: To: Time: Tue Dec 9 15:53:24 2008 Ah. I understand my confusion. Typically you're setting rrc because you don't have a trailer . Everything is nice and reasonably well defined provided that you can trust the application to pass in right data buffer lengths and that the sum of header+padding+trailer buffers actually corresponds to the overhead you have. Although that invarient is structurally maintained by the API. From: To: Time: Tue Dec 9 15:54:09 2008 does SSPI error out if you give it header and trailer buffers of incorrect length? From: To: Time: Tue Dec 9 15:55:50 2008 ok, something is eating krb5-bugs-incoming postings. a posting that i was fairly sure was approved hasn't shown up. From: To: Time: Tue Dec 9 16:15:05 2008 ok, the bug report eating monster has been slain From: To: Time: Tue Dec 9 16:41:10 2008 anyway sorry about the long trace headers on the last bug; i did a redist from my machine using a copy from the mod queue. From: To: Time: Tue Dec 9 16:42:39 2008 Anyone want to look at http://k5wiki.kerberos.org/wiki/Projects/Remove_krb4 before I send mail about it? From: To: Time: Tue Dec 9 16:44:05 2008 looking From: To: Time: Tue Dec 9 16:48:18 2008 I wonder if turning setv4key into a stub would be the right thing. But the page looks fine for sending out mail... From: To: Time: Tue Dec 9 16:49:03 2008 Yeah, I'm mainly curious if there's stuff about the project I should write up before soliciting review; no need to form opinions on what to keep and what to punt right away. From: To: Time: Tue Dec 9 16:50:01 2008 I think it's fine on that score. From: To: Time: Tue Dec 9 16:52:11 2008 Heh... The SRVTAB keytab stuff reminds me -- since you're working on the Kerberos team now, are you going to integrate the "ANY" keytab code? :-) From: To: Time: Tue Dec 9 16:53:55 2008 I hope not! From: To: Time: Tue Dec 9 16:54:38 2008 Is Athena10 switching to actualyl using keytab files, or still srvtabs? From: To: Time: Tue Dec 9 16:54:56 2008 There was an interesting problem a while back because Red Hat adopted a slightly buggy version of that code. The upshot was that stock RHEL machines administered by IS&T people wouldn't work with a keytab and no srvtab. From: To: Time: Tue Dec 9 16:55:09 2008 It'd be kind of nice to be able to use MIT krb5 with Athena's krb5.conf... From: To: Time: Tue Dec 9 16:55:15 2008 Oh, ow. From: To: Time: Tue Dec 9 16:56:39 2008 There's no automated upgrade path from Athena 9 to Athena 10, and Athena 10 doesn't have an Athena krb5.conf exactly (it has some changes to the Ubuntu one, I think, but it doesn't add the ANY keytab type). From: To: Time: Tue Dec 9 17:00:33 2008 Ah, okay. We -- er, they -- should get accounts to start giving out keytabs intsead of srvtabs if they haven't changed already. From: To: Time: Tue Dec 9 17:01:09 2008 I'm pretty sure they gave me a keytab the last time I asked. From: To: Time: Tue Dec 9 17:01:24 2008 Good. It's been a while since I've tried. From: To: Time: Tue Dec 9 17:01:30 2008 It's been a while, though. From: To: Time: Tue Dec 9 17:14:32 2008 xvm always asks for keytabs and accounts is happy to give us keytabs From: To: Time: Tue Dec 9 17:14:49 2008 do we know what they do by default? From: To: Time: Tue Dec 9 17:15:20 2008 I thought they gave keytabs by default, but a friend of mine didn't specify and got a srvtab. From: To: Time: Tue Dec 9 17:15:28 2008 This was a couple months back. From: To: Time: Tue Dec 9 17:16:49 2008 in any case the policies of accounts are important to align with what MIT has deployed, not necessarily the latest and greatest that we release From: To: Time: Tue Dec 9 17:19:06 2008 Greg, may I add v4rcp to the set of applications being removed? From: To: Time: Tue Dec 9 17:19:46 2008 rlogin and telnet were not intended to be a complete list, just a way of making people realize what I meant by "applications". From: To: Time: Tue Dec 9 17:19:59 2008 v4rcp definitely qualifies as application code to do krb4 authentication, and is on the chopping block. From: To: Time: Tue Dec 9 17:20:18 2008 anyway are people finding the fisheye links in commit messages to be helpful? From: To: Time: Tue Dec 9 17:24:08 2008 I wish lenny would get around to releasing so I can pull krb4 out of debian. I plan to decouple that from the 1.7 release and for a while basically be shipping --without-krb4 . Obviously I'll need to coordinate with Russ. From: To: Time: Tue Dec 9 17:27:08 2008 is it just me or has discussion of the k5crypto AEAD stuff gotten thoroughly entangled with the GSS AEAD stuff? From: To: Time: Tue Dec 9 17:31:31 2008 I haven't really seen that to an excessive extent. But they are closely related APIs From: To: Time: Tue Dec 9 17:32:13 2008 true. i'm trying to untangle them enough to decide if i should hold off on the k5crypto approval until the GSS stuff is straightened out. From: To: Time: Tue Dec 9 17:32:33 2008 What do you consider open for the gss stuff? From: To: Time: Tue Dec 9 17:33:12 2008 I sent a summary message to the list indicating what I believed were resolutions for the comments that had been brought up. From: To: Time: Tue Dec 9 17:33:38 2008 Today I sent a message on the RRC issue. Currently the project does not speak one way or another to that issue. From: To: Time: Tue Dec 9 17:37:39 2008 hm. Love's issue re flags and types being separate members of gss_iov_buffer_desc? From: To: Time: Tue Dec 9 17:38:14 2008 My summary said we agreed to change that. Luke has not yet implemented that change. From: To: Time: Tue Dec 9 17:39:02 2008 oh, that was not obvious. i thought you were only talking about sign_only. From: To: Time: Tue Dec 9 17:39:18 2008 I was being a bit lazy and was not going to update the API in the project page until Luke had updated gssapi_ext.h. However regardless of whether anyone votes yes, I will not mark the project approved until that is dealt with From: To: Time: Tue Dec 9 17:39:44 2008 O, no you're right. I was talking about sign_only. From: To: Time: Tue Dec 9 17:40:13 2008 I thought Love said he could live with separate flags and type. I proposed combining them, but Luke and someone else objected. From: To: Time: Tue Dec 9 17:40:23 2008 oh. From: To: Time: Tue Dec 9 17:40:33 2008 I thought Love said that sign_only being a flag was unacceptable From: To: Time: Tue Dec 9 17:40:59 2008 And personally I was not very happy with it. From: To: Time: Tue Dec 9 17:41:25 2008 If Love is unhappy with the result we can go another round. From: To: Time: Tue Dec 9 17:41:51 2008 let me see what the win32 api for this looks like From: To: Time: Tue Dec 9 17:43:10 2008 You should check. As I recall, it has a type and you xor in flags. From: To: Time: Tue Dec 9 17:44:44 2008 typedef struct _SecBuffer { ULONG cbBuffer; ULONG BufferType; PVOID pvBuffer; } SecBuffer, *PSecBuffer; From: To: Time: Tue Dec 9 17:45:08 2008 BufferType gets type and bitwise-ORed flags From: To: Time: Tue Dec 9 17:48:09 2008 there is no equivalent to an alloc flag, as far as i can tell From: To: Time: Tue Dec 9 17:49:03 2008 offline to find power From: To: Time: Tue Dec 9 17:49:46 2008 Right, no alloc flag. From: To: Time: Tue Dec 9 17:53:21 2008 There's really only so long in a given day you can manage to read gss-api code. From: To: Time: Tue Dec 9 17:55:31 2008 In fact, what *is* this code doing? Didn't I already read a function to unwrap a v1 token? From: To: Time: Tue Dec 9 18:02:33 2008 deja vu... From: To: Time: Tue Dec 9 18:36:33 2008 *sigh* It looks like my current screen reader does not claim to support w2k8. (narrator is good enough to install a screen reader, but especially over rdp kind of sucks to use) The just released version I don't have does support 2k8. I wonder if it will work anyway From: To: Time: Thu Dec 11 12:47:09 2008 kinit.c:kinit_prompter() chose an odd place to do the preprocessor conditionalization. From: To: Time: Thu Dec 11 12:48:32 2008 yes, that does seem odd From: To: Time: Thu Dec 11 13:07:04 2008 Ken, have you ever heard of ares? From: To: Time: Thu Dec 11 13:31:17 2008 Yes. AFAIK you don't support /etc/hosts, nsswitch, etc., in ares, right? So we could do async SRV and TXT lookups but still want getaddrinfo calls for addresses. From: To: Time: Thu Dec 11 13:39:07 2008 Yeah. It's not necessarily a practical option; I only mention it because you said existing asynchronous libraries are under the GPL. From: To: Time: Thu Dec 11 13:41:07 2008 nsswitch makes it really impractical to do asynchronous hostname lookups without assuming DNS. From: To: Time: Thu Dec 11 13:43:13 2008 Unless of course threads make you happy From: To: Time: Thu Dec 11 13:45:47 2008 And your OS doesn't just wrap a mutex around the grotty DNS or YP libraries because it's too hard to make them thread-safe. From: To: Time: Thu Dec 11 13:46:35 2008 Do modern oses (Linux, Solaris, OS X) still do that? From: To: Time: Thu Dec 11 13:48:34 2008 Probably not, so that's mostly FUD. From: To: Time: Thu Dec 11 13:53:14 2008 UTF8 has the property that ASCII code points only appear as themselves as single byte chars, right? That is, I can parse through a string looking for slash or quote without doing anything special, right? From: To: Time: Thu Dec 11 13:53:55 2008 Yes, that's a key property of it. From: To: Time: Thu Dec 11 13:53:57 2008 That is correct. From: To: Time: Thu Dec 11 13:55:49 2008 Hmm. Luke seems to have done a lot of damage to krb5_parse_name given that. From: To: Time: Thu Dec 11 13:56:41 2008 I'm about to go into a conference call, but I'd be very interested in whether anyone else can see a reason why get_char and next_char need to exist and c needs to be ucs4. From: To: Time: Thu Dec 11 13:56:52 2008 This is on the mskrb-integ branch From: To: Time: Thu Dec 11 14:11:32 2008 In krb5int_utf8_to_ucs4 he's checking for invalid UTF-8 encodings, but in krb5_parse_name he's not checking for that error. Given that, and the fact that QUOTECHAR et al are all ASCII, no, I don't see much reason for all that stuff. From: To: Time: Thu Dec 11 14:12:06 2008 So does this UTF-8 work mean we're no longer supporting the just-send-8 deployments? From: To: Time: Thu Dec 11 14:15:10 2008 Ken, that's one of the many reasons I'm very uncomfortable with the utf8 work. Do people here believe rejecting invalid UTF8 is a good idea? I tend to believe not. From: To: Time: Thu Dec 11 14:20:12 2008 it depends on where. if you're deep in the rc4 string-to-key where you by definition need to convert to utf-16, it might be ok to reject invalid utf-8. then again, you might want to use a heuristic to convert from native locale encoding. From: To: Time: Thu Dec 11 14:28:56 2008 Right. Also, in the admin interface it might be reasonable to reject invalid encodings. But I don't think libkrb5 is really the right place to do that From: To: Time: Thu Dec 11 14:40:41 2008 If we're going to do UTF-8, then in the parts where we need UTF-8 I think we should reject invalid encodings. But *switching* any particular bit of code from 8-bit to UTF-8 worries me if it affects the existing API. From: To: Time: Thu Dec 11 14:41:46 2008 If we're trying to do some blend of UTF-8 and native encoding, then we can't do any validation. And we may not be able to tell which encoding we have in any given case. From: To: Time: Thu Dec 11 14:43:07 2008 It's the last bit--that it is a blend--that makes it hard for me to believe validation is good From: To: Time: Thu Dec 11 14:43:48 2008 It's the "can't tell" bit that makes me think this may just be a bad idea. From: To: Time: Thu Dec 11 15:13:11 2008 gack. RT ticket content searches don't work on content that belongs to a ticket that has been merged into another ticket. i understand why it happens but it's not easy to fix. From: To: Time: Thu Dec 11 15:19:04 2008 Is it something that RT 3 migration might fix? From: To: Time: Thu Dec 11 15:21:31 2008 Hm, krb_run_aklog in login.krb5 is wrapped up in the krb4 compatibility code, which is probably no longer correct. From: To: Time: Thu Dec 11 15:22:47 2008 Yeah, if aklog can do krb5, or at least fake it really well, we still want to do that even without the krb4 support. From: To: Time: Thu Dec 11 15:24:28 2008 RT3 migration might fix that. dunno. From: To: Time: Thu Dec 11 15:24:57 2008 Ah, the call chain error_message -> kim_os_string_create_localized -> kim_string_copy -> kim_library_init -> kim_error_init -> add_error_table is where our mutex contention comes from. Given that, I think the patch Love provided is probably correct, for the KfM version of com_err, for now. Eventually the localized-string stuff needs to move out of KIM, of course. From: To: Time: Fri Dec 12 11:06:30 2008 klogind currently has flags -4, -5, and -k (which == -4 -5). If you specify none of them, it refuses all connections. After krb4 removal, those options are pointless; should klogind continue to refuse all connections if not given -k? From: To: Time: Fri Dec 12 11:06:48 2008 when running standalone or out of inetd? From: To: Time: Fri Dec 12 11:07:24 2008 Either way, I believe. From: To: Time: Fri Dec 12 11:09:34 2008 I think there was once code to support handling non-Kerberos connections too. If that's gone, we might as well accept krb5 connections without any options. From: To: Time: Fri Dec 12 11:09:42 2008 given that we don't really encourage non-kerberos connections... From: To: Time: Fri Dec 12 11:10:05 2008 I checked pretty carefully, and host-based authentication is no longer allowed. From: To: Time: Fri Dec 12 11:10:30 2008 (If KERBEROS is defined.) From: To: Time: Fri Dec 12 11:10:52 2008 speaking of which, we probably want to get rid of the ifdef soup From: To: Time: Fri Dec 12 11:11:16 2008 Good. From: To: Time: Fri Dec 12 11:12:41 2008 And just have all the applications assume Kerberos? Sounds good, but out of scope for the moment. From: To: Time: Fri Dec 12 11:13:57 2008 if it happens that we stop handling non-kerberos stuff because that's the easiest way to implement something else, i probably won't complain From: To: Time: Fri Dec 12 11:58:21 2008 hm. lots of tab characters in the mskrb-integ branch in files that were marked indent-tabs-mode:nil From: To: Time: Fri Dec 12 11:58:38 2008 i guess Luke doesn't use emacs, or has turned off local variables if he does. From: To: Time: Fri Dec 12 12:09:33 2008 Ken, any insight on why accept_a_connection got added to compat_recv.c? (It was five years ago, so you may or may not remember.) From: To: Time: Fri Dec 12 12:12:02 2008 looking From: To: Time: Fri Dec 12 12:12:30 2008 r15075. Having removed the v4 compat stuff from compat_recv.c, I'm now left with that function, which is only used by krshd.c (where it originally came from). From: To: Time: Fri Dec 12 12:15:46 2008 Not sure. It appears to accept either IPv4 or IPv6 connections on debug_port. I probably was intending that it be useable from krlogind.c too but never got around to implementing it. From: To: Time: Fri Dec 12 12:18:35 2008 I think kcmd.o is pulled into both daemons, you could move the function there, though it'll get linked into the client programs as well. From: To: Time: Fri Dec 12 12:44:25 2008 Slight oversight in my ktutil plan: kt_srvtab is read-only, so ktutil's rst command will live but wst will die. From: To: Time: Fri Dec 12 14:29:17 2008 Anyone else having problems with RT right now? It's telling me I'm not an authorized user. From: To: Time: Fri Dec 12 14:29:43 2008 Hmm: [Fri Dec 12 19:28:08 2008] [error] [client 18.18.1.160] FastCGI: server "/var/www/rt/mason_handler.fcgi" stderr: DBD::Pg::st execute failed: no connection to the server, referer: https://krbdev.mit.edu:444/rt/Ticket/Display.html?id=6286 [Fri Dec 12 19:28:08 2008] [error] [client 18.18.1.160] FastCGI: server "/var/www/rt/mason_handler.fcgi" stderr: RT::Handle=HASH(0x1c230b0) couldn't execute the query 'SELECT * FROM Users WHERE lower(Gecos) = ?' at /usr/share/perl5/DBIx/SearchBuilder/Handle.pm line 518, referer: https://krbdev.mit.edu:444/rt/Ticket/Display.html?id=6286 [Fri Dec 12 19:28:08 2008] [error] [client 18.18.1.160] FastCGI: server "/var/www/rt/mason_handler.fcgi" stderr: \tDBIx::SearchBuilder::Handle::SimpleQuery('RT::Handle=HASH(0x1c230b0)', 'SELECT * FROM Users WHERE lower(Gecos) = ?', 'raeburn') called at /usr/share/perl5/DBIx/SearchBuilder/Record.pm line 1207, referer: https://krbdev.mit.edu:444/rt/Ticket/Display.html?id=6286 From: To: Time: Fri Dec 12 14:30:05 2008 ick From: To: Time: Fri Dec 12 14:30:06 2008 looking From: To: Time: Fri Dec 12 14:32:21 2008 thanks From: To: Time: Fri Dec 12 14:33:25 2008 try now From: To: Time: Fri Dec 12 14:34:33 2008 That looks much happier, thank you. What broke? From: To: Time: Fri Dec 12 14:38:10 2008 RT doesn't recover gracefully if the db server crashes and restarts From: To: Time: Fri Dec 12 14:38:16 2008 not sure why the db crashes yet From: To: Time: Fri Dec 12 14:38:20 2008 Ah. From: To: Time: Fri Dec 12 14:38:47 2008 Is a restart of apache what it needs in that case? From: To: Time: Fri Dec 12 14:39:02 2008 yeah restarting apache from the init script is good enough here From: To: Time: Fri Dec 12 14:39:13 2008 Okay, I'll keep that in mind. From: To: Time: Fri Dec 12 15:36:11 2008 So, I'm looking at Apple's bonjour announcement patches. It seems to me that there *may* be other cases where such hooks are useful, e.g., registering dynamic DNS records, say for a kdc-specific alias after getting a DHCP address, or get an external address and port with uPnP and set up a SRV record. (Either of which could happen with a KDC running at my house. :-) From: To: Time: Fri Dec 12 15:38:14 2008 Probably none of this is stuff we'd want to incorporate in our source tree any time soon, but I'm thinking of rearranging the code to have a somewhat well-defined interface from the KDC code (instead of peeking at global variables or whatever) that might later be turned into a plugin interface. In the meantime, the Apple code would live in our KDC sources... does that sound like a horrible idea? From: To: Time: Fri Dec 12 15:48:55 2008 I'm having trouble reconciling "none of this is stuff we'd want to incorporate" with "the Apple code would live in our KDC sources". From: To: Time: Fri Dec 12 15:55:06 2008 I meant more specifically the DDNS/uPnP stuff, but as far as the Apple code goes, I'd like to provide them the hooks and let them maintain a plugin, eventually. I'd also be okay with just making the plugin interface and sending them back a modification to their code to make it a plugin, and then let them worry about maintaining it going forward. From: To: Time: Fri Dec 12 15:55:46 2008 ... and not ever actually check their code into our tree. From: To: Time: Fri Dec 12 17:17:26 2008 Hm, actually, I think the hooks will be pretty simple. Right now the Apple code is just using the list of realms. There's code for registering SRV records that would have port numbers, but (1) it's disabled by an #ifdef, and (2) it hardcodes 88 as the port number. From: To: Time: Fri Dec 12 17:21:05 2008 In fact, what Apple's doing would be really inadequate for a general hook for any of the stuff I was suggesting. No real use of the port numbers, no providing of UDP local addresses, etc. From: To: Time: Fri Dec 12 17:21:50 2008 At least it's a minimal intrusion into our existing code, which is nice... From: To: Time: Fri Dec 12 17:33:04 2008 If I read this right, when you start providing service for a realm, the Apple code will announce via bonjour a TXT record mapping _kerberos.$HOST.local to the realm being served. Never mind if your machine's default local realm is actually something different. From: To: Time: Fri Dec 12 17:33:49 2008 Oh, I guess the .local name wouldn't be known by your regular KDC anyways. Hm. From: To: Time: Fri Dec 12 17:34:16 2008 But still, I wouldn't expect the local KDC to know the .local name either. From: To: Time: Fri Dec 12 17:34:24 2008 it's all this ad-hoc stuff. won't conflict with statically configured things, assuming people aren't actively doing stupid things. From: To: Time: Fri Dec 12 17:34:45 2008 Yeah, but what is it good for? From: To: Time: Fri Dec 12 17:35:14 2008 $HOST is the Bonjour name right? From: To: Time: Fri Dec 12 17:35:32 2008 I guess. It's "nome-king" for my desktop machine. From: To: Time: Fri Dec 12 17:36:06 2008 is that's what is configured in your "Sharing" preferences pane? From: To: Time: Fri Dec 12 17:36:30 2008 nome-king.mit.edu From: To: Time: Fri Dec 12 17:36:44 2008 hm From: To: Time: Fri Dec 12 17:37:00 2008 do you have "use dynamic hostname" ticked in the "edit" box? From: To: Time: Fri Dec 12 17:37:10 2008 Everything else in bonjour seems to be using just nome-king(.local) though. From: To: Time: Fri Dec 12 17:37:20 2008 yeah i'm not sure where all that hides. From: To: Time: Fri Dec 12 17:37:48 2008 Oh, I see... no, it's not ticked, and the "local hostname" box shows "nome-king.local" there. From: To: Time: Fri Dec 12 17:37:58 2008 ah From: To: Time: Fri Dec 12 17:38:07 2008 I didn't know that was hiding back there. :-) From: To: Time: Fri Dec 12 17:38:31 2008 i had to hunt for it. i was sick of my local hostname being "Macintosh-2" or something like that. From: To: Time: Fri Dec 12 17:38:44 2008 Yeah, I've got to go fix my laptop, now that I know how. From: To: Time: Fri Dec 12 17:39:12 2008 And probably my home machine, which seems to use "squish-raeburn-org" (for squish.raeburn.org). From: To: Time: Fri Dec 12 17:41:29 2008 So, okay, it's assuming that a local realm being served up is the one to advertise for use when accessing via the local-network name that's been configured. I wonder if the .local names are registered in an open directory setup or something. From: To: Time: Fri Dec 12 17:54:59 2008 upgraded the postgresql package on krbdev; hopefully that makes the crashes less frequent. From: To: Time: Fri Dec 12 17:55:13 2008 heading out to Pirates... From: To: Time: Sun Dec 14 02:02:27 2008 This room is not anonymous. From: To: Time: Mon Dec 15 14:07:59 2008 OK, Luke has committed a lot. A lot of this is stuff I'm not entirely comfortable with. 1) How much do we care about making things easy for Novell in the future? 2) Are we ready to commit to a public KDB ABI? From: To: Time: Mon Dec 15 14:08:20 2008 I also don't see anything in here that explicitly has to do with referrals or name canonicalization. From: To: Time: Mon Dec 15 14:11:29 2008 I'd say no on #2. Some of the audit and iprop stuff I'm looking at doing may make some minor tweaks to the KDB API desirable. I'd want to review the semantics of the various operations to make sure they're what we want, too. And that's all assuming we don't wind up working sometime soon on a larger-scale reworking of the database interface. From: To: Time: Mon Dec 15 14:13:15 2008 BTW, it would be really good if people did not change the kdc or admin server extensively while I'm dealing with these merges. From: To: Time: Mon Dec 15 14:13:44 2008 I don't think for example Greg's changes are going to be problematic but let's say I'm really glad iprop was already on the trunk From: To: Time: Mon Dec 15 14:13:45 2008 And we've got an authdata framework already; does Luke's work mesh with that, or is it an additional one? From: To: Time: Mon Dec 15 14:14:09 2008 The kadmin krb4 removal is all done, and didn't touch the admin server. From: To: Time: Mon Dec 15 14:14:14 2008 O, ugh. ugh ugh ugh From: To: Time: Mon Dec 15 14:14:48 2008 Unfortunately I'm behind somewhat because of the ice storm I had no net. (I still have no net at home) From: To: Time: Mon Dec 15 14:15:32 2008 I think my only pending KDC side changes ... oh, scratch that, I've got too many trees floating around. I'll have to look... I know I've got one on my laptop merging some RECVDSTADDR changes from Apple, but it's not done yet. From: To: Time: Mon Dec 15 14:16:30 2008 Oh, yes, I was looking at some KDC announcement patches, but they should be just add-ons. And I'm looking at logging/auditing stuff in the KDC. From: To: Time: Mon Dec 15 14:17:28 2008 OK. The networking handling for kadmin is very different on the ms-krb-integ branch. It sounds like getting that onto the trunk soon would be good. From: To: Time: Mon Dec 15 14:17:34 2008 I hope you at least have power at home. Last I heard Ruth didn't... From: To: Time: Mon Dec 15 14:18:37 2008 Yes, have power. From: To: Time: Mon Dec 15 14:19:34 2008 Are Luke's changes there about ready to merge? I've been reworking the Apple changes to use both RECVDSTADDR and PKTINFO options, and share some code between KDC and kadmind, but it's got a ways to go, and it's been bumped down my priority list. So probably Luke's changes should go first if they're close... From: To: Time: Mon Dec 15 14:20:56 2008 I believe that section of Luke's changes are ready to go. From: To: Time: Mon Dec 15 14:22:00 2008 (I've also got the KDC multithreading patches from Novell, but they're on indefinite hold.) From: To: Time: Mon Dec 15 14:25:27 2008 Interesting. There's a new ELF header DT_RUNPATH which works like DT_RPATH except it doesn't supercede LD_LIBRARY_PATH. DT_RPATH is deprecated. (I think the Linux ld still uses DT_RPATH, though.) From: To: Time: Mon Dec 15 14:29:00 2008 Hmm. Luke talked about changes to do_as_req.c and do_tgs_req.c However I don't see those at all. In fact I see no changes to src/kdc at all From: To: Time: Mon Dec 15 14:29:45 2008 How do people feel about making spnego a plugin? From: To: Time: Mon Dec 15 14:29:59 2008 I'm concerned that it will increase its fragility. From: To: Time: Mon Dec 15 14:33:44 2008 (on phone... back in a bit...) From: To: Time: Mon Dec 15 14:34:02 2008 Because our plugin framework is fragile? I don't understand. From: To: Time: Mon Dec 15 14:34:41 2008 First, our plugin framework is not supported on Windows. Second, it requires the config file get installed. From: To: Time: Mon Dec 15 14:35:09 2008 Okay, that first one sounds like a showstopper. Is there an advantage to making it a plugin? From: To: Time: Mon Dec 15 14:41:47 2008 "Roll on the random krlogind name generation table to find the name of krlogind in this phase of the compilation process." From: To: Time: Mon Dec 15 14:43:31 2008 Hey, renaming files in cvs is hard. From: To: Time: Mon Dec 15 15:11:07 2008 r21341 Add krb5_{mk,rd}_rep_dce *sigh* From: To: Time: Mon Dec 15 15:14:46 2008 I think I may take back all the nice things I ever said about Microsoft not changing kerberos unreasonably From: To: Time: Mon Dec 15 15:21:44 2008 Adding the Windows support for plugins probably won't be hard, though maybe there'd be some design issues. (Like, are we hardcoding paths on Windows or finding things relative to the library somehow?) From: To: Time: Mon Dec 15 15:22:21 2008 what's up with making spnego a plugin? From: To: Time: Mon Dec 15 15:22:24 2008 Is it MS or the old DCE folks? If it wasn't really the DCE folks' fault, we shouldn't be blaming them in the naming. :-) From: To: Time: Mon Dec 15 15:23:46 2008 I think Luke wants us to actually use the plugin architecture. From: To: Time: Mon Dec 15 15:24:07 2008 have we got a real design for the pseudomech problem? From: To: Time: Mon Dec 15 15:24:30 2008 any objections to kiraz for tomorrow's meeting? From: To: Time: Mon Dec 15 15:24:36 2008 I don't see much advantage to making spnego a plugin. It would save ~10K of code but only for a process that chooses not to use spnego. (I don't know if spnego is even remotely capable of unloading itself after you've chosen a real mechanism, but I doubt it.) From: To: Time: Mon Dec 15 15:24:53 2008 So, basically he's trying to push us to accept that if you get the wrong malloc/free you'll lose but that will probably be OK. Jeff argues that it is unacceptable for Windows. I certainly agree it is more common you will run into trouble for windows, but I'm not sure it is completely unacceptable. I can run the question by a a couple of other developers to get second opinions. From: To: Time: Mon Dec 15 15:25:19 2008 Kiraz sounds okay, but we've had it often recently (when we've had meetings). I think I've got a mild preference for pizza this time. From: To: Time: Mon Dec 15 15:26:04 2008 how about the case where you preload a debugging malloc for the main program but the plugin modules use the libc malloc? that doesn't seem too unlikely From: To: Time: Mon Dec 15 15:27:06 2008 On a lot of architectures, but not all, I think the preload would override the plugins. From: To: Time: Mon Dec 15 15:28:15 2008 keep in mind that we want to use something RTLD_GROUP-like whenever possible to minimize inter-version conflicts From: To: Time: Mon Dec 15 15:33:32 2008 Wait, this seems to violate RFC 4121 in a security important way. In particular it fails to generate a subkey. From: To: Time: Mon Dec 15 16:01:16 2008 RFC 4121 doesn't require the generation of a subkey. It's desirable (especially if we want enctype negotation), but not required. From: To: Time: Mon Dec 15 16:02:39 2008 ok, fisheye hasn't updated because anonsvn hasn't updated because afs repository clone hasn't updated. all due to a stale lock directory owned by luekh. no clue why. From: To: Time: Mon Dec 15 16:02:46 2008 I'm not sure I follow what the issue is regarding malloc and free on Windows. I thought our position was that our collection of libraries must all use the same C runtime but applications could use another. From: To: Time: Mon Dec 15 16:03:47 2008 Not that we've ever done anything to try to ensure that we're doing it right, of course... From: To: Time: Mon Dec 15 16:06:24 2008 did a commit to kick off a resync. in progress. From: To: Time: Mon Dec 15 16:10:39 2008 and it has hit fisheye From: To: Time: Mon Dec 15 17:26:39 2008 We decided that we did not want the novell auditing stuff, right? From: To: Time: Mon Dec 15 17:26:53 2008 hm, where is it? From: To: Time: Mon Dec 15 17:27:07 2008 They sent us a design years ago, and Luke has integrated From: To: Time: Mon Dec 15 17:28:20 2008 I don't remember what they did... From: To: Time: Mon Dec 15 17:28:46 2008 ... but Google works nicely. :-) From: To: Time: Mon Dec 15 17:31:14 2008 At a first glance, some of this is like part of the project I've been starting to write up. From: To: Time: Mon Dec 15 17:31:36 2008 Please let me know in the next day whether it is a keeper. From: To: Time: Mon Dec 15 18:11:10 2008 Based on the email I've skimmed so far, the discussion seemed to peter out, but it looks interesting. From: To: Time: Mon Dec 15 18:30:30 2008 java kerberos seems to read /etc/krb5.conf, but noaddresses=true isn't used. From: To: Time: Mon Dec 15 21:43:32 2008 ok i think i have tracked down the svn-rt lossage and fixed it. also rerunning commits to compensate. From: To: Time: Mon Dec 15 21:54:44 2008 confirmed working From: To: Time: Tue Dec 16 11:07:50 2008 has anyone other than Luke experience problems with anonsvn not keeping up with their commits? From: To: Time: Tue Dec 16 11:08:00 2008 i am guessing there is some ticket forwarding issue going on here From: To: Time: Tue Dec 16 13:20:28 2008 And write a emacs mode to read vim customizations From: To: Time: Tue Dec 16 14:03:05 2008 What's Love's jid? From: To: Time: Tue Dec 16 14:07:03 2008 lha@kth.se From: To: Time: Tue Dec 16 14:08:03 2008 Not quite as short as a@x.org. From: To: Time: Tue Dec 16 14:09:37 2008 http://alt.pluralsight.com/wiki/default.aspx/Keith.GuideBook/WhatIsProtocolTransition.html looks useful From: To: Time: Tue Dec 16 14:19:26 2008 Yeah, that wiki page is helpful. So, yes, I was not expecting this feature, but it is a nice bonus to get From: To: Time: Tue Dec 16 14:52:34 2008 Sam, is the Novell auditing stuff part of Luke's branch? I don't know if we ever saw code from them here. I found discussions in the krbdev archive but not a patch, and nothing obvious in RT. From: To: Time: Tue Dec 16 14:55:07 2008 I believe it is, yes. From: To: Time: Tue Dec 16 14:55:20 2008 I've certainly found calls into it From: To: Time: Tue Dec 16 15:09:44 2008 Well, I did a quick grep for "audit" in the KDC code on the branch. The TGS code has one call to audit_tgs_request, which can never be reached. The call to audit_as_request in the AS code is actually reachable, but it's conditional on update_client (the same flag controlling whether the KRBCONF_KDC_MODIFIES_KDB code writes back an updated principal record), and I'm not entirely sure that's the right thing. They also seem to have taken a new direction with the KDB interface, adding a "db_invoke" method that takes a parameter identifying the operation (in this case, "do AS auditing stuff", etc). From: To: Time: Tue Dec 16 15:11:14 2008 So the audit mechanism is tied up in the database layer. I would assume you *might* want to tie them, but I'm not sure we want to force that on people. From: To: Time: Tue Dec 16 15:12:18 2008 And db_invoke appears to be implemented for neither db2 nor ldap. From: To: Time: Tue Dec 16 15:17:31 2008 Their use of update_client highlights some questions I hadn't gotten to. Like, does an AS request for an unknown client or server get recorded in the audit log? (Not for Novell.) From: To: Time: Tue Dec 16 16:08:03 2008 Overall I'd say the Novell auditing code -- unless I'm missing something -- isn't very interesting. From: To: Time: Tue Dec 16 16:08:20 2008 ok, you're fairly sure the Sun code does a better job? From: To: Time: Tue Dec 16 16:08:41 2008 No. From: To: Time: Tue Dec 16 16:10:09 2008 For the basic "log ticket requests" project, neither is needed. They're both just variations on this, with differences in what gets called when. For the "real auditing" project, neither is enough, but Sun's may be better. From: To: Time: Tue Dec 16 17:03:17 2008 CategoryTree installed. does that help with locating projects? From: To: Time: Tue Dec 16 17:42:35 2008 svnlook can suppress diffs for added/deleted files. do we want to do that when sending diffs in mail? From: To: Time: Tue Dec 16 17:43:12 2008 No, assuming that Greg is correct and it does not include diffs for copies From: To: Time: Tue Dec 16 17:43:49 2008 there's a separate --diff-copy-from that diffs against the copy source (presumably if you atomically commit a copy-and-edit) From: To: Time: Tue Dec 16 17:44:26 2008 oh nevermind we don't have that recent a version of svnlook on drugstore. From: To: Time: Tue Dec 16 18:06:04 2008 hm. do we want to retain loadv4? giving the last krb4 holdouts a migration path to 1.7 would be nice. From: To: Time: Tue Dec 16 18:11:47 2008 No. It was explicitly listed in a project we approved. We should not second guess ourselves. More over, someone can use 1.6 as a migration. From: To: Time: Tue Dec 16 18:12:37 2008 more like it slipped my mind when we floated the project. of course, nobody else noticed or complained. From: To: Time: Tue Dec 16 20:15:51 2008 I noticed and failed to complain:-) From: To: Time: Wed Dec 17 11:27:43 2008 Sam, are you preparing to merge some stuff to trunk shortly? From: To: Time: Wed Dec 17 11:32:25 2008 Huh, we currently build libdes425 even without --with-krb4? I wonder why that is. From: To: Time: Wed Dec 17 11:39:19 2008 Greg, not currently. Why? From: To: Time: Wed Dec 17 11:39:45 2008 Probably because libdes425 provides the -ldes api, which some people use outside the krb4 context. From: To: Time: Wed Dec 17 11:41:28 2008 Just wondering if I should hold off on more krb4 deletion commits. (Not that I have any ready just yet, but I may this afternoon.) From: To: Time: Wed Dec 17 11:43:29 2008 Should I reconsider removing libdes425, in that case? (It's in the project plan, but I don't know if people caught the implication.) From: To: Time: Wed Dec 17 11:46:22 2008 I would not. From: To: Time: Wed Dec 17 11:46:30 2008 Not reconsider? Okay. From: To: Time: Wed Dec 17 11:46:51 2008 I think it was reasonably common to use it 8 years ago. I suspect most people have moved away from the des api by now. From: To: Time: Wed Dec 17 11:47:27 2008 *boggle* Novell just randomly adds a field to a structure in krb5.h. From: To: Time: Wed Dec 17 12:01:00 2008 O, and emits encodings incompatible with RFC 4120. From: To: Time: Wed Dec 17 12:08:52 2008 there was a libdes425 issue with something Apple was doing From: To: Time: Wed Dec 17 12:10:07 2008 O, I'd never had the displeasure of reading appendix a in Ken's draft. From: To: Time: Wed Dec 17 12:11:50 2008 ok, svn revprop rewriting in precommit works. From: To: Time: Wed Dec 17 12:12:28 2008 isn't telnet ENCRYPT implemented using the libdes425 library? From: To: Time: Wed Dec 17 12:13:50 2008 I would suggest holding off removal of libdes425 until the consortium removes all support for DES from the distribution From: To: Time: Wed Dec 17 12:16:29 2008 O, hey, we could drop telnet with 1.7 too. From: To: Time: Wed Dec 17 12:17:15 2008 ( I realize doing so has been on the agenda for a while. along with the rest of the apps) From: To: Time: Wed Dec 17 12:18:07 2008 My understanding is that dropping has not been on the agenda. moving them outside the kerberos distribution where they can be supported by third parties has been. From: To: Time: Wed Dec 17 12:18:29 2008 certainly that is what Tom proposed to the AFS/Kerberos Workshop attendees in May From: To: Time: Wed Dec 17 12:18:55 2008 You are correct. From: To: Time: Wed Dec 17 12:19:26 2008 But there is nothing that requires telnet use a kerberos library for its des implementation (or if it does so, that it use the des425 interface) From: To: Time: Wed Dec 17 12:20:12 2008 But making that happen may be more work than Greg wants to sign up for. From: To: Time: Wed Dec 17 12:52:07 2008 Sam, did you mean to imply that telnet currently uses the des425 interface? It seems to compile just fine without it. From: To: Time: Wed Dec 17 12:53:17 2008 greg, what does telnet use for the des implementation for the ENCRYPT DES option when libdes425 is not available? From: To: Time: Wed Dec 17 12:53:52 2008 without libdes425 is configure disabling the encrypt support? From: To: Time: Wed Dec 17 12:54:16 2008 oh, we also have people who want to encourage us to disable single-DES sooner rather than later. how will this affect telnet? From: To: Time: Wed Dec 17 12:54:52 2008 you could implement the ENCRYPT 3DES option From: To: Time: Wed Dec 17 12:56:29 2008 libtelnet appears to be using krb5_c_encrypt to implement DES. From: To: Time: Wed Dec 17 12:57:18 2008 then the kerberos telnet distribution is not a blocking point. From: To: Time: Wed Dec 17 12:57:30 2008 at one point in the past it did use libdes425 From: To: Time: Wed Dec 17 13:27:06 2008 make distclean doesn't remove include/autoconf.h, which messes up make depend. Is there any history there or is it just an oversight? From: To: Time: Wed Dec 17 13:28:05 2008 autoconf.h should go away with distclean. From: To: Time: Wed Dec 17 13:30:07 2008 What's Novell's RFC4120 incompatibility? From: To: Time: Wed Dec 17 13:32:24 2008 If we're killing the des425 library, we should also see if we can kill any exports of DES-related symbols from the crypto library too. From: To: Time: Wed Dec 17 13:32:38 2008 autoconf.h can only get generated by using autoheader, right? make distclean won't get rid of it then. From: To: Time: Wed Dec 17 13:32:53 2008 That's autoconf.h.in. The .h is generated by configure. From: To: Time: Wed Dec 17 13:32:59 2008 oh right From: To: Time: Wed Dec 17 13:33:40 2008 ...and commit logs aren't making it through mailman for some reason, so it's making testing changes somewhat difficult From: To: Time: Wed Dec 17 13:37:59 2008 Ken: pa-svr-referral. From: To: Time: Wed Dec 17 13:39:00 2008 Ken, I just read referrals in the hope of understanding why pa-svr-referral is needed and/or why pa-server-referral is needed. Sadly, I ran across a certain open issue:-) Unfortunately before I can merge Luke's changes, I need to close that issue. From: To: Time: Wed Dec 17 13:45:45 2008 it turns out the commit handler was actually borked because i made a typo. From: To: Time: Wed Dec 17 13:47:02 2008 The kdc-req includes an ap-req. That ap-req includes a checksum of the kdc-req-body. I believe the kdc-req-body includes the sname and srealm. Thus, I believe in the TGS case the KDC gets an encrypted copy of the server name From: To: Time: Wed Dec 17 13:48:02 2008 ok, there are the diffs. prepare for the deluge. From: To: Time: Wed Dec 17 13:48:08 2008 Thank you! From: To: Time: Wed Dec 17 13:49:17 2008 Not sure if I want to see property diffs. From: To: Time: Wed Dec 17 13:49:28 2008 i'm not sure how to suppress them. From: To: Time: Wed Dec 17 13:50:25 2008 The sname and srealm are in the encrypted part of the kdc-rep-body. In cases other than realm and server changing at the same time, when will the pa-server-referral include useful information? From: To: Time: Wed Dec 17 13:50:30 2008 You're using svnlook diff? From: To: Time: Wed Dec 17 13:50:37 2008 yes From: To: Time: Wed Dec 17 13:51:06 2008 Huh. Surprising that there's no option for it. From: To: Time: Wed Dec 17 13:51:36 2008 and it puts the property changes up front, unlike svn diff From: To: Time: Wed Dec 17 13:53:07 2008 Property diffs are kind of annoying. Add or change one line in a multi-line property, and it shows you the full content of both versions? Bleah. From: To: Time: Wed Dec 17 13:55:12 2008 we could switch to whatever the athena repository is using, right? From: To: Time: Wed Dec 17 13:57:55 2008 then again we would have to modify it to deal with suppressing "user/" directory commits From: To: Time: Wed Dec 17 14:15:30 2008 so what does the athena commit hook do about diffs in properties? From: To: Time: Wed Dec 17 14:18:21 2008 PA-SERVER-REFERRAL was needed in part to ensure that the AS-REQ was not altered on its way from the client to the KDC. Otherwise, the client sends a request with the canonicalize flag set (and thus will accept a modified returned server name), a man in the middle changes the server name to something else and sends it on to the KDC, and all the client knows is that the server name coming back is different from that requested, which it was ready to permit. From: To: Time: Wed Dec 17 14:19:10 2008 In a TGS exchange it might not be needed in that case, I'd have to look a little more. From: To: Time: Wed Dec 17 14:19:24 2008 MS just side-steps the issue by always starting with a TGT. From: To: Time: Wed Dec 17 14:28:51 2008 Actually, no, ms seems to not always start with a tgt. At least if Luke and his code are to be believed. They use pa-svr-referral From: To: Time: Wed Dec 17 14:29:32 2008 But I don't see why it matters in the tgs case. From: To: Time: Wed Dec 17 14:30:47 2008 I think that means they don't protect the requested name, unless the referred-name and sname are the two names. From: To: Time: Wed Dec 17 14:31:25 2008 What is $* in make? Is that filename without directory? I'm getting the following make[3]: Entering directory `/home/hartmans/luke-krb5/build/lib/gssapi/krb5' rm -f et-c-../../../../src/lib/gssapi/krb5/gssapi_err_krb5.et et-c-../../../../src/lib/gssapi/krb b5/gssapi_err_krb5.c et-c-../../../../src/lib/gssapi/krb5/gssapi_err_krb5.h cp ../../../../src/lib/gssapi/krb5/gssapi_err_krb5.et et-c-../../../../src/lib/gssapi/krb5/gssapi i_err_krb5.et And cannot figure out what changed. It seems like either this should have never worked or always worked From: To: Time: Wed Dec 17 14:31:58 2008 I believe those are in fact the two names. From: To: Time: Wed Dec 17 14:32:17 2008 This seems to be coming from a rule in pre.in, which doesn't seem to have changed recently From: To: Time: Wed Dec 17 14:33:23 2008 .et.c: $(RM) et-c-$*.et et-c-$*.c et-c-$*.h $(CP) $< et-c-$*.et $(COMPILE_ET) et-c-$*.et $(MV) et-c-$*.c $*.c $(RM) et-c-$*.et et-c-$*.h From: To: Time: Wed Dec 17 14:37:07 2008 what make program? From: To: Time: Wed Dec 17 14:37:38 2008 hartmans@luminous:src(138)> make -v GNU Make 3.81 Copyright (C) 2006 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. This program built for i486-pc-linux-gnu From: To: Time: Wed Dec 17 14:38:13 2008 Looks like I last updated make Jul 8. From: To: Time: Wed Dec 17 14:38:20 2008 So, not that. From: To: Time: Wed Dec 17 14:38:53 2008 My recollection is that it's the base name (without suffix) of the file to be generated, so it shouldn't get the pathname prefix. From: To: Time: Wed Dec 17 14:41:44 2008 Ah, posix says "the current target name with its suffix deleted", so you get the pathname prefix *if* the target doesn't go in the current directory. I think in our error-table cases they're supposed to go in the build tree. From: To: Time: Wed Dec 17 14:41:45 2008 Let's try building trunk From: To: Time: Wed Dec 17 14:42:38 2008 Yeah, my build tree has the .c and .h files. If somehow you got those files in your source tree instead, make might find them via VPATH and decide that the rebuilt files are supposed to live there. From: To: Time: Wed Dec 17 14:42:41 2008 How does make decide for an implicit rule where the target goes? From: To: Time: Wed Dec 17 14:43:33 2008 I think it's always the current directory unless an explicit mention in the makefile or a search via VPATH places it elsewhere. From: To: Time: Wed Dec 17 14:47:14 2008 In the TGS case, it may be that PA-SERVER-REFERRAL isn't needed for protection, if some of the data fields aren't needed. There are a few paragraphs describing when certain data fields are needed, but I don't think it's been fully reviewed any time recently to see if we're requiring it in cases where it's not needed. From: To: Time: Wed Dec 17 14:48:12 2008 Ah, *smack* Refactor for mechglue changes. Introduce new mechanism-specific APIs: gsskrb5_extract_authz_data_from_sec_context, gss_krb5_get_subkey, gss_krb5_set_cred_rcache (from Heimdal) git-svn-id: svn://anonsvn.mit.edu/svn/krb5/branches/mskrb-integ@21368 dc483132-0cff-0310-8789 adds $(srcdir)/gssapi_err_krb5.c to sources From: To: Time: Wed Dec 17 14:50:52 2008 OK. So, I'm going to assert that we don't need to dopa_ server_referral in cases where we do w2k3 style aliases (we alias the key but return the name the client requested) and that doing as_req without pa_svr_referral or pa_server_refferal where the sname changes is bad From: To: Time: Wed Dec 17 14:51:32 2008 Sounds about right. From: To: Time: Wed Dec 17 14:54:52 2008 Luke currently has code in there to sort of generate pa-svr-referral I consider it kind of unacceptable in its current form, but assuming that he wants to support canonicalization of sname on as-req and wants to make that code more acceptable, it will require a change to the kdc encrypted part reply structure in krb5.hin. This structure is technically part of our ABI through krb5_get_in_tkt. However as far as I can tell to the extent it is in our ABI, it is always allocated by libkrb5. From: To: Time: Wed Dec 17 14:55:31 2008 How do we feel about that change? From: To: Time: Wed Dec 17 14:57:02 2008 Disappointed at our shortsightedness? :-) From: To: Time: Wed Dec 17 14:57:56 2008 If he's adding it at the end, it's probably okay, I guess. If it's not at the end, any existing code referencing fields that change position could be broken by the ABI change. From: To: Time: Wed Dec 17 14:59:21 2008 He adds it at the end. From: To: Time: Wed Dec 17 14:59:57 2008 This one is really not our fault. IT's a rfc 4120 pdu without extensibility markers. MS is just wrong. From: To: Time: Wed Dec 17 15:01:27 2008 Yes. Though if our implementation properly rejected sequences with junk added on the end, perhaps it would've been caught sooner. From: To: Time: Wed Dec 17 15:02:15 2008 No, they are careful only to send it when you set the canonicalize flag. Our implementation did reject junk back then as I recall. From: To: Time: Wed Dec 17 15:03:44 2008 OK, so really the mskrb-integ branch is getting to quite good shape int terms of my understanding of it and what all needs to happen before merge. I have been much less conservative than I would normally be. I think some of the decisions made are not what we would have made--particularly, with regard to the kdb layer. From: To: Time: Wed Dec 17 15:03:50 2008 Oh. Hm. I *guess* then that the canonicalize flag could also be interpreted as an "accepts this new version of the structure" flag as well, but eh. From: To: Time: Wed Dec 17 15:04:42 2008 The main reason I don't merge it now is that there are several project write-ups I need to do and I need to collect together a few sets of things to back out. From: To: Time: Wed Dec 17 15:05:21 2008 Does the DAL change? From: To: Time: Wed Dec 17 15:05:55 2008 O, yeah, and Luke make some changes to gc_frm_kdc.c Sadly, I could not understand what was going on reading the diffs. So, I need to do a complete code audit of that file again. That always ends up being un-fun. From: To: Time: Wed Dec 17 15:06:28 2008 ick. gc_frm_kdc needs to be smacked upside the head again. hopefully Luke's smacking in that direction is reasonable. From: To: Time: Wed Dec 17 15:06:42 2008 Yes, it does. But we don't consider it a public API do we? One of the changes I'll back out is installing the dal headers. From: To: Time: Wed Dec 17 15:07:17 2008 No, it's not public. Especially if Luke needs to make changes, that means it's obviously not stabilized just yet. From: To: Time: Wed Dec 17 15:08:26 2008 I've got my doubts about this "db_invoke" thing.... From: To: Time: Wed Dec 17 15:30:58 2008 Is "db_invoke" now a general extension mechanism to the DAL? From: To: Time: Wed Dec 17 15:31:37 2008 Yes. From: To: Time: Wed Dec 17 15:33:59 2008 Bleah. Unless there's a logical -- not chronological -- dividing line between "extension" and "other stuff", since the API is still not public, I'd rather we look at switching to a general "invoke method" hook and *remove* as many of the explicit functions as possible if they can be invoked that way instead. From: To: Time: Wed Dec 17 15:34:34 2008 Maybe we should re-do our database interface in objective c. :-) From: To: Time: Wed Dec 17 15:36:33 2008 We can choose to do that, From: To: Time: Wed Dec 17 15:39:49 2008 Though I'd want to look at how data (principals, policy, whatever) is returned. From: To: Time: Wed Dec 17 15:39:52 2008 The "distinction" between kdb.h and kdb_ext.h was one of the reasons I was quite sure we did not want to make the DAL public From: To: Time: Wed Dec 17 15:41:14 2008 anyway, implemented quick hack to reverse ordering of mailed diffs so property diffs go at the end From: To: Time: Wed Dec 17 15:41:30 2008 Oh, dear. I have'nt looked at kdb_ext.h yet.... From: To: Time: Wed Dec 17 15:43:36 2008 Please let me know if anything there is a complete show stopper for you as an internal interface. I consider the non_ms_principal unacceptable, but the rest seems like an acceptable starting point. From: To: Time: Wed Dec 17 15:43:45 2008 Looks like somebody has an issue with numbering things with an increment of 1 instead of 16 or 256.... From: To: Time: Wed Dec 17 15:44:01 2008 It just seems wrong for us to be claiming that most of our principals are microsoft principals. From: To: Time: Wed Dec 17 15:45:04 2008 Well, our usual conflict between "don't make it more ugly" and "ship the promised functionality on time" seems to be coming into play again. From: To: Time: Wed Dec 17 15:46:03 2008 If you except that the db layer is the glue between the kdc and the rest of the universe, it's not clear this is all that ugly. From: To: Time: Wed Dec 17 15:46:04 2008 The name "protocol transition", from what I quickly skimmed, seems to have more to do with the architecture of a system using Kerberos and other authentication methods than to do with Kerberos specifically. What does that mean in a flag in the KDB layer? From: To: Time: Wed Dec 17 15:46:47 2008 "flag used to indicate trust is non-transitive"?? From: To: Time: Wed Dec 17 15:47:58 2008 It means that this principal is permitted to use pa_for_user to get a ticket for any other principal From: To: Time: Wed Dec 17 15:48:33 2008 Meaning that a cross-realm key only permits one-hop operation From: To: Time: Wed Dec 17 15:48:55 2008 It needs to not involve the word trust From: To: Time: Wed Dec 17 15:49:02 2008 Okay, but is "protocol transition" a good name for that? You just described an attribute of a principal; "protocol transition" has to do with the authentication system architecture. From: To: Time: Wed Dec 17 15:49:27 2008 Where does the one-hop restriction come in? From: To: Time: Wed Dec 17 15:51:04 2008 protocol transition is in fact the name of the facility, yes. From: To: Time: Wed Dec 17 15:51:34 2008 protocol transition is a way of getting a kerberos ticket on behalf of someone else the name comes from the fact that it is useful in protocol transition situation From: To: Time: Wed Dec 17 15:51:54 2008 The list of db_invoke methods has me wondering (1) why are these not numbered 1,2,3,etc, or passed as strings, and (2) why are most of these considered db operations? From: To: Time: Wed Dec 17 15:52:32 2008 re query from Henry Hotz - do we have a way to query whether the "none" rcache type is supported? From: To: Time: Wed Dec 17 15:53:25 2008 Ken: it makes sense for them to be db operations if the db is the glue between kerberos and the infrastructure From: To: Time: Wed Dec 17 15:53:33 2008 And does the "transition" refer to authentication protocols or application protocols? From: To: Time: Wed Dec 17 15:54:17 2008 Then it's not a "database" interface, it's a lot more, and we should look at just what that's going to mean. From: To: Time: Wed Dec 17 15:55:37 2008 Yes. It is a lot more. From: To: Time: Wed Dec 17 15:56:07 2008 You need that lot more somewhere. (as part of Luke's project) If it is not going to be the db, you need to do a lot of thinking fast. From: To: Time: Wed Dec 17 15:56:20 2008 authentication protocol From: To: Time: Wed Dec 17 15:56:26 2008 Actually, I'm not sure. From: To: Time: Wed Dec 17 16:06:58 2008 If it's just authentication protocols, then a web server you authenticate but don't delegate to, which then turns around and authenticates as you to other internal services, would use the facility but the name doesn't work. If it's application protocols, I could argue that the name still doesn't fit if the back-end protocol is still http. Or for an imap aggregator, etc. From: To: Time: Wed Dec 17 16:08:08 2008 I could also see a design for a "trusted cron" type service that, at a specified time each day, authenticates as you and invokes certain actions from other services. No "transition" there, but it would still use the facility. From: To: Time: Wed Dec 17 16:09:34 2008 If the "infrastructure interface" is going to be DAL for the moment, that's a BIG extra reason why not to make it public any time soon. From: To: Time: Wed Dec 17 16:10:05 2008 what bits of infrastructure is the DAL going to mediate access to anyway? From: To: Time: Wed Dec 17 16:11:25 2008 I'm not sure what that really gains us, though, aside from lumping together all the plugin type functionality in one place associated with the realm, and not having to write support for each plugin item separately. But it means your "database" implementation has to learn how to support any of the operations you want to customize. And we should have example/test code for the various hooks. From: To: Time: Wed Dec 17 16:12:01 2008 kdb_ext.h currently lists: #define KRB5_KDB_METHOD_SIGN_AUTH_DATA 0x00000010 #define KRB5_KDB_METHOD_CHECK_TRANSITED_REALMS 0x00000020 #define KRB5_KDB_METHOD_CHECK_POLICY_AS 0x00000030 #define KRB5_KDB_METHOD_CHECK_POLICY_TGS 0x00000040 #define KRB5_KDB_METHOD_AUDIT_AS 0x00000050 #define KRB5_KDB_METHOD_AUDIT_TGS 0x00000060 #define KRB5_KDB_METHOD_REFRESH_POLICY 0x00000070 #define KRB5_KDB_METHOD_GET_PAC_PRINC 0x00000080 From: To: Time: Wed Dec 17 16:13:35 2008 I'm not happy about this "infrastructure interface" stuff being sprung on us at this point in the project. From: To: Time: Wed Dec 17 16:15:37 2008 For one thing, "Microsoft compatibility" shouldn't trump our plugin interface design/review process. From: To: Time: Wed Dec 17 16:17:44 2008 Ken, the infrastructure stuff is the entire point of the kdc part of the project--it's why we hired Luke. Or rather why you hired Luke. From: To: Time: Wed Dec 17 16:18:14 2008 And this is worse than the apple pkinit mess how? From: To: Time: Wed Dec 17 16:18:17 2008 We need the stuff, sure. But we get no input on the design? From: To: Time: Wed Dec 17 16:18:46 2008 I am asking Luke to reconcile this with the authdata plugins. I'm still waiting for an answer there. From: To: Time: Wed Dec 17 16:18:50 2008 Oh, the pkinit mess is bad. That's not a good reason for making more of a mess, unless the conclusion is "we just don't care". From: To: Time: Wed Dec 17 16:19:11 2008 s/conclusion/argument/ From: To: Time: Wed Dec 17 16:19:29 2008 so to summarize, Luke has implemented PAC retrieval using some extension to the DAL? From: To: Time: Wed Dec 17 16:20:07 2008 And it may be the right way to go. But "here's the patch" is not a design proposal, discussion, and review process. From: To: Time: Wed Dec 17 16:21:06 2008 When you set up a project with someone hired to write up designs after the code is written and tested, and when for a primary chunk of code you wait until a couple of weeks before the project is concluding to let that person even start to see the approach, you do tend to get more limited input into the design than with other approaches.:-) I'm happy that it is self consistent and inn many ways well done and Luke seems to be doing a relatively good job of testing. From: To: Time: Wed Dec 17 16:21:26 2008 No argument there. From: To: Time: Wed Dec 17 16:22:18 2008 But it does open us up to the possibility that 1.7 ships with a chunk of work done to a design that no one working on the code after 1.7 ships will like. From: To: Time: Wed Dec 17 16:22:31 2008 But yes, I suspect for the most part, this is a take or leave, not take+fix proposition. I mean Luke has been very open to changes to the extent he has time to make them. From: To: Time: Wed Dec 17 16:23:16 2008 It does. At least for this part it will be an internal design that is not exposed. From: To: Time: Wed Dec 17 16:25:20 2008 Yes, as long as the changes to the public headers are minimal, we're not too committed to all the specific details. From: To: Time: Wed Dec 17 16:25:58 2008 Can I write a single module that implements authdata, kdb and padata plugins? I believe the answer is no, and I believe that's kind of problematic for someone designing an infrastructure. From: To: Time: Wed Dec 17 16:27:39 2008 You should look at the changes to the public gss-api headers. A lot has happened in the last week there and I am not going to have time to write up as greate of a project write-up as I'd like. I will be doing a project write up there, it will just not be of the quality I'd really like From: To: Time: Wed Dec 17 16:29:59 2008 We put things in different directories, so no, not with one plugin (ignoring hard links). And even if you get the same file dlopen'ed multiple times, the APIs treat them as independent interfaces and thus you'd have to do a little work to re-associate them with each other. I do think that's a problem. But with Luke's approach it looks like you can't create the plugins independently. From: To: Time: Wed Dec 17 16:30:57 2008 is it such a problem if they have to make multiple modules that talk to the same backend? From: To: Time: Wed Dec 17 16:32:03 2008 You could probably do things like create one .so with the authdata structure and kdb structure and such, and share static data. But at least in theory this could be bad for a KDC serving multiple realms. From: To: Time: Wed Dec 17 16:32:58 2008 And you'd be relying on dlopen not mapping multiple copies of the shared object (and its static data) for multiple calls; I don't know if that's guaranteed. From: To: Time: Wed Dec 17 16:33:37 2008 Tom, people like Samba would say yes definitely. From: To: Time: Wed Dec 17 16:34:02 2008 ok, i'd like to understand why From: To: Time: Wed Dec 17 16:34:33 2008 OTOH, one could also create a DAL back end that knows how to load different additional modules for authdata or preauth support, etc. From: To: Time: Wed Dec 17 16:35:55 2008 Actually, authdata/padata and kdb are quite different, in that for the former you may want to support more than one at a time for your realm. Though on second thought, you might also want to control the list of supported mechanisms per realm, if your KDC services multiple realms. From: To: Time: Wed Dec 17 16:37:31 2008 Tom: it means they have to do the backend communication. It tends to complicate design somewhat and complicates installation From: To: Time: Wed Dec 17 16:40:23 2008 i don't really like the risk profile of "all eggs in one basket" like AD, but i understand that it's a reasonable tradeoff for some people. maybe what we should do is to make both that approach and the "a few pieces at a time" approach viable, because i think there is substantial interest from both sides. From: To: Time: Wed Dec 17 16:46:10 2008 I think we're doing that. We have the authdata interface and what Luke's doing. From: To: Time: Wed Dec 17 16:52:50 2008 If we do that, I think they should at least be consistent when practical in how they implement the basic interface. E.g., having one authdata interface that returns structure A, and having Luke's approach return the same authorization data but using structure B, would be bad. From: To: Time: Wed Dec 17 16:53:06 2008 (Not that I've looked yet at just what data structures Luke is using.) From: To: Time: Wed Dec 17 16:54:14 2008 It would be incredibly constructive if in the very near future (read today or tomorrow) you could give Luke any suggestions you have on aligning this interface with the authdata plugin interface. As that is something I think we can move forward on and is already on his agenda. From: To: Time: Wed Dec 17 17:11:17 2008 re Henry Hotz -- aside from "try it and see", assuming it's from the command line and not application code, all i can think of is checking "krb5-config --version" From: To: Time: Wed Dec 17 17:12:08 2008 No, it's from application code. From: To: Time: Wed Dec 17 17:14:04 2008 Ah, Luke comments that he does not understand what the gc_frm_kdc changes do. From: To: Time: Wed Dec 17 17:14:27 2008 wait, who wrote them then? From: To: Time: Wed Dec 17 17:15:22 2008 Oh. Then.. hm, no, we made that internal. Do we have any way to specify an rcache name from application code? The only rcache functions in krb5.hin are krb5_auth_con_getrcache, krb5_auth_con_setrcache, and krb5_get_server_rcache. Maybe the last could be called after tweaking the environment variable, but, yuck. From: To: Time: Wed Dec 17 17:16:35 2008 Rahul From: To: Time: Wed Dec 17 17:17:51 2008 But, the chances that I can audit changes of undefined behavior to gc_frm_kdc.c that even Luke does not understand seem limited. From: To: Time: Wed Dec 17 17:40:41 2008 Looking at gssapi_ext.h, I see it still uses the "gss_(un)wrap_aead" names, and I still don't like them. :-) The suggestion of "gss_wrap_with_ad" seemed okay, I thought. From: To: Time: Wed Dec 17 17:43:12 2008 In Luke's gssapi_krb5.hin, two new functions use "gsskrb5_" as the prefix instead of "gss_krb5_" (difference in underscores). They should be consistent (unless we're stuck with this because of Heimdal compatibility, and even there we could have a macro). From: To: Time: Wed Dec 17 17:48:13 2008 Actually it looks like Luke's DAL changes don't include anything for providing authorization data. They do include a new call for signing authorization data that's provided, which is a different thing... From: To: Time: Wed Dec 17 18:02:15 2008 Is the PAC code still coming? There's a KRB5_KDB_METHOD_GET_PAC_PRINC, which would be a way of getting authz data through db_invoke, but it's never used in the tree. If it's not going to be, it should go away. From: To: Time: Wed Dec 17 18:03:34 2008 If we wind up porting our KDC to Windows, we're going to have to deal with the plugin malloc/free problems... From: To: Time: Thu Dec 18 13:10:33 2008 Hey, if we're ditching the krb4 support, should we turn off the use of port 750 (in addition to port 88) by default? From: To: Time: Thu Dec 18 13:43:31 2008 heh. now that we're sending diffs, stuff is getting hung up in the mod queue due to the size of the diffs. From: To: Time: Thu Dec 18 13:44:02 2008 i bumped the limit to 1M From: To: Time: Thu Dec 18 13:44:35 2008 What was the limit before? My last commit was big, but mostly due to deleted files. From: To: Time: Thu Dec 18 13:44:44 2008 40k From: To: Time: Thu Dec 18 13:49:27 2008 maybe i should have it suppress diffs for deleted files From: To: Time: Thu Dec 18 13:55:44 2008 Oh, hey, I just found doc/coding-style. Do people have pre-existing thoughts on what should happen to that vs. the coding style documentation in the wiki? (Not going to take any immediate action on this, just thinking.) From: To: Time: Thu Dec 18 13:57:56 2008 I'm inclined to think we should have both distributed and online versions, but maybe the online one could be (or include) a pointer to the latest version of doc/coding-style via fisheye. From: To: Time: Thu Dec 18 13:59:15 2008 In more relevant news, I guess doc/krb425.texinfo should just go away. From: To: Time: Thu Dec 18 14:04:29 2008 the coding style pages on the wiki are more up to date From: To: Time: Thu Dec 18 14:26:16 2008 right. one thread on the kerberos list is getting caught in the moderation queue due to having "weight" in the subject header From: To: Time: Thu Dec 18 14:29:25 2008 Because of weight loss product spam, I guess? From: To: Time: Thu Dec 18 14:29:37 2008 probably From: To: Time: Thu Dec 18 14:29:44 2008 it's an explicit rule in our list config From: To: Time: Thu Dec 18 14:31:24 2008 Oh, the category tree extension makes the project page better; I just wish we could make the tree expanded by default. From: To: Time: Thu Dec 18 14:31:40 2008 i looked but didn't see an obvious way to do that From: To: Time: Thu Dec 18 14:32:59 2008 I believe we could do it if we stopped using the category page directory, and instead used a tag on a different page. From: To: Time: Thu Dec 18 14:43:02 2008 possibly. we are using an old-ish version of CategoryTree because we only have Mediawiki-1.11 or so From: To: Time: Thu Dec 18 14:44:59 2008 http://k5wiki.kerberos.org/wiki/Test/Projects From: To: Time: Thu Dec 18 14:45:24 2008 I had to edit LocalSettings.php to change the maximum value of depth to make that work. From: To: Time: Thu Dec 18 14:45:45 2008 ok From: To: Time: Thu Dec 18 15:03:51 2008 i wonder if we can make Category:Projects redirect to Projects and put the there From: To: Time: Thu Dec 18 15:15:38 2008 Or un-make Projects redirect to a category page From: To: Time: Thu Dec 18 15:15:58 2008 the project pages would still link to the category page though From: To: Time: Thu Dec 18 15:18:35 2008 ok, that seems to work From: To: Time: Thu Dec 18 15:19:32 2008 does it look reasonable to people now? From: To: Time: Thu Dec 18 15:23:27 2008 Looks okay to me... From: To: Time: Thu Dec 18 15:40:46 2008 Changed the main page link to point to Projects instead of the category page, for tidiness. From: To: Time: Thu Dec 18 16:15:34 2008 frobbed some templates to make their category links includeonly From: To: Time: Thu Dec 18 16:53:31 2008 Ken, I don't know if you read between the lines in Luke's mail, but it sounds like we really need to support AS sname canonicalization with no integrity checks. Can we work through how bad that is in practice? From: To: Time: Thu Dec 18 16:53:56 2008 That was the impression I got. From: To: Time: Thu Dec 18 16:55:55 2008 So, how bad is it if you don't have integrity protected as-req Let's split into two cases. Case 1: you are requesting the TGS. case 2: you are not From: To: Time: Thu Dec 18 16:57:22 2008 Cases where the AS-REQ service principal isn't a TGT will probably be uncommon in practice. The password-changing service is an exception. If the client can be made to think that that SPN maps to some other name, for a service in the realm that's been compromised, the new password may be sent to that server (where the attacker may be running a fake password service). Return an error or timeout, and the user will probably try again with the same password; let them get to the real service this time, and they'll change the password to the one they just sent the attacker. From: To: Time: Thu Dec 18 16:57:30 2008 So, an attacker can direct me to another realm. case 1a: my password works there. case 1b: it doesn't and I notice a failure. That realm gets known plaintext case 1c: pkinit: I probably log in thinking my client realm is different than I expect case 1d: otp From: To: Time: Thu Dec 18 16:57:47 2008 If you're asking for the TGS, we probably shouldn't accept a server name change. From: To: Time: Thu Dec 18 16:58:35 2008 Oh, client name canonicalization too? (Your message said "sname", I assumed server only.) From: To: Time: Thu Dec 18 16:58:37 2008 You kind of need to accept a server name changes from krbtgt/a to krbtgt/b as part of a redirect from realm a to realm b From: To: Time: Thu Dec 18 16:59:05 2008 Anything that changes srealm in the AS case implicitly changes crealm. From: To: Time: Thu Dec 18 16:59:18 2008 I'm not sure that's valid. The TGS for realm A is krbtgt/B@B ? From: To: Time: Thu Dec 18 17:00:22 2008 No, I get a wrong realm error sending me to krbtgt/b@B and telling me to use b as my client realm From: To: Time: Thu Dec 18 17:00:37 2008 I think this is the most important case from an interop standpoint to support From: To: Time: Thu Dec 18 17:01:09 2008 No, if the client realm needs to change from what was specified, I think we need to use the client name canonicalization path, which involves sending an error back. Handling that insecurely has issues too. But I don't think changing the TGS service name is the way to do it. (Unless MS already does it, in which case what I think is the right way doesn't matter much, does it?) From: To: Time: Thu Dec 18 17:02:22 2008 I agree changing the realm involves an error From: To: Time: Thu Dec 18 17:02:42 2008 does client realm referral happen in the change-password case? From: To: Time: Thu Dec 18 17:03:18 2008 It's not explicitly disallowed, but I think we should disable it. From: To: Time: Thu Dec 18 17:03:33 2008 Oh, wait, client referral. Hm. From: To: Time: Thu Dec 18 17:03:44 2008 Yeah, I guess it would be supported, same as for any other AS exchange. From: To: Time: Thu Dec 18 17:03:49 2008 I don't know. can we deal with case 1 first? My head is already exploding. From: To: Time: Thu Dec 18 17:05:48 2008 for 1b, how much known plaintext does the attacker get if there is a confounder? From: To: Time: Thu Dec 18 17:06:17 2008 They get an encrypted timestamp to dictionary attack. From: To: Time: Thu Dec 18 17:06:35 2008 1a - If your password works, unless you've got some policy saying which realm changes you'll accept, or you ask for validation, you won't notice, except authenticating to services may get you the wrong access. More access, or less, or just to different data if an account name is derived from your principal name; any of those could be bad. From: To: Time: Thu Dec 18 17:06:51 2008 oh, whole-message validation? From: To: Time: Thu Dec 18 17:07:25 2008 Right. Also, the other difference in 1a is that a different realm is involved in the path. From: To: Time: Thu Dec 18 17:07:55 2008 1c (pkinit) probably works out similar to 1a, I'm not sure. From: To: Time: Thu Dec 18 17:10:41 2008 I'm really uncomfortable with this. And it seems strange to me that MS does not see these as security problems. From: To: Time: Thu Dec 18 17:11:17 2008 have you had a chance to talk to Larry about it? From: To: Time: Thu Dec 18 17:11:18 2008 1d (otp) - If the passwords are associated with the specific realm, you'll just get a failure, I think. Checking the draft now. From: To: Time: Thu Dec 18 17:12:02 2008 No, the concern with 1d is that an attacker may be in the fast channel who would not normally be. No, I have not talked to Larry. From: To: Time: Thu Dec 18 17:13:10 2008 Oh, if otp-value is sent, it could be bad. From: To: Time: Thu Dec 18 17:13:14 2008 And 1c is that it is more likely your pkinit could work than your password, so the threat value is expanded From: To: Time: Thu Dec 18 17:15:18 2008 Well, yes. From: To: Time: Thu Dec 18 17:15:53 2008 so you get a pkinit TGT in the wrong realm; what can you do with it? From: To: Time: Thu Dec 18 17:16:01 2008 The real use case we have to support is that windows workstations send their netbios realm name rather than their domain name in the as-req From: To: Time: Thu Dec 18 17:16:16 2008 There's a reason I've been doing lots of hand-waving about needing policies to restrict what changes you'll accept in the AS exchange. :( From: To: Time: Thu Dec 18 17:17:08 2008 Tom, in an infrastructure where it is the cert that determines your authorizations and both realms are vaguely trusted, you might have the same authorizations, but you might have a different set of kdcs see session keys. From: To: Time: Thu Dec 18 17:17:18 2008 You might also have more or less authorizations. From: To: Time: Thu Dec 18 17:18:27 2008 the application server can decide whether it wants to trust a given KDC w.r.t. session keys can't it? From: To: Time: Thu Dec 18 17:22:40 2008 This is basically a question about whether an attacker downgrading you to minimally acceptable is ok or whether you want downgrade protection From: To: Time: Thu Dec 18 17:23:36 2008 so it's a tradeoff From: To: Time: Thu Dec 18 17:24:17 2008 I'm not sure it's just downgrading. From: To: Time: Thu Dec 18 17:25:22 2008 If both realms map cert identities to local names, it could be a change of principal realm name (and thus basically different accounts, to some services). From: To: Time: Thu Dec 18 17:26:25 2008 so it's back to the "using an identity you didn't intend" problem From: To: Time: Thu Dec 18 17:26:34 2008 Yes. From: To: Time: Thu Dec 18 17:28:37 2008 which is hardly an easy problem to talk about From: To: Time: Thu Dec 18 17:29:53 2008 I actually find the having a different set of people be able to look at your data more frightening than the using an unintended identity problem, although both seem real. From: To: Time: Thu Dec 18 17:30:28 2008 clearly we should hurry up with the PFS solutions From: To: Time: Thu Dec 18 17:31:53 2008 They don't help in this instance so much. From: To: Time: Thu Dec 18 17:33:14 2008 hm. if you get the wrong TGT successfully and you rely on subsequent TGS-REQs to correctly tell you where some service is located... From: To: Time: Thu Dec 18 17:33:52 2008 No, PFS wouldn't help with bogus client referrals. Some of the FAST armoring would. Or TLS, if you validate the certificate. From: To: Time: Thu Dec 18 17:33:58 2008 Yes, that is a concern. From: To: Time: Thu Dec 18 17:35:19 2008 Yes. Though at least in the same-password case, you've been redirected to a realm you trust at least enough to give your shared password to. Depending on your password-reuse policy, that may or may not help. From: To: Time: Thu Dec 18 17:35:46 2008 whereas for the pure pkinit case you don't have that assurance From: To: Time: Thu Dec 18 17:35:51 2008 Right. From: To: Time: Thu Dec 18 17:37:04 2008 Having the host authenticate to the KDC and use the session key in FAST armoring is probably adequate (though I still don't like the exposure of a recorded exchange to a later compromise of the host key), and doesn't require a PKI. From: To: Time: Thu Dec 18 17:37:41 2008 you mean the situation where the client host has a strong host key? From: To: Time: Thu Dec 18 17:37:53 2008 Yes. From: To: Time: Thu Dec 18 17:38:34 2008 Its AS exchange shouldn't be redirectable, I think. The second realm wouldn't have the key. From: To: Time: Thu Dec 18 17:38:40 2008 that's still future scenario. what are our exposures today? From: To: Time: Thu Dec 18 17:39:37 2008 At this point I'm very uncomfortable with the functionality. However I have low confidence in my understanding because I'd expect Paul and all the other folks at MS to have rejected something with these exposures. From: To: Time: Thu Dec 18 17:39:51 2008 Today, we (MIT) don't have client referrals or canonicalization, so a bunch of these problems don't come up. Merging this code will introduce weaknesses. From: To: Time: Thu Dec 18 17:40:10 2008 to what degree are the AS referrals documented by MS in MS-KILE or similar? From: To: Time: Thu Dec 18 17:40:44 2008 Ken, i was asking about what "our" exposures were where "we" include all Kerberos implementations including MS From: To: Time: Thu Dec 18 17:41:04 2008 Sorry. From: To: Time: Thu Dec 18 17:41:29 2008 so MS users are already exposed to whatever vulnerabilities there are in this scheme, assuming it's what we understand it to be. From: To: Time: Thu Dec 18 17:41:56 2008 I think MS is vulnerable to these various problems, though I haven't tried to verify it. It does require a reused password, or certain PKINIT configurations, to exploit it, and one could argue that the proper response is "don't do that". From: To: Time: Thu Dec 18 17:42:20 2008 It also requires an active attacker. From: To: Time: Thu Dec 18 17:42:33 2008 ... who knows about the password reuse. From: To: Time: Thu Dec 18 17:42:36 2008 if we could just say "don't do that" then we wouldn't be going to all this effort to protect systems against weak user-chosen passwords. From: To: Time: Thu Dec 18 17:43:36 2008 If I use "x" plus the realm name as my password everywhere, that's weak but not vulnerable to this. Similarly, a randomly-generated 128-character base64 password may be "strong" but still vulnerable if reused. From: To: Time: Thu Dec 18 17:43:50 2008 Oh... you weren't equating the two problems... From: To: Time: Thu Dec 18 17:44:59 2008 I think too many of us working on these systems assume users have somewhat stronger security practices than we should be assuming. Password reuse is one such case. From: To: Time: Thu Dec 18 17:45:20 2008 i was drawing similarities. we're undertaking some IETF efforts (FAST et al.) to deal with the weak user-chosen password problem. if we consider that above the threshold of what we need to bother with, then we should also consider the password reuse case. From: To: Time: Thu Dec 18 17:46:29 2008 I also believe the necessary pkinit configuration is reasonably common. In addition, I think the attacker gets to set up the necessary pkinit configuration. Basically, I think I can phish you if you are willing to connect to badguy.com with a badguy.com cert. And I think we have very strong evidence that is a bad property to have in a security system from the web From: To: Time: Thu Dec 18 17:46:48 2008 Yes, I think so. But knowing the client principal name and sending our notion of it to the KDC in a TGS-REQ for verification (not the main purpose, but it happens) has given us a saving throw so far. With client referrals and canonicalization, we lose that. From: To: Time: Thu Dec 18 17:47:27 2008 DNS-related attacks have redrawn the map of who can be considered on-path vs off-path attackers i think. From: To: Time: Thu Dec 18 17:47:57 2008 That too. From: To: Time: Thu Dec 18 17:48:05 2008 Yes. And highlighted that we really need to stop using DNS for security-critical name processing. From: To: Time: Thu Dec 18 17:48:25 2008 if i'm an attacker, i'm not off-path if i can convince the path to come through my network. From: To: Time: Thu Dec 18 17:55:44 2008 Heading out From: To: Time: Thu Dec 18 17:56:08 2008 If luke responds to my krbdev mail, please engage him if you are still around until we have clarity From: To: Time: Fri Dec 19 14:54:50 2008 Can someone expand PAC for me, please? From: To: Time: Fri Dec 19 14:55:10 2008 privilege attribute certificate, i think From: To: Time: Fri Dec 19 14:56:53 2008 Thanks. From: To: Time: Fri Dec 19 14:57:09 2008 No. I think privilege attribute certificate is the root, but it is complicated and has inconsistent expansion even within MS. From: To: Time: Fri Dec 19 14:57:34 2008 No was to Greg, not Tom From: To: Time: Fri Dec 19 14:57:36 2008 do they have conflicting expansions within their official docs? From: To: Time: Fri Dec 19 14:58:02 2008 Tom, I think Chuck and I found that to be true, yes. From: To: Time: Fri Dec 19 14:58:19 2008 ok From: To: Time: Fri Dec 19 14:59:12 2008 The term is used in Luke's code, and in the draft RFC referred to by Luke's code, without ever being expanded. From: To: Time: Fri Dec 19 14:59:54 2008 Though perhaps it's best if I just think of it as Microsoft Data Structure #2336. From: To: Time: Sun Dec 21 02:02:30 2008 This room is not anonymous. From: To: Time: Mon Dec 22 15:48:08 2008 What would one need to know about a session key besides its length in order to use it reasonably? From: To: Time: Mon Dec 22 15:52:08 2008 Its structure. DES keys for example are not uniformly distributed. From: To: Time: Mon Dec 22 15:52:36 2008 And depending on the crypto system using one crypto system's keys with another might not be so clever. From: To: Time: Mon Dec 22 15:53:16 2008 Heading out. From: To: Time: Mon Dec 22 16:52:49 2008 oddly enough, we didn't actually have a project-completed template on the wiki From: To: Time: Mon Dec 22 16:53:35 2008 And how long did it take us to notice? Not a good sign... :) From: To: Time: Mon Dec 22 16:53:53 2008 Oh, heh. I changed the krb4 removal project and it looked okay to me, but I guess it wasn't right. From: To: Time: Mon Dec 22 16:54:06 2008 i was wondering why the krb4 removal project disappeared from the projects page. From: To: Time: Mon Dec 22 17:52:50 2008 added roadmap to wiki; not yet well-linked From: To: Time: Mon Dec 22 18:27:54 2008 what do people wish they could find more easily on the wiki? From: To: Time: Mon Dec 22 19:04:33 2008 newish front page on the wiki. it could still use improvement. From: To: Time: Tue Dec 23 11:59:48 2008 RT mail gateway is broken From: To: Time: Tue Dec 23 12:00:14 2008 have fix in progress but testing is delayed because PCH is hosed From: To: Time: Tue Dec 23 12:28:15 2008 nevermind. PCH wasn't hosed; i was just confused. From: To: Time: Tue Dec 23 12:33:57 2008 send-pr-gate works From: To: Time: Tue Dec 23 12:58:44 2008 oh great. on-disk rcache format is byte-order dependent From: To: Time: Tue Dec 23 12:58:54 2008 and also word-size dependent. From: To: Time: Tue Dec 23 13:00:09 2008 also, uses counted arrays for client and server names, but uses strcmp on them, so they have to be null-terminated anyway From: To: Time: Tue Dec 23 13:04:48 2008 and i don't like having to suck in a base64 implementation just for this project. perhaps we can have a special null-terminated string that is a prefix. From: To: Time: Tue Dec 23 13:09:37 2008 if we put the magic inside rc_io_store and rc_io_fetch, we can get away with using a zero-length string as a prefix ;-) From: To: Time: Tue Dec 23 13:14:33 2008 oh nevermind. that won't work because the caller has to pass in the stuff. From: To: Time: Tue Dec 23 14:50:34 2008 Huh. krb5_get_fallback_host_realm is declared in krb5.h but not exported in libkrb5. From: To: Time: Tue Dec 23 14:50:51 2008 which export file? From: To: Time: Tue Dec 23 14:52:13 2008 libkrb5.exports. From: To: Time: Tue Dec 23 14:53:42 2008 It's listed in libcollected.exports, but that has little impact on the world. From: To: Time: Tue Dec 23 14:53:55 2008 probably just as well. it was an artifact of the way we implemented realm referrals. From: To: Time: Tue Dec 23 15:20:51 2008 Ooookay... that fallback function returns a list of realms. The only caller (since it's not exported to applications) uses the first name returned and discards the rest. From: To: Time: Tue Dec 23 15:22:22 2008 (Which would be a memory leak, if the function ever returned more than one realm.) Well, not my plot. From: To: Time: Tue Dec 23 15:28:37 2008 Greg, the interface comes from krb5_get_realm_of_host or whetever it is. I.E. the multiple returns is not new. From: To: Time: Tue Dec 23 15:30:21 2008 This gets to my issue with the amount of cut-and-paste code reuse in the krb5 code base. From: To: Time: Tue Dec 23 15:31:17 2008 do you have a strategy for reducing the amount? From: To: Time: Tue Dec 23 15:32:19 2008 "Slowly." From: To: Time: Tue Dec 23 15:32:43 2008 You will see no argument from me Greg From: To: Time: Tue Dec 23 15:35:09 2008 Ken does r21566 make you happier? From: To: Time: Tue Dec 23 15:36:43 2008 i think he's not on jabber From: To: Time: Tue Dec 23 15:52:30 2008 i wonder if it would be a good idea to make special format specifiers for set_error_message that take principal names. or somehow else make it so that callers of set_error_message that have krb5_principals they want to stringify into the error message don't have to deal with memory management themselves. From: To: Time: Tue Dec 23 16:39:39 2008 hm, my dejagnu on my mac seems hosed somehow. From: To: Time: Tue Dec 23 16:40:52 2008 Running ../../../krb5/src/tests/dejagnu/krb-standalone/standalone.exp ... The process has forked and you cannot use this CoreFoundation functionality safely. You MUST exec(). From: To: Time: Tue Dec 23 17:37:11 2008 did someone touch the mod queue for krbdev? a message from mmezydlo@plantebingo has gone missing. From: To: Time: Wed Dec 24 11:55:06 2008 Do we have a place where we record new features to make writing release notes easier? (It's fine if we don't; just want to check since I added a new feature.) From: To: Time: Wed Dec 24 11:55:49 2008 not really. you could update the README. there is a RT ticket associated with it? From: To: Time: Wed Dec 24 11:57:54 2008 Yes. From: To: Time: Wed Dec 24 11:59:18 2008 which feature is this? From: To: Time: Wed Dec 24 12:00:41 2008 krb4? i would update the README for that. unfortunately README on the trunk is for 1.6, and needs other changes as well. From: To: Time: Wed Dec 24 12:03:50 2008 The new host->realm heuristic support from Sun. From: To: Time: Wed Dec 24 12:04:03 2008 oh ok From: To: Time: Sun Dec 28 02:02:45 2008 This room is not anonymous. From: To: Time: Mon Dec 29 11:09:18 2008 that's quite the body of editorial comments we just got From: To: Time: Mon Dec 29 11:48:08 2008 Editorial comments? From: To: Time: Mon Dec 29 11:48:30 2008 to krbcore about our installation and administration documents From: To: Time: Mon Dec 29 11:53:24 2008 I see them now. From: To: Time: Mon Dec 29 11:57:34 2008 every time i try looking at the rcache code, my brain melts. From: To: Time: Mon Dec 29 12:01:37 2008 and mailman is being quite high-latency again From: To: Time: Mon Dec 29 12:02:36 2008 these observations are hopefully not related. From: To: Time: Mon Dec 29 12:16:49 2008 i can forward you some of the e-mail threads that are relevant, once i find them. From: To: Time: Mon Dec 29 12:17:08 2008 Thanks. Not urgent. From: To: Time: Mon Dec 29 12:24:53 2008 right. at some point we should talk about untangling the client-side referrals mess. From: To: Time: Mon Dec 29 13:01:40 2008 Did Luke just implement over Christmas the enctype negotiation that Zhanna's already working on? From: To: Time: Mon Dec 29 13:01:53 2008 yes From: To: Time: Mon Dec 29 13:04:37 2008 Hmm. I thought she was working on domain_realm mappings. Does she have a project write-up for enctype nego I can take? From: To: Time: Mon Dec 29 13:05:15 2008 there was no project write-up published. that was an oversight. From: To: Time: Mon Dec 29 13:05:44 2008 She's moving on to domain_realm stuff, but has been working on enctype nego for a while. I think Tom's got patches in his queue to review. From: To: Time: Mon Dec 29 13:06:09 2008 OK. She should review Luke's implementation. If you want me to pull it I certainly can, but if it is fine, then perhaps we should keep it From: To: Time: Mon Dec 29 13:06:45 2008 yeah, i think she's planning on reviewing Luke's implementation, but i think we're going to focus on domain_realm for now. From: To: Time: Mon Dec 29 13:07:16 2008 and we have quite the lively thread going on about replay caches From: To: Time: Mon Dec 29 13:07:17 2008 Luke appears to have gotten the GSSAPI bits done, which she hadn't last I knew. From: To: Time: Mon Dec 29 13:21:03 2008 BTW, in case anyone was wondering, having a flat tire sucks, as does having to pump up the tire you put on in its place. Having a flat tire on the way to the garage to put on the snow tires that are in your trunk, and changing it in the parking lot of a hardware store that sells pumps, somewhat less so, but still.... From: To: Time: Mon Dec 29 13:24:00 2008 As far as I can tell, the kerberos crypto systems do have int-ctxt. Unless I'm missing something. From: To: Time: Mon Dec 29 13:24:13 2008 i believe you're right, except for single-DES From: To: Time: Mon Dec 29 13:25:01 2008 ...because we use "encrypt an unkeyed hash" in the single-DES cryptosystems. From: To: Time: Mon Dec 29 13:26:54 2008 So? It's hard to prove that is reasonable, but if the hash covers the confounder, how do you construct two ciphertexts that have the same plaintext From: To: Time: Mon Dec 29 13:27:20 2008 remember that cross-protocol crypto attack? From: To: Time: Mon Dec 29 13:27:37 2008 Even unkeyed hashes might be enough, I'm not certain. Though if we don't hash the trailing padding bytes (I don't recall offhand), it would be possible to alter the last block undetected if (say) only one byte of it is hashed. (Uncontrollable, 1/256 chance of winning, but that's probably enough to fail the INT-CTXT test.) From: To: Time: Mon Dec 29 13:28:55 2008 if the attacker has a block encryption oracle, game over... From: To: Time: Mon Dec 29 13:29:57 2008 Oh, the description says we do hash the padding bytes. From: To: Time: Mon Dec 29 13:30:07 2008 Tom, yes, but I'm not remembering how to apply that here. From: To: Time: Mon Dec 29 13:30:29 2008 We have to hash the padding bytes because we don't bother to tell you how to figure out what is padding From: To: Time: Mon Dec 29 13:30:38 2008 Right, forgot that. From: To: Time: Mon Dec 29 13:31:08 2008 IIRC that was an important issue where Cable Labs and RFC 3961 went different directions... From: To: Time: Mon Dec 29 13:31:26 2008 It's quite clear that if you give someone an encryption oracle, the des enctypes are weak From: To: Time: Mon Dec 29 13:31:41 2008 so single-DES in krb5 uses concat(confounder,cksum,plain,pad). computes cksum over the encoded plaintext prior to encryption using a zeroed cksum field, then encrypts. cksum is unkeyed. if you have a block encryption oracle, you can fabricate an entire valid ciphertext without knowing the key. that's enough to render it not INT-CTXT From: To: Time: Mon Dec 29 13:32:52 2008 Oh, you get a block encryption oracle for that game? Yeah, we'd lose, then. From: To: Time: Mon Dec 29 13:32:58 2008 Um, I'd think that would render it not int-ctxt^block-encryption But I would need to go look at the definition. From: To: Time: Mon Dec 29 13:33:44 2008 But yes if block encryption oracle is part of the adversary then we would lose. From: To: Time: Mon Dec 29 13:33:45 2008 in any case, it's clearly a weakness From: To: Time: Mon Dec 29 13:34:03 2008 Right, but I don't think it is a weakness for the replay cache stuff From: To: Time: Mon Dec 29 13:34:52 2008 if they have a block encryption oracle, you're already massively hosed if you're using single-DES, so a replay attack is the least of your worries. From: To: Time: Mon Dec 29 14:33:33 2008 hm, Danilo works for Likewise Software. From: To: Time: Mon Dec 29 14:37:41 2008 Our crypto specs really could use revising. Especially if we can require properties that the DES mechanisms don't meet. Stuff like the AEAD support would be nice (so specs don't have to say "whatever Microsoft does" and can point to something official). It would be unfortunate to invent a new Kerberos cryptosystem that turns out to be impossible to use with some SSPI calls. From: To: Time: Mon Dec 29 14:43:12 2008 Okay, so for INT-CTXT the attacker gets to choose the message but doesn't get an oracle. Choosing a plaintext message and CBC-encrypting it *would* be a block encryption oracle, but our confounder addition breaks that. From: To: Time: Mon Dec 29 14:44:09 2008 if you include the krb4 protocol in the analysis then the attacker could have a block-encryption oracle. From: To: Time: Mon Dec 29 14:44:50 2008 Well, yeah. But if you include krb4 and continue using DES under krb5, you're just kind of doomed. (Hello, MIT...) From: To: Time: Mon Dec 29 14:45:53 2008 there are probably more interesting details in Boldyreva&Kumar From: To: Time: Mon Dec 29 14:52:43 2008 Boldyreva&Kumar demonstrates that the general 3961 profile is not INT-CTXT, but the simplified profile is. From: To: Time: Mon Dec 29 14:54:21 2008 Why is it not int-ctxt? Or rather what does it mean to demonstrate that it is not? From: To: Time: Mon Dec 29 14:56:22 2008 Yeah, I've seen that. I think their analysis focused mainly on how encryption and MAC operations were combined; I don't know if they looked very closely at how DES is used specifically. From: To: Time: Mon Dec 29 14:57:45 2008 the proof is, unfortunately, rather terse. From: To: Time: Mon Dec 29 14:58:09 2008 Oh, I'm looking at the brief write-up, not the full paper. From: To: Time: Mon Dec 29 14:58:20 2008 it also relies on mildly contrived components From: To: Time: Mon Dec 29 14:59:30 2008 What do they mean by the profile? If you read the text to imply int-ctxt then presumably anything that is not int-ctxt is not a valid encryption system. From: To: Time: Mon Dec 29 14:59:55 2008 Or are they saying a specific encryption system that we have already standardized is not int-ctxt From: To: Time: Mon Dec 29 15:04:31 2008 Ah. The proof that the general form is weak starts by positing a CTR or XOR encryption mode. And a simpler variant where the encryption function outputs a 0 followed by the "real" (strong) encryption output, and decryption ignores the first bit; then you can flip the first bit (violating ciphertext integrity) without any effect on the decrypted result. From: To: Time: Mon Dec 29 15:07:03 2008 But I think our general encryption specs were pretty weak on what properties we demanded, so that's not surprising. They don't appear to specifically analyze the DES CBC construction we use. From: To: Time: Mon Dec 29 15:07:34 2008 true, but we do have the proof that the construction we used for the single-DES cryptosystems is weak. From: To: Time: Mon Dec 29 15:08:04 2008 also, any future revision to 3961 should explicitly require INT-CTXT From: To: Time: Mon Dec 29 15:08:44 2008 (And as they point out, if you can pick an encryption function with arbitrary weakness, even a keyed MAC wouldn't give us INT-CTXT.) From: To: Time: Mon Dec 29 15:09:05 2008 Do we need INT-CTXT, or is INT-PTXT adequate? From: To: Time: Mon Dec 29 15:11:33 2008 But that encryption function fails to be valid under Ken's reading of 3961 because it does not verify the ciphertext's integrity. From: To: Time: Mon Dec 29 15:12:26 2008 We want int-ctxt. We've had multiple cases where being able to compare ciphertexts to detect replays is incredibly useful. From: To: Time: Mon Dec 29 15:12:55 2008 Our DES encryption systems don't verify it directly anyways. They do have a hash of the entire plaintext (including padding and excluding a fixed block of zeros) that has a one-to-one correspondence with a ciphertext. From: To: Time: Mon Dec 29 15:13:03 2008 Yeah, okay. From: To: Time: Mon Dec 29 15:14:26 2008 Proving the DES stuff is secure is hard. It seems likely that des-cbc-crc is weak. I suspect that if des-cbc-md5 is weak in this regard, it's fairly challenging to show it. That said, our cross-protocol paper definitely raises concerns with the des enctypes From: To: Time: Mon Dec 29 15:15:30 2008 Well, yes, the cross-protocol attack gives you an oracle that kills the whole thing. From: To: Time: Mon Dec 29 15:16:52 2008 I would be curious if the specific construction we're using for DES is good (e.g., if you substituted SHA-2 and AES, and assume no oracle), even though CRC is definitely a poor choice. From: To: Time: Mon Dec 29 15:17:30 2008 But curiosity is the only point... we're using DES and CRC and should just kill them both. From: To: Time: Mon Dec 29 15:18:21 2008 Yes, but ignoring the oracle, Tom wrote up some more general concerns about the des enctypes true even without krb4. From: To: Time: Mon Dec 29 15:19:01 2008 With 1.7 we'll be able to "upgrade" to aes keys encrypted in des with crc From: To: Time: Mon Dec 29 15:21:25 2008 The RC4 enctype hmacs the plaintext not the ciphertext. From: To: Time: Mon Dec 29 15:21:41 2008 I think it is OK though because it includes the confounder. From: To: Time: Mon Dec 29 15:24:59 2008 an encryption scheme modeled on the single-DES ones but using a strong block cipher and collision-proof hash would still suffer the same weaknesses as we identified in the krb4 paper. From: To: Time: Mon Dec 29 15:32:39 2008 Hm, just skimming (I do have real work to get to sometime today, after all) but mostly I see krb4, krb5 attacks based on having an oracle, references to Bellare et al, etc., not specific weaknesses in the krb5 use of DES. Well, there is some talk of the benefits of using key derivation, which reduces the ability to attack one use case with data generated from another. From: To: Time: Mon Dec 29 15:46:30 2008 OK, large chunks of this code are getting to a point where I'm not finding bugs reviewing changes. Some of that is that I'm familiar with the code, but a lot of it is that the code is getting to fairly high quality From: To: Time: Mon Dec 29 15:46:55 2008 is this the completely new stuff, or the patches? From: To: Time: Mon Dec 29 16:19:53 2008 any strong interest in holding the collab session tomorrow? From: To: Time: Mon Dec 29 16:20:13 2008 or the dev meeting for that matter? From: To: Time: Mon Dec 29 16:24:59 2008 re rcache, fake zero-length principal is useful as a sentinel so old implementations will never be able to match. whether it's useful to stuff binary data after it is debatable given that old implementations will drop such data after an expunge. should we bother trying to have binary data? From: To: Time: Mon Dec 29 16:31:10 2008 i'm kind of partial to hex encoding. we can (ab)use asprintf and strtol, etc. From: To: Time: Mon Dec 29 16:35:14 2008 I wouldn't have any special difficulty making the meeting tomorrow (car trouble is all fixed) but am fine whether or not it happens. From: To: Time: Mon Dec 29 16:36:26 2008 Hex encoding is fine for a hash. Less fine if we wind up storing the full authenticator. From: To: Time: Mon Dec 29 16:36:50 2008 i think discussion is leading away from storing full authenticator From: To: Time: Mon Dec 29 16:38:48 2008 Agreed. From: To: Time: Mon Dec 29 16:54:42 2008 I don't think we need to care whether a principal name exists that matches the {binary,hex,base64} form of some authenticator. It seems unlikely, especially if the principal name gets stored with an @ in it and the authenticator does not. From: To: Time: Mon Dec 29 16:57:35 2008 BTW, anyone want a script for un-breaking your edu.mit.Kerberos preferences file after AppleConnect screws around with it? /mit/raeburn/rubinstein.{scpt,app} is some applescript code to kill off the daemon and remove the broken entries it puts in the config file. From: To: Time: Mon Dec 29 18:18:09 2008 Is Steve in town this week? From: To: Time: Mon Dec 29 18:18:33 2008 On vacation From: To: Time: Mon Dec 29 18:18:40 2008 i think he's still on vacation, last i checked with techtime From: To: Time: Mon Dec 29 18:18:40 2008 (but AFAIK in town) From: To: Time: Mon Dec 29 18:18:57 2008 (I forgot and called him this morning when I got the flat tire...) From: To: Time: Mon Dec 29 18:20:42 2008 Thanks. From: To: Time: Mon Dec 29 20:16:43 2008 Larry's email just made me look at some of the enctype stuff from another point of view: Our failure to handle enctype switching in (for example) GSSAPI is a bug. We don't actually run into it because currently no implementations switch enctypes when talking to us, but they're allowed to if they know what we support (like, the required enctypes). The bug needs to be fixed before we can use enctype negotiation under GSSAPI, but the change isn't directly related to RFC 4537 per se, and not turning on enctype negotiation is not a guarantee that the other side won't switch enctypes on us.... From: To: Time: Mon Dec 29 22:03:48 2008 Larry's email where? From: To: Time: Mon Dec 29 23:44:09 2008 Larry's email to ietf-krb-wg today: The behavior is defined by RFC4121, the client MUST pick up the etype that the server asserts or fail. For RFC1964 however,  the behavior is undefined (or implementation defined J). For MIT RFC1964 implementations, the server asserted key is dropped’ for MS implementations, it  basically does what RFC4121 says in this regard, and honors the server’s assertion. From: To: Time: Tue Dec 30 11:21:21 2008 postgres on krbdev.mit.edu had issues. i kicked it. From: To: Time: Tue Dec 30 11:21:34 2008 also took another update that might fix it. From: To: Time: Tue Dec 30 11:42:22 2008 "MD5 considered harmful today: Creating a rogue CA certificate" http://www.win.tue.nl/hashclash/rogue-ca/ From: To: Time: Tue Dec 30 11:42:31 2008 ja From: To: Time: Tue Dec 30 11:48:36 2008 Neat. They did it using game consoles, because for brute-force arithmetic computations, "one PlayStation 3 game console is equivalent to about 40 modern single core processors." From: To: Time: Tue Dec 30 11:53:34 2008 because the GPU is so incredibly powerful? From: To: Time: Tue Dec 30 12:43:38 2008 I'm not sure if it's the GPU specifically; I think the whole processor design is geared towards parallel computation. From: To: Time: Tue Dec 30 12:44:58 2008 Yeah, the PS3 uses the Cell architecture, with multimedia and vector coprocessor support. From: To: Time: Tue Dec 30 12:45:31 2008 Though the FAQ in the paper does point out that others have used graphics cards for serious md5 crunching. From: To: Time: Tue Dec 30 12:58:49 2008 still nothing about breaking MD5-HMAC yet, as far as i know. From: To: Time: Tue Dec 30 12:59:20 2008 I wonder what sort of transaction rate you could get out of a KDC on a PS3. :-) From: To: Time: Tue Dec 30 13:07:01 2008 http://eprint.iacr.org/2006/187.pdf "On the Security of HMAC and NMAC Based on HAVAL, MD4, MD5, SHA-0 and SHA-1" looks like it might have some interesting stuff. From: To: Time: Tue Dec 30 13:08:15 2008 is that one of Bellare's papers? From: To: Time: Tue Dec 30 13:08:34 2008 No, Bart Preneel et al. From: To: Time: Tue Dec 30 13:08:56 2008 ok. but 2006 so probably nothing too earth-shattering From: To: Time: Tue Dec 30 13:11:19 2008 Probably not. Much of it is about distinguishing HMAC with those hashes from random functions, but they do suggest (in the Abstract) that their approach could lead to second-preimage attacks. I'm not sure how serious an attack though; something that shaves off just a few powers of two might be interesting but not threatening any time soon. From: To: Time: Tue Dec 30 13:12:07 2008 to what extent to vendors who repackage our code provide documentation that is targeted specifically to their users, as opposed to providing near-verbatim copies of our docs? From: To: Time: Tue Dec 30 13:22:30 2008 Ah, they're talking on the order of 2^58 messages just for attacking hmac-md4, higher for others. From: To: Time: Tue Dec 30 13:29:09 2008 Debian basically provides your docs. Sun provides completely different docs. Redhat probably provides your docs and some docs of their own. From: To: Time: Wed Dec 31 12:11:27 2008 something on mskrb-integ broke kadmind From: To: Time: Wed Dec 31 12:30:56 2008 confirmed it's not broken on trunk. still investigating. if people have ideas on why it might be broken... From: To: Time: Wed Dec 31 12:54:58 2008 Define broken? From: To: Time: Wed Dec 31 12:55:34 2008 any clients trying to talk to kadmind get prematurely dropped connections, i think. From: To: Time: Wed Dec 31 12:55:45 2008 this is while trying to run tests out of tests/dejagnu From: To: Time: Wed Dec 31 12:56:45 2008 On Solaris? From: To: Time: Wed Dec 31 12:57:01 2008 darwin From: To: Time: Wed Dec 31 12:57:04 2008 works on the trunk From: To: Time: Wed Dec 31 12:57:19 2008 maybe now i get to learn about the joy of git bisect From: To: Time: Wed Dec 31 12:58:52 2008 Mmm. Let's hope not. OK. Let me see if Linux also falis. I'm also pondering recent changes. From: To: Time: Wed Dec 31 12:59:32 2008 is there an easy way to specify a git reference to a branch point? From: To: Time: Wed Dec 31 13:02:24 2008 No. Git doesn't know about branch points. Let me think about whether there is another way of phrasing that question with a better answer. From: To: Time: Wed Dec 31 13:03:12 2008 I also can give you points at which things were working. From: To: Time: Wed Dec 31 13:04:34 2008 mskrb-integ@{2008-12-18} doesn't manage to even start kadmind during tests From: To: Time: Wed Dec 31 13:05:09 2008 i can dig around with gitk but there has got to be a better way From: To: Time: Wed Dec 31 13:06:49 2008 I have reasonably high confidence in 21294. From: To: Time: Wed Dec 31 13:09:57 2008 heh, that looks right after the aes-ccm revert From: To: Time: Wed Dec 31 13:13:22 2008 oh wow From: To: Time: Wed Dec 31 13:13:23 2008 In file included from ../../../../krb5/src/lib/kadm5/unit-test/../../../include/krb5.h:7, from ../../../../krb5/src/lib/kadm5/unit-test/lock-test.c:7: ../../../include/krb5/krb5.h:2518: error: syntax error before 'time_t' From: To: Time: Wed Dec 31 13:14:47 2008 OK, perhaps I'm wrong about that. However I'm able to reproduce the failure here in a reasonable debugging environment. From: To: Time: Wed Dec 31 13:14:54 2008 ok From: To: Time: Wed Dec 31 13:16:32 2008 It's before the call to gss_accept_sec_context From: To: Time: Wed Dec 31 13:17:34 2008 krb5_mk_safe and similar APIs have a krb5_replay_data output parameter. Is this for further replay checking by the application? From: To: Time: Wed Dec 31 13:18:13 2008 it could be. i have never looked very carefully at those. do any callers actually pass non-null into those? From: To: Time: Wed Dec 31 13:20:26 2008 for mk_safe, the callers i can find in our tree only pass null for that parameter From: To: Time: Wed Dec 31 13:56:45 2008 i'm going to suspect rfc3244 stuff for now From: To: Time: Wed Dec 31 14:09:00 2008 ok, there was a persistent time_t vs krb5_timestamp botch a while back From: To: Time: Wed Dec 31 14:09:16 2008 but that is why a lot of builds are failing, not the cause of the kadmind spinning From: To: Time: Wed Dec 31 14:11:11 2008 OK. The problem roughly seems to be that the call to register kadmin's rpc service with portmap is failing. I cannot figure out why From: To: Time: Wed Dec 31 14:11:32 2008 oh is this part of the iprop support? From: To: Time: Wed Dec 31 14:11:36 2008 As far as I can tell pmap_set says yes or no but not why From: To: Time: Wed Dec 31 14:11:58 2008 why would that lead to spinning in the vicinity of the select loop? From: To: Time: Wed Dec 31 14:14:33 2008 That is I think unrelated. It's spinning in the select loop because there seems to be a disconnect between the fds in connections[] and the fds passed to select. In particular it seems to be read selecting on its replay cache From: To: Time: Wed Dec 31 14:15:45 2008 That seems to just be a waste of CPU. Obviously broken. Tom, can I get you to look at network.c for the call to svc_register and for example make sure that we're using the right byte order? From: To: Time: Wed Dec 31 14:15:51 2008 ick From: To: Time: Wed Dec 31 14:16:18 2008 hold on, need to figure out what branch i'm sitting on From: To: Time: Wed Dec 31 14:17:26 2008 Note that network.c is all new. However from this error I'm puzzled how this ever worked and I thought I had tested a version after the 3244 changes went in. From: To: Time: Wed Dec 31 14:17:58 2008 Or rather is all mostly copied from kdc/network.c (I believe I mentioned this in the development meeting where we discussed 3244) From: To: Time: Wed Dec 31 14:19:30 2008 AFK for a bit From: To: Time: Wed Dec 31 14:19:41 2008 i'm not sure byte order is an issue because it' s just passing what it got from svctcp_create From: To: Time: Wed Dec 31 14:32:31 2008 It looks like we store replay entries for mk_safe and friends, and we use zero-length server strings when we do so. So using a zero-length server string as a way to recognize extension entries may be as robust as hoped. We could use zero-length client strings instead? From: To: Time: Wed Dec 31 14:32:47 2008 sure, we could do that. From: To: Time: Wed Dec 31 14:33:20 2008 though i wonder how many other things use special replay cache entries for purposes not originally intended for the replay cache From: To: Time: Wed Dec 31 14:40:59 2008 I think that's it inside libkrb5. Outside, it's hard to tell. We don't have declarations for these interfaces, but they do have krb5_ names and they are exported symbols. From: To: Time: Wed Dec 31 14:41:25 2008 ok From: To: Time: Wed Dec 31 14:41:51 2008 note that SAM preauth in the kdc does something weird too From: To: Time: Wed Dec 31 14:42:20 2008 We make no stability guarantees for interfaces in that state. If you want to smoke out problems rename them to krb5int. From: To: Time: Fri Jan 2 13:20:04 2009 Why does iprop pass in tcp into the last argument of svc_register while kadmind passes in 0? Does iprop actually use portmap to find itself? From: To: Time: Fri Jan 2 13:22:09 2009 Sun's iprop implementation uses portmap, that's why we try to register (but continue on even if it failed). From: To: Time: Fri Jan 2 13:25:37 2009 OK. So, Luke tried to abstract things somewhat on the mskrb-integ branch and got them confused. I'll write it up From: To: Time: Fri Jan 2 13:36:53 2009 I believe Luke's latest commits serve to mitigate the canonicalization risk From: To: Time: Fri Jan 2 13:53:08 2009 Man, the dejagnu tests are slow. From: To: Time: Fri Jan 2 14:20:10 2009 Yep. If you have any observations to add to tickets 3943 or 2873, please do... I assume Luke's branch has my changes from early December (r21064) to reduce the number of tests run... From: To: Time: Fri Jan 2 14:21:27 2009 I actually think I may have an environment problem. Should tests take 30 minutes to run? Yes, I have those changes. From: To: Time: Fri Jan 2 14:22:17 2009 BTW, the tests are of course being useful. For example, we accidentally changed behavior to not assume everything supports des-cbc-crc on the mskrb-integ branch and the tests definitely noticed:-) From: To: Time: Fri Jan 2 14:22:24 2009 No, 30 minutes is way too long. From: To: Time: Fri Jan 2 14:22:51 2009 That's what I was afraid of. They did conclude eventually. From: To: Time: Fri Jan 2 14:26:03 2009 Yeah, something is seriously slow here. It's taking a second or so to create a principal From: To: Time: Fri Jan 2 14:27:54 2009 Hm, I thought I'd made notes someplace about how long it took me to run the dejagnu tests, but I can't find them, only references to the percentage speedup of that patch (from early November, actually). From: To: Time: Fri Jan 2 14:29:04 2009 Not assuming everything supports des-cbc-crc is probably a good thing, if we want to deprecate DES eventually (or interoperate with a Heimdal release that disables it by default). But, only if things actually work... :) From: To: Time: Fri Jan 2 14:30:53 2009 Well, it's a major behavior change and it breaks a bunch of tests that depend on des-cbc-crc being supported-by-default. We could of course change the tests:-) From: To: Time: Fri Jan 2 14:33:26 2009 I'd be curious to see whether the tests are broken or what, at some point. But we don't need additional distractions from getting Luke's primary work incorporated.. From: To: Time: Fri Jan 2 14:35:29 2009 No, several passes have comments that mention they explicitly depend on that behavior From: To: Time: Fri Jan 2 14:39:19 2009 Oops. The aes-tcp pass was AES-only, no des-cbc-crc listed, but that's the pass I turned off in favor of a single TCP test in another pass. The other AES passes include des-cbc-crc. From: To: Time: Fri Jan 2 14:56:49 2009 Hm, our test suite doesn't seem to work on a machine with only an IPv6 address in DNS. From: To: Time: Fri Jan 2 14:57:07 2009 (Like, say, my desktop machine at home.) From: To: Time: Fri Jan 2 15:07:32 2009 OK. not sure why the tests are so slow. However with des-cbc-crc enabled, we're down to two failures. Now investigating From: To: Time: Fri Jan 2 15:32:45 2009 It makes me feel good that Larry doesn't know how the Microsoft KDC behaves. It makes me feel better about not understanding our code From: To: Time: Fri Jan 2 18:15:26 2009 password changing failures in the DES case are due to incorrect network address, for reasons not yet known to me. From: To: Time: Fri Jan 2 18:23:34 2009 My slow test cases were caused by a spinning expect From: To: Time: Fri Jan 2 18:25:08 2009 kadmind logs success for the pwchange test but the client gets a bad network address error somehow. From: To: Time: Fri Jan 2 18:39:16 2009 The warnings on every file from k5-platform.h are annoying. From: To: Time: Fri Jan 2 18:59:25 2009 Luke! I'm trying to merge this. No moving target please From: To: Time: Fri Jan 2 20:23:13 2009 The dejagnu test suite also takes my machine about half an hour to finish. My impression from looking at the test code was that most of the time is probably spent in "sleep" but that's an unscientific guess. From: To: Time: Fri Jan 2 20:23:41 2009 What warnings is k5-platform giving on every file? From: To: Time: Fri Jan 2 20:27:17 2009 ../../../../src/lib/krb5/krb/../../../include/k5-platform.h: In function 'store_16_be': ../../../../src/lib/krb5/krb/../../../include/k5-platform.h:542: warning: conversion to 'short unsigned int' from 'unsigned int' may alter its value ../../../../src/lib/krb5/krb/../../../include/k5-platform.h:542: warning: conversion to 'short unsigned int' from 'int' may alter its value ../../../../src/lib/krb5/krb/../../../include/k5-platform.h: In function 'load_16_be': ../../../../src/lib/krb5/krb/../../../include/k5-platform.h:586: warning: conversion to 'short unsigned int' from 'int' may alter its value ../../../../src/lib/krb5/krb/../../../include/k5-platform.h: In function 'store_16_le': ../../../../src/lib/krb5/krb/../../../include/k5-platform.h:619: warning: conversion to 'uint16_t' from 'unsigned int' may alter its value From: To: Time: Fri Jan 2 20:27:49 2009 Actually, I didn't check if those were macros. If so, that's a bug in and of itself since that's relatively new code From: To: Time: Fri Jan 2 20:39:17 2009 I don't get those warnings on the mskrb-integ branch, so it's presumably a compiler version issue. From: To: Time: Fri Jan 2 20:40:45 2009 Looks like some casts would be an appropriate way to shut those up. From: To: Time: Fri Jan 2 20:45:09 2009 "DES" test case failures are actually due to "run_once" From: To: Time: Fri Jan 2 20:47:05 2009 hartmans@luminous:dejagnu(243)> gcc -v Using built-in specs. Target: i486-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 4.3.2-1' --with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without From: To: Time: Fri Jan 2 20:48:11 2009 Thread model: posix gcc version 4.3.2 (Debian 4.3.2-1) ----> jwrite krb5@conference.mit.edu -a hartmans@jis.mit.edu/owlwill quit. From: To: Time: Fri Jan 2 20:50:13 2009 gcc version 4.0.1 (Apple Inc. build 5465) and i don't see the warnings From: To: Time: Fri Jan 2 20:51:14 2009 incorrect net address things are likely due to schpw.c ending up with an incorrect local address to pass into mk_priv when responding to the client From: To: Time: Fri Jan 2 20:51:24 2009 gcc version 4.2.4 (Ubuntu 4.2.4-1ubuntu3) gives no warnings. So maybe 4.3 added those. (It's a pretty good warning, in my opinion.) From: To: Time: Fri Jan 2 20:51:41 2009 warning about value truncation? From: To: Time: Fri Jan 2 20:53:48 2009 i can see many use cases where the truncation is either intended or harmless... From: To: Time: Fri Jan 2 21:00:08 2009 Greg, i handed off ticket #1201 to you From: To: Time: Fri Jan 2 21:00:17 2009 it concerns replay cache false postiives From: To: Time: Fri Jan 2 21:30:36 2009 I'll open a bug, but I think that my merging of Ken's logging changes and Luke's sx4u logging changes end ups with sx4u not being logged correctly. However, I think Ken will have a better handle on how to fix than I. From: To: Time: Sat Jan 3 07:51:44 2009 Sam, do you get -Wconversion in your compiler invocations? Greg turned that off on the trunk a while ago. I think that might be the flag for the warnings you're seeing. From: To: Time: Sat Jan 3 11:48:48 2009 At least in my version of gcc, -Wconversion is any change in type size resulting from a function prototype, whether it's widening (which it usually is) or narrowing. Sam is getting warnings about implicit type narrowing, which I would guess is a different flag. From: To: Time: Sat Jan 3 11:49:49 2009 or additional functionality for an existing flag. From: To: Time: Sat Jan 3 11:50:34 2009 anyway, the problem with kpasswd appears to be that Luke didn't port the UDP destination address determination hackery sufficiently well, and we might even be getting stack garbage for destination address. From: To: Time: Sat Jan 3 11:53:52 2009 Huh. I don't see the WARN_CFLAGS change on the mskrb branch. From: To: Time: Sat Jan 3 11:54:13 2009 i'm not getting the int->short truncation warnings on mskrb From: To: Time: Sat Jan 3 11:57:00 2009 Now I'm concerned about what other trunk changes Sam's merge missed. From: To: Time: Sat Jan 3 12:19:04 2009 yeah i'm not sure why that change got missed From: To: Time: Sat Jan 3 12:25:18 2009 conflict markers in some files too From: To: Time: Sat Jan 3 14:14:37 2009 -Wconversion changed meaning at some point. But I'm not 100% sure that's it. From: To: Time: Sat Jan 3 14:21:04 2009 My laptop has gcc 4.3; I guess I'll try with that. From: To: Time: Sat Jan 3 14:29:30 2009 If Sam's keeping track, he could do the merges without bringing everything from the trunk over to the branch. But, yeah, I'd be a little surprised if he was intentionally doing it that way. From: To: Time: Sat Jan 3 14:41:13 2009 Well, and his mail implied that he thought he was done. From: To: Time: Sat Jan 3 14:45:57 2009 Oh, missed that... From: To: Time: Sat Jan 3 14:52:59 2009 Actually, the -Wconversion change was merged to mskrb-integ but was unmerged while pulling aes-ccm onto its own branch. I'm looking into how that happened and what else is affected From: To: Time: Sat Jan 3 14:55:38 2009 It's r21286, which as far as I can tell, seems to have affected files entirely unrelated to its log message From: To: Time: Sat Jan 3 14:56:58 2009 No, hmm. From: To: Time: Sat Jan 3 14:58:23 2009 OK something bad happened with git-svn. From: To: Time: Sat Jan 3 15:00:09 2009 Yeah, I have two R21286 commits. From: To: Time: Sat Jan 3 15:12:03 2009 Uh. This is most strange, but looks relatively easy to revert From: To: Time: Sat Jan 3 15:28:18 2009 It's -Wconversion giving the warnings in k5-platform.h. It seems that gcc 4.3 made the warning more useful than it was previously, though I'm not sold on adding it back into our warning set since gcc 4.3 isn't very widespread yet. From: To: Time: Sat Jan 3 15:30:33 2009 Unless they come up with a variation that quietly allows you to pass a 'short' to a function with a prototype indicating a 'short' argument, I think we probably don't want to re-enable it. From: To: Time: Sat Jan 3 15:30:50 2009 (Or does the 4.3 version allow that?) From: To: Time: Sat Jan 3 15:31:38 2009 I think that's the only instance where git-svn managed to fail in that particular way. I think I sort of understand the causation enough to believe it is an isolated incident and to avoid it From: To: Time: Sat Jan 3 15:32:24 2009 Yeah, it looks like the gcc 4.3 -Wconversion is irritating whenever you're doing arithmetic on shorts as well ("shortvar = shortvar + 1"). So it's still too noisy. From: To: Time: Sat Jan 3 15:33:04 2009 It's logical but annoying. The use of a 'short' in an expression really results in an 'int' value, so... From: To: Time: Sat Jan 3 15:36:12 2009 It was very irritating when for example it warned that sizeof(foo)*2 might overflow for some small foo. It had enough information to know it was harmless From: To: Time: Sat Jan 3 15:46:12 2009 That's just kind of sad. From: To: Time: Sat Jan 3 17:29:10 2009 Running a make test before git svn dcommit of the mskrb-integ merge From: To: Time: Sat Jan 3 17:32:12 2009 i suspect kpasswd is still broken From: To: Time: Sat Jan 3 17:37:26 2009 Sure. There will be bugs. I suspect it breaks the Windows build. We know we need to think more about the portmap issue. From: To: Time: Sat Jan 3 17:37:41 2009 I do have kpasswd on my open issues list I'm sending to krbdev From: To: Time: Sat Jan 3 21:12:12 2009 I don't think the gss error mapping-table mutex gets initialized properly any more. (Not the two-phase initialization hack that ensures both UNIX and Windows will be happy.) If I hadn't gotten rid of the thread shim debug code, maybe it would've been flagged earlier. From: To: Time: Sun Jan 4 02:02:43 2009 This room is not anonymous. From: To: Time: Mon Jan 5 12:01:16 2009 The krb5_tkt_authent structure seems to exist purely as a means to pass arguments to krb5_auth_to_rep, which is odd. (Also, it's an exported structure, but krb5_auth_to_rep cannot be used without including k5-int.h or duplicating some of its contents.) From: To: Time: Mon Jan 5 12:03:50 2009 Maybe we can make it private then. From: To: Time: Mon Jan 5 12:05:10 2009 Well, we could probably eliminate its use completely, and perhaps leave the declaration around for compatibility. From: To: Time: Mon Jan 5 12:05:26 2009 Since Sam's merge is done, it's not as immediately useful, but over the weekend I was looking into a change he suggested, namely moving the machine-generated dependencies out of Makefile.in and into a separate file (I called it "deps") that would also be checked in. I did the work on a branch where I was experimenting with requiring GNU make for UNIX builds, but it would probably only be an hour's work or so to redo on the trunk, if people think it's a good idea. From: To: Time: Mon Jan 5 12:07:23 2009 Sure. Helps keep the version history of the makefiles cleaner. From: To: Time: Mon Jan 5 12:07:50 2009 I'm kind of on the fence... if we've got a structure defined in a public header but useless with only that public header, do we have to consider it part of the stable, public API? The most strict interpretation would be that of course we do, someone could be using it for their own purposes in Kerberos-related code, but we don't always go with the most strict approach... From: To: Time: Mon Jan 5 12:09:57 2009 That too. The major benefit to Sam would've been to simplify merging, of course -- just let the merge process trash the file, or pick one version, it doesn't matter because you should regenerate it anyways; but with the other stuff in Makefile.in you do need to take care with the merge process. But we don't have any other big merges coming up soon AFAIK. From: To: Time: Mon Jan 5 12:12:38 2009 Oh. Hm. Wait, I need to rethink whether it'll actually work that easily... with gmake I could just do "include $(srcdir)/deps". For non-gmake, I need to insert a different per-makefile file. Or change autoconf/configure to always include the file, but then I need to create dummy versions in directories with no sources. From: To: Time: Mon Jan 5 12:13:32 2009 I need to check whether substituting $srcdir/deps for @deps@ will do the right thing per directory... From: To: Time: Mon Jan 5 12:16:54 2009 Skimming config.status, it looks to me like the answer is no. So I guess either I need a huge number of substitutions, each used once in a different directory, or change configure to build the makefile from pre.in+$srcdir/Makefile.in+$srcdir/deps+post.in and create deps in every directory. Or require GNU make so we can test for non-empty $(SRCS), which is what I was doing on my branch. From: To: Time: Mon Jan 5 12:22:26 2009 (along with changing how the recursion rules are defined, to allow greater parallelism and make new recursive targets easier to define, expressing the error-table processing rules more precisely, including fragments like post.in indirectly so we don't have to rebuild a zillion makefiles when they change, stuff like that) From: To: Time: Mon Jan 5 12:57:06 2009 Okay, it was half an hour's work. :-) But it results in 27 dummy "deps" files being needed, including src/deps. It's a little ugly. Using GNU make would clean that up. From: To: Time: Mon Jan 5 12:58:33 2009 Oh, and the Windows build would need a little tweaking to pull in the new file. Should be easy, but after the big merge, I'm not betting on it being easy to just plow through and do it in a few minutes without fixing other damage first. From: To: Time: Mon Jan 5 13:21:48 2009 Do we have someone who is going to look at the Windows issues? I'd hate to see the trunk rot for too long on the windows platform From: To: Time: Mon Jan 5 13:22:39 2009 No one assigned currently as far as I know. I was thinking of giving it a try, but not this week. From: To: Time: Mon Jan 5 13:26:17 2009 I know that the .def files will need to be updated. I think we got calling conventions right for new APIs. I expect we introduced some internal APIs with KRB5_CALLCONV which is "wrong" but harmless. Things likely to break: * library initialization issues * gss-api may behave strangely because of the mechglue changes GSS-API will not support loading dynamic mechanisms on windows until the plugin interface is ported From: To: Time: Mon Jan 5 14:31:22 2009 Even if we don't standardize a GSSAPI AEAD extension with multiple sign-only data, I kind of think we should push to revise RFC 3961 to incorporate it, with Microsoft involved in the process. It should also incorporate some of the assumptions/restrictions imposed by the SSPI design. From: To: Time: Mon Jan 5 15:36:24 2009 Can I get a refresher on the difference between mk_cred/rd_cred and mk_req/rd_req? From: To: Time: Mon Jan 5 15:38:01 2009 Ah, _cred is for forwarding credentials, req is for authentication. From: To: Time: Mon Jan 5 15:38:02 2009 mk_cred/rd_cred are for KRB-CRED messages, which use an established session key to transmit entire credentials (ticket-granting tickets etc) to a server. mk_req/rd_req are for the AP-REQ exchange, which actually sets up the session key. From: To: Time: Mon Jan 5 15:42:33 2009 do we really need a guided tour of the source tree in the install guide? From: To: Time: Mon Jan 5 15:42:56 2009 No. From: To: Time: Mon Jan 5 15:43:15 2009 That's fodder for a "hacking" guide or something. From: To: Time: Mon Jan 5 15:43:30 2009 yeah, and probably fits best somewhere in the wiki From: To: Time: Mon Jan 5 15:44:37 2009 also, it's 2009. do we really need to instruct people how to unpack .tar.gz files? From: To: Time: Mon Jan 5 16:04:46 2009 rd_cred doesn't use a replay cache? From: To: Time: Mon Jan 5 16:06:08 2009 Uh, it does, I just failed to list it. I'll follow up. From: To: Time: Mon Jan 5 16:21:05 2009 Hm, I was going to add a "message" field to krb5_donot_replay so that the replay cache back end could decide what to do with the message (hash it, ignore it, store it whole, psychoanalyze it, whatever). But the same structure is used to store entries read in from disk inside the default implementation. From: To: Time: Mon Jan 5 16:21:59 2009 how about wrapping the krb5_donot_replay with another structure inside the rcache implementation? From: To: Time: Mon Jan 5 16:23:58 2009 Maybe... or I could abuse the message field to hold the hash for records read in from the cache. From: To: Time: Mon Jan 5 16:26:17 2009 so if we are treating a new-style rcache record as two paired records, do we store them in one data structure or two? From: To: Time: Mon Jan 5 16:26:36 2009 I was thinking one. From: To: Time: Mon Jan 5 16:27:18 2009 so this one structure would need to contain enough information to disambiguate between a new-style record (read from two on-disk records) and an old-style record? From: To: Time: Mon Jan 5 16:27:33 2009 Sure. Empty hash value means old-style record. From: To: Time: Mon Jan 5 16:30:41 2009 Essentially, I can (1) expose the hashing assumption to the callers, removing that decision from the back end; (2) abuse that field of the donot_replay structure in the default back end; or (3) separate the structures used by the callers and the back end. (The callers are all internal to libkrb5 or the KDC, so there aren't any API compatibility issues.) From: To: Time: Mon Jan 5 16:59:11 2009 After some AFK thinking about it, (1) seems most in keeping with the current interface design. From: To: Time: Mon Jan 5 17:12:10 2009 I'd argue 3 is best in that the current interface seems at too-low-level of an interface From: To: Time: Mon Jan 5 17:32:43 2009 I agree that the current interface is rather low level, but I'm not sure I should be trying to fix that in the context of the current project and with heavy time constraints. And I'm not sure that it makes sense to have one field be high-level and the rest tailored to a specific conception of replay records. From: To: Time: Mon Jan 5 17:34:54 2009 "first, do no harm" From: To: Time: Mon Jan 5 17:39:41 2009 i vastly prefer solutions that increase modularity and maintainability. at worst, do not make the code less maintainable or less modular. what are the tradeoffs in these respects among your three options? From: To: Time: Mon Jan 5 17:41:07 2009 The utf8 code doesn't build unless your system is linux, mac, or little-endian. Fixing... From: To: Time: Mon Jan 5 17:47:31 2009 Q: agree/disagree?: our existing documentation (mostly the texinfo-based stuff) reads too much like reference material and not enough like "how-to" From: To: Time: Mon Jan 5 18:05:07 2009 It does read that way somewhat, I'm not sure I'd agree with "too much". From: To: Time: Mon Jan 5 18:05:54 2009 Really, I think we should have setup programs or scripts that do most of the work anyways, so there shouldn't be much need for a "how-to" for the common cases. From: To: Time: Mon Jan 5 18:07:40 2009 or make more of the defaults sufficiently sane that the amount of configuration is minimized From: To: Time: Mon Jan 5 18:08:17 2009 That too. From: To: Time: Mon Jan 5 18:31:43 2009 anyway i am wondering how typical the difficulties that "dr moe" encountered are From: To: Time: Mon Jan 5 18:34:56 2009 Sam: lib/krb5/krb/pac.c:k5_time_to_seconds_since_1970 has a check for unsigned greater than zero, and negates the value if it's not greater. Is that supposed to be signed? From: To: Time: Mon Jan 5 18:37:41 2009 I think if one installs from a packaging system, there's a fair chance that the packaging could provide config scripts or files that also obviate some of our documented setup procedures. We can't predict that. But we should indeed explain stash files better, and not couple "make install" with config file setup. From: To: Time: Mon Jan 5 18:41:17 2009 also, Zhanna's experiences setting up a test environment corroborate the observation that "kdb5_util stash" might not often do the right thing. From: To: Time: Mon Jan 5 18:42:34 2009 We should check if she has any comments in general on the install guide. From: To: Time: Mon Jan 5 18:43:28 2009 well technically she was working out of a non-installed build tree, which requires a slightly pointier hat than normal installations. From: To: Time: Mon Jan 5 19:01:19 2009 I think I see a way to trim a few hundred more bytes off the DES implementation. Maybe more, but I should stop staring at this code. From: To: Time: Mon Jan 5 19:03:41 2009 Ick. Do we still have to export des_FP_table etc? From: To: Time: Mon Jan 5 19:43:40 2009 We have a bunch of implicitly-declared function warnings in the Sun build. Most of them are krb5int_asprintf or krb5int_vasprintf. A few are string functions. After eliminating those sets, I see two warnings left, in the telnet code. From: To: Time: Tue Jan 6 11:18:52 2009 I find it really hard to explain why you want RFC 4537 In particular, why do you want to encrypt an AES key in DES or RC4 ? From: To: Time: Tue Jan 6 11:19:27 2009 it raises the bar From: To: Time: Tue Jan 6 11:22:01 2009 To what attacks? From: To: Time: Tue Jan 6 11:22:38 2009 I guess it is effective against known plaintext attacks or attacks that depend on getting lots of ciphertext in a given key From: To: Time: Tue Jan 6 11:22:44 2009 if you have an eavesdropper who sees the encrypted application data but not necessarily the ap-req From: To: Time: Tue Jan 6 11:23:35 2009 i will grant that it doesn't help where the eavesdropper sees the entire ap-req and conversation and can brute-force the encryption to get the subsession key. From: To: Time: Tue Jan 6 11:25:52 2009 but yeah, ap-req encrypted with single-des is less ciphertext than an entire application session encrypted using single-des, which may be a significant distinction. From: To: Time: Tue Jan 6 11:26:37 2009 I think the "lots of ciphertext" attacks are the main case it helps with. Well, and in some circumstances an attacker might be able to control some of the plaintext of the session encrypted with the subkey, possibly opening up some other avenues of attack on the subkey, I guess. From: To: Time: Tue Jan 6 11:27:08 2009 It's too bad we can't do DH or something similar to produce the AES key. From: To: Time: Tue Jan 6 11:27:40 2009 PFS is on our list of things to look at; hopefully the FAST framework will enable it. From: To: Time: Tue Jan 6 11:29:40 2009 FAST seems kind of heavy-weight for getting PFS in an AP exchange. From: To: Time: Tue Jan 6 11:30:16 2009 But confusingly even DES seems relatively hard to mount a chosen-ciphertext or chosen-plaintext attack. It still has 2**46 security right? From: To: Time: Tue Jan 6 11:36:52 2009 Wikipedia's DES entry lists a linear cryptanalysis approach by Matsui that needs 2**43 known (not chosen) plaintexts, and later improvements knock a little off of that. Still pretty large. From: To: Time: Tue Jan 6 11:37:41 2009 2**43 known plaintext resulting in what work factor? From: To: Time: Tue Jan 6 11:38:36 2009 Experimentation in 2001 with the improved versions showed "that it was somewhat faster than predicted, requiring time equivalent to 239–241 DES evaluations." From: To: Time: Tue Jan 6 11:38:49 2009 (er, that was 2**39 - 2**41; so much for cut and paste) From: To: Time: Tue Jan 6 11:39:12 2009 Oh, wait, that was a chosen-plaintext variant. From: To: Time: Tue Jan 6 11:39:29 2009 brute force is still 2**56? From: To: Time: Tue Jan 6 11:40:08 2009 With known plaintexts, Biryukov got it down to 2**41 in 2004. Or, "their analysis suggests" it could be gotten down to 2**41. From: To: Time: Tue Jan 6 11:40:44 2009 you need to know some characteristics of the plaintext to confirm that you have found the correct key by brute force. From: To: Time: Tue Jan 6 11:41:17 2009 True. From: To: Time: Tue Jan 6 11:44:08 2009 The EFF cracking machine ($250K in 1998) needed 2 days to do the brute-force search. COPACOBANA cost $10K according to the Wikipedia DES entry. The COPACOBANA web site says their 2007 design can crack a DES key in 12.8 days worst case (6.4 average). From: To: Time: Tue Jan 6 11:49:44 2009 I have to wonder what the time to crack a DES key would be like on current desktop hardware, with an implementation tuned for modern multicore x86 SIMD processors. From: To: Time: Tue Jan 6 11:51:36 2009 or a rack full of playstations From: To: Time: Tue Jan 6 11:52:57 2009 True. From: To: Time: Tue Jan 6 15:14:09 2009 FYI, the test suite passes on trunk for me. (My laptop crashed before my first test run finished, so it took even longer than usual to finish a run.) From: To: Time: Tue Jan 6 15:45:59 2009 Damn, I blanked on ticket headers in the last two commits. Well, I'll mention the revision numbers in the ticket when I change its status. From: To: Time: Tue Jan 6 16:24:18 2009 Ah, found my kprop failure. I hadn't run "make clean" in way too long, and there was an ancient kadmind acl file in the build tree, predating the iprop merge. We only create the acl file if it's not already there... *sigh* From: To: Time: Tue Jan 6 16:24:18 2009 oops From: To: Time: Tue Jan 6 16:24:20 2009 are you seeing kpasswd-related failures? From: To: Time: Tue Jan 6 16:25:31 2009 Not with "RUNTESTFLAGS=iprop.exp" :-). Trying now. (On Linux) From: To: Time: Tue Jan 6 16:26:03 2009 yes From: To: Time: Tue Jan 6 16:27:29 2009 Ah, both are bad-address errors. One comes from kinit, but it's a test that kinit (get_init_creds) will change your password if the KDC says that's required. So, yeah, both are password-changing problems. From: To: Time: Tue Jan 6 16:36:44 2009 ok, so we now have declaration of a proposal to change the coding style... From: To: Time: Tue Jan 6 16:36:44 2009 Yay, last night's automated testing didn't fail until running the tests. :) From: To: Time: Tue Jan 6 16:39:54 2009 I'm sorry that was not clear in my original message. From: To: Time: Tue Jan 6 16:47:11 2009 what is current BSD or GNU practice for // comments? From: To: Time: Tue Jan 6 16:51:36 2009 GNU coding standards basically say, "C 89 is widespread enough to use (but no trigraphs!), C 99 is not." No explicit mention of comment syntax, but it's implied that "//" shouldn't be used. From: To: Time: Tue Jan 6 16:52:34 2009 ok. it is now 2009, so c99 is presumably at least moderately widely adopted. however, i do recall that well into early 2000s, c89 support was dodgy on many platforms. From: To: Time: Tue Jan 6 16:55:05 2009 http://cvsweb.NetBSD.org/bsdweb.cgi/src/share/misc/style?rev=HEAD&content-type=text/x-cvsweb-markup indicates netbsd style uses /* */ From: To: Time: Tue Jan 6 16:55:52 2009 c99 is not supported on Windows yet. But they've got sort of a mixed c/c++ compiler that I'm pretty sure will accept // comments. From: To: Time: Tue Jan 6 16:56:43 2009 There's certainly other stuff from c99 I'd like to be able to use, like designated initializers, but, oh well. From: To: Time: Tue Jan 6 16:57:08 2009 We could try using gcc on Windows. :) From: To: Time: Tue Jan 6 16:57:22 2009 please let us not open that can of worms right now From: To: Time: Tue Jan 6 17:19:20 2009 novell tgt referral chase code gets points off for dubious use of goto From: To: Time: Tue Jan 6 17:23:06 2009 Yeah, the goto did not make it more clear. I'm also concerned that it changes the logic somewhat in the case where a realm was specified. It sounded like it was trying to do something like use the realm as a hint rather than as a starting point in ways that I'm not sure are consistent with our "design" From: To: Time: Tue Jan 6 17:23:34 2009 You know it might be a good idea to grab Andrew's notes about how this is supposed to work and stick them on the wiki. From: To: Time: Tue Jan 6 17:23:50 2009 so i have this nebulously defined problem about the way we implement client behavior for service principal referral, and i would like to clarify it before i toss it to the mailing list. From: To: Time: Tue Jan 6 17:23:53 2009 And update them if we change the intended behavior From: To: Time: Tue Jan 6 17:27:00 2009 Do you need help defining it? From: To: Time: Tue Jan 6 17:28:56 2009 sure. i think it has several components. one of them is that we clearly degraded user and administrator experience by implementing referrals, and i would like to understand how and whether we can un-break things without causing worse damage along the way. From: To: Time: Tue Jan 6 17:30:31 2009 OK. for that, I think we just introduced bugs. Basically we didn't catch all the dependencies on default realm and we need to find them all and shake out fixes. I believe that trunk has all the things handled people commonly run into besides verify_init_creds. From: To: Time: Tue Jan 6 17:30:55 2009 there is the empty realm name issue, which causes confusion and thwarts troubleshooting From: To: Time: Tue Jan 6 17:31:13 2009 I.E. I've tried to see a pattern in what broke and have failed to see one. Once I fixed verify_init_creds and ksu in Debian I've not seen user or administrator complaints. From: To: Time: Tue Jan 6 17:33:16 2009 amb's notes on referrals: is this ticket #2652? From: To: Time: Tue Jan 6 17:34:09 2009 I don't know. I was thinking of his readme from his branch. I'll go look. From: To: Time: Tue Jan 6 17:34:12 2009 I think some of the utf8/ucs2 code is a little broken in endianness handling. From: To: Time: Tue Jan 6 17:35:05 2009 I could believe build issues but would find significant byte-order problems in openldap highly surprising From: To: Time: Tue Jan 6 17:37:33 2009 No, just the adaptation to the krb5 tree. We don't guarantee that K5_BE will be defined on big-endian platforms, nor K5_LE for little endian. We try, for the architectures and endianness headers we know about, but the only guarantee is that we won't define both. And, the swapping of the value happens only if K5_BE is defined and the argument little_endian is nonzero. (And, it used to assume that the macro SWAP16 was always defined, also not true.) From: To: Time: Tue Jan 6 17:39:07 2009 Yes, 2652 has the appropriate part of the readme. And after re-reading that, the Novell patch seemed more in line than I expected. From: To: Time: Tue Jan 6 17:39:26 2009 I stuck in a SWAP16, though if the UTF8 value is outside the BMP my macro (and other bits of the code) won't deal well. From: To: Time: Tue Jan 6 17:40:10 2009 also, i am going to propose dropping use of hierarchical traversal by default, or perhaps limiting its depth. From: To: Time: Tue Jan 6 17:41:31 2009 It seems kind of late in the 1.7 process for that major of a change. so, I'd like to push back on dropping it by default because it will be a fairly major behavior change whose impact you will not be able to find in time. Limiting its depth sounds more plausible; what do you mean by that? From: To: Time: Tue Jan 6 17:42:31 2009 for example, do you really think there will be a plausible COM or EDU realm in existence, ever? From: To: Time: Tue Jan 6 17:43:36 2009 No. From: To: Time: Tue Jan 6 17:43:56 2009 DLV for Kerberos:-) From: To: Time: Tue Jan 6 17:43:59 2009 Oh, I see. The ucs2 functions for big-endian are defined but aren't actually exported, so it doesn't matter so much that that path is buggy. From: To: Time: Tue Jan 6 17:44:47 2009 DLV? From: To: Time: Tue Jan 6 17:45:15 2009 DNSSec thing for having many signed roots. You pick the root signer you like From: To: Time: Tue Jan 6 17:45:41 2009 So, I could pick my edu realm based on who I thought would do a good job From: To: Time: Tue Jan 6 17:46:15 2009 You'd need to have some glue to make this work with Kerberos while allowing a site to belong to more than one .edu realm. Again, inserted as a joke From: To: Time: Tue Jan 6 17:46:53 2009 So, yeah, limiting to two components would be fine. From: To: Time: Tue Jan 6 17:47:56 2009 I could imagine a one-component realm for some small ccTLD or special-purpose TLD. From: To: Time: Tue Jan 6 17:49:42 2009 "Hey, kid, get a modern kdc" From: To: Time: Tue Jan 6 17:49:57 2009 I.E. one that gives us referrals. From: To: Time: Tue Jan 6 17:50:22 2009 I mean if your KDC hands back a krbtgt/TV@TV, then by all means use it. From: To: Time: Tue Jan 6 17:51:04 2009 basically the motivation is decreasing network traffic and minimizing configuration requirements at the client. having a referrals-enabled KDC will help immensely. From: To: Time: Tue Jan 6 17:51:13 2009 If we had a few more months, I might think that turning off hierarchical traversal by default was a good idea. I just don't think we'll be able to get the impact in time From: To: Time: Tue Jan 6 17:51:34 2009 (.mil, maybe) From: To: Time: Tue Jan 6 17:52:10 2009 .MIL? i dunno, there has been strong inter-service rivalry at times. From: To: Time: Tue Jan 6 17:53:42 2009 All a .MIL would need to be was a central coordinator for cross-realm authentication, to avoid requiring N**2 keys or PKCROSS. I suppose if they don't *want* to talk to each other.... From: To: Time: Tue Jan 6 17:55:56 2009 I wonder if having a way to say "stop upward traversal here" would be helpful -- you could list CO.UK as well as ORG and COM. From: To: Time: Tue Jan 6 17:56:18 2009 that's starting to smell like lots of additional configuration From: To: Time: Tue Jan 6 17:56:56 2009 Yes, it would. But let's also remember that Tom's under really tight time pressure on this project. ANd he has not even proposed a design. The tighter we can scope it the more likely he'll get done by end of January. From: To: Time: Tue Jan 6 17:56:59 2009 Yeah, because different TLDs may be arranged differently. From: To: Time: Tue Jan 6 17:57:36 2009 Yeah, I'm thinking longer term, but maybe we can get hierarchical traversal off by default in a similar time frame. From: To: Time: Tue Jan 6 17:58:44 2009 Seems likely. From: To: Time: Tue Jan 6 19:24:27 2009 Is KDC_OPT_CNAME_IN_ADDL_TKT supposed to be an alias for KDC_OPT_REQUEST_ANONYMOUS? They're defined with the same value. From: To: Time: Tue Jan 6 19:26:20 2009 i have no idea From: To: Time: Tue Jan 6 19:43:30 2009 Kind of a weird indentation style we use for prototypes in k5-int.h. From: To: Time: Tue Jan 6 19:47:15 2009 Yeah. We should make things more regular, and readable. From: To: Time: Wed Jan 7 11:20:19 2009 apparently something broke the lib/kadm5 unit tests recently From: To: Time: Wed Jan 7 11:22:55 2009 trying to determine if it was the mskrb merge that did that From: To: Time: Wed Jan 7 11:30:44 2009 answer is "yes". oh great. From: To: Time: Wed Jan 7 11:31:46 2009 does make check in lib/kadm5/unit-test work for anyone? From: To: Time: Wed Jan 7 11:32:52 2009 It kind of blew up in several of the nightly testing runs last night. From: To: Time: Wed Jan 7 11:33:45 2009 i've confirmed that something in the mskrb merge made it blow up. not sure what yet; some sort of gss error in kadm5_init on the client side maybe. From: To: Time: Wed Jan 7 11:34:31 2009 However, it seems to do it in a way that doesn't cause the overall "make check" to fail. From: To: Time: Wed Jan 7 11:34:49 2009 that seems like a bug From: To: Time: Wed Jan 7 11:35:47 2009 runtest reports an error in the test, and goes on. It's not a failure detected by the test suite, I guess. From: To: Time: Wed Jan 7 11:36:36 2009 "make check" is actually failing on some (but not all) of the nightly testing systems. It does appear to be the same subset as is configured to have IPv6 addresses, so the machines passing the tests are all single-address systems. From: To: Time: Wed Jan 7 11:36:44 2009 right From: To: Time: Wed Jan 7 11:56:52 2009 Authentication attempt failed: 209.225.173.248, GSS-API error strings are: Unspecified GSS failure. Minor code may provide more information No matching key in entry GSS-API error strings complete. From: To: Time: Wed Jan 7 12:00:53 2009 We don't have a MS call today, do we? From: To: Time: Wed Jan 7 12:05:01 2009 Wow, someone's admitting publicly to running krb4. From: To: Time: Wed Jan 7 12:08:20 2009 looks like there is trouble with default-named services From: To: Time: Wed Jan 7 12:08:34 2009 null service principal names, that is From: To: Time: Wed Jan 7 12:11:22 2009 someone should fix up copyright notices, too. the merge blew away the oldest years on the copyrights in a lot of files. From: To: Time: Wed Jan 7 12:15:14 2009 What do you mean default service principals? From: To: Time: Wed Jan 7 12:15:42 2009 accept_sec_context using GSS_C_NO_NAME as acceptor From: To: Time: Wed Jan 7 12:17:10 2009 OK. do we have something in the tree that does that so I can go look at it? From: To: Time: Wed Jan 7 12:17:22 2009 kadmind From: To: Time: Wed Jan 7 12:17:43 2009 i'm getting test failures in lib/kadm5/unit-test that happen to not cause make check to fail From: To: Time: Wed Jan 7 12:19:01 2009 I thought kadmind had a long complicated set of calling accept_sec_context multiple times to deal with kadmin/host and kadmin/admin From: To: Time: Wed Jan 7 12:19:41 2009 no. that was for AUTH_GSSAPI (ovsec flavor), not AUTH_GSS (RPCSEC flavor). From: To: Time: Wed Jan 7 12:21:15 2009 i guess technically the problem might come from acquire_cred using GSS_C_NO_NAME From: To: Time: Wed Jan 7 12:21:19 2009 OK. So, it's only failing some of the time, right? From: To: Time: Wed Jan 7 12:21:47 2009 it's consistently failing where it fails, but some parts of that test suite pass. From: To: Time: Wed Jan 7 12:21:53 2009 And do the unit tests use a kdb keytab or do they specify a keytab? From: To: Time: Wed Jan 7 12:22:01 2009 kdb keytab, i think. From: To: Time: Wed Jan 7 12:22:32 2009 OK, that's mildly surprising. From: To: Time: Wed Jan 7 12:22:49 2009 The problem is almost certainly in rd_req_dec.c From: To: Time: Wed Jan 7 12:23:05 2009 That == using kdb keytab. I would be mildly surprised if we updated the tests From: To: Time: Wed Jan 7 12:23:37 2009 i imagine some of the tests go ahead and create a keytab that is then never used. From: To: Time: Wed Jan 7 12:24:53 2009 Does kadmind ignore the keytab if one is given to it? From: To: Time: Wed Jan 7 12:25:09 2009 Do the tests need updating? From: To: Time: Wed Jan 7 12:25:20 2009 i believe kadmind ignores the keytab if one is given. From: To: Time: Wed Jan 7 12:25:51 2009 it calls gss_register_acceptor_identity with the kdb keytab From: To: Time: Wed Jan 7 12:32:57 2009 Ah, the problem is that the kdb keytab returns a different error for no matching key found than the file keytab. So, do we want rd_req_dec to understand the kdb error or do we want our keytabs to be consistent? From: To: Time: Wed Jan 7 12:34:19 2009 They should probably be consistent. Not just file and kdb, but also memory and srvtab, if you haven't checked those. From: To: Time: Wed Jan 7 12:34:30 2009 s/probably// From: To: Time: Wed Jan 7 12:36:48 2009 Of course I'm failing to see how this code returns the error you're getting. From: To: Time: Wed Jan 7 12:37:27 2009 Unless somehow the kvno is wrong . Is this some failure case in the tests? From: To: Time: Wed Jan 7 12:37:47 2009 no i am fairly sure it's a case where it is supposed to succeed normally From: To: Time: Wed Jan 7 12:42:18 2009 OK. Can I get you to look at kdb_default.c for the return of KDB_NO_MATCHING_KEY? As I read that loop, you only get that if the kvno is not found, or the enctype or salt type is not found. IN the case where a key is not a cross-realm ticket, the kdb keytab seems to pass in -1 for enctype and salt type. So, I think the only thing that can cause this is if the kvno is wrong. From: To: Time: Wed Jan 7 12:42:57 2009 Are we sure that this is not an old auth_gssapi test case? From: To: Time: Wed Jan 7 12:43:27 2009 auth_gssapi stuff succeeds using the ovsec/admin service principal From: To: Time: Wed Jan 7 12:43:35 2009 as does auth_gss (RPCSEC) using kadmin/admin From: To: Time: Wed Jan 7 12:44:42 2009 Yes. Basically the only case I can see getting this error is if you pass in a service name to krb5_rd_req and that service exists but has a different kvno than the ticket actually has and you happen to be using the kdb keytab. From: To: Time: Wed Jan 7 12:45:29 2009 So, I'd expect this for example with auth_gssapi using a kadmin/admin ticket if the library tries ovsec_admin first and the kvno between kadmin/admin and ovsec_admin differ From: To: Time: Wed Jan 7 12:46:00 2009 why did it work before, then? From: To: Time: Wed Jan 7 12:49:34 2009 Because svc_auth_gssapi.c special cases krb5APP_ERR_WRONG_PRINC and uses that as a hint to try the next principal From: To: Time: Wed Jan 7 12:49:57 2009 Before the mskrb-integ merge, krb5_rd_req gave you that if ticket->server != the passed in server. From: To: Time: Wed Jan 7 12:50:22 2009 ok. so should we be doing something special with kvnos? From: To: Time: Wed Jan 7 12:50:35 2009 So, are you really sure that this is a GSS_C_NO_NAME case? Because if so, I have no clue what's going on From: To: Time: Wed Jan 7 12:51:19 2009 No, if we fix the kdb keytab code to return the write error all will be happy. I'm looking at the file keytab code to figure out what that is. From: To: Time: Wed Jan 7 12:56:39 2009 KRB5_KT_KVNONOTFOUND seems appropriate here From: To: Time: Wed Jan 7 12:56:59 2009 ok From: To: Time: Wed Jan 7 12:58:27 2009 Testing a patch From: To: Time: Wed Jan 7 12:58:38 2009 so this failure is in api.0/mod-policy.exp which runs immediately after api.0/init.exp, which toward its end deletes ovsec_adm/admin or ovsec_adm/changepw to verify that an error occurs; it then recreates them and re-extracts the (ignored) keytab. From: To: Time: Wed Jan 7 13:02:26 2009 What do you mean or? From: To: Time: Wed Jan 7 13:03:06 2009 there are two tests that do that sort of thing. one deletes ovsec_adm/admin and the other deletes ovsec_adm/changepw From: To: Time: Wed Jan 7 13:03:51 2009 Are both being called? From: To: Time: Wed Jan 7 13:04:02 2009 yes From: To: Time: Wed Jan 7 13:04:17 2009 I still don't understand how that would trigger this From: To: Time: Wed Jan 7 13:04:36 2009 Unless for example there is a lack of kinit or something From: To: Time: Wed Jan 7 13:05:06 2009 How will I know if this succeeds btw? From: To: Time: Wed Jan 7 13:05:32 2009 i will need to look at what this does where it succeeds. From: To: Time: Wed Jan 7 13:05:59 2009 does acquire_cred stash any knowledge of kvno etc away if called with explicit service name? From: To: Time: Wed Jan 7 13:07:57 2009 wait. it also might not be a GSS_C_NO_NAME case. i will have to check. From: To: Time: Wed Jan 7 13:14:34 2009 patch committed; let me know if it helps From: To: Time: Wed Jan 7 13:29:40 2009 lib/kadm5 client tests just passed for me From: To: Time: Wed Jan 7 13:29:55 2009 yeah, works for me now. thanks. From: To: Time: Wed Jan 7 13:30:03 2009 still not quite understanding why it's doing what it was doing. From: To: Time: Wed Jan 7 14:01:27 2009 Calling in to Apple conference... From: To: Time: Wed Jan 7 14:06:45 2009 I just saw a conference call report email. Did we have a MS call today after all then? Or was that something else? From: To: Time: Wed Jan 7 14:07:08 2009 we had a conf call with ms; it turned out to be mostly logistics. From: To: Time: Wed Jan 7 15:13:21 2009 The dejagnu tests run for quite a while if you're using valgrind. From: To: Time: Wed Jan 7 15:14:27 2009 not surprising From: To: Time: Wed Jan 7 15:16:15 2009 After we branch, I might be interested in comparing an individual test run with Ken to see why the tests (sans Valgrind) take so long for some people. From: To: Time: Wed Jan 7 15:17:19 2009 Yeah, I'd like to get that figured out. (And get my own test runs going a bit faster too.) From: To: Time: Wed Jan 7 15:17:27 2009 i think Ken said it might have something to do with the various waits to synchronize parts of the test. tail -f on the log files is a lousy way to do this but what else can you do? pidfiles might help though. From: To: Time: Wed Jan 7 15:18:27 2009 other parts of the test suite actually need to delay for fixed amounts of time because they test time-dependent things, but that's probably not what's going on here. From: To: Time: Wed Jan 7 15:21:52 2009 GNU tail on Linux sleeps a second at a time, and checks the file size on waking. I think some OSes give you file monitoring capabilities. Though GNU tail does have a --sleep-interval option... From: To: Time: Wed Jan 7 15:22:44 2009 AFAIK very little in our test suite is actually time-dependent. The iprop test comes to mind -- if you query for updates less than 10s(?) after a db change, the server tells you it's busy. From: To: Time: Wed Jan 7 15:22:44 2009 if you use a pidfile, is the convention to only write out the pidfile once you are ready to serve stuff? or do some daemons use it to lock out simultaneous invocations? From: To: Time: Wed Jan 7 15:22:59 2009 there are kadm5 tests that depend on expiration times From: To: Time: Wed Jan 7 15:23:05 2009 I'd guess the latter. From: To: Time: Wed Jan 7 15:23:13 2009 Oh, okay. From: To: Time: Wed Jan 7 15:23:36 2009 Too bad we can't run our tests in parallel. From: To: Time: Wed Jan 7 15:24:02 2009 because we need some facility for synchronization so tests don't fail spuriously due to the kdc not being ready yet. From: To: Time: Wed Jan 7 15:25:07 2009 maybe we should have a command line flag that prints "READY" to stdout or something when it is ready, and have the test suite wait for that. From: To: Time: Wed Jan 7 15:26:13 2009 Monitoring the log tells us when the KDC is ready, but we get the "tail -f" delays. I think we've got other daemons we fire up that don't give us such status; I've thought about some kind of READY message for them before. But I think that's only a few things under /appl. From: To: Time: Wed Jan 7 15:27:06 2009 what things do we actually need appl/bsd whatever programs to test, other than themselves? From: To: Time: Wed Jan 7 15:28:10 2009 You need to be able to get a root shell via rlogin to test some of the other applications (appl/gssftpd?) but nothing outside of appl, I believe. From: To: Time: Wed Jan 7 15:28:11 2009 Aside from login.krb5 being used by telnet, nothing AFAIK. From: To: Time: Wed Jan 7 15:28:18 2009 I think we use the OS rlogin for that. From: To: Time: Wed Jan 7 15:28:23 2009 or ssh From: To: Time: Wed Jan 7 15:28:35 2009 ftpd should be testable as a non-superuser i thought. From: To: Time: Wed Jan 7 15:28:57 2009 Might be thinking of telnet. From: To: Time: Wed Jan 7 15:29:50 2009 Yes, ftpd tests are non-root. Only telnet and rlogin tests require root. From: To: Time: Wed Jan 7 15:30:28 2009 How can I make those use ssh, by the way? From: To: Time: Wed Jan 7 15:30:51 2009 at the moment, you don't From: To: Time: Wed Jan 7 15:31:11 2009 I think something like RUNTESTFLAGS=RLOGIN=ssh might do it; you may need to pass in RLOGINFLAGS or whatever it's called as well. From: To: Time: Wed Jan 7 15:32:04 2009 RLOGIN_FLAGS From: To: Time: Wed Jan 7 15:32:19 2009 And you may need to add some new messages to watch for. From: To: Time: Wed Jan 7 15:34:17 2009 "You don't" is an acceptable answer; if it was easy, it would let me kill off my machine's rlogind service, is all. From: To: Time: Wed Jan 7 15:34:44 2009 test suite needs improvement in various ways From: To: Time: Wed Jan 7 15:37:18 2009 Give it a try. It might be easy. :) From: To: Time: Wed Jan 7 15:37:57 2009 And I think we probably should switch to trying ssh by default anyways; probably a lot of machines will run it and not rlogind. From: To: Time: Wed Jan 7 15:38:51 2009 (Though, we could also try ksu and sudo, if we get really excited about it.) From: To: Time: Wed Jan 7 15:39:33 2009 we should just abstract the idea of getting a root shell. From: To: Time: Wed Jan 7 15:40:05 2009 that's not an invitation to write some l33t exploit and check it into the test suite From: To: Time: Wed Jan 7 15:40:08 2009 Odd. There's something about how our "t_inetd" program works that causes valgrind to never finish the report. From: To: Time: Wed Jan 7 15:40:13 2009 Aww. :) From: To: Time: Wed Jan 7 15:40:23 2009 why are we bothering with inetd? From: To: Time: Wed Jan 7 15:42:45 2009 Looks like it's for launching the sample server, only. We could fix that. From: To: Time: Wed Jan 7 15:51:40 2009 oh. it's for simulating an inetd. From: To: Time: Wed Jan 7 15:56:59 2009 Yeah. All our other server programs have options for "listen for a connection on port X" so we don't need it. Though it might make our code cleaner to use t_inetd *more* and get that stuff out of the various server programs. (Then again, many of them should just be going away with the appl tree.) From: To: Time: Thu Jan 8 12:09:46 2009 has anyone experienced trouble getting kdb5_util stash to work, e.g. the message to krbcore we got last week or so? From: To: Time: Thu Jan 8 12:10:45 2009 I've found kdb5_util create -s to be much more reliable. I think his concern was simply that you have to already have a database to get kdb5_util stash to work From: To: Time: Thu Jan 8 12:10:55 2009 I think you may have to have a database first, so that it can verify the password. From: To: Time: Thu Jan 8 12:11:41 2009 yeah. it may also be that if your default realm isn't the realm of the database, you will have trouble. From: To: Time: Thu Jan 8 12:11:44 2009 Which is kind of weird when setting up a slave -- if you don't copy your real database over manually, you have to start by creating a false database and then throwing it away (by replacing it via kprop). From: To: Time: Thu Jan 8 12:12:10 2009 Oh, I could imagine that too, though there should be a command-line option to deal. From: To: Time: Thu Jan 8 12:12:47 2009 did it ever work to use kdb5_util load to initialize a database from a dump? From: To: Time: Thu Jan 8 12:20:25 2009 i know the lore is that kdb5_util create -s is more reliable; i'm mostly trying to track down the reasons why that lore exists, as it was almost certainly due to someone's frustrations with kdb5_util stash failing in some way. From: To: Time: Thu Jan 8 12:25:44 2009 For me, I'd rather come up with one password to forget than have to remember it for a few seconds. From: To: Time: Thu Jan 8 12:26:03 2009 heh From: To: Time: Thu Jan 8 12:27:42 2009 Maybe we need "kdb5_util unstash" that reads the stash file and tells you the password? From: To: Time: Thu Jan 8 12:28:14 2009 and how long will it take to run? From: To: Time: Thu Jan 8 12:28:50 2009 Depends how big your playstation cluster is. From: To: Time: Thu Jan 8 12:29:15 2009 that also sounds like it would need lots of configuration information about your playstation cluster From: To: Time: Thu Jan 8 12:29:51 2009 Well, sure, that's what krb5.conf is for. From: To: Time: Thu Jan 8 12:30:01 2009 Why do we have the nprincs and more abstraction? From: To: Time: Thu Jan 8 12:30:28 2009 baggage from ndbm, possibly. From: To: Time: Thu Jan 8 12:30:33 2009 I think the idea might have been that the "get principal" interface could do wildcard matching. From: To: Time: Thu Jan 8 12:30:44 2009 maybe that too From: To: Time: Thu Jan 8 12:31:10 2009 i suspect some dbm or ndbm implementations would let you store multiple values under a single key if you weren't careful From: To: Time: Thu Jan 8 12:32:15 2009 i think Berkeley DB also lets you do that but you have to ask it to let you do that. From: To: Time: Thu Jan 8 12:32:17 2009 Not as far as I recall. A relational DB certainly could. From: To: Time: Thu Jan 8 12:32:33 2009 O, and get_principal used to be a much thinner shim than it is now? But wait that doesn't really make sense: you still have to decode the entry in the kdb library. Someone has to have written code to make that work... From: To: Time: Thu Jan 8 12:33:50 2009 our entire KDB interface is a much thinner shim than it should be. From: To: Time: Thu Jan 8 12:34:17 2009 i think you would get the first record on the first query, and possibly subsequent queries would give you the additional records under that same key. From: To: Time: Thu Jan 8 12:36:42 2009 The nentries/more stuff goes back at least to our 1.0 release, but even then, "more" was always set to false, and "nentries" would be 0 or 1. (When reading, that is; the "nentries" argument to storing really was used to store multiple entries, each under its own name.) From: To: Time: Thu Jan 8 12:37:19 2009 oh. how odd. From: To: Time: Thu Jan 8 12:37:28 2009 And there's a comment "XXX deal with wildcard lookups" in the 1.0 sources. From: To: Time: Thu Jan 8 12:38:07 2009 Horror. So, someone actually wanted that interface. From: To: Time: Thu Jan 8 12:38:12 2009 So I think the intent was originally to support some kind of wildcard handling, but it was never developed beyond the pointless extra arguments up and down the call chain. From: To: Time: Thu Jan 8 12:39:24 2009 Reading kdc_util.c takes a couple of points of sanity. For example, if a client asks for forwardable and the KDC doesn't want to grant it, we return policy error rather than simply clearing the flag. I bet it really sucks if you set disallow_forwardable on a principal: I bet you basically can't log in. From: To: Time: Thu Jan 8 12:39:29 2009 (wikipedia says bdb supports multiple data items per key) From: To: Time: Thu Jan 8 12:39:53 2009 my recollection is you have to ask for it though (bdb) From: To: Time: Thu Jan 8 12:41:05 2009 And now I run across fetch_asn1_field. Which I knew about but had forgotten. From: To: Time: Thu Jan 8 12:41:25 2009 Although I wonder when we don't have the packet (and thus need the no packet code path) From: To: Time: Thu Jan 8 12:42:26 2009 Weird. Checking out the 1.0 tree just failed for me: A V1_0_RELEASE/src/util/db2/man/db_mpool.3 A V1_0_RELEASE/src/util/db2/man/db_recno.3 A V1_0_RELEASE/src/util/db2/man/db_lock.3 svn: In directory 'V1_0_RELEASE/src/util/db2' svn: Can't move source to dest svn: Can't move 'V1_0_RELEASE/src/util/db2/.svn/tmp/prop-base/CHANGELOG.svn-base' to 'V1_0_RELEASE/src/util/db2/.svn/prop-base/CHANGELOG.svn-base': No such file or directory From: To: Time: Thu Jan 8 12:43:15 2009 we did some ill-advised renaming in CVS that may have broken the SVN migration. From: To: Time: Thu Jan 8 12:44:30 2009 I bet there is a file and directory that differ only in case and Ken is using a mac From: To: Time: Thu Jan 8 12:44:33 2009 Ah. Hm. I would've hoped that it would break the continuity of the history, not the svn repository itself. From: To: Time: Thu Jan 8 12:44:41 2009 Oh, right... From: To: Time: Thu Jan 8 12:45:00 2009 oh. CHANGELOG vs ChangeLog, perhaps? From: To: Time: Thu Jan 8 12:45:41 2009 Perhaps, although I'd expect that to just give you a confusing result not an error. From: To: Time: Thu Jan 8 12:45:59 2009 Yeah. There's db2/ChangeLog and db2/CHANGELOG. From: To: Time: Thu Jan 8 12:46:19 2009 is someone keeping score of SVN vs krb5 for cryptic error messages? From: To: Time: Thu Jan 8 12:47:03 2009 If I check out into AFS, it works fine (but slowly). From: To: Time: Thu Jan 8 12:49:47 2009 Now, if you go back and check out alpha2 the cvs remaning will make your life a bit tricky. From: To: Time: Thu Jan 8 12:50:05 2009 Of course once you deal with that, you'll have to build an Imake configuration. From: To: Time: Thu Jan 8 12:57:22 2009 and then we switched to autoconf, which was all kinds of excitement. From: To: Time: Thu Jan 8 13:07:01 2009 does it strike anyone else as inefficient to have get_cred_from_kdc use the output of walk_realm_tree, which is a list of krbtgt/R2@R1 principals, when what it's going to do is mangle it into a list of realms? From: To: Time: Thu Jan 8 13:07:22 2009 Yep. From: To: Time: Thu Jan 8 13:07:56 2009 I'd guess it's another historical artifact -- early versions probably didn't try the shortcuts, so that sequence of principals was exactly what you'd be asking for. From: To: Time: Thu Jan 8 13:07:58 2009 not to mention it doesn't really tell you whether the transit path came from capaths or from hierarchical traversal... From: To: Time: Thu Jan 8 13:08:04 2009 that could be From: To: Time: Thu Jan 8 13:08:08 2009 Do you care? From: To: Time: Thu Jan 8 13:08:41 2009 i think there are times when you care From: To: Time: Thu Jan 8 13:08:46 2009 Such as? From: To: Time: Thu Jan 8 13:09:53 2009 if there are plausible but different capath and hierarchical path between two realms, and you have to confirm the validity of some referral. capath will mask the hierarchical. From: To: Time: Thu Jan 8 13:11:03 2009 When do you confirm the validity of a referral? From: To: Time: Thu Jan 8 13:11:04 2009 But if you've got capath configured, doesn't that imply that you want to use only that path (or, only realms along that path, not necessarily all of them)? From: To: Time: Thu Jan 8 13:11:53 2009 if a kdc gives you a shortcut realm referral, you want to see if that's on-path to determine whether to cache that TGT, for instance. From: To: Time: Thu Jan 8 13:12:27 2009 No, that is not consistent with our design. From: To: Time: Thu Jan 8 13:13:33 2009 If you are proposing a design change, you can do that, but I think it would be very poor to propose a change in something that security sensitive this late in the process. From: To: Time: Thu Jan 8 13:14:10 2009 However I believe we should only be caching things from the local KDC and the ultimate service ticket (which if the client is driving cross-realm will be a TGT) From: To: Time: Thu Jan 8 13:14:26 2009 According to the design we agreed to in the past. From: To: Time: Thu Jan 8 13:17:36 2009 i'm not so sure it's inconsistent with design, or inconsistent with implementation. From: To: Time: Thu Jan 8 13:19:07 2009 does -Wmissing-prototypes complain if you have a static function defined before all its uses but lacking a separate prototype declaration? From: To: Time: Thu Jan 8 13:22:56 2009 - 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 From: To: Time: Thu Jan 8 13:23:24 2009 I don't think a separate prototype is needed for static functions. From: To: Time: Thu Jan 8 13:24:24 2009 So, if you are actually using walk_rtree to drive what realm to contact, caching is OK. If the KDC gave you a referral, it is not. From: To: Time: Thu Jan 8 13:25:13 2009 I guess caching if the KDC gives you a shortcut that is within your walk_rtree is fine too. But I think that you do not need to distinguish between hierarchical and capaths. From: To: Time: Thu Jan 8 13:29:34 2009 Why was it we wanted not to cache in some cases? From: To: Time: Thu Jan 8 13:37:17 2009 cache poisoning concerns From: To: Time: Thu Jan 8 13:38:15 2009 When a client obtains a TGT that is 'closer' to the destination realm, the client MAY cache this ticket and reuse it in future KRB-TGS exchanges with services in the 'closer' realm. However, if the client were to obtain a TGT for the 'closer' realm by starting at the initial KDC rather than as part of obtaining another ticket, then a shorter path to the 'closer' realm might be used. This shorter path may be desirable because fewer intermediate KDCs would know the session key of the ticket involved. For this reason, clients SHOULD evaluate whether they trust the realms transited in obtaining the 'closer' ticket when making a decision to use the ticket in future. [from RFC 4120] So, basically it is a trust issue. I think that 4120 understates things somewhat in the referrals case. From: To: Time: Thu Jan 8 13:39:05 2009 You trust the client's KDC to tell you what realm a service lives in. however, when it gives you a referral it does not tell you what part of the namespace it is delegating trust for. So you have to be very careful in how much you are willing to assume it has delegated From: To: Time: Thu Jan 8 13:41:23 2009 --> lunch truck, back later From: To: Time: Thu Jan 8 14:02:58 2009 *munch*munch* From: To: Time: Thu Jan 8 14:03:16 2009 Our capaths documentation kind of sucks. From: To: Time: Thu Jan 8 14:04:31 2009 As I understand it, on the client you configure an ordered list of realms to (possibly) use on the way to a specific target realm. As opposed to saying, "if you want to get to realm X, first go to realm Y" and looking up Y separately. Yes? From: To: Time: Thu Jan 8 14:05:01 2009 it gives a path, not an unordered set of edges, i believe From: To: Time: Thu Jan 8 14:05:13 2009 Right. From: To: Time: Thu Jan 8 14:05:48 2009 that might even be justified From: To: Time: Thu Jan 8 14:07:23 2009 But then we've got the possibility that to get to realm A, you work out a hierarchical path that goes up to a common parent and then down through B to the target. And then to get to realm C, you get an explicitly configured path that takes you through B via some realm not on the hierarchical path. You've already got the cross-realm TGT for B, but perhaps C won't allow the parent realms to be in the transit path. From: To: Time: Thu Jan 8 14:08:16 2009 (And, maybe your local KDC doesn't know the preferred path to B, so it can't tell you the shortcut to use.) From: To: Time: Thu Jan 8 14:08:54 2009 So you need to store and check the transit path used to get the TGT for B, so that on the way to C you know not to use it. Or, you lose, I think. From: To: Time: Thu Jan 8 14:14:50 2009 Ken, that's all possible. We don't support it. And it seems fairly uncommon. From: To: Time: Thu Jan 8 14:17:12 2009 Yeah. I'm just skeptical of thinking that we've actually addressed the issue of what we can cache under whatever circumstances... From: To: Time: Thu Jan 8 14:20:37 2009 I think we've addressed it so that we will fail by under-caching or g getting into a situation where the server rejects us not a situation where we have allowed a realm to get itself onto our authentication path. From: To: Time: Thu Jan 8 14:20:54 2009 At least in the referrals case. I agree in the non-referrals case things are more complex From: To: Time: Thu Jan 8 14:21:04 2009 I think that's probably true, yes. From: To: Time: Thu Jan 8 14:58:16 2009 say you have a setup where you are client@A. you want to get to service/foo.c, which is actually in realm C but you ask your local kdc for service/foo.c@A. local kdc gives you krbtgt/B@A, so you ask realm B for service/foo.c@B, which then gives you krbtgt/C@B. finally you ask realm C for service/foo.c@C, which succeeds. obviously you cache krbtgt/B@A because it came from the local kdc and you trust that, but not krbtgt/C@B because it did not come from the local kdc. is there any reasonable way to determine (in a referrals universe) that it is safe to cache krbtgt/C@B? From: To: Time: Thu Jan 8 15:03:14 2009 Actually, I think it is safe to cache krbtgt/C@B, because in our current implementation you'll only use it again if you've decided that B is okay to use on the way to C (i.e., you don't look up krbtgt/C@*, you look up krbtgt/C@B), and there's no other transited realm to worry about. But extending it a bit further, you wouldn't want to cache krbtgt/D@C without also storing the transit list (B) and checking it when you're considering using that ticket. From: To: Time: Thu Jan 8 15:05:35 2009 Hm, wait a sec... From: To: Time: Thu Jan 8 15:07:19 2009 Why is it safe to cache krbtgt/C@B? From: To: Time: Thu Jan 8 15:08:20 2009 it's not clear that it is safe to cache krbtgt/C@B. From: To: Time: Thu Jan 8 15:08:25 2009 It's safe for host service referrals, but I'm not sure it is generally safe. Consider the case where A has a shared key with C but doesn't know that the service lives in C. It just knows B is closer. From: To: Time: Thu Jan 8 15:08:43 2009 Because you'd only use it out of the cache if you decided (either by local config or KDC referral) that you wanted krbtgt/C@B. From: To: Time: Thu Jan 8 15:08:51 2009 it *may* be that you could ask A for krbtgt/C@A and see if you get krbtgt/B@A in return. From: To: Time: Thu Jan 8 15:09:37 2009 Right, Sam, in your case, the KDC for A doesn't know that foo.c is in C, but when you ask for a ticket for some other host it does know is in C, it'll give you krbtgt/C@A and you won't use the cached ticket. From: To: Time: Thu Jan 8 15:09:45 2009 Right, but I believe that there are cases where you will look at krbtgt/x@* for any * From: To: Time: Thu Jan 8 15:10:11 2009 If there are, that's a different matter. I'm not aware of any, but I haven't looked for such a thing. From: To: Time: Thu Jan 8 15:10:36 2009 There certainly used to be. From: To: Time: Thu Jan 8 15:10:54 2009 Or at least behaviors I could not distinguish from that From: To: Time: Thu Jan 8 15:11:43 2009 TC_MATCH_SRV_NAMEONLY will be your doom, basically. From: To: Time: Thu Jan 8 15:12:32 2009 Ah. Hm, need to think about that. From: To: Time: Thu Jan 8 15:12:57 2009 we could rework the code that uses TC_MATCH_SRV_NAMEONLY but we would have to carefully specify what happens instead. From: To: Time: Thu Jan 8 15:14:05 2009 This sort of complexity is why I think we need to be careful to narrowly scope the problem we're trying to solve for 1.7 3 From: To: Time: Thu Jan 8 15:15:40 2009 "make it suck less" From: To: Time: Thu Jan 8 15:15:46 2009 At first glance, I don't see the one use I found of TC_MATCH_SRV_NAMEONLY checking that the found TGT was issued by a realm on the permitted transit list. If it's really not there, we've already got a problem. From: To: Time: Thu Jan 8 15:16:23 2009 gc_frm_kdc.c uses it to figure out whether there is already some way to get to the target realm. From: To: Time: Thu Jan 8 15:16:38 2009 Yeah, looking at that. From: To: Time: Thu Jan 8 15:16:54 2009 I think it's really not there and I don't understand why we have have a problem. Tom, I think in the time you have that is an overly broad scope From: To: Time: Thu Jan 8 15:17:40 2009 i have a collection of problem reports about people using our software as clients in an AD forest. i want to make them go away. From: To: Time: Thu Jan 8 15:18:33 2009 Well, if we never cache referrals TGTs and nobody runs "kvno krbtgt/TRUSTED.REALM@COMPROMISED.REALM", maybe there's no problem. From: To: Time: Thu Jan 8 15:19:12 2009 if we don't cache referral TGTs, it gets reported as a performance problem. From: To: Time: Thu Jan 8 15:21:18 2009 If we do cache them, and we follow a referral chain through a compromised realm, then I think we can get, for example, krbtgt/HOME@HOME, krbtgt/COMPROMISED@HOME, krbtgt/ATHENA@COMPROMISED, host/whatever@ATHENA. From: To: Time: Thu Jan 8 15:21:30 2009 (With the last two forged by the attacker of course.) From: To: Time: Thu Jan 8 15:22:42 2009 Then later if you look for krbtgt/ATHENA@* because you know host X is in the real ATHENA realm, you may use the fake TGT rather than fetching a safe krbtgt/ATHENA@HOME. From: To: Time: Thu Jan 8 15:23:32 2009 (The host "whatever" would need to be in the compromised realm or one accessed through it, and *not* in ATHENA, because then you wouldn't have used the compromised realm as an intermediary.) From: To: Time: Thu Jan 8 15:48:38 2009 I'm having trouble figuring out why you'd ever want to look for krbtgt/foo@*. From: To: Time: Thu Jan 8 15:50:29 2009 if you already know a service is in realm foo and want to find a tgt that gets you there From: To: Time: Thu Jan 8 15:52:13 2009 If your computed authentication path is A (starting point), B, C, D, E (destination), the slow way is to get krbtgt/B@A, tgt/C@B, tgt/D@C, etc. But maybe realm B has exchanged keys with E, so you can ask for tgt/E@B, or tgt/D@B, etc. Since any of these could be stored in your ccache, you can look for all of them in the cache. With our current implementation, it's probably an improvement performance-wise to look for all tgt/E@* in one pass and check the issuing realm. And without thinking about the security issues too much, you might code it to look for any tgt/E@* and not check the realm. Not sure if that's where we are... From: To: Time: Thu Jan 8 15:55:05 2009 I think even after looking at the security issues, if you are conservative in what you cache, then what we do is fine. From: To: Time: Thu Jan 8 15:57:31 2009 I wonder if there's a solution which involves better caching of referral responses. If you ask for host/foo@A and get back krbtgt/B@A, that response isn't really cached, right? That is, if the application asks for host/foo@A again, the library can't pick the previous answer out of the credentials cache. From: To: Time: Thu Jan 8 15:57:31 2009 As long as no one is stupidly running bad "kvno" commands to load their ccache with evil TGTs, I think you're right. But that probably means caching no TGTs other that those issued locally, or where you've decided on the authentication path yourself. From: To: Time: Thu Jan 8 15:57:37 2009 That's certainly out of scope for 1.7, though. From: To: Time: Thu Jan 8 16:01:20 2009 actually Greg it does cache host/foo@B and host/foo@A even though both refer to the ticket host/foo@B From: To: Time: Thu Jan 8 16:02:02 2009 and if your local realm is A, then krbtgt/B@A gets cached as well From: To: Time: Thu Jan 8 16:03:24 2009 Okay, so the overall answer is cached, but if I ask for host/bar@A and have to follow the same long chain of referrals to get there, will there be a cached entry which lets me pick up the chain at step 2? From: To: Time: Thu Jan 8 16:04:31 2009 if you don't know that host/bar@A is actually host/bar@B, you have to ask realm A (if that's your local realm) and get back a superfluous krbtgt/B@A (because you already have one cached) From: To: Time: Thu Jan 8 16:04:32 2009 If you're doing it with referrals, no; you have to go back to your local KDC to find out that you should be going to realm B, and you find out by getting back another TGT, so the cached one gives you no help in that case. From: To: Time: Thu Jan 8 16:04:51 2009 if you already know host/bar is actually in realm B, you just use the cross-realm tgt you already got From: To: Time: Thu Jan 8 16:05:12 2009 If you know bar is in realm B, then yes, you could use the cached TGT. But if you're computing the path yourself, you can do more caching than that, too, if you've got multiple hops. From: To: Time: Thu Jan 8 16:05:27 2009 yeah, what tom said (faster) :) From: To: Time: Thu Jan 8 16:08:06 2009 In the case I'm thinking of, host/foo and host/bar are actually in realm E or something. But thinking on it further, no amount of caching would help avoid the extra effort, since knowing where host/foo is doesn't help you know where host/bar is. From: To: Time: Thu Jan 8 16:09:45 2009 Right. Even if your local KDC knows both are in realm E, if the only cross-realm ticket it can give you is for B, it can't give you any more info. At least, not without, what, two or three of the extensions discussed at the IETF? From: To: Time: Thu Jan 8 16:26:27 2009 Has Luke's code been tested for interop with 1.6.x? It looks to me like the gssapi client will send and use a subkey; Larry says their experience was that the gss acceptor code in MIT's release ignores a subkey. I may have it wrong; haven't run tests yet. From: To: Time: Thu Jan 8 16:32:50 2009 i don't know if it has From: To: Time: Thu Jan 8 16:33:56 2009 Okay, I'll keep that on my list, maybe get to it tonight or tomorrow. From: To: Time: Fri Jan 9 11:46:35 2009 This is neat: http://www.cs.columbia.edu/~smb/papers/codebooks.pdf - "Compression, Correction, Confidentiality: A Look at Telegraph Codes" From: To: Time: Fri Jan 9 11:53:31 2009 Windows 7 beta available to public (first 2.5M downloaders)... http://technet.microsoft.com/en-us/evalcenter/dd353205.aspx From: To: Time: Fri Jan 9 11:53:49 2009 Not that you can get through. From: To: Time: Fri Jan 9 11:54:04 2009 Figures. Probably getting hammered pretty hard. From: To: Time: Fri Jan 9 11:54:39 2009 I'm trying to download the 64-bit en-US version and failing. From: To: Time: Fri Jan 9 13:35:34 2009 Wow... from Steve's paper, the 1920 ABC Telegraphic Code included code words to compress certain phrases into short easily-transmitted "words", though some of the phrases were pretty extreme: ENBET = "Captain is insane", PAASG = "Arrived here, encountered a severe gale and heavy seas, which carried away boats and wheel, stanchions and bulwarks, broke mast and jib-boom, all sails gone." Steve notes that the first, but not the second, was still present in the next edition in 1936. From: To: Time: Fri Jan 9 16:42:42 2009 We export krb5_rc_recover and krb5_rc_initialize, but not krb5_rc_recover_or_initialize. From: To: Time: Fri Jan 9 17:20:45 2009 according to which export list? From: To: Time: Fri Jan 9 17:41:51 2009 libtecla appears to use some unfortunate prefixes From: To: Time: Fri Jan 9 17:47:31 2009 This was the ss-with-line-editing patch? We should also look at some of the ss+editline stuff, unless it's bitrotted and tecla is the preferred way these days. (I've no idea...) From: To: Time: Fri Jan 9 17:47:52 2009 not sure. i thought GNU readline was more popular than tecla, too. From: To: Time: Fri Jan 9 17:48:02 2009 tecla has the advantage of being BSD-ish From: To: Time: Fri Jan 9 17:49:19 2009 Well, yes, the point of editline is getting the readline functionality (same API) without the GPL issues. So, you target editline with your patches, and, oh, look, it seems to work with readline too if you prefer. From: To: Time: Fri Jan 9 17:49:35 2009 What's "BSD-ish" about it? From: To: Time: Fri Jan 9 17:49:45 2009 er, tecla has a BSD-ish license. From: To: Time: Fri Jan 9 17:51:18 2009 though Love says that libsl (Heimdal) has a lot of interesting advantages. From: To: Time: Fri Jan 9 17:55:28 2009 It probably does; our ss lib has gotten no, er, love, in a lot of years. From: To: Time: Fri Jan 9 17:55:36 2009 heh From: To: Time: Fri Jan 9 17:55:59 2009 i think among other things libsl has some utilities that will generate manpages from the data structures, as well as usage messages etc. From: To: Time: Fri Jan 9 17:56:29 2009 so kind of a hybrid of libss, the afs command parsing library (libcmd?) plus self-documenting. From: To: Time: Fri Jan 9 17:59:08 2009 It's got built-in argument parsing, more sophisticated than "break words apart at whitespace"? From: To: Time: Fri Jan 9 18:11:55 2009 it appears to handle quoted strings, with backslash escapes even. From: To: Time: Fri Jan 9 18:14:05 2009 (and heimdal source files are almost universally not 7-bit clean, but whatever...) From: To: Time: Fri Jan 9 18:18:05 2009 actually, ss does as well, unfortunately just not with unix syntax From: To: Time: Fri Jan 9 18:18:28 2009 (handle quoted strings, that is, not backslash escapes) From: To: Time: Sun Jan 11 01:18:25 2009 postgres on krbdev crashed and restarted yesterday morning. i just had to restart apache now... From: To: Time: Sun Jan 11 02:06:04 2009 This room is not anonymous. From: To: Time: Mon Jan 12 12:57:28 2009 Ugh. There's got to be a way to avoid trying multiple decodes. From: To: Time: Mon Jan 12 12:58:48 2009 msft has finally decided to produce a hotfix for the broken Kerberos LSA support in the WOW64 environment on XP64 and Win2003-64 From: To: Time: Mon Jan 12 13:00:10 2009 This is the RPC endpoints can't talk to each other problem? Or rather the you can't call the LSA from a 32-bit app? From: To: Time: Mon Jan 12 13:00:26 2009 can't call LSA from 32-bit app From: To: Time: Mon Jan 12 13:00:55 2009 the reason for the is_broken_wow64() test in cc_mslsa.c From: To: Time: Mon Jan 12 13:01:32 2009 now the test needs to be modified to support hotfix detection and kfw re-issued From: To: Time: Mon Jan 12 13:04:24 2009 I think checking enctypes will often do it. If you're up-to-date enough to have acceptor-specified subkeys (which weren't supported in rfc 1964) then you're probably able to use AES. But, no, the RFC 1964 format doesn't tell you whether you're using the acceptor-supplied subkey, because RFC 1964 didn't support using it, and the update in RFC 4121 lets you use the acceptor-supplied subkey but doesn't give you a way to tell. From: To: Time: Mon Jan 12 13:05:25 2009 How about only sending back an acceptor supplied subkey if we plan on using cfx with it? From: To: Time: Mon Jan 12 13:06:33 2009 I thought about suggesting that, and it would probably work; we just generally try to get acceptor-supplied subkeys in for replay avoidance. Which, I guess, is already doomed to failure in this case because of prot-ready. From: To: Time: Mon Jan 12 13:07:25 2009 Well, no it's doomed to protocol knowledge. From: To: Time: Mon Jan 12 13:07:27 2009 (Also, note that we should not send an acceptor subkey if the initial enctype is old and enctype negotiation is not enabled.) From: To: Time: Mon Jan 12 13:07:36 2009 I.E. you need to know about the app protocol From: To: Time: Mon Jan 12 13:07:59 2009 I really wish that the enctype negotiation spec said you could assume CFX. From: To: Time: Mon Jan 12 13:08:27 2009 Sure. But in our implementation the library doesn't get that info. From: To: Time: Mon Jan 12 13:08:41 2009 I believe 4121 makes it clear that if you are using RFC4121 messages you can (SHOULD? MUST?) use an acceptor subkey. It is certainly clear that if you are using new enctypes you can assume RFC4121, but if you are not using new enctypes then you need to know a priori that the peer supports RFC4121. I believe the intent was that such knowledge would come from things like the application being a "new" application that explicitly specified use of RFC4121 in all cases. From: To: Time: Mon Jan 12 13:08:49 2009 Yeah, it would've been good. Pity some of these issues don't come up until we look at implementing. From: To: Time: Mon Jan 12 13:10:15 2009 That is why we have the distinction between Draft Standard and Proposed Standard. Unfortunately, changing the assumptions in an update sometimes breaks interop in unacceptable ways From: To: Time: Mon Jan 12 13:10:44 2009 The acceptor MAY assert a subkey, and if it does, "subsequent" messages MUST use it. But prot-ready and lack of message ordering requirements mean our library can't assume it without additional knowledge. From: To: Time: Mon Jan 12 13:11:18 2009 Generally I'd hope an application would specify the use of GSSAPI, not RFC 4121. From: To: Time: Mon Jan 12 13:13:10 2009 Yeah, I know. The problem is, if the app doesn't explicitly say that Kerberos must be 4121 or newer, then implementors won't take care that it's true, and you'll end up with a situation where a new app is linked against a 1964 library. I think the intent was that there would be very narrow cases, probably none of them IETF protocols, where it was reasonable to specifiy/assume 4121. From: To: Time: Mon Jan 12 13:14:26 2009 4121 has an answer to acceptor subkey po prot-ready, in the form of the AcceptorSubkey bit. From: To: Time: Mon Jan 12 13:14:59 2009 Which, I admit, is not great. From: To: Time: Mon Jan 12 13:16:37 2009 I think AcceptorSubkey would be fine, if it didn't also allow you to use 1964 format. From: To: Time: Mon Jan 12 13:16:53 2009 The problem is enctype nego that selects non-CFX.p What key do you use to unwrap initiator generated messages? From: To: Time: Mon Jan 12 13:18:21 2009 You use the acceptor subkey if the message has the AcceptorSubkey bit, and not if not. Obviously the bit won't be set in a 1964 message. The unwrapping is not hard. The hard part is, how do you know whether you can generate such a message, given that an acceptor's Kerberos may assert a subkey even when the acceptor's GSS-API is RFC1964 only. From: To: Time: Mon Jan 12 13:19:40 2009 I think it can be argued that 4121 allows the use of acceptor subkeys with 1964 format tokens. From: To: Time: Mon Jan 12 13:19:43 2009 Um, that's wrong. For example Windows will use acceptor subkey (but not generate) in some cases in non-cfx From: To: Time: Mon Jan 12 13:34:43 2009 Oh, hrm. That's unfortunate. From: To: Time: Mon Jan 12 13:43:36 2009 Ken, if you agree with my mail it would be great if you could say so so that Luke does not think he is being pulled in two different directions. If not, please state your concerns. From: To: Time: Mon Jan 12 13:46:30 2009 Thinking about it... will reply after lunch. From: To: Time: Mon Jan 12 13:46:49 2009 Sure. The goal is to try and get a reply say by 1530. From: To: Time: Mon Jan 12 14:04:50 2009 Can we do that (only send subkey if it's a "newer" type) cleanly with our library API? From: To: Time: Mon Jan 12 14:05:33 2009 No. I talk about that. We need to expand the auth context to tell you what subkey enctype it would generate From: To: Time: Mon Jan 12 14:06:25 2009 Also, one comment indicates that DCE_STYLE implies use of an acceptor subkey. Can we change that and not break compatibility? (Alternatively, we could send back the same key.) From: To: Time: Mon Jan 12 14:07:04 2009 O, hmm. DCE_STYLE could imply no prot_ready From: To: Time: Mon Jan 12 14:07:29 2009 Can we assume that for other implementations? From: To: Time: Mon Jan 12 14:07:57 2009 sam, what do you mean by "autoconf like?" From: To: Time: Mon Jan 12 14:08:40 2009 I assume he means, do a feature (well, bug) test at run time? From: To: Time: Mon Jan 12 14:08:58 2009 does anyone understand the problem? From: To: Time: Mon Jan 12 14:09:04 2009 other than Larry and myself From: To: Time: Mon Jan 12 14:09:34 2009 autoconf attempts to probe the current system to determine how it behaves rather than to rely on information about versions of software. I mean autoconf-like because autoconf is typically a build-time set of tests and we want to probe the running system not the SDK we're built against From: To: Time: Mon Jan 12 14:09:39 2009 If you call the Lsa functions from a 32-bit app on a 64-bit XP / 2003 system, the pointer you are given back is invalid From: To: Time: Mon Jan 12 14:09:47 2009 if you dereference it you crash From: To: Time: Mon Jan 12 14:09:56 2009 Ah. That would suck. From: To: Time: Mon Jan 12 14:10:38 2009 all of the other tests in cc_mslsa.c are performed using tests on the Lsa properties. We cannot do that for this bug. From: To: Time: Mon Jan 12 14:10:39 2009 Can you trap a bad pointer exception? If so, it seems like some KFW component could test for this at startup? When nim ran? and update a registry key From: To: Time: Mon Jan 12 14:11:41 2009 Or even better are their properties of the address you get back in the pointer that you could look at? I'm guessing no for this. From: To: Time: Mon Jan 12 14:11:48 2009 no From: To: Time: Mon Jan 12 14:12:14 2009 and the library is loaded by system processes prior to session startup From: To: Time: Mon Jan 12 14:13:21 2009 the installer can't do it because the hot fix when applied must be detected. From: To: Time: Mon Jan 12 14:14:53 2009 Jeff, would it be more correct to rephrase as it would be bad for the installer to do it, because 1) if the hotfix is applied later you wouldn't detect and 2) (not sure this is possible) if the hotfix is unapplied you would end up with a system crash From: To: Time: Mon Jan 12 14:15:44 2009 a hotfix can be uninistalled From: To: Time: Mon Jan 12 15:25:40 2009 does anyone think we need to diff deleted files in commit messages? From: To: Time: Mon Jan 12 15:30:09 2009 You mean, a diff which shows the entire contents of the file being deleted? I can't think of a good reason to do that. From: To: Time: Mon Jan 12 15:31:50 2009 No. From: To: Time: Mon Jan 12 15:38:45 2009 pjpark strikes again From: To: Time: Mon Jan 12 15:42:01 2009 ? From: To: Time: Mon Jan 12 15:42:37 2009 uh oh From: To: Time: Mon Jan 12 15:48:30 2009 As far as I can tell he added methods not part of GSSAPI V2 while "moving us to the v2 interface" back in 1995 From: To: Time: Mon Jan 12 15:49:07 2009 In particular gss_export_name_object From: To: Time: Mon Jan 12 15:49:55 2009 it is possible that there were some GSS-API v2 interfaces that did not make it into RFC From: To: Time: Mon Jan 12 15:52:24 2009 Looking at the 1.6 tree, I see that name in gssapi.hin, but nowhere else -- i.e., it's not actually defined. From: To: Time: Mon Jan 12 15:54:01 2009 Hm, wait, I think my 'find' invocation may be missing files... From: To: Time: Mon Jan 12 15:55:14 2009 I think you are correct. I'm creating a patch to restore that state. From: To: Time: Mon Jan 12 15:55:16 2009 Oh, wait, no, that file used a slightly different name. And it's certainly not in the 1.6 export list. From: To: Time: Mon Jan 12 15:57:50 2009 Try 'find ... -noleaf' ? From: To: Time: Mon Jan 12 16:01:20 2009 Good idea, I updated my script just to be safe. But the symbol really isn't defined. From: To: Time: Mon Jan 12 16:03:45 2009 If a session key (or generated subkey) is of the most-preferred enctype, is there a good reason for the client to do enctype negotiation? It'll only make a difference if the server's preference list has a different order, and the server chooses to impose its ordering over the client's. From: To: Time: Mon Jan 12 16:04:11 2009 No, there is not. From: To: Time: Mon Jan 12 16:04:47 2009 ==hartmans From: To: Time: Mon Jan 12 16:05:18 2009 Oh, hrm. Well, it might signal to the server that the client wants a subkey From: To: Time: Mon Jan 12 16:05:51 2009 But I think I'd have to think hard to contrive a situation where you'd want/need to signal that in that way From: To: Time: Mon Jan 12 16:26:09 2009 Okay, this doesn't look right... RFC 4537 says if the session key type is included in the client's list, it SHOULD be last. I don't think that means you should *swap* it with the last enctype in the list, which is what I'm seeing: make_etype_list: before: tkt_enctype=16 etypes: 18 17 16 23 1 3 2 after: etypes: 18 17 2 23 1 3 16 From: To: Time: Mon Jan 12 16:27:21 2009 I think the decls in gssapi.hin can probably go away, as we aren't supporting them. From: To: Time: Mon Jan 12 16:29:29 2009 Yeah, it might be better to trim the list at the client session key From: To: Time: Mon Jan 12 16:30:31 2009 yay. i have most of the components of RT ticket id pre-allocation working. now to just put them together... From: To: Time: Mon Jan 12 17:40:24 2009 yay. it works. From: To: Time: Mon Jan 12 17:42:06 2009 do people care about "RT-Ticket: foo" vs "Ticket: foo"? From: To: Time: Mon Jan 12 17:42:21 2009 no From: To: Time: Mon Jan 12 17:43:01 2009 What context? From: To: Time: Mon Jan 12 17:43:07 2009 log rewriting. From: To: Time: Mon Jan 12 17:43:38 2009 Meaning, we'd have to put in "rt-ticket: new" instead of "ticket: new"? From: To: Time: Mon Jan 12 17:44:54 2009 as in the rewrite will take "ticket: new" and turn it into "RT-Ticket: 9999" or something. From: To: Time: Mon Jan 12 17:45:09 2009 i suppose i could make it match whatever was input, with a little more tweaking. From: To: Time: Mon Jan 12 17:45:35 2009 Oh. Probably fine. Might look a little funny if "ticket: 123" goes through unchanged but "ticket: new" becomes "RT-Ticket: 123". But, whatever. From: To: Time: Mon Jan 12 17:49:17 2009 ok, fixed. From: To: Time: Mon Jan 12 17:50:31 2009 Looks good, thanks... From: To: Time: Mon Jan 12 18:04:42 2009 and i made a small-ish hole in the ticket id number space in the course of chasing down another bug, but nobody probably cares. From: To: Time: Mon Jan 12 18:05:40 2009 i wonder how many people i have annoyed with this testing From: To: Time: Mon Jan 12 18:07:39 2009 Eh. They're welcome to remove themselves from the list. From: To: Time: Mon Jan 12 18:48:44 2009 the hotfix provided by msft doesn't actually implement the required functionality, it just causes the functions to return ERROR_NOT_SUPPORTED when attempting to read ticket data From: To: Time: Mon Jan 12 18:51:02 2009 So, not really helpful, then? And no new kfw release needed for it? From: To: Time: Mon Jan 12 18:51:22 2009 not until msft actually implements the functionality. I don't see the point From: To: Time: Mon Jan 12 18:57:25 2009 Oh, so it should be fairly easy to detect, yes? From: To: Time: Mon Jan 12 18:57:53 2009 to detect what? From: To: Time: Mon Jan 12 18:58:22 2009 The hotfix. But I gather there's no point. From: To: Time: Mon Jan 12 19:00:41 2009 SP2 and earlier behavior is to return success but give you garbage output. The hotfix behavior is to return not supported and no garbage. From: To: Time: Mon Jan 12 19:01:07 2009 what we want is success and real data From: To: Time: Mon Jan 12 19:09:00 2009 yeah, I got that From: To: Time: Sun Jan 18 02:02:55 2009 This room is not anonymous. From: To: Time: Tue Jan 20 15:42:08 2009 I now have a hotfix from msft that permits tickets to be read from the wow64 environment on xp-64/2003-64. nothing that can be publicly released yet but it should be in the back of people's minds that a new kfw release should come in the next month or so From: To: Time: Tue Jan 20 17:29:53 2009 what the...? blank lines in code should not consist of 124 spaces. From: To: Time: Tue Jan 20 17:56:41 2009 people are seeing serious slowness with svn.mit.edu right now. It's taking me >7m to check in a file with svk, and still counting... From: To: Time: Tue Jan 20 17:57:02 2009 people on other repositories? From: To: Time: Tue Jan 20 17:57:20 2009 Yeah, some of the isda folks. From: To: Time: Tue Jan 20 18:37:05 2009 I sent some question on fast to ietf-krb-wg. It would be good to get closure in the next day or two. From: To: Time: Tue Jan 20 18:37:18 2009 btw, svn.mit.edu problems are fixed From: To: Time: Tue Jan 20 18:37:45 2009 Okay, will try to look soon. From: To: Time: Wed Jan 21 13:36:29 2009 today's conf calls are in w92=212 "aquarium" due to conflict in scheduling From: To: Time: Thu Jan 22 15:06:58 2009 Urgh. Coverity defect 1141 is Just Plain Wrong, in a really obvious way. (That is, Coverity is wrong, not the code.) From: To: Time: Thu Jan 22 15:07:17 2009 what is the coverity port number again? From: To: Time: Thu Jan 22 15:08:16 2009 https://krbdev.mit.edu:60000/ From: To: Time: Thu Jan 22 15:10:46 2009 I think it can be shut up by initializing *out to NULL in make_too_big_error, which we may decide is good practice anyway. From: To: Time: Thu Jan 22 15:11:51 2009 yeah coverity's dataflow analysis is kind of disappointing From: To: Time: Thu Jan 22 15:13:04 2009 I think it's not correctly concluding that make_too_big_error will change the value of reply whenever it returns 0. (It's smart enough to associate constant-value returns with actions in some cases, but I guess not this one.) From: To: Time: Thu Jan 22 15:16:41 2009 1140 and 1141 also appear to be identical, which is odd. From: To: Time: Thu Jan 22 15:16:42 2009 I think a lot of our "change *ptr iff returning 0" cases are too much for it to handle. It might be worth playing around a bit to see if there's some simple form of that that it will understand, and figure out if it's worth restructuring some of our routines in that style as needed to make it happy. (It might be as simple as "assert(retval != 0)" in a common error-return path or something.) From: To: Time: Thu Jan 22 15:17:12 2009 No, 1141 is about response->data, 1140 is about response itself. From: To: Time: Thu Jan 22 15:18:00 2009 Ah, I see. From: To: Time: Thu Jan 22 17:53:55 2009 Is there a good reason the KDC should default supported_enctypes to des3:normal and des-crc:normal, no aes or rc4? From: To: Time: Thu Jan 22 17:54:13 2009 no. where is that default? From: To: Time: Thu Jan 22 17:54:23 2009 alt_prof.c From: To: Time: Thu Jan 22 17:54:43 2009 line 698 From: To: Time: Thu Jan 22 17:54:54 2009 buried in the code that looks up supported_enctypes in the config file From: To: Time: Thu Jan 22 17:55:36 2009 ick. 321 lines. From: To: Time: Thu Jan 22 17:57:21 2009 Ah. I removed AES for 1.3, with the comment: Until all services including GSS-based ones can support AES, we don't want it in the default supported enctypes list on the KDC. From: To: Time: Thu Jan 22 17:57:40 2009 oh From: To: Time: Thu Jan 22 18:22:20 2009 whitespace smacked about From: To: Time: Thu Jan 22 18:23:29 2009 Good, it deserved it. It's really been getting out of line lately. From: To: Time: Thu Jan 22 18:23:54 2009 well mostly the stuff that had already been tagged with indent-tabs-mode:nil but had regained tabs From: To: Time: Thu Jan 22 18:26:55 2009 We could use a before-save-hook for checking for tabs in those files (for initial indentation or otherwise). Though, once we go that far, we could also tackle trailing whitespace on lines, misc stuff like that. From: To: Time: Thu Jan 22 18:28:07 2009 oh great. i forgot the trailing whitespace. From: To: Time: Thu Jan 22 18:28:33 2009 :) From: To: Time: Thu Jan 22 18:30:54 2009 Emacs 23 (dunno about 22) has a "whitespace" package that includes "whitespace-cleanup", which can do lots of stuff like killing trailing whitespace, fixing indentation whitespace, change tab+spaces to one or the other, etc. From: To: Time: Thu Jan 22 18:31:02 2009 it's quite old actually From: To: Time: Thu Jan 22 18:31:09 2009 even emacs21 has it From: To: Time: Thu Jan 22 18:31:43 2009 Ah, good. Then maybe we should update our emacs-user notes to suggest it. Or something. From: To: Time: Thu Jan 22 18:32:01 2009 what emacs-user notes? :-) From: To: Time: Thu Jan 22 18:32:30 2009 The stuff buried in our coding-style guidelines. Or did you delete it when I wasn't looking? From: To: Time: Thu Jan 22 18:32:41 2009 no, i think it's still there From: To: Time: Thu Jan 22 19:30:17 2009 coverity #1150 I *think* is the tool being confused about mk_req_extended writing an output value. From: To: Time: Thu Jan 22 19:30:42 2009 #1151 is my bad... I saw the compiler giving some warnings about it too. will fix... From: To: Time: Fri Jan 23 13:14:50 2009 So, do we actually define constants to be used when initializing magic fields in structures? From: To: Time: Fri Jan 23 13:15:15 2009 Did this concept never actually go any further than "throw magic fields into all of the structure definitions"? From: To: Time: Fri Jan 23 13:15:16 2009 Yeah, through the "kv5m" error table, of all things. The messages are "bad magic number in...." From: To: Time: Fri Jan 23 13:15:18 2009 yes. these constants come from com_err tables. From: To: Time: Fri Jan 23 13:15:23 2009 Aha. From: To: Time: Fri Jan 23 13:15:40 2009 I think the serializer code looks at the magic number to decide which decoder to pass off the void* to. From: To: Time: Fri Jan 23 13:15:41 2009 so the "bad magic number" error corresponds to the magic number that should have been there. From: To: Time: Fri Jan 23 13:15:46 2009 Er, encoder. From: To: Time: Fri Jan 23 13:16:34 2009 So if anything wants to check magic numbers, you compare foo->magic against KV5M_FOO, and if they don't match, you return KV5M_FOO. Kind of weird. But I guess it works. From: To: Time: Fri Jan 23 13:21:24 2009 or would kind of work if we actually were consistent about it. From: To: Time: Fri Jan 23 13:21:48 2009 Well, yeah. From: To: Time: Fri Jan 23 14:10:04 2009 Hm, Coverity defect #1128 seems to happen because Coverity can't see that decode_krb5_ap_req doesn't allocate its output parameter if it doesn't return 0. decode_krb5_ap_req is macro-obscured but it seems relatively straightforward in that respect. I'm not immediately sure how to work around that. From: To: Time: Fri Jan 23 14:23:10 2009 Cogitating a bit, I think the best workaround is to avoid the pattern "*ret = malloc(blah); if (error) { free(*ret); *ret = NULL; }". It may be a little difficult to change the decode routines to avoid that, but in this case I don't think it's too hard. From: To: Time: Fri Jan 23 14:25:46 2009 #1128 in run 105? From: To: Time: Fri Jan 23 14:26:43 2009 Pretty sure they are independent of run number. From: To: Time: Fri Jan 23 14:28:15 2009 but what is happening there looks more like the error handling code is doing the free. why doesn't it see that? From: To: Time: Fri Jan 23 16:40:18 2009 Yeah, in one database/product, the defect numbers should be consistent across runs if the defect is still there. So in one run you can mark it as not a real problem, and it should stay marked for addition runs, as I understand it. From: To: Time: Fri Jan 23 17:19:55 2009 there are an awful lot of tickets in "review" state. From: To: Time: Fri Jan 23 17:23:38 2009 i have been resolving some of them, but it's kind of slow work From: To: Time: Sun Jan 25 02:02:28 2009 This room is not anonymous. From: To: Time: Mon Jan 26 14:38:56 2009 Hi! Luke suggested the replacing strncpy by strlcpy in the code that he has reviewed for me. One can see that we use more often calls to the first one than to strlcpy. Some would say that it is safer approach. Others would argue that it is not standard and not always portable. What should be our policy with regard this issue, i.e. Do we want to replace all strncpy's by strlcpy's? From: To: Time: Mon Jan 26 14:39:46 2009 I think that's what Greg has been doing. We've got a local implementation of strlcpy in case the OS doesn't provide it. From: To: Time: Mon Jan 26 14:41:00 2009 I haven't actively replaced strncpy/strncat, but it's our policy (as written by me, a month or two ago) to prefer strlcpy/strlcat because they have better APIs. We have machinery to handle the portability issues. From: To: Time: Mon Jan 26 14:41:23 2009 Oh, just strcpy/strcat were replaced? From: To: Time: Mon Jan 26 14:41:27 2009 http://k5wiki.kerberos.org/wiki/Coding_style/Practices#String_Handling From: To: Time: Mon Jan 26 14:41:37 2009 So far, yes. From: To: Time: Mon Jan 26 14:41:39 2009 coding style page doesn't explicitly call out strncpy, i think From: To: Time: Mon Jan 26 14:56:21 2009 "coding style page doesn't explicitly call out strncpy" ... So, do I break the rules by using strncpy? From: To: Time: Mon Jan 26 14:57:09 2009 there is as yet no wholesale conversion of strncpy to strlcpy, but now is a good a time as any to start using it. From: To: Time: Mon Jan 26 14:59:05 2009 The rules don't explicitly prohibit strncpy/strncat, but do say to use strlcpy/strlcat for simple copy operations. From: To: Time: Mon Jan 26 14:59:34 2009 I didn't do a wholesale replacement because strncpy/strncat weren't posing an active problem (they aren't flagged by audit software), so they're more of an aesthetic issue. From: To: Time: Mon Jan 26 15:00:13 2009 strncpy/strncat are somewhat less preferred because there are situations where they can leave a string unterminated. From: To: Time: Mon Jan 26 15:09:17 2009 On Will's suggestion, I just added an attachandrun script "svn" to the krbdev locker for linux, to do the fairly obvious thing. So "add krbdev" should be all he needs to do... Does this seem like a problem to anyone? From: To: Time: Mon Jan 26 15:09:53 2009 What machine is he using? From: To: Time: Mon Jan 26 15:10:05 2009 My office linux machine. From: To: Time: Mon Jan 26 15:10:07 2009 In the master key migration branch: get_key_data_kvno should have a namespace prefix, shouldn't it? From: To: Time: Mon Jan 26 15:10:35 2009 is it being exported? From: To: Time: Mon Jan 26 15:10:57 2009 I'd argue it doesn't really matter whether it is being exported. If it is non-static, yes From: To: Time: Mon Jan 26 15:11:02 2009 I noticed that. It probably should, but it's a library that's entirely non-public, so it doesn't seem that urgent. Feel free to fix it, though, or suggest it to Will. From: To: Time: Mon Jan 26 15:11:23 2009 If you build on Solaris, yes, it's exported. :-) From: To: Time: Mon Jan 26 15:12:20 2009 It's used by kdb5_util. From: To: Time: Mon Jan 26 15:12:23 2009 right. if it's not static, it needs namespace prefix From: To: Time: Mon Jan 26 15:12:52 2009 But we don't expect people to be linking things against the kdb library, or whichever it was... From: To: Time: Mon Jan 26 15:13:15 2009 I'd be happy to fix it myself but I think I'll suggest it to Will to avoid giving him merge headaches. From: To: Time: Mon Jan 26 15:19:49 2009 Do we have an Apple call this week? Andrew Yu's presentation on mobile devices overlaps with it. From: To: Time: Mon Jan 26 15:21:40 2009 no word on whether we will have one yet. From: To: Time: Mon Jan 26 15:29:41 2009 Ken, did you have trouble building the branch because libkdb5 isn't symlinked into lib, causing test programs to fail to link? (Preexisting issue.) From: To: Time: Mon Jan 26 15:30:41 2009 i'm getting mkey_migrate branch to build on Darwin. From: To: Time: Mon Jan 26 15:31:22 2009 No, I saw no problems like that. From: To: Time: Mon Jan 26 15:31:44 2009 I hope that doesn't mean it linked against something else instead. From: To: Time: Mon Jan 26 15:32:30 2009 I am getting lib/libkdb5.* symlinks, actually. From: To: Time: Mon Jan 26 15:32:45 2009 (on linux at least) From: To: Time: Mon Jan 26 15:32:59 2009 (and mac) From: To: Time: Mon Jan 26 15:33:20 2009 Oh, I am too, I just didn't see them (?). So my problem is somewhere else. From: To: Time: Mon Jan 26 15:33:35 2009 which test programs? From: To: Time: Mon Jan 26 15:34:51 2009 lib/kadm5/unit-test/init-test. Problem seems to be that it isn't specifying -lkdb5 on the link line. From: To: Time: Mon Jan 26 15:35:15 2009 Hm, but it shouldn't have to. From: To: Time: Mon Jan 26 15:35:30 2009 was it working without it previously? From: To: Time: Mon Jan 26 15:38:53 2009 On trunk, libkadm5clnt doesn't depend on libkdb5. On the branch, it does. From: To: Time: Mon Jan 26 15:39:28 2009 Why does it on the branch? That seems kind of odd and undesirable From: To: Time: Mon Jan 26 15:39:38 2009 On my machine, "gcc -L../../../lib -lfoo -lbar -lbaz" is pulling in dependencies of foo, bar, and baz from /usr/lib (or the library's run path) instead of ../../../lib. From: To: Time: Mon Jan 26 15:39:50 2009 It probably breaks any kind of lite client support, yes. From: To: Time: Mon Jan 26 15:40:40 2009 Yeah, if that's a real dependency, it's a bug. From: To: Time: Mon Jan 26 15:41:03 2009 It's for krb5_free_key_data_contents. From: To: Time: Mon Jan 26 15:42:52 2009 I didn't realize the client library needed it. Maybe it does need to go back into libkrb5. Or get duplicated, but, ick. From: To: Time: Mon Jan 26 15:43:00 2009 where is the "right" place for it? From: To: Time: Mon Jan 26 15:45:54 2009 key_data is a kdb thing not a libkrb5 thing, so it might need to go into kadm5 From: To: Time: Mon Jan 26 15:46:22 2009 basically libkadm5clnt can use structures out of kdb.h but does not depend on libkdb From: To: Time: Mon Jan 26 15:46:36 2009 Except both libkdb and libkadm5* seem to want it. From: To: Time: Mon Jan 26 15:47:05 2009 ok that sucks a lot From: To: Time: Mon Jan 26 15:49:27 2009 hey this is will From: To: Time: Mon Jan 26 15:49:33 2009 hi From: To: Time: Mon Jan 26 15:50:03 2009 and yes, in order to get things to compile I added the -lkdb5 dependency for kadmt5clnt From: To: Time: Mon Jan 26 15:50:41 2009 of course I could just duplicate the krb5_free_data_contents() found in the kadm code in kdb5.c From: To: Time: Mon Jan 26 15:50:48 2009 but I was hoping to avoid this From: To: Time: Mon Jan 26 15:52:45 2009 it's suboptimal, but i think what we should do here is duplicate the code for now and file a bug indicating that we need to fix it. From: To: Time: Mon Jan 26 15:53:25 2009 ok. Actually, let me look at something quickly From: To: Time: Mon Jan 26 15:55:05 2009 ok, I'll restore the kadmin version of the free func and make the one in kdb5.c private From: To: Time: Mon Jan 26 15:55:08 2009 easy enough From: To: Time: Mon Jan 26 15:55:50 2009 perhaps the eventual correct solution is making yet another library From: To: Time: Mon Jan 26 15:57:50 2009 wouldn't surprise me. currenlty there is a twisty maze of dependencies that all look alike 8^) From: To: Time: Mon Jan 26 15:58:17 2009 What's wrong with sticking it in krb5? Or rather why isn't that less wrong? From: To: Time: Mon Jan 26 15:58:21 2009 (to quote Zork if I'm not mistaken) From: To: Time: Mon Jan 26 15:58:23 2009 wait we should not be multiplying the number of libraries. combining the kadm5 and kdb functionalities might be the correct thing. From: To: Time: Mon Jan 26 15:58:49 2009 we could stick it in libkrb5 but is there anything in there that needs kdb.h? From: To: Time: Mon Jan 26 15:59:39 2009 Yeah, k5-int.h already includes kdb.h From: To: Time: Mon Jan 26 15:59:39 2009 A couple of things, yes. From: To: Time: Mon Jan 26 15:59:54 2009 Uh, k5-int.h shouldn't include kdb.h. From: To: Time: Mon Jan 26 15:59:57 2009 oh. it's worse than i thought. From: To: Time: Mon Jan 26 16:00:38 2009 yeah, I had added kdb.h to k5-int.h but I removed that recently at Ken's request in his review comments From: To: Time: Mon Jan 26 16:00:38 2009 And in my copy, it looks like it doesn't. (It did briefly on Will's branch, but I think that's fixed.) From: To: Time: Mon Jan 26 16:01:09 2009 BTW, I did a commit today with addressed a number of Ken's review comments From: To: Time: Mon Jan 26 16:01:24 2009 including the kdb.h in k5-int.h issue From: To: Time: Mon Jan 26 16:01:33 2009 whatever file implements the kdb.h stuff should explicitly include kdb.h. From: To: Time: Mon Jan 26 16:02:22 2009 unrelatedly, i'm currently looking at implementing something like Heimdal's "allow_weak_crypto" libdefault to disable DES From: To: Time: Mon Jan 26 16:05:31 2009 That might be simpler than doing all the "DEFAULT - foo" stuff. From: To: Time: Mon Jan 26 16:06:03 2009 it is easier, but we should do the inclusion/exclusion stuff at a later time too. From: To: Time: Mon Jan 26 16:06:29 2009 mostly i realized that the OpenSSL syntax was actually kind of hairy and we need to decide if we want to support anything nearly that complicated. From: To: Time: Mon Jan 26 16:26:49 2009 I wonder if update_princ_encryption (which I'm just starting to look at implementing) should (someday) take a minimum master-key version number, allowing all newer mkey versions to keep being used. It would reduce the database changes being done (and propagated) at one time. But it requires a use case where you want to expire old master keys but don't mind keeping multiple others that may have been around a while. I'm not sure that's useful at all... From: To: Time: Mon Jan 26 16:27:15 2009 And, it's not part of the current proposal. So, time to write code in parallel with idle wondering. From: To: Time: Mon Jan 26 16:28:24 2009 I'm a little clear on how you use that function. Wouldn't it invalidate every keytab in the database? From: To: Time: Mon Jan 26 16:28:55 2009 No, it's just changing which master key is used to encrypt the key data in each database entry, so that you can purge old versions of the master key. From: To: Time: Mon Jan 26 16:29:09 2009 Oh, right, of course. From: To: Time: Mon Jan 26 16:30:18 2009 So, generally speaking, master key migration would be a pretty quick process, right? Just long enough to propagate the new key to slaves? From: To: Time: Mon Jan 26 16:31:48 2009 Well, introducing a new master key is easy and quick. update_princ_encryption over the whole database could be a pretty long process. And purging an old one requires scanning principals to verify that it's not in use. From: To: Time: Mon Jan 26 16:32:21 2009 Actually, as it's written up, "kdb5_util purge_mkeys" would scan the database to figure out which ones are in use, and delete the unused ones. From: To: Time: Mon Jan 26 16:33:33 2009 I guess "quick" in the sense that the only deployment issue is the mkey stash files on the slaves. The rest is done at the speed of computing and not at the speed of people. From: To: Time: Mon Jan 26 16:35:15 2009 Actually, the mechanism is set up so that the local stash file can list *any* of the master keys still in the database, and the database includes the current one encoded in each of the older ones. So the stash files only have to be updated sometime before purging the listed master key. And there's a kdb5_util for doing that update. From: To: Time: Mon Jan 26 16:36:27 2009 If we had some fancy replicated database system that knew about all instances of the database, we might even be able to automate some of that somehow. But currently, checking that the stash files are sufficiently up-to-date will be a manual process... From: To: Time: Mon Jan 26 16:49:21 2009 ok, I"ve commited the changes to remove the -lkdb5 dependency I added to kadm5clnt From: To: Time: Mon Jan 26 16:50:39 2009 Thanks. Oh, I should have noted here that I changed my mind and decided to namespace-protect get_key_data_kvno myself. From: To: Time: Mon Jan 26 16:51:02 2009 that's cool. I figured it out From: To: Time: Mon Jan 26 16:51:06 2009 no problems From: To: Time: Mon Jan 26 16:51:22 2009 and there weren't any conflicts so it was easy From: To: Time: Mon Jan 26 17:36:28 2009 if i'm going to add a "weak" flag to the enctype structure, should it be a flags word, a bit field, etc.? From: To: Time: Mon Jan 26 18:23:46 2009 What do you plan to do with it? From: To: Time: Mon Jan 26 18:24:30 2009 to allow things like disabling single-DES From: To: Time: Mon Jan 26 18:24:43 2009 Add an option to enable/disable weak crypto. From: To: Time: Mon Jan 26 18:25:20 2009 I assume cryptosystems currently marked strong may become weak in the future if they are broken or their key size stops being big enough? From: To: Time: Mon Jan 26 18:25:39 2009 yes From: To: Time: Mon Jan 26 18:26:22 2009 I would do that that way. I'd use permitted_enctypes and perhaps add a weak_enctypes config file variable that defaulted to something and that was subtracted from permitted_enctypes From: To: Time: Mon Jan 26 18:27:47 2009 there would be a config file variable that enables weak enctypes. the flag is to allow that config variable to function From: To: Time: Mon Jan 26 18:32:13 2009 for now i'm planning to align with Heimdal's config variable, which is "allow_weak_crypto". in the future, we could add a general mechanism for including/excluding enctypes in the config file. From: To: Time: Mon Jan 26 18:35:10 2009 also, permitted_enctypes isn't used anywhere nearly enough places From: To: Time: Mon Jan 26 18:44:54 2009 I think it is used in most of the places that it needs to be. My issue is that I think what enctypes are weak is probably a matter for site configuration more than a matter for an enctype structure. Also, doing it all with config file variables would be more in alignment with everything else we do. From: To: Time: Mon Jan 26 18:45:56 2009 granted. and i am planning for us to enable that level of site configuration, just not necessarily on the 1.7 timeline. From: To: Time: Mon Jan 26 18:46:34 2009 but i need to leave now From: To: Time: Mon Jan 26 18:47:11 2009 OK. We can discuss as part of the project review From: To: Time: Tue Jan 27 16:12:19 2009 I'm hoping that is overly specific config files in tests. From: To: Time: Tue Jan 27 16:12:37 2009 it has to do with "v1" kadmin protocol From: To: Time: Tue Jan 27 16:30:54 2009 /* Version 1 clients will expect to see a DES_CRC enctype. */ From: To: Time: Tue Jan 27 16:31:48 2009 v1 must die From: To: Time: Tue Jan 27 16:41:40 2009 Oh, yeah, I forgot to mention in the meeting... we're going to have to make sure we update documentation for Will's changes -- i.e., for the specific commands, not just the overall rollover process. From: To: Time: Tue Jan 27 16:41:51 2009 yeah From: To: Time: Tue Jan 27 16:42:10 2009 anyway re-enabling weak crypto makes the tests pass From: To: Time: Tue Jan 27 16:44:07 2009 Ooohh: *JOINT CIS/MICROSOFT TALK- AT MIT * *Open To The Public * /Date/: * Friday, Feb 6, 2009 * /Time/: * 10:30 am - 12:00 pm * /Place/: *32-G449 (Kiva), Stata Center, 32 Vassar Street* /Title/: *Key Agreement from Close Secrets over Unsecured Channels * /Speaker/: *Bhavana Kanukurthi, Boston University * The specific example given in the abstract is biometric data. They're proposing a protocol that runs in "only a few seconds on consumer-grade computers". From: To: Time: Tue Jan 27 16:44:56 2009 Ah, paper is online at http://eprint.iacr.org/2008/494 . From: To: Time: Tue Jan 27 16:48:18 2009 In their sample test on a LAN with 2.4GHz PCs, ~1.5s spent by each party on computation, and ~1s in communication, totaling under 5s. A bit resource-intensive for a KDC, but still worth keeping an eye on. From: To: Time: Tue Jan 27 17:05:15 2009 i could have sworn that i had lib/rpc/unit-test working on Darwin but it's failing for me now. is there some portmapper tweaking i have forgotten? From: To: Time: Tue Jan 27 17:10:20 2009 Probably. :) From: To: Time: Tue Jan 27 17:10:36 2009 Find the socket Darwin's launchd uses, and chown/chmod it so you can write to it. From: To: Time: Tue Jan 27 17:10:56 2009 Or just delete the rpc tests and assume that kadm5 and other tests will be adequate, as I usually do. From: To: Time: Tue Jan 27 17:10:56 2009 but we're using our built-in pmap stuff that doesn't grok local IPC From: To: Time: Tue Jan 27 17:11:17 2009 it's bothering me because i'm fairly certain it worked before From: To: Time: Tue Jan 27 17:11:32 2009 We're using our built-in pmap stuff that I wrote code for to tickle the Darwin launchd setup. From: To: Time: Tue Jan 27 17:11:52 2009 where does that live? From: To: Time: Tue Jan 27 17:12:27 2009 Buried in the rpc library somewhere. Search for AF_UNIX, I think that'll find it. From: To: Time: Tue Jan 27 17:12:42 2009 pmap_clnt.c From: To: Time: Tue Jan 27 17:16:46 2009 now i'm getting failures in fullrun.exp "expected 11 dots, got 0" From: To: Time: Tue Jan 27 17:17:17 2009 Yeah. Good luck with that one. I still haven't managed to figure it out. From: To: Time: Tue Jan 27 17:17:52 2009 it was working for me not long ago. does it work for you at all? From: To: Time: Tue Jan 27 17:17:59 2009 or did it ever work for you? From: To: Time: Tue Jan 27 17:18:48 2009 I haven't tried the tests on the mac in a while, but as I recall, that came up sometimes. When I've tried to track it down before (don't recall which platform), it hasn't happened consistently. From: To: Time: Tue Jan 27 17:19:19 2009 just my luck if it's another race condition From: To: Time: Tue Jan 27 17:20:24 2009 increasing the timeout to see if that helps From: To: Time: Tue Jan 27 18:10:55 2009 hey Ken, can you give me the valgrind report script? I just did a full check with that on and I'd like some help with determining the real errors From: To: Time: Tue Jan 27 18:15:12 2009 Thanks for the reminder (again)... I just checked it in to src/util/trim-valgrind-logs on the trunk. From: To: Time: Tue Jan 27 18:16:22 2009 I believe it still discards test cases that indicate memory leaks but no access errors or uninitialized-storage uses. From: To: Time: Tue Jan 27 18:17:07 2009 ok From: To: Time: Tue Jan 27 18:17:08 2009 thanks From: To: Time: Tue Jan 27 18:17:24 2009 and I got your e-mail about the bug. I'll look at that now From: To: Time: Tue Jan 27 18:18:39 2009 okay, thanks. From: To: Time: Tue Jan 27 18:34:49 2009 right. rpc_test.0/fullrun.exp reads everything from the server, waits for it to time out, then reads everything from the client. this could cause trouble. From: To: Time: Tue Jan 27 18:40:28 2009 got it. From: To: Time: Tue Jan 27 18:41:28 2009 it looks like rewriting that script to run a single loop around both expect spawn IDs does it From: To: Time: Tue Jan 27 18:43:27 2009 Is expect as poorly set up for handling that case as it appears? From: To: Time: Tue Jan 27 18:44:15 2009 no, i think there's some interaction with pty buffers getting dumped at the wrong time when expect doesn't read from it soon enough. From: To: Time: Tue Jan 27 18:45:14 2009 Making update_princ_encryption take a principal-name pattern, as described in the project proposal, is going to be disappointing. The pattern matching is done in the DAL back end (in the iterator function), and db2 ignores the pattern argument. LDAP does implement it, though. From: To: Time: Tue Jan 27 18:45:35 2009 ah, didn't see that From: To: Time: Tue Jan 27 18:45:43 2009 ouch From: To: Time: Tue Jan 27 18:46:02 2009 And I just spent way too long trying to figure out: % kdb5_util update_princ_encryption kadmin/* kdb5_util: No match. % From: To: Time: Tue Jan 27 18:46:30 2009 what the existing test case does is loops reading error indications from the server, then waits for 5 sec timeout, then starts reading from client. the code that causes the client to output lots of dots runs after the code that causes the client to induce errors on the server. for some reason the client was indicating eof prematurely. From: To: Time: Tue Jan 27 18:46:48 2009 how does kadmin listprincs do it? From: To: Time: Tue Jan 27 18:46:51 2009 Of course, it's the shell, not the kdb5_util code, complaining. But it did get me looking at the pattern-matching code. :) From: To: Time: Tue Jan 27 18:49:55 2009 The kadm5 library (server-side flavor, at least) has regexp and glob-to-regexp code in it. From: To: Time: Tue Jan 27 18:51:50 2009 I assumed that functionality would be used by kdb5_util update_princ_encryption From: To: Time: Tue Jan 27 18:52:38 2009 I suppose I could borrow that code for kdb5_util. But it would be better to implement something in db2... From: To: Time: Tue Jan 27 18:53:35 2009 Well, kdb5_util links against the kadm5 server library; I guess I could do some refactoring and export some of that code. But, ick. :) From: To: Time: Tue Jan 27 18:58:07 2009 Actually, it doesn't look too hard to just grab the code from kadm5/srv and stick it in kdb5_util, for now. From: To: Time: Tue Jan 27 18:58:57 2009 I suppose it might be a little weird to have the exact details of pattern matching dependent on the back-end database. From: To: Time: Tue Jan 27 18:59:30 2009 yeah, diff glob behavior seems like a problem From: To: Time: Tue Jan 27 19:02:09 2009 argh. we are very inconsistent about making every dejagnu "pass" call match exactly one "fail" call. From: To: Time: Tue Jan 27 19:05:27 2009 Oh, yes, we totally fail on that score. We also theoretically ought to have the pass/fail names match, so each name shows up in every run as pass, fail, untested, whatever. From: To: Time: Tue Jan 27 19:28:12 2009 ken, you there? From: To: Time: Tue Jan 27 19:29:42 2009 yep From: To: Time: Tue Jan 27 19:32:37 2009 I'm a bit confused on the kvno returning 0 thing. When I run in on trunk bits I'm getting kvno 0 also From: To: Time: Tue Jan 27 19:32:56 2009 I did kinit test; kvno test From: To: Time: Tue Jan 27 19:33:08 2009 and test has a knvo of 1 From: To: Time: Tue Jan 27 19:33:46 2009 Uh oh... lemme take a look.... From: To: Time: Tue Jan 27 19:34:33 2009 I wonder if Luke's changes broke something. That's a very windows behavior From: To: Time: Tue Jan 27 19:34:52 2009 That was my first guess. From: To: Time: Tue Jan 27 19:39:16 2009 I can't find any changes. it looks like do_tgs.c tries to set the kvno correctly From: To: Time: Tue Jan 27 19:39:35 2009 is something creating principals with kvno of 0? From: To: Time: Tue Jan 27 19:39:47 2009 No, getprinc shows them to have reasonable kvno values. From: To: Time: Tue Jan 27 19:39:57 2009 that's kind of disturbing then From: To: Time: Tue Jan 27 19:40:27 2009 ken are you trying this on trunk bits? From: To: Time: Tue Jan 27 19:42:59 2009 Just built a tree, haven't set up the test yet. I've got an environment set up for testing on the branch, I was thinking of just running that KDC under a debugger to see what's up. From: To: Time: Tue Jan 27 19:47:57 2009 just so I'm clear in do_tgs_req.c I see the ticket_reply.enc_part.kvno = server_key->key_data_kvno which I know is set to 1 however further down I see reply.enc_part.kvno = 0 . which of these is kvno supposed to print out? From: To: Time: Tue Jan 27 19:50:10 2009 That code looks the same as 1.6. From: To: Time: Tue Jan 27 19:51:06 2009 in tgs you'd expect the reply enc_part to have a kvno of 0 because the reply key starts out as the subkey from the authentictaor. kvno should print the ticket kvno From: To: Time: Tue Jan 27 19:51:42 2009 ok From: To: Time: Tue Jan 27 19:57:08 2009 looks like do_tgs_req.c fills it in, then krb5_c_encrypt overwrites with 0 From: To: Time: Tue Jan 27 19:57:22 2009 that seems wrong From: To: Time: Tue Jan 27 19:58:57 2009 In 1.6 there were two calls to encrypt_tkt_part, one (u2u, no kvno to use) comes after setting kvno to 0, the other (normal service key) is followed by setting kvno. Now, kvno is always set before and both code paths merge before the call to encrypt_tkt_part. From: To: Time: Tue Jan 27 19:58:59 2009 I wonder how that changed. From: To: Time: Tue Jan 27 19:59:24 2009 Ah, so a bug. From: To: Time: Tue Jan 27 19:59:53 2009 Yeah, looks like. I don't know if anyone but Luke has been doing that much rearranging of KDC code. Checking logs now... From: To: Time: Tue Jan 27 20:02:23 2009 Yes, it was the merge of Luke's code where this seems to have happened. From: To: Time: Tue Jan 27 20:04:15 2009 The KDC process seems to be crashing on exit, on the mkey_migrate branch. GNU libc detects some malloc pool corruption while in krb5_dbe_free_key_list and aborts. From: To: Time: Tue Jan 27 20:04:39 2009 ok, will check that out From: To: Time: Tue Jan 27 20:04:43 2009 Thanks. From: To: Time: Tue Jan 27 20:10:21 2009 I'm going to stop looking at the kvno thing until y'all fix that bug, ok? From: To: Time: Tue Jan 27 20:11:14 2009 Sure. Sam, do you have time to deal? From: To: Time: Tue Jan 27 20:13:20 2009 Sure. From: To: Time: Tue Jan 27 20:13:26 2009 Thanks. From: To: Time: Tue Jan 27 23:59:49 2009 iprop test is now consistently failing for me on Darwin. not sure why yet. From: To: Time: Wed Jan 28 12:00:17 2009 I've got a question: it dawned on me that it may be a good idea for krb5kdc and kadmind to try refetching the master key list if the current list does not contain the mkey necessary to decrypt a princ's keys. Thoughts? From: To: Time: Wed Jan 28 12:01:25 2009 this would be useful in the case that the daemon has been running for a while and the master princ was updated with a new mkey which the daemon does not have in it's list of mkeys in memory From: To: Time: Wed Jan 28 12:02:34 2009 sounds reasonable From: To: Time: Wed Jan 28 12:03:25 2009 ok From: To: Time: Wed Jan 28 12:18:41 2009 also, the plot thickens re the iprop test. looks like it is silently terminating early on solaris due to long line lengths upsetting the pty driver. From: To: Time: Wed Jan 28 12:27:45 2009 hmmm, seems like I've seen something similar in our test suites that test telnet/rsh From: To: Time: Wed Jan 28 12:28:12 2009 don't remember what was done to deal with that but I can look into it (when I have time) From: To: Time: Wed Jan 28 12:29:25 2009 the iprop tests are failing on Darwin for what appear to be unrelated reasons. From: To: Time: Wed Jan 28 13:05:21 2009 Where's the code to load plugin libraries? (Specifically, kdb plugins.) From: To: Time: Wed Jan 28 13:10:46 2009 I think I found it. From: To: Time: Wed Jan 28 13:26:55 2009 Okay, in the presence of an existing stash file, "kdb5util stash" behaves kind of oddly. It opens the database, reads in the master key from the stash file, then ignores it, prompts the user for the master key, verifies it against the database, and writes out a new stash file. From: To: Time: Wed Jan 28 13:31:32 2009 i'll look at that (note, I'm on a conference call so I'll get back to you in a bit) From: To: Time: Wed Jan 28 13:32:23 2009 I don't think that's new behavior, and it's just an oddity. From: To: Time: Wed Jan 28 13:32:39 2009 It's because of the structure of kdb5_util. From: To: Time: Wed Jan 28 13:33:57 2009 oh, is it because the shared initialization parts of kdb5_util unconditionally try to obtain the master key before running the subcommand? From: To: Time: Wed Jan 28 13:35:25 2009 Yeah. That same structure prevents "kdb5_util stash" from working when there is no database, before kdb5_stash() is even invoked. From: To: Time: Wed Jan 28 13:35:59 2009 that seems unnecessarily broken From: To: Time: Wed Jan 28 13:36:30 2009 What damage does it cause? From: To: Time: Wed Jan 28 13:36:54 2009 One complaint is that you can't stash the master password before creating the database, which sucks when creating slaves. From: To: Time: Wed Jan 28 13:37:01 2009 it causes kdb5_util stash to behave very unexpectedly From: To: Time: Wed Jan 28 13:37:09 2009 what Greg said From: To: Time: Wed Jan 28 13:37:41 2009 Is that the only think that breaks the slave issue? Won't you still lose with kdb5_util load? From: To: Time: Wed Jan 28 13:38:55 2009 you might still lose with kdb5_util load but that might also be fixable. From: To: Time: Wed Jan 28 13:39:11 2009 and now i can't reproduce the Darwin kprop failure. From: To: Time: Wed Jan 28 14:00:50 2009 Will, when you have time to answer: it doesn't look like libkdb on your branch currently has code to write out more than one master key into a keytab-format stash. Is that correct? From: To: Time: Wed Jan 28 14:02:11 2009 (Which means part of writing the new stash command will be writing krb5_db_store_master_key_list.) From: To: Time: Wed Jan 28 14:17:16 2009 I think that's a bug. I intended the stash command to append a new key to the keytab From: To: Time: Wed Jan 28 14:38:27 2009 while modifying code to try refreshing the master key list I notice that in get_sam_edata() in kdc_preauth.c there seems to be a bug From: To: Time: Wed Jan 28 14:39:20 2009 the function definition takes a krb5_context and calls it context but the function calls within are using kdc_context which I'm guessing is global From: To: Time: Wed Jan 28 14:42:04 2009 in fact that's happening all over kdc_preauth.c From: To: Time: Wed Jan 28 15:00:15 2009 Will, you intended krb5_def_store_mkey to add to an existing keytab file? What if the existing file is in old format? From: To: Time: Wed Jan 28 15:01:31 2009 mmm, no the old format should not contain > 1 key, but I thought the keytab should From: To: Time: Wed Jan 28 15:01:48 2009 basically, the old format is read only at this point From: To: Time: Wed Jan 28 15:02:20 2009 I'm just confused, since your implementation seems pretty deliberate about replacing rather than appending. From: To: Time: Wed Jan 28 15:02:32 2009 let me look at it From: To: Time: Wed Jan 28 15:02:48 2009 not sure why it isn't appending From: To: Time: Wed Jan 28 15:02:56 2009 maybe I had a reason at the time (or it's just a bug) From: To: Time: Wed Jan 28 15:03:35 2009 btw, did anyone see my previous comments about kdc_preauth.c? From: To: Time: Wed Jan 28 15:03:37 2009 looks buggy From: To: Time: Wed Jan 28 15:04:53 2009 are those bits even compiled? From: To: Time: Wed Jan 28 15:05:46 2009 I saw them but the preauth code is beyond me right now. From: To: Time: Wed Jan 28 15:06:14 2009 ok, just wanted to make sure someone saw that From: To: Time: Wed Jan 28 15:48:50 2009 I could use responses on my questions about how to handle non-tgts in fast. From: To: Time: Wed Jan 28 16:31:38 2009 do we really fail to use kdc_supported_encytpes for anything? From: To: Time: Wed Jan 28 16:32:48 2009 Yes, I believe so. I thought you phased it out a while back. From: To: Time: Wed Jan 28 16:33:05 2009 that could be. it's still in our docs and test suite though. From: To: Time: Sun Feb 1 02:02:33 2009 This room is not anonymous. From: To: Time: Mon Feb 2 12:01:03 2009 I want to go ahead with macros for config attribute. Any objections? From: To: Time: Mon Feb 2 12:01:23 2009 Context? From: To: Time: Mon Feb 2 12:03:57 2009 As example, #define KRB5_CONF_KDCDEFAULTS "kdcdefaults" and then using the macro in the code. Mostly, to avoid misspellings. From: To: Time: Mon Feb 2 12:04:42 2009 Ah, certainly no objections from me. From: To: Time: Mon Feb 2 12:06:12 2009 Sounds fine. From: To: Time: Mon Feb 2 12:16:37 2009 Go for it. From: To: Time: Mon Feb 2 12:28:00 2009 I'm preparing to update the Coverity version used for the nightly builds. From: To: Time: Mon Feb 2 12:28:39 2009 ... somewhat hampered by running out of disk space on krbdev. From: To: Time: Mon Feb 2 12:28:41 2009 Cool. I'm looking at some of the stuff it's complaining about since the mkey_migrate merge. Most of the new items are false positives, more or less. From: To: Time: Mon Feb 2 12:29:03 2009 Oh. Oops. Let me see if some of the old nightly testing results can be purged... From: To: Time: Mon Feb 2 12:30:53 2009 I just purged the 2007 results, now 558M is free. How much more do you need? From: To: Time: Mon Feb 2 12:31:34 2009 Here goes 2008.... From: To: Time: Mon Feb 2 12:31:39 2009 That's probably enough, but I'll want to purge 4.0.0 pretty quickly after I have 4.3.0 set up. So I'm going to put it off a few hours (I'm going out in a bit). From: To: Time: Mon Feb 2 12:31:45 2009 679M free From: To: Time: Mon Feb 2 12:31:53 2009 Okay. From: To: Time: Mon Feb 2 12:40:17 2009 Coverity seems not to like memset for pointers. At least, I'm getting an "uninitialized" warning about a pointer field in a struct that was memset to 0. From: To: Time: Mon Feb 2 12:40:29 2009 Also an integer in a nested structure. That's kind of poor. From: To: Time: Mon Feb 2 12:41:29 2009 Okay, now just a plain integer field. This is annoying. From: To: Time: Mon Feb 2 12:45:05 2009 I haven't run across that case yet. From: To: Time: Mon Feb 2 12:52:12 2009 I just tried looking up one of them on krbdev, and it's not there. I'm running the new version, and I've got some local patches which I don't *think* should affect this, but maybe they do. From: To: Time: Mon Feb 2 13:02:08 2009 Well, is memset guaranteed to work for integers and pointers? From: To: Time: Mon Feb 2 13:02:25 2009 I mean I realize it does on any hardware we care about. From: To: Time: Mon Feb 2 13:03:06 2009 Integers, yes. Not pointers (or floating-point values), though I'd question whether "uninitialized" is the right diagnostic for those cases. From: To: Time: Mon Feb 2 13:18:13 2009 Gosh, a full "make check" is taking me nearly 9 minutes. I wonder where all that time is being wasted.... :) From: To: Time: Mon Feb 2 13:22:03 2009 The lib/kadm5 tests take a while. It looks like start_servers_local is going to sleep about 15 seconds, but mod-principal.exp tests also seem to eat a bit of time. From: To: Time: Mon Feb 2 13:22:53 2009 And the mechanism it uses for figuring out when kadmind has started up is kind of weird. From: To: Time: Mon Feb 2 13:23:35 2009 4:35 out of 8:45 is just the lib/kadm5 tests... From: To: Time: Mon Feb 2 13:31:17 2009 Oh. One of the mod-principal tests isn't getting the output it wants, so it eventually times out. It just doesn't consider it to be a failure, apparently. From: To: Time: Mon Feb 2 13:32:24 2009 It looks like the timeout there is about 60s, and I think it'll get hit four times. From: To: Time: Mon Feb 2 13:33:08 2009 BTW, the tcl "after" command is pretty handy. Running send_log "<>" every second really highlights where the problem is. :) From: To: Time: Mon Feb 2 13:37:06 2009 Oh, I see. The test wants to check that a specific string *doesn't* get output. But it's implemented via a timeout. From: To: Time: Mon Feb 2 13:39:25 2009 And with that fixed, plus the start_servers_local change I already checked in, the lib/kadm5 test suite now runs for me in 19s. From: To: Time: Mon Feb 2 13:50:45 2009 The full "make check" (with test programs already compiled) just ran for me in 4:16. Darn it... when am I supposed to play sudoku now? From: To: Time: Mon Feb 2 13:55:16 2009 And for no readily apparent reason, the kpasswd tests sleep for 30 seconds in the middle. From: To: Time: Mon Feb 2 13:55:41 2009 Twice. From: To: Time: Mon Feb 2 13:58:31 2009 Oh, minimum password lifetime tests. *sigh* From: To: Time: Mon Feb 2 14:00:30 2009 And this is our kadmin-v1 passwd program, which we only use for testing. Testing what other than itself, I'm not sure. It might be good to make sure that all the capabilities we test are tested for our "real" password-changing program too, before we nuke this program. From: To: Time: Mon Feb 2 14:36:56 2009 Test suite runs in 4:13 for me now. The iprop tests need a 10s delay. The password-changing tests need 60s delay. That leaves around 3m run time, and I'm seeing 94s CPU usage, so I doubt there's a lot left to trim. I can probably cut down the password-changing delays a bit (i.e., change the policy from min-life 30s to 20s or 10s, and adjust the delays accordingly). From: To: Time: Mon Feb 2 16:07:01 2009 Okay, I think Coverity is upgraded. From: To: Time: Mon Feb 2 16:09:25 2009 Trying a midday run of the build cron job to verify. From: To: Time: Mon Feb 2 16:24:14 2009 Opinions on whether we're likely to have a dev meeting tomorrow? (Tom is sick, which increases the uncertainty factor.) From: To: Time: Mon Feb 2 16:28:07 2009 I would guess we probably will. Even if Tom can't make it in and can't call in for the meeting, Steve's around (today at least, and I assume tomorrow). From: To: Time: Mon Feb 2 16:31:39 2009 Okay. I'll keep watching for mail about lunch. From: To: Time: Mon Feb 2 16:32:16 2009 I don't see Tom online, so I doubt he's going to send any. What do people want? Is Kiraz again okay? From: To: Time: Mon Feb 2 16:38:39 2009 hi thomas! :-) From: To: Time: Mon Feb 2 16:39:47 2009 Steve's not in his office, though the lights are on so maybe he hasn't gone home yet. Still, I think we should just assume we're going to have the meeting, and figure out lunch. From: To: Time: Mon Feb 2 16:40:09 2009 If Kiraz is okay with everyone, we could just go ahead and email Bryan... From: To: Time: Mon Feb 2 16:40:39 2009 And now, it looks like Zhanna has gone home. From: To: Time: Mon Feb 2 16:43:46 2009 Cron job successfully ran. 121 "new" defects. From: To: Time: Mon Feb 2 16:45:53 2009 If I don't forget, I'll purge prevent 4.0.0 and the old DB from krbdev in a couple of days, to recover about 500MB. From: To: Time: Mon Feb 2 16:47:05 2009 Okay, then, hearing no objections (or other feedback), I'm going to assume we're going with Kiraz, and email Bryan... From: To: Time: Mon Feb 2 16:49:01 2009 #1272 is one of the UNINIT problems I was complaining about. From: To: Time: Mon Feb 2 16:49:31 2009 We call memset up front, and later it complains that some integer fields may be used uninitialized. From: To: Time: Mon Feb 2 16:53:42 2009 Whoops, I failed to adjust the spacing when I fixed that typo. From: To: Time: Mon Feb 2 16:58:39 2009 These NEGATIVE_RETURNS checks are kind of annoying, considering that many (all?) of our error codes wind up having negative values when treated as signed. From: To: Time: Tue Feb 3 11:33:21 2009 the one NEGATIVE_RETURNS defect i looked at (#1246) looks like it's because we're assigning a negative signed value to an unsigned variable, then casting that back to signed. From: To: Time: Tue Feb 3 11:34:05 2009 which is technically non-conforming. unsigned integer values greater than the range of positive signed integer values can't be converted to signed. From: To: Time: Tue Feb 3 11:35:15 2009 Yeah, the gssapi bits are dicey. From: To: Time: Tue Feb 3 11:36:46 2009 Oh, that's interesting. It looks like (so far as coverity can tell) krb5int_get_error can pass the negative value to strerror, which would be a no-no. From: To: Time: Tue Feb 3 11:38:16 2009 we could have a macro that converts unsigned back into signed, which is written in a conforming way but amounts to a no-op on twos-complement systems. From: To: Time: Tue Feb 3 11:39:33 2009 That might make it happier in some places, yeah. From: To: Time: Tue Feb 3 11:40:48 2009 e.g. for turning unsigned int into signed int, #define U2I(x) ((x)-INT_MAX-1-INT_MAX-1) From: To: Time: Tue Feb 3 11:41:01 2009 suitably munged to deal with deciding if it's actually in range for that From: To: Time: Tue Feb 3 11:41:41 2009 and with a cast at the right time... From: To: Time: Tue Feb 3 11:45:16 2009 so it would be more like (((x) > INT_MAX) ? (((int)((x) - INT_MAX)) - 1 - INT_MAX - 1) : (x)). yuck. From: To: Time: Tue Feb 3 11:46:33 2009 Yep. :) From: To: Time: Tue Feb 3 11:47:15 2009 which of course should optimize to a no-op on a twos-complement machine... From: To: Time: Tue Feb 3 11:47:17 2009 And, of course, you want 0x7FFFFFFFL rather than INT_MAX.... From: To: Time: Tue Feb 3 11:49:09 2009 Hm.. ah. You could be converting (x - INT_MAX - 1) to int, not (x - INT_MAX). If x is UINT_MAX, x-INT_MAX can be INT_MAX+1. From: To: Time: Tue Feb 3 11:49:25 2009 (substitute 32-bit constants appropriately) From: To: Time: Tue Feb 3 11:50:20 2009 but if x is INT_MAX, then x - INT_MAX - 1 is UINT_MAX From: To: Time: Tue Feb 3 11:51:49 2009 ANSI says strerror takes any value of int From: To: Time: Tue Feb 3 11:54:55 2009 oh nevermind. conditional guarantees that it's not INT_MAX From: To: Time: Tue Feb 3 11:55:46 2009 Yeah... From: To: Time: Tue Feb 3 11:56:25 2009 Actually, since at that point you're dealing with unsigned, you could just use 0x80000000. From: To: Time: Tue Feb 3 11:56:39 2009 Anyways, heading upstairs... From: To: Time: Tue Feb 3 16:08:31 2009 I wonder if there's an easy way we could collect multiple replay cache writes from multiple threads trying to update it at more or less the same time, and only do the fsync once... From: To: Time: Tue Feb 3 16:08:51 2009 if we head down that road we start reinventing a replay cache daemon... From: To: Time: Tue Feb 3 16:09:05 2009 does anyone have a revision history of pkinit? From: To: Time: Tue Feb 3 16:09:41 2009 The code or the spec? The ietf tools site should have old drafts. From: To: Time: Tue Feb 3 16:10:07 2009 no, i'm more interested in when certain major changes happened to the protocol without having to dig through a huge pile of diffs. From: To: Time: Tue Feb 3 16:10:54 2009 ah.. no idea. From: To: Time: Tue Feb 3 16:11:34 2009 the one i have heard about people implementing is draft-9, but i think there are one or two other variants out there. From: To: Time: Tue Feb 3 16:18:52 2009 heading home now, i think; roads are starting to look icky, and afternoon rush is going to make things worse. From: To: Time: Wed Feb 4 13:31:21 2009 gave up on trying to track assignments in a text file and am using a database. From: To: Time: Wed Feb 4 13:31:38 2009 kerberos number assignments that is From: To: Time: Wed Feb 4 15:15:07 2009 (support@coverity.com, I guess; trying to see if they have any guidelines for talking to them about checkers.) From: To: Time: Wed Feb 4 15:22:56 2009 Okay, that's weird. It only has this problem if you cast the first argument of fread to (char *). From: To: Time: Wed Feb 4 15:23:48 2009 that sounds like someone is being really strict about the object aliasing rules of ANSI C From: To: Time: Wed Feb 4 15:24:45 2009 is there a ID# as an example? From: To: Time: Wed Feb 4 15:25:37 2009 1271. (Ignore my comment entry there.) I've used a test program to verify that the problem doesn't happen if you pass an uncasted pointer or a pointer casted to void *. From: To: Time: Wed Feb 4 15:28:05 2009 does it make the same complaint if you cast to (unsigned char *)? From: To: Time: Wed Feb 4 15:28:32 2009 Yes. From: To: Time: Wed Feb 4 15:30:36 2009 i distrust redundant casts of void pointers From: To: Time: Wed Feb 4 15:31:26 2009 I've got an account at their support site, too, I can check to see if they've got advice. From: To: Time: Wed Feb 4 15:32:24 2009 No need to contact them about this one. From: To: Time: Wed Feb 4 15:32:53 2009 ok From: To: Time: Wed Feb 4 15:33:09 2009 #1276 might be worth contacting them about but I want to work out a test case first. From: To: Time: Wed Feb 4 15:33:47 2009 and really shouldn't it be checking that it read exactly as many bytes as it asked for? From: To: Time: Wed Feb 4 15:34:06 2009 fread returns the number of objects read, not the number of bytes. From: To: Time: Wed Feb 4 15:34:12 2009 So in this case it will return 0 or 1. From: To: Time: Wed Feb 4 15:34:21 2009 oh From: To: Time: Wed Feb 4 15:35:00 2009 On further reflection, I don't want to delve too far into #1276 because it's probably not worth our effort to clean src/appl of Coverity defects. From: To: Time: Wed Feb 4 15:41:42 2009 In 1276, could it be uninitialized padding bytes it complains about? From: To: Time: Wed Feb 4 15:43:51 2009 Looking at the linux one, probably not between fields, but possibly at the end if the struct alignment is bigger than sizeof(ll_time). From: To: Time: Wed Feb 4 15:44:00 2009 Or was this a case where the cast makes it complain and it's okay without it? From: To: Time: Wed Feb 4 16:17:56 2009 Can't figure out what Coverity is thinking in #1261. I'll see if I can narrow it down. From: To: Time: Wed Feb 4 16:31:27 2009 Uh, okay... I have a test program which produces an UNINIT defect if you say sg[0].iov_len = 0; but not if you say sg->iov_len = 0; From: To: Time: Wed Feb 4 16:31:48 2009 ... maybe not. From: To: Time: Wed Feb 4 16:32:16 2009 Okay, yes, I do. From: To: Time: Wed Feb 4 16:32:56 2009 Ken, I'll send you the program; can you pursue it with Coverity? From: To: Time: Wed Feb 4 16:33:20 2009 Sure. I'm trying to write a little test case for the cast vs no-cast thing you described earlier, I'll file that too if I get it working. From: To: Time: Wed Feb 4 16:50:54 2009 I wonder how difficult it would be to tweak gcc to warn about a function argument with a pointer cast from a pointer type (i.e., not "(char*)0"), when the function takes void*. From: To: Time: Wed Feb 4 16:51:31 2009 you seem to have an awful lot of suggested solutions that involve "patch gcc to ..." From: To: Time: Wed Feb 4 16:52:37 2009 Generally, "patch gcc to flag this situation so we can fix it", i.e., using gcc as a customizable source code analysis tool. From: To: Time: Wed Feb 4 16:53:14 2009 not very friendly to outside developers, i think. From: To: Time: Wed Feb 4 16:55:44 2009 so did people know that mac os x ships with sqlite? From: To: Time: Wed Feb 4 16:57:41 2009 No, and it's not meant to be for outside developers, or a tool for long-term use. More like, hack gcc, detect all cases of X and change them right now. For example, it sounds like that might help clear up a bunch of false-positive UNINIT complaints from coverity, with the result that the remaining UNINIT complaints are more likely to be serious. Or, for example, if we change krb5_data.data to void*, use a hacked gcc to find casts of the data field to whatever flavor of char* and remove the casts. Once those changes are done, the benefits remain without our having to apply it again later. From: To: Time: Wed Feb 4 16:58:03 2009 Yeah, they've been using sqlite in, for example, Mail.app's internal databases. From: To: Time: Wed Feb 4 16:58:56 2009 ok. how many instances of your "hack gcc as analysis tool" have you racked up? how long would each take to implement (both patching gcc and dealing with discovered defects)? From: To: Time: Wed Feb 4 17:00:29 2009 Dunno, I don't bother to keep track. :) From: To: Time: Wed Feb 4 17:04:23 2009 I haven't done much C front-end work in a while. It might take me a few days to dig in and do some of them. Others may turn out to be very difficult, depending on the kind of construct we want to detect. (E.g., detecting "thingptr = (thing*) voidptr" might be hard *if* gcc throws away the info that there was an explicit cast before it processes the assignment, but if it doesn't throw it away, it probably wouldn't take long for someone familiar with the internal representation, and I think it probably hasn't changed so much that I couldn't find my way around.) From: To: Time: Wed Feb 4 17:04:53 2009 and how would you compare the required effort so using grep? From: To: Time: Wed Feb 4 17:08:21 2009 Based on using grep to find char* casts in memcpy/memset/memcmp calls, it's faster, at least at first, though it requires actually reading the code since the second argument may not be on the same line. You also want to exclude cases of memcpy((char*)voidptr + 12,...) because you need to keep the pointer arithmetic. Working out where to do the syntax tree analysis in gcc would take longer, but would probably be more likely to just get such cases right to start with. From: To: Time: Wed Feb 4 17:08:49 2009 And grep wouldn't get memcpy invocations done via macro, necessarily. From: To: Time: Wed Feb 4 17:09:00 2009 (fread, memset, whatever) From: To: Time: Wed Feb 4 17:11:20 2009 And the gcc hacking would be more interesting. :) From: To: Time: Wed Feb 4 17:26:29 2009 fread((char*)&thing) bug reported From: To: Time: Wed Feb 4 19:10:57 2009 The web service Coverity seems to be using for their customer support site is annoying. I don't seem to be able to create or update reports attaching a file, and naturally any leading whitespace on lines I submit in the main text seems to get discarded, making the test case look ugly... From: To: Time: Wed Feb 4 19:11:19 2009 But, I've got both Greg's iovec test and my fread test submitted. From: To: Time: Wed Feb 4 19:38:55 2009 Looks like Coverity's process is to close an incident report if it's confirmed to be a real bug and given a bugzilla number, so they're tracking reports and bugs separately... From: To: Time: Wed Feb 4 19:54:03 2009 Looks like the attachment problem might be a bug in Safari or webkit. Firefox works okay. From: To: Time: Wed Feb 4 20:54:20 2009 Coverity support seems to be pretty responsive this evening. From: To: Time: Thu Feb 5 11:16:15 2009 Hi! Earlier we have discussed python version to use for the tests. It was decided to pick up version 2.3 since it is available for many OS . However, python.org recommends 2.6 as the most stable version. So, can we consider 2.3 as a minimum version , and still use 2.6+ as preferred one? My understanding is that the upgrade from 2.3 to 2.6 is a simple exercise if someone needs it for his env. From: To: Time: Thu Feb 5 11:27:30 2009 We can certainly use 2.6, definitely, but we should try to make sure that the tests don't rely on anything not in 2.3. From: To: Time: Thu Feb 5 12:11:33 2009 Well, I suspect that more people are using 2.5 than 2.3. I don't see a reason why should we downgrade our software to 2.3 if the upgrade to python 2.5 or 2.6 is a simple one and gives you reacher functionality combined with stability. From: To: Time: Thu Feb 5 12:12:03 2009 the ease of the upgrade really depends on what OS you're running, in some respects. From: To: Time: Thu Feb 5 12:36:22 2009 well, if people made through Kerb software they might be able to [re]install python. ;) We are talking here about developing test suites not major modules. So, they won't be show-stoppers... Newer versions are better both for writing the code and reading it... Undoubtly there are more people who would be willing to write (and contribute code) in newer version that 3-releases-back version. From: To: Time: Thu Feb 5 12:38:45 2009 i dislike languages that are moving targets. how many new language features are there in 2.6? also note that on Leopard, the python version is 2.5.1. From: To: Time: Thu Feb 5 12:39:40 2009 on my solaris machine it's 2.3.3 From: To: Time: Thu Feb 5 12:40:19 2009 2.5 would be fine. From: To: Time: Thu Feb 5 12:40:52 2009 is there an easy reference to find out the changes in the language features over python releases? From: To: Time: Thu Feb 5 12:40:56 2009 If we ignore the versions in the OSes we and other people are likely to be using, we're no longer talking about a scripting language that often comes with the system or is trivially installed out of its packaging system (which was part of our reasoning Tuesday for allowing it); instead we're talking about requiring people to install a new tool for working with our code. From: To: Time: Thu Feb 5 12:41:36 2009 Are there language features of 2.5 that you particularly want to use which aren't in 2.3? From: To: Time: Thu Feb 5 12:44:30 2009 so, should we continue with perl? Subprocess From: To: Time: Thu Feb 5 12:46:19 2009 No, we decided python was okay, but part of the reasoning behind it was that on many if not most systems it's already available. But that's only true if our minimum version is 2.3, not 2.5 or 2.6. From: To: Time: Thu Feb 5 12:52:21 2009 Did Coverity say anything yet about the test cases we sent? From: To: Time: Thu Feb 5 13:02:20 2009 The fread()-cast one is confirmed as a false positive and filed as a bug with the developers; they recommend just marking it as a false positive for now. The iovec one they've reproduced and "expect to have a full report on this" soon. From: To: Time: Thu Feb 5 13:15:49 2009 Memory leak which only happens when a mutex lock fails: pull up or leave on trunk? From: To: Time: Thu Feb 5 13:16:22 2009 how risky is the change? From: To: Time: Thu Feb 5 13:17:05 2009 I restructured the function to use a cleanup handler. It's a pretty short function. Left to my own devices I wouldn't pull up the change (mutex lock failures don't generally happen unless we have bugs) but I thought I would ask. From: To: Time: Thu Feb 5 13:17:49 2009 it makes the code cleaner? From: To: Time: Thu Feb 5 13:18:16 2009 Yes. From: To: Time: Thu Feb 5 13:18:26 2009 sure, mark it for pullup From: To: Time: Thu Feb 5 13:18:35 2009 Okay. From: To: Time: Thu Feb 5 13:29:41 2009 Our code is kind of inconsistent about whether it puts braces around single-line bodies. From: To: Time: Thu Feb 5 13:30:50 2009 do you have a preference? From: To: Time: Thu Feb 5 13:32:22 2009 I prefer no braces around single-line bodies (especially if we're trying to keep functions short) but it also feels like an area where consistency will help with readability, whichever way we choose. From: To: Time: Thu Feb 5 13:32:45 2009 I agree, on both counts.. From: To: Time: Thu Feb 5 13:35:55 2009 ok. no braces around single-line bodies. which is distinct from no braces around single-statement bodies. From: To: Time: Thu Feb 5 13:36:09 2009 see "brace placement" in the coding practices page From: To: Time: Thu Feb 5 14:03:51 2009 The iovec test case has been confirmed and filed in Coverity's bug database. From: To: Time: Thu Feb 5 14:04:17 2009 Thanks. From: To: Time: Thu Feb 5 15:08:03 2009 Crap, meant to mark that one for pullup. Creating the ticket manually. From: To: Time: Thu Feb 5 15:37:37 2009 Tom may want to look at CID #1143 at some point. The function's logic is too convoluted for me to figure out when otgtptr should be freed. From: To: Time: Thu Feb 5 15:40:58 2009 if it's still null at that point, it's a bug (probably in the free function because we're moving toward having them quietly no-op on null pointers) From: To: Time: Thu Feb 5 15:42:02 2009 It's plausible for it to be null. Note that at conditional 5 it's assuming retval is nonzero, so it skips the assignment and jumps to the cleanup code. From: To: Time: Thu Feb 5 16:48:25 2009 Well, this is interesting.... Apparently the Windows CCAPI code includes C++ source that includes k5-int.h, which has some assumptions built in that it's being compiled as C, not C++... Grr. From: To: Time: Thu Feb 5 16:48:48 2009 well oops From: To: Time: Thu Feb 5 16:49:04 2009 Oh, sorry, k5-thread.h, which pulls in k5-platform.h but not k5-int.h. But still. From: To: Time: Thu Feb 5 16:50:11 2009 The unaligned load/store functions use void*, and C++ doesn't automatically convert void* to other pointer types. From: To: Time: Thu Feb 5 16:50:43 2009 so is the ccapi code calling them? From: To: Time: Thu Feb 5 16:51:13 2009 It's including the header, which defines the inline functions, so they get compiled... From: To: Time: Thu Feb 5 16:58:10 2009 Kind of annoying that C++ requires explicit casts from void. (Of course, it also provides a bunch of language features which make it less necessary to cast from void.) From: To: Time: Thu Feb 5 16:59:58 2009 C++ is a lot more paranoid about type safety. Given 'new' and 'delete', much of the need goes away, too, so it's kind of reasonable, if inconvenient for shared C/C++ code. From: To: Time: Thu Feb 5 17:02:14 2009 Oh, ick ick ick. "typedef struct k5_ipc_stream *k5_ipc_stream" ... that's never going to work in C++. And to change it, I need to go look through the Mac code because I might break it... From: To: Time: Thu Feb 5 17:03:39 2009 Actually, a quick grep indicates it's *probably* only used in code shared across platforms. So maybe it won't break things too much. From: To: Time: Thu Feb 5 17:06:03 2009 (This editing work is going surprisingly smoothly and efficiently, considering I'm typing on my desktop machine, using Screen Sharing over Back To My Mac to get at my laptop's screen, where VMware in running in Unity mode to splatter the Windows programs all over my screen.) From: To: Time: Thu Feb 5 17:07:03 2009 it turns out you don't need BTMM if you're willing to tweak a few things manually. From: To: Time: Thu Feb 5 17:08:15 2009 Probably not. But BTMM, when it works, just gives me IPsec protection automatically. (And it's using IPv6. They've really stacked up a lot of shiny new tech and gotten something that works pretty well, even if it doesn't work always and is a pain to debug...) From: To: Time: Thu Feb 5 17:11:41 2009 that's somewhat surprising given that it's Apple and this is a feature they want to have Just Work for non-technical users. From: To: Time: Thu Feb 5 17:27:39 2009 apparently there's a cvs repository "krbdev.test" on drugstore. i assume nobody cares? From: To: Time: Thu Feb 5 18:02:45 2009 The IPv6 bits are reasonably simple. Use of IPv6 link-local addresses gets them out of having to figure out which IPv4 private network addresses they could use for the tunnel between machines. The IPsec bits I've had trouble with sometimes, but at least part of that is probably the broken NAT setup I've got at home. From: To: Time: Thu Feb 5 18:22:33 2009 Does k5-buf.h really need unistd.h? From: To: Time: Thu Feb 5 18:24:11 2009 dunno. maybe some of the implementation needs it. From: To: Time: Thu Feb 5 18:25:00 2009 Nothing I can see should need it. Though I'd have to check if the other headers would define size_t. Windows doesn't have unistd.h... From: To: Time: Thu Feb 5 18:25:23 2009 Also, somehow we're getting a Windows header file that defines FIXED as a typedefname, and Greg's using it for an enumerator in the k5buf code. From: To: Time: Thu Feb 5 18:26:11 2009 ick From: To: Time: Thu Feb 5 18:26:23 2009 control your namespaces, people... From: To: Time: Thu Feb 5 18:29:10 2009 (insert c++ comments here) From: To: Time: Thu Feb 5 18:31:14 2009 I only use FIXED in the .c file, so I blame the Windows header. From: To: Time: Thu Feb 5 18:32:07 2009 I wouldn't have put unistd.h in there for no reason, but I do'nt remember what the reason is. :/ From: To: Time: Thu Feb 5 18:33:10 2009 Possibly ssize_t. From: To: Time: Thu Feb 5 18:36:25 2009 Ah, missed that. Okay, I'll keep it in for unix; seems unneeded for Windows. From: To: Time: Thu Feb 5 18:39:03 2009 Ooh, and ERROR is a macro... From: To: Time: Thu Feb 5 18:40:23 2009 I think I need to rename the enumerators. Any preference what prefix I stick on? From: To: Time: Thu Feb 5 18:49:21 2009 *sigh* really need automatic nightly builds on windows From: To: Time: Thu Feb 5 18:56:30 2009 lib/krb5/unicode/Makefile.in needs work ... it's got a list of source files and headers, and runs "find" over its part of the source tree to find the files, and creates symlinks. Ugly for UNIX, broken on Windows. From: To: Time: Thu Feb 5 19:16:03 2009 I can rename the buffer types in k5-buf.c. Just a second... From: To: Time: Thu Feb 5 19:17:01 2009 I've already got a hacked-up tree building past that point. I could just go change the prefix I used and check it in... From: To: Time: Thu Feb 5 19:19:13 2009 I was going to go with BUFTYPE_FIXED etc. From: To: Time: Thu Feb 5 19:20:01 2009 Probably prettier than what I used (k5buf_FIXED). I can just go do the global-replace and check it in later with all the other stuff I've got to clean up, if you like. From: To: Time: Thu Feb 5 19:23:02 2009 Sure. From: To: Time: Thu Feb 5 19:23:31 2009 Okay. It'll probably get in tomorrow or early next week. From: To: Time: Thu Feb 5 19:40:34 2009 Our coding standards ought to touch on the Windows issues -- reliance on POSIX headers, calling-convention specifications, etc. From: To: Time: Thu Feb 5 20:15:06 2009 I'm trying to remember (if I ever knew) what the logic behind the calling-convention choices was. Is there any reason to use KRB5_CALLCONV (or any spec at all) for functions we don't export? And is there a reason for specifying the calling convention for new API functions, other than consistency with a previous mistake? From: To: Time: Thu Feb 5 20:15:42 2009 (Some of the GSSAPI changes recently put in give us inconsistent calling-convention specifications in some places where we use function pointers internally.) From: To: Time: Fri Feb 6 13:51:52 2009 Gah, the contract for krb5int_utf8_normalize is totally different from anything I've seen in the code base. From: To: Time: Fri Feb 6 13:52:58 2009 ... and we never use it, anywhere. From: To: Time: Fri Feb 6 13:53:37 2009 (And it leaks like a sieve.) From: To: Time: Fri Feb 6 14:26:31 2009 what do you think about return code of get_from_windows_dir  if malloc fails? From: To: Time: Fri Feb 6 14:26:58 2009 it is lib/krb5/os/init_os_ctx.c From: To: Time: Fri Feb 6 14:28:25 2009 "can't open" doesn't seem ideal, but is sort of accurate... ENOMEM might be better. From: To: Time: Fri Feb 6 14:53:28 2009 We have a unicode regular expression library now? We which don't use, and which Coverity thinks contains at least one subtle logic error. From: To: Time: Fri Feb 6 16:58:11 2009 anyone know of reasons why #!/usr/bin/env perl might not work well? From: To: Time: Fri Feb 6 17:02:00 2009 occasionally env isn't in /usr/bin? http://www.in-ulm.de/~mascheck/various/shebang/#details references openserver 5.0.6 and unicos 9.0.2, at least. we might not care. From: To: Time: Fri Feb 6 17:03:08 2009 That's definitely good enough for test suite code. For stuff we're installing, I might think twice. From: To: Time: Fri Feb 6 17:03:44 2009 agreed From: To: Time: Fri Feb 6 17:06:01 2009 i was more thinking of making our perl scripts function on the new svn server From: To: Time: Fri Feb 6 17:06:48 2009 well more precisely, making the svn hook scripts function equally well on both the old svn server and the new one, to minimize the coordination required for cutover. From: To: Time: Fri Feb 6 17:17:12 2009 Oh, then, yeah, /usr/bin/env is probably fine. Unless there's some command-line option to perl that can't be set in the script -- I think at least some OS kernels limit #! interpretation to the interpreter plus one argument. From: To: Time: Fri Feb 6 17:17:36 2009 Oh, the link I sent has other info. Some system limit the #! line length, other stuff. From: To: Time: Fri Feb 6 17:18:34 2009 For *real* portability, use /bin/sh. From: To: Time: Fri Feb 6 17:18:58 2009 http://cr.yp.to/slashpackage/studies/findingperl/7 recommends: #!/bin/sh #! -*-perl-*- eval 'exec perl -x -wS $0 ${1+"$@"}' if 0; From: To: Time: Fri Feb 6 17:19:32 2009 The "\n if 0;" bit takes advantage of the different parsing between sh and perl. From: To: Time: Fri Feb 6 17:41:59 2009 env perl seems adequate for us:-) From: To: Time: Fri Feb 6 17:44:58 2009 Yeah, probably... From: To: Time: Fri Feb 6 18:17:20 2009 So, I was thinking a bit about the issue of parallel processing of requests in the KDC to deal with LDAP access delays. I've worked up an outline of a way it could be done with multiple processes working in parallel. It's a little clunky in places (like, rather than set up infrastructure for coordinating, each idle process will try to grab each packet that becomes available, and will just not complain if another process got it first), and the procedure for reconfiguring when network interface changes are detected is rather awkward. But it's much less intrusive into the actual packet processing and database access. From: To: Time: Fri Feb 6 18:17:37 2009 The outline is at /mit/raeburn/parallel-kdc.txt, if anyone is interested. From: To: Time: Fri Feb 6 18:18:27 2009 (And as for the automatic reconfiguration, we *could* just assert that it's not supported in the multi-process mode, and skip all the ugly bits.) From: To: Time: Fri Feb 6 18:30:20 2009 Should we avoid passing strerror() negative values? There are something like 40 defect reports from coverity that come down to that. ISO C says strerror accepts int and will produce a message for any int value, but it also specifies that the values set in errno, when specified by ISO C (either E* macros defined by the spec, or explicitly implementation-defined), are positive. I'm not sure we can jump from that to "strerror doesn't know about negative values", or from there to "strerror shouldn't be passed negative values". And, I'd want to check on Windows whether some system errors you'd pass to strerror might in fact be negative. From: To: Time: Fri Feb 6 19:19:13 2009 Can I see an example defect? From: To: Time: Fri Feb 6 19:31:39 2009 On the one hand, strerror should perhaps not be a negative sink (the Coverity term for a function which isn't supposed to take a negative argument). On the other hand, if we are passing negative values to strerror, we're doing something wrong even if the behavior is defined. Unless that's not true on Windows. From: To: Time: Fri Feb 6 21:35:01 2009 #1243 is one example; chase the "negative sink" links down. From: To: Time: Fri Feb 6 21:40:23 2009 The case where we can pass strerror a negative value is, I think, we get a com_err code but the com_err library hasn't been initialized properly so it hasn't installed the callback handler. (krb5int_get/set_error are in the support library because the plugin code in the support library uses it; it supports a function-pointer callback installed by com_err to convert the error code to a string.) I'm not sure how one would get to krb5int_get_error without having the com_err library loaded and initialized, but that may be too high-level for coverity to analyze. From: To: Time: Sat Feb 7 09:47:45 2009 ken, on windows NT Status errors are unsigned 32-bit values that are partitioned as follows: // // Values are 32 bit values layed out as follows: // // 3 3 2 2 2 2 2 2 2 2 2 2 1 1 1 1 1 1 1 1 1 1 // 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 // +---+-+-+-----------------------+-------------------------------+ // |Sev|C|R| Facility | Code | // +---+-+-+-----------------------+-------------------------------+ // // where // // Sev - is the severity code // // 00 - Success // 01 - Informational // 10 - Warning // 11 - Error // // C - is the Customer code flag // // R - is a reserved bit // // Facility - is the facility code // // Code - is the facility's status code // // From: To: Time: Sat Feb 7 09:52:01 2009 Zhanna: if you are working on init os context for Windows, it would be a reasonable time to modify the code to first read the profile file from the ProgramData "MIT\Kerberos" directory. This is necessary on Vista/2008/Win7/2008R2 for the following reasons: 1. on 64-bit systems, the WOW64 environment processes do not see the same \WINDOWS directory as the native 64-bit processes 2. standard users are often not permitted to read \WINDOWS, only execute The ProgramData directory is the same as \Documents and Settings\All Users\Application Data\ on 2000,XP,2003 systems. From: To: Time: Sat Feb 7 10:18:42 2009 Sounds like we should be using a different approach for windows than always calling strerror, then. I expect we can probably adapt the code from util/et. Which only calls strerror for small-enough positive values, and uses FormatMessage for other values on Windows. Though I'm still not sure if there should ever be real-world cases where that code path can get used, instead of going via the existing util/et library code. From: To: Time: Sun Feb 8 02:02:28 2009 This room is not anonymous. From: To: Time: Mon Feb 9 12:55:32 2009 I'm about to add my very first krb5 error code. Anything to do besides add a line to lib/krb5/error_tables/krb5_err.et? From: To: Time: Mon Feb 9 12:56:05 2009 Make sure it's at the end, or replacing a placeholder value. Shifting the other offsets around would mess up ABI compatibility. From: To: Time: Mon Feb 9 12:58:15 2009 What is DEFAULT_PROFILE_FILENAME on Vista+? krb5.conf or krb5.ini ? From: To: Time: Mon Feb 9 12:58:51 2009 krb5.ini From: To: Time: Mon Feb 9 12:59:54 2009 see Jeffrey Altman's note http://mailman.mit.edu/pipermail/kerberos/2008-January/012978.html From: To: Time: Mon Feb 9 13:02:27 2009 Yes, he's saying there that the environment settings indicate a changed file name to krb5.conf (and specify a path), vs the compiled-in default of krb5.ini. From: To: Time: Mon Feb 9 13:05:22 2009 "Note that "krb5.ini" has been renamed to "krb5.conf" as on UNIX for two " From: To: Time: Mon Feb 9 13:10:29 2009 Yes, he's recommending that people set environment variables to do that. It's not changed within the MIT code base (so far). From: To: Time: Mon Feb 9 13:10:47 2009 include/osconf.hin has the settings From: To: Time: Mon Feb 9 14:27:11 2009 Objections to making asn1buf_destroy return void instead of krb5_error_code? It's just a free function. From: To: Time: Mon Feb 9 14:28:07 2009 (We don't check the return value at most call sites, and when we do we leak memory, which isn't surprising. It's very, very hard to cleanup correctly when your cleanup functions can fail.) From: To: Time: Mon Feb 9 14:53:54 2009 Purging prevent 4.0.0 from krbdev to reclaim space from the upgrade. From: To: Time: Mon Feb 9 15:09:26 2009 Go ahead and change it. From: To: Time: Mon Feb 9 15:09:32 2009 (asn1buf_destroy) From: To: Time: Mon Feb 9 15:10:14 2009 I've just run across a couple krb5_free_* functions that return 0 always. Unfortunately they're part of the public API, so no fixing that... From: To: Time: Mon Feb 9 15:10:58 2009 Time for krb6! From: To: Time: Mon Feb 9 15:11:28 2009 Aaaaiiiiiieeeee!!!!! From: To: Time: Mon Feb 9 15:12:38 2009 It can run over IPv16. From: To: Time: Mon Feb 9 15:25:50 2009 Oh, yeah, about krb5_err.et ... non-protocol messages should be added above 128, offsets below 128 are used for protocol errors. (Today's change is in the right place; just for future reference.) I don't think any of the other error tables have such issues. From: To: Time: Mon Feb 9 15:26:30 2009 let's hope we figure out how to deal with protocol error numbers higher than 127 by the time someone starts using one. From: To: Time: Mon Feb 9 15:27:16 2009 Shouldn't be hard -- either we keep adding them to the "krb5" table and the mapping is non-linear above 127, or we create a new table for 128..255 (or whatever). From: To: Time: Mon Feb 9 15:28:12 2009 some messages in the kerberos mod queue keep vanishing without a trace. is someone other than me touching the queue? From: To: Time: Mon Feb 9 15:28:52 2009 I was thinking, once upon a time, about how one might extend tables beyond 256 entries by making the names case-insensitive, folding to lower-case, and using the extra part of the number space thus made available. But I think someone's using upper-case table names now too, so it would be bad... From: To: Time: Mon Feb 9 15:30:05 2009 Yeah, I go through the queues sometimes. I approved one message today that was in Spanish (or something looking kind of like it) but clearly on topic, but I haven't seen it come through. At least, I'm pretty sure I selected 'accept'. There were, I think, three I approved this morning, but I've only seen two come through. From: To: Time: Mon Feb 9 15:30:31 2009 she sent other messages that i approved but never showed up, either on the list or in the archives. From: To: Time: Mon Feb 9 15:31:09 2009 Then we need to complain... From: To: Time: Mon Feb 9 15:31:47 2009 Too bad the web browsers don't record the info about forms submitted... From: To: Time: Mon Feb 9 15:33:48 2009 also she signs herself from Centro de Tecnologia SAP From: To: Time: Mon Feb 9 15:35:32 2009 but maybe only related to SAP in terms of a consultancy that works on SAP stuff. From: To: Time: Mon Feb 9 15:46:19 2009 you're fairly sure you didn't accidentally hit a "discard all pending"? From: To: Time: Mon Feb 9 15:47:35 2009 I examined that message separately, clicked accept, submitted, got back to the full listing where the message was not listed. At least, I'm fairly sure that's how it went... :( From: To: Time: Mon Feb 9 15:54:43 2009 Ken, can you look at asn1_k_encode.c and comment on asn1_addlenfield destroying the input buffer on error but none of the other macros doing so? From: To: Time: Mon Feb 9 15:55:08 2009 looking... From: To: Time: Mon Feb 9 16:00:05 2009 It probably shouldn't, and nor should the other functions in that file that take asn1buf pointer arguments, since the caller should destroy them once on any error. Fortunately asn1buf_destroy appears to be idempotent. From: To: Time: Mon Feb 9 16:02:13 2009 Want me to go clean that up, or are you digging into it already? From: To: Time: Mon Feb 9 16:02:45 2009 I'm digging into it already. The idempotence of asn1buf_destroy is not actually helpful in this case. From: To: Time: Mon Feb 9 16:02:58 2009 Okay. From: To: Time: Mon Feb 9 16:03:07 2009 (Since only the local variable of the immediate caller gets nulled out, not the caller's caller's value.) From: To: Time: Mon Feb 9 16:04:26 2009 Oh. Yeah, that could be a problem. From: To: Time: Mon Feb 9 16:32:48 2009 Greg: Is tmpcode set in the error case? It's always used to set *code before returning... From: To: Time: Mon Feb 9 16:35:28 2009 It's only used if retval is 0. From: To: Time: Mon Feb 9 16:37:04 2009 The code could be simplified slightly (initialize tmpcode to NULL, get rid of that conditional return) but I think Coverity will be more likely to model the function correctly as it is. From: To: Time: Mon Feb 9 16:37:40 2009 (Previously, Coverity did not correctly model that the function only initialized *code when it returned 0. That was the original impetus for the change.) From: To: Time: Mon Feb 9 16:41:09 2009 Oh, I see. The control flow didn't really jump out at me. Okay. From: To: Time: Mon Feb 9 17:40:55 2009 Gaah. The FSF has started another mailbombing attack on the IETF. From: To: Time: Mon Feb 9 17:46:42 2009 another? or the same one, just resurrected by people discovering the bitrotted call to arms? From: To: Time: Mon Feb 9 17:47:19 2009 Same issue, seems to be a new call, I think. (A couple messages seemed to refer to the previous time.) From: To: Time: Mon Feb 9 17:49:46 2009 also, i discovered the hard way that gnu /usr/bin/env doesn't deal with flags reasonably. #!/usr/bin/perl -w tries to find the executable "perl -w" inside /usr/bin. From: To: Time: Mon Feb 9 17:49:50 2009 It's pretty blatant, and kind of lame. The messages are coming from email addresses in roughly alphabetical order over time. Some of them duplicate the same message text, though many of them are unique, and some indicate a pretty poor understanding of the situation -- like, one person objects to the IETF granting Red Hat the patent. (It's RedPhone that already has the patent, IETF is considering standardizing some TLS related thing that uses it.) From: To: Time: Mon Feb 9 17:50:08 2009 Yes, #! gives you only one program argument in some environments. From: To: Time: Mon Feb 9 17:50:55 2009 Wait... "#!/usr/bin/perl -w"? That should be fine. "#!/usr/bin/env /usr/bin/perl -w" I could see behaving the way you say. From: To: Time: Mon Feb 9 17:51:19 2009 But it wouldn't be env, it would be the kernel -- it would invoke env with argv[0] = "/usr/bin/env" and argv[1] = "/usr/bin/perl -w". From: To: Time: Mon Feb 9 17:52:15 2009 i meant #!/usr/bin/env perl -w From: To: Time: Mon Feb 9 17:52:38 2009 Oh okay. Hm. That should look for "perl -w", but not just in /usr/bin. From: To: Time: Mon Feb 9 17:53:03 2009 ... and they're up to the letter 'j'... From: To: Time: Mon Feb 9 17:53:39 2009 is this a spambot? or are these real people sending the messages and they are somehow being stimulated to do so on an alphabetical order basis? From: To: Time: Mon Feb 9 17:54:30 2009 Not clear. Given the steady rate at which they're coming in, I'm guessing people submit messages to the FSF, and then at some point the FSF blasts them all out. From: To: Time: Mon Feb 9 17:55:35 2009 Okay, that's wrong. The received headers indicate they've all come from different sources. From: To: Time: Mon Feb 9 17:55:58 2009 Oh... probably it's a moderation queue at ietf.org. One I'm looking at come in to the IETF last night. From: To: Time: Mon Feb 9 17:56:33 2009 Others are dated this afternoon. So, probably the mod queue is being processed in alphabetical order, as is normal with mailman. From: To: Time: Mon Feb 9 17:57:08 2009 They should've put the list in digest mode temporarily. :-) From: To: Time: Mon Feb 9 18:05:18 2009 ick. failing on the "one commit hook set to rule them all" due to "#!/usr/bin/env perl" being an old version on drugstore. From: To: Time: Mon Feb 9 18:08:15 2009 The ipc stream code lxs added uses "k5_" for its prefix. Tsk tsk... From: To: Time: Mon Feb 9 18:12:00 2009 k5_ isn't such a bad prefix, as long as it's not for public APIs From: To: Time: Mon Feb 9 18:12:52 2009 We should still avoid it if we have to export the symbol name from the library. From: To: Time: Mon Feb 9 19:12:00 2009 Ha. I just made 1349 lines of diffs to a file and it compiled the first time with no warnings. That doesn't happen very often. From: To: Time: Mon Feb 9 21:02:31 2009 There, 32 libkrb5 Coverity defects squashed in one fell swoop. From: To: Time: Tue Feb 10 11:16:44 2009 The outstanding defects in the automated tests dropped by almost 50 this morning. Nice progress... From: To: Time: Tue Feb 10 11:19:23 2009 Though, we've had lower numbers before. We had a jump of 101 the morning of 1/5, and haven't gotten 2/3 of the way back to where we were before... From: To: Time: Tue Feb 10 11:20:26 2009 Or was there a configuration change in the coverity setup then? From: To: Time: Tue Feb 10 11:23:06 2009 Or maybe we had problems with the snapshots, and that's when Luke's code got picked up... looking at some of the file names, and how the count went up by 101 but there were 114 new defects (meaning 13 went away or couldn't be correlated), I think it's probably a big code change like Luke's merge. From: To: Time: Tue Feb 10 11:30:38 2009 We had a big jump when Luke's code was merged, and another big jump when we went to Coverity 4.3.0. The more interesting number is the defects in libkrb5 proper, which is now down to two digits. From: To: Time: Tue Feb 10 11:32:47 2009 i've disabling commits from time to time as i tweak the hooks From: To: Time: Tue Feb 10 11:45:27 2009 i think things are stable again now From: To: Time: Tue Feb 10 11:47:11 2009 the last round of flailing brought to you by "remember to chmod +x" From: To: Time: Tue Feb 10 11:50:43 2009 how are we doing on gcc warnings? From: To: Time: Tue Feb 10 15:11:29 2009 Who asked this question? From: To: Time: Tue Feb 10 15:12:52 2009 greg ...? from pistolstar From: To: Time: Tue Feb 10 15:13:28 2009 What is Pistolstar? From: To: Time: Tue Feb 10 15:53:01 2009 I see links in the conference call detail report email, no attachments. From: To: Time: Tue Feb 10 15:53:12 2009 Oh, Tom's not here... From: To: Time: Wed Feb 11 10:41:23 2009 Damn, I had this great idea for an ASN.1 decoder test harness, but it doesn't work out. From: To: Time: Wed Feb 11 10:41:40 2009 interesting... From: To: Time: Wed Feb 11 10:43:02 2009 The idea was to encode a sample structure (working from krb5_encode_test), then decode all possible truncations of the buffer. From: To: Time: Wed Feb 11 10:43:45 2009 Unfortunately, that exercises very little code; a truncated encoding fails at asn1_get_sequence() at the beginning of most decoder functions. From: To: Time: Wed Feb 11 10:44:41 2009 What I want is a way to produce bogus encodings which will test every failure point within the decoders, without having to construct them by hand. From: To: Time: Wed Feb 11 10:47:05 2009 Maybe I'll try perturbing the bytes of the encoding. From: To: Time: Wed Feb 11 10:55:58 2009 That works better. Not sure whether it's comprehensive. Definitely finds some leaks. From: To: Time: Wed Feb 11 10:56:50 2009 You could tweak the encoder to generate bad encodings... Set a counter, and insert various decision points where the counter gets decremented, and if it hits zero, generate a corrupted encoding of the current thing. Maybe multiple decision points if you want to test multiple forms of corruption. From: To: Time: Wed Feb 11 10:58:36 2009 Interesting, but I'm not sure whether I want to complicate the encoder that much. From: To: Time: Wed Feb 11 10:59:05 2009 Fair enough. Especially if you've already done a bunch of tests though other means... From: To: Time: Wed Feb 11 11:03:29 2009 some of the existing tests were hand-coded encodings that were intended to exercise failure cases in the decoders From: To: Time: Wed Feb 11 12:02:00 2009 I'm a little confused that encode_krb5_pwd_sequence encodes a single passwd_phrase_element. (... which is not a namespace-protected type name.) From: To: Time: Wed Feb 11 12:03:06 2009 what part of the protocol uses this? From: To: Time: Wed Feb 11 12:03:31 2009 I don't know. It really looks like contributed code we took at some point without adequate review. From: To: Time: Wed Feb 11 12:03:57 2009 I'm trying to figure out when it was added, but svn blame isn't working on krb5.hin due to (apparently) some kind of binary content in the file. From: To: Time: Wed Feb 11 12:03:59 2009 "Sandia password generation".... yeah, looks like. From: To: Time: Wed Feb 11 12:04:39 2009 svn blame won't work because at some point the ".hin" file got registered as non-text and only got corrected substantially later. From: To: Time: Wed Feb 11 12:04:57 2009 Ah, the problem is with the history, got it. From: To: Time: Wed Feb 11 12:05:37 2009 of course, frobbing the history breaks everyone's mirrors. From: To: Time: Wed Feb 11 12:10:49 2009 Ideally, new exported functions are declared *without* KRB5_CALLCONV, right? From: To: Time: Wed Feb 11 12:16:26 2009 internal or not? From: To: Time: Wed Feb 11 12:18:06 2009 the guideline we had used in the past was "KRB5_CALLCONV except for variadic functions" for the sake of consistency. From: To: Time: Wed Feb 11 12:19:21 2009 I'll go with consistency. (This is a krb5_free function for passwd_phrase_element, and will be exported, but only declared in k5-int.h. But it's very similar to other functions using KRB5_CALLCONV.) From: To: Time: Wed Feb 11 12:20:11 2009 basically C-like vs Pascal-like stack frames for win32 platforms, i believe. KRB5_CALLCONV corresponds to Pascal-like, which doesn't handle variadic functions. From: To: Time: Wed Feb 11 14:06:01 2009 Yeah, I don't know if there's a good technical argument in favor of KRB5_CALLCONV, except maybe "things don't break if I pass the wrong number of arguments" or something like that, but it's where we are now... In our New API, we should consider dropping it. From: To: Time: Wed Feb 11 14:44:31 2009 ... there's an encode_krb5_sam_key but no decode_krb5_sam_key? From: To: Time: Wed Feb 11 14:46:36 2009 Interesting. We also never use the encoder outside of the test program. I'm not sure we should get rid of it, but you could probably comment out the encoder. From: To: Time: Wed Feb 11 14:47:45 2009 For my current purposes, it doesn't matter; I just won't include a test case for the decoder. From: To: Time: Wed Feb 11 14:50:39 2009 Also, encode_krb5_sam_response is exported but encode_krb5_sam_response_2 is only exported via the accessor (and the decoder is not exported). From: To: Time: Wed Feb 11 17:38:12 2009 repository migration is ZOMG NOW!!! in case you care. From: To: Time: Wed Feb 11 19:03:53 2009 Well, after a few hours of work, I have gssmaster and gssmaggot now compiling *and* running on the Mac (to completion of the master process) in the case where you supply an invalid password (so it can't actually run the tests). I'm surprised it worked for Adam before -- snprintf vs vsnprintf errors, select passing 0 for the max file descriptor, other errors... From: To: Time: Wed Feb 11 19:04:25 2009 And I keep forgetting this annoying habit it has of destroying my existing Kerberos tickets when I run it... From: To: Time: Wed Feb 11 19:05:37 2009 (And, on the Mac, setting the default principal name to a variant of my principal name, with funky capitalization.) From: To: Time: Wed Feb 11 20:59:05 2009 Is the repository URI changing? From: To: Time: Wed Feb 11 21:01:28 2009 Apparently a migration is happening, because the old machine ran out of space. From: To: Time: Wed Feb 11 21:02:07 2009 So svn.mit.edu maps to a new machine. But I was just discovering that I'm getting "connection closed unexpectedly" type errors when I try to use svn to it. I don't know if it's supposed to be finished yet. From: To: Time: Wed Feb 11 21:02:31 2009 (I only heard about the migration from Tom. That it was happening tonight, I mean.) From: To: Time: Wed Feb 11 21:06:15 2009 i wasn't expecting it to take this long. i was going to hopefully assume that they weren't finished yet. From: To: Time: Thu Feb 12 11:08:22 2009 Not working yet... Sending configure.ac Transmitting file data .svn: Commit failed (details follow): svn: 'pre-commit' hook failed with error output: Can't exec "/svn/krb5/hooks/svntxnprop/svntxnprop.Linux": No such file or directory at /svn/krb5/hooks/lib/SVN/Hook/Alloc.pm line 23. Can't run svntxnprop: No such file or directory at /svn/krb5/hooks/lib/SVN/Hook/Alloc.pm line 23. From: To: Time: Thu Feb 12 11:13:38 2009 I can't get into the athenasnap account to look around. From: To: Time: Thu Feb 12 11:15:38 2009 Looks like they've copied over the old root .k5login... looking... From: To: Time: Thu Feb 12 11:16:30 2009 Ah. There's hooks/svntxnprop/svntxnprop.SunOS and hooks/svntxnprop.Linux ... note the missing subdirectory there. From: To: Time: Thu Feb 12 11:16:51 2009 Not sure if I should be messing with it or just informing ops though. From: To: Time: Thu Feb 12 11:17:00 2009 hang on From: To: Time: Thu Feb 12 11:17:35 2009 i was going to try to test this but haven't been feeling well. i will take a look. From: To: Time: Thu Feb 12 11:18:03 2009 If it's something we're allowed to mess around with, I'll try moving it into the place where it's being looked for and test it out. From: To: Time: Thu Feb 12 11:18:15 2009 I just don't want to step on ops's toes. From: To: Time: Thu Feb 12 11:20:43 2009 no, it's my setup. From: To: Time: Thu Feb 12 11:20:58 2009 but i would rather deal with it in case something goes wrong. From: To: Time: Thu Feb 12 11:21:20 2009 Okay, I'll leave it to you then. From: To: Time: Thu Feb 12 11:22:41 2009 oh. the program just plain isn't there. From: To: Time: Thu Feb 12 11:23:09 2009 or maybe it is. From: To: Time: Thu Feb 12 11:23:09 2009 I saw svntxnprop.Linux one directory up, in the wrong place... From: To: Time: Thu Feb 12 11:36:37 2009 hm, fisheye looks broken. From: To: Time: Thu Feb 12 11:37:22 2009 also anonsvn mirroring is currently broken. From: To: Time: Thu Feb 12 11:47:59 2009 i think it's working now. (at least the RT integration part) From: To: Time: Thu Feb 12 11:48:09 2009 still have to work on the anonsvn mirroring From: To: Time: Thu Feb 12 11:51:47 2009 Well, my checkin worked this time, that's a good sign. :) From: To: Time: Thu Feb 12 11:51:50 2009 Thanks. From: To: Time: Thu Feb 12 11:51:54 2009 Is anyone attached to the APIs of asn1_k_decode.c? It will be easier to write proper cleanup handlers if the asn1_k_decode functions allocate memory for the krb5 structures instead of filling them in. (Right now a cleanup handler can't know how much of a structure is initialized, and I'm nervous about calling the krb5_free functions on half-initialized structures.) From: To: Time: Thu Feb 12 11:54:11 2009 Unless something there is exported from the library or via the accessor structure (and I think both are unlikely but not impossible), go ahead and change it. From: To: Time: Thu Feb 12 11:54:39 2009 Any chance I can tempt you to look at making the decoders table-driven, sharing tables with the encoders? :) From: To: Time: Thu Feb 12 11:55:02 2009 (And for that matter, perhaps the free functions could use the structure-description aspects too.) From: To: Time: Thu Feb 12 11:57:32 2009 Maybe. What I'm thinking of doing is an easier transformation of the existing code. From: To: Time: Thu Feb 12 11:57:32 2009 what did you check in? i'm not seeing anything. From: To: Time: Thu Feb 12 11:58:29 2009 oh, gssmonger. From: To: Time: Thu Feb 12 12:06:13 2009 Yeah, transformations are the easy way. My path to a table-driven encoder involved a series of transformations. First, make the code more regular, then push function-call info into a static structure per call, then group the structures into an array, stuff like that. M-x replace-regexp is extremely helpful. :) From: To: Time: Thu Feb 12 12:08:24 2009 Why do I feel like I'm only seeing half the conversation? From: To: Time: Thu Feb 12 12:11:20 2009 I dunno... what are you seeing, and what do you think you're missing? From: To: Time: Thu Feb 12 12:11:58 2009 Context from your last message, except I found it From: To: Time: Thu Feb 12 12:12:59 2009 Ah, okay. From: To: Time: Thu Feb 12 12:16:07 2009 Be aware that I'm going to be working on encoders and decoders for FAST structures soon and these may or may not want to get merged on to 1.7 depending on what you want to do with fast. From: To: Time: Thu Feb 12 12:17:34 2009 So, if there are going to be changes to asn1_* we should coordinate From: To: Time: Thu Feb 12 12:29:43 2009 Maybe I'll revisit this after the FAST work is done. From: To: Time: Thu Feb 12 14:35:33 2009 ok From: To: Time: Thu Feb 12 14:37:19 2009 Ah, I think that goes back to when we were inappropriately using signed int for some length fields, and giving -1 a special meaning. It should be safe to take out the >=0 checks. From: To: Time: Thu Feb 12 14:38:56 2009 We still do that for afs3 salt, right? Or did that go away in the krb4 change From: To: Time: Thu Feb 12 14:39:11 2009 Hmm, maybe not, just a sec... maybe it should be checking >0 ? From: To: Time: Thu Feb 12 14:39:30 2009 No, we should still support the databases with old afs-derived entries. From: To: Time: Thu Feb 12 14:40:47 2009 Oh, I think getting rid of the checks is probably okay. From: To: Time: Thu Feb 12 14:43:16 2009 ... removed. From: To: Time: Thu Feb 12 15:35:40 2009 I may be able to understand this function when I'm more lucid, but I certainly can't right now. CID #877, in krb5int_rd_setpw_rep, ap_rep.length can be used uninitialized if the packet is an error packet. From: To: Time: Thu Feb 12 15:42:20 2009 Looks like it. I think depending on stack garbage we might get a false success indication. From: To: Time: Thu Feb 12 15:42:37 2009 Looking From: To: Time: Thu Feb 12 15:47:41 2009 Yeah. I think ap_rep.length wants to be initialized From: To: Time: Thu Feb 12 16:08:12 2009 Looks like Prevent was quietly complaining about errors parsing two files, and not analyzing them at all. In my tree I get 27 new defects since my last run, most of them in tcl_kadm5.c. I've checked in fixes for both -- apparently "const const ..." confuses it. From: To: Time: Thu Feb 12 16:18:03 2009 krb5_send_tgs used to be in krb5.h. In 1.3 it was under #if KRB5_PRIVATE, I don't know about earlier releases. From: To: Time: Thu Feb 12 16:18:16 2009 (re: sam's email to krbdev) From: To: Time: Thu Feb 12 16:26:13 2009 It's krb5_private in 1.2.5, which defines the API From: To: Time: Thu Feb 12 16:27:19 2009 Okay, good enough... From: To: Time: Fri Feb 13 10:57:15 2009 When is anonsvn going to be fixed? From: To: Time: Fri Feb 13 10:57:56 2009 i'll try to work on it today. (still at home sick.) likely solution will involve getting afs tokens on the main svn server from locally stored keytab. From: To: Time: Fri Feb 13 11:48:35 2009 ok, that's weird Failed kinit to krbsnap: Illegal seek at /svn/krb5/hooks/commit-handler line 181. From: To: Time: Fri Feb 13 11:50:05 2009 the weird thing is that the tickets get obtained anyway. From: To: Time: Fri Feb 13 11:51:03 2009 v4 problem of some kind? From: To: Time: Fri Feb 13 11:52:09 2009 shouldn't be. this version of kinit defaults to not doing -4. From: To: Time: Fri Feb 13 11:57:44 2009 So, for FAST data structures. . . We have krb5_kdc_req which combines the req_body and the req. Do I want to have a separate padata in the krb5_fast_req structure or do I want to use the padata in the krb5_kdc_req? If I use the same padata then you'd typically construct a kdc_req_body, put together padata , put together a fast swap out the padata send From: To: Time: Fri Feb 13 12:06:07 2009 anonsvn mirroring looks like it's working again, at least to afs From: To: Time: Fri Feb 13 12:06:38 2009 i think i reversed the test on the return value of perl's system() From: To: Time: Fri Feb 13 12:06:57 2009 perl's system returns the exit status of the program you ran From: To: Time: Fri Feb 13 12:07:14 2009 (well, the status as returned by wait or in $?) From: To: Time: Fri Feb 13 12:08:20 2009 ... or -1 if there is some other error, like fork or wait failing From: To: Time: Fri Feb 13 12:17:03 2009 sent request to kick fisheye From: To: Time: Fri Feb 13 12:33:21 2009 fisheye kicked. back to r22000. From: To: Time: Fri Feb 13 12:48:56 2009 Anyone familiar with dns-sd? I'm trying to figure out if this "trailing dot" stuff is just the dns-sd folks saying "we want to make sure the software knows it's an FQDN so we include the dot when we get the option", or if they're saying "dns-sd really needs to behave differently from normal DNS so we add the dot when it would normally not be included"... From: To: Time: Fri Feb 13 12:49:55 2009 I'm getting the sense it's the former, probably. From: To: Time: Fri Feb 13 12:50:19 2009 early DNS RFCs suggest using a trailing dot to unambiguously identify FQDNs in user interfaces. note that RFC 821 and successors explicitly forbid the trailing dot, though. From: To: Time: Fri Feb 13 12:50:50 2009 And various standard APIs omit the dot these days too. From: To: Time: Fri Feb 13 12:52:28 2009 I wonder if, with principal alias processing, we're going to get bit by the ambiguity between host/fqdn and host/alias, since we don't use the trailing dot. From: To: Time: Fri Feb 13 12:52:49 2009 on output, yes. nearly everything handles it on input, and it's still meaningful in master files From: To: Time: Fri Feb 13 12:55:12 2009 FQDN doesn't necessarily mean "canonical name", whatever that means. From: To: Time: Fri Feb 13 12:55:56 2009 No, but it does mean "not relative", so if you know you have an FQDN you don't need the trailing dot also, necessarily. From: To: Time: Fri Feb 13 12:56:08 2009 ken, I'm not sure what you mean From: To: Time: Fri Feb 13 12:56:26 2009 wrt principal alias confusion From: To: Time: Fri Feb 13 12:56:45 2009 In the DNS, "canonical name" means one that's not an alias From: To: Time: Fri Feb 13 12:57:48 2009 Wouldn't it be more correct to say that a canonical name is the result of following a CNAME record? From: To: Time: Fri Feb 13 12:58:33 2009 Sorry. host/fqdn vs host/shortname ... e.g., host/mit.edu if one of your hosts is mit.edu.example.com. If we were doing DNS queries (with domain search paths) to try to process unrecognized hostnames in host/* principals, we'd have an issue. Since we aren't, currently, I'm just wondering if we've still got such problems to look forward to. From: To: Time: Fri Feb 13 12:58:56 2009 No, I don't think so. Names used in the RHS of an RR are supposed to be "canonical". From: To: Time: Fri Feb 13 12:59:16 2009 We'd logically turn host/foo into host/foo.example.com. But what about host/foo.bar if bar is a legitimate TLD too? From: To: Time: Fri Feb 13 12:59:23 2009 damn jabber and its lack of useful threading From: To: Time: Fri Feb 13 12:59:27 2009 :) From: To: Time: Fri Feb 13 12:59:40 2009 you would, even if host/foo weren't registered? From: To: Time: Fri Feb 13 12:59:42 2009 The RHS is supposed to be canonical, but isn't always. From: To: Time: Fri Feb 13 13:00:18 2009 Well, you might implement heuristics rather than a table, so if you don't have host/X in your database, you try host/X.example.com, for example. From: To: Time: Fri Feb 13 13:00:41 2009 Right. It's _supposed_ to always be canonical, but often it isn't, and lots of things are forgiving about that. But "canonical" here means it is not an alias, not that it is the result of following an alias. From: To: Time: Fri Feb 13 13:01:06 2009 Yes, I apologize, I shouldn't have used the word "alias" in this case... From: To: Time: Fri Feb 13 13:01:29 2009 worse, the name you get by following a CNAME record might itself be an alias, and thus not canonical (though that's supposed to be forbidden) From: To: Time: Fri Feb 13 13:01:40 2009 I was responding to sam's comment about what "canonical" means. From: To: Time: Fri Feb 13 13:01:55 2009 I've seen that case come up, yeah... From: To: Time: Fri Feb 13 13:03:06 2009 Anyway, it seems like the issue you're talking about is about fully-qualified names vs not, no? In which case, a couple of thoughts... - you could decide to do foo->foo.example.com only where foo has no dots - you could have an ndots config value - people who have (relative) names like foo.bar where bar is a valid TLD already have problems. From: To: Time: Fri Feb 13 13:03:58 2009 Our largest third-level domain is cs.cmu.edu No one thinks foo.cs means foo.cs. rather than foo.cs.cmu.edu From: To: Time: Fri Feb 13 13:05:38 2009 Right, fq vs not. We will have to figure that out -- or at least point out the issue if/when we set up the process for people to define their own heuristics. From: To: Time: Fri Feb 13 13:06:14 2009 In the shorter term, there's the guy on c.p.k asking about using Kerberos with dns-sd, because he wound up with host/foo.bar.@realm . From: To: Time: Fri Feb 13 13:07:58 2009 His email goes on about how the trailing dot on the hostname is the right thing for dns-sd, but their web pages sound like they're just being militant about specifying FQDNs explicitly when they can, not that dns-sd is magical and requires a different syntax. From: To: Time: Fri Feb 13 13:09:01 2009 I believe your interpretation is correct From: To: Time: Fri Feb 13 13:09:29 2009 Looks like we don't have a test program for trying out krb5_sname_to_principal. From: To: Time: Fri Feb 13 13:09:39 2009 I miss Saber C sometimes. From: To: Time: Fri Feb 13 13:10:28 2009 perl Inline::C From: To: Time: Fri Feb 13 13:11:45 2009 hmm... From: To: Time: Fri Feb 13 13:13:26 2009 No, it doesn't look like quite enough. I want to be able to type in something like: #include krb5_principal x; krb5_context ctx; krb5_init_context(&ctx); ... and define variables and call functions and such in real time. From: To: Time: Fri Feb 13 13:16:20 2009 > perl Inline::C That is evil From: To: Time: Fri Feb 13 13:19:05 2009 Ugh. Well, running gdb on kinit and breaking at the password prompt gets me partway there, but we don't have constants like KRB5_NT_SRV_HST available in gdb. Blame it on the debugger and compiler, sure, but realistically, we should generate an enumerator if we want to export such values. From: To: Time: Fri Feb 13 13:24:13 2009 Hrm. You should be able to do something with Inline::bind() and a certain amount of trickery and some limitations on what you can do. The main problem I see is that functions you define in separate calls to Inline::bind() might not be able to see each other or each others' globals. From: To: Time: Fri Feb 13 14:18:19 2009 Sometimes I think we over-abbreviate, and then I see type names like krb5_external_principal_identifier. From: To: Time: Fri Feb 13 14:22:50 2009 And then we get stuff like krb5_get_init_creds_opt_set_change_password_prompt even with abbreviations. From: To: Time: Fri Feb 13 14:24:08 2009 By that point I really feel like you should add some _blah_blah_blah or at least something repetative. From: To: Time: Fri Feb 13 14:24:20 2009 _bork_bork_bork From: To: Time: Fri Feb 13 14:24:58 2009 Of course it would be better (in some ways) if we had used _gicopt for get_init_creds_opt From: To: Time: Fri Feb 13 14:24:59 2009 We don't have any names where "krb5" shows up twice. krb5_decode_krb5_foo for example. From: To: Time: Fri Feb 13 14:25:52 2009 krb5_upgrade_from_krb4_to_krb5_via_sploitz From: To: Time: Fri Feb 13 14:26:18 2009 heh From: To: Time: Fri Feb 13 14:27:03 2009 implementation might get a bit complicated. From: To: Time: Fri Feb 13 14:28:17 2009 Well, it relies on primitives like mit_des_decrypt_via_ps3_cluster From: To: Time: Fri Feb 13 14:29:35 2009 And you have to identify the ps3 cluster machines in your config file? From: To: Time: Fri Feb 13 14:30:09 2009 it will find them via mdns advertisments From: To: Time: Fri Feb 13 14:30:10 2009 Or, I suppose we could look it up with DNS SRV. From: To: Time: Fri Feb 13 14:31:56 2009 hm. somehow i failed to notice that Monday is a holiday. From: To: Time: Fri Feb 13 14:32:18 2009 Yep. All day long. From: To: Time: Fri Feb 13 16:09:31 2009 Gah. krb5_free_cred_enc_part is a body free function, not a full structure free. From: To: Time: Sun Feb 15 02:02:49 2009 This room is not anonymous. From: To: Time: Tue Feb 17 11:23:52 2009 over how many commits is the "consolidate config file strings as macros" change spread? From: To: Time: Tue Feb 17 11:49:32 2009 21871, 21879,21880 From: To: Time: Tue Feb 17 11:50:32 2009 thanks. i'll also look at Greg's related changes. From: To: Time: Tue Feb 17 11:55:17 2009 In krb5_kuserok() we use access() to check if .k5login exists, and fall back to an aname-to-lname check if not. (Otherwise, we open it and read it.) I would like to change the code to simply try opening .k5login, and fall back if we can't open it. That does introduce a slight behavior change if euid != ruid. I think it's a desirable behavior change, but I'm checking here first. (ksu doesn't use krb5_kuserok; it has its own code which checks for existence using stat.) From: To: Time: Tue Feb 17 12:09:10 2009 access with R_OK or F_OK? From: To: Time: Tue Feb 17 12:10:16 2009 F_OK. Which I guess is just a stat? From: To: Time: Tue Feb 17 12:11:03 2009 (I just timed out and checked in my change but I can revisit.) From: To: Time: Tue Feb 17 12:11:10 2009 Effectively, but it still does the access check with ruid (wrt 'x' on directories leading to the .klogin). I think the change is desirable, though there's some question of what should happen if the file exist but we can't read it (what happens now?) From: To: Time: Tue Feb 17 12:12:35 2009 If access() succeeds but fopen() fails, krb5_kuserok returns false prior to my change. Now it falls back to aname-to-lname. That's perhaps not a desirable change. From: To: Time: Tue Feb 17 12:13:40 2009 Yeah; if I were going to object, it'd be because of that, not because of the euid!=ruid corner case From: To: Time: Wed Feb 18 11:24:20 2009 hm, i had to manually poke at launchd to make portmapper start running. From: To: Time: Wed Feb 18 11:25:03 2009 Did you chown/chmod the socket so the RPC library could try to poke it? From: To: Time: Wed Feb 18 11:25:15 2009 oh, that's probably what i forgot. From: To: Time: Wed Feb 18 11:25:31 2009 socket permissions get reset at boot From: To: Time: Wed Feb 18 11:25:38 2009 Yeah, I've got to get my ADC account access straightened out, and report that. From: To: Time: Wed Feb 18 11:27:27 2009 i wonder if there's a way to frob the plist so that will work From: To: Time: Wed Feb 18 11:34:03 2009 Probably; there are other launched daemons like ntpd that run all the time, so copying some of the config data from there might work. From: To: Time: Wed Feb 18 11:36:49 2009 Huh. Looking at the opendarwin portmap.c code, it seems to actually want to get info about the OnDemandTickler setting if it's started from launchd. From: To: Time: Wed Feb 18 11:37:06 2009 the socket permissions are probably settable from the plist From: To: Time: Wed Feb 18 11:37:25 2009 Oh, here: http://www.corebounce.org/wiki/Soundium/PortmapMacosX -- info on how to make it run by default (under 10.4). From: To: Time: Wed Feb 18 11:38:19 2009 Maybe. I haven't found any info on controlling the socket permissions so far. From: To: Time: Wed Feb 18 11:38:48 2009 SockPathMode This optional key specifies the mode of the socket. Known bug: Property lists don't support octal, so please convert the value to decimal. From: To: Time: Wed Feb 18 11:39:11 2009 Just found that in one of the other plist files, yeah. From: To: Time: Wed Feb 18 11:59:48 2009 And, I just had a software update to install, so I tried it, and it appears that SockPathMode is working. Haven't tried running the test suite yet though. From: To: Time: Wed Feb 18 12:06:20 2009 Test suite seems to be working. From: To: Time: Wed Feb 18 12:12:12 2009 #6362 should be pulled up? From: To: Time: Wed Feb 18 12:13:24 2009 nevermind; marked it myself. From: To: Time: Wed Feb 18 12:28:48 2009 re #6363, how did that ever work? From: To: Time: Wed Feb 18 12:29:39 2009 We probably weren't checking sequence numbers in any tests. From: To: Time: Wed Feb 18 13:18:04 2009 incoming.... (bunch of pullup commits) From: To: Time: Wed Feb 18 13:27:06 2009 ok, git-svn is somewhat more pleasant than svk, now that i'm somewhat used to it. From: To: Time: Wed Feb 18 15:21:16 2009 Wow. IE7 crashes (nearly?) every time I try to download something from sourceforge. And two or three of the packages we need to build kfw are on sourceforge. From: To: Time: Wed Feb 18 15:21:50 2009 (Including tortoisesvn, which I'm downloading to get tortoiseplink, because our internal web pages point to a plink.exe that's no longer in jaltman's MIT directory.) From: To: Time: Wed Feb 18 16:12:42 2009 *sigh* Our docs say we only support VS2003 for building KFW. But the project file for gssmonger requires VS2005 (or, presumably, later). And I'm not sure, but I think I recall Kevin complaining that VS is one of those packages where two versions can't co-exist. From: To: Time: Wed Feb 18 16:13:26 2009 don't let it bother you. From: To: Time: Wed Feb 18 16:15:17 2009 use VS2005 and we'll deal with kfw later. From: To: Time: Wed Feb 18 16:16:46 2009 As it happens, I've got two VMs set up, one on my laptop where I'm trying to get kfw building again, and one I'm still setting up here (hence the ie7 complaints). So making this one incapable of building kfw isn't such a big deal. From: To: Time: Wed Feb 18 16:17:16 2009 I just don't remember where I got the vs2003 cd image, so I've got to poke around and track down where I get vs2005+ from... From: To: Time: Wed Feb 18 16:19:53 2009 I don't see it on any of the local software lists; are we supposed to buy it? And if so, shouldn't Kevin have had an image and product key I can use (if no one else has taken it)? From: To: Time: Wed Feb 18 16:22:29 2009 Oh, I need to go fetch my car at the garage. Back in a little while.... From: To: Time: Wed Feb 18 17:23:07 2009 Apparently 90-day trial versions of vs2008 can be had for free, so... From: To: Time: Wed Feb 18 18:32:28 2009 i'm getting test failures in kprop.exp. not sure why yet. From: To: Time: Wed Feb 18 18:42:42 2009 they persist on the trunk so i'm going to assume it wasn't something i broke on the branch. From: To: Time: Wed Feb 18 18:43:08 2009 I guess I can have vs 2008 and vs .net 2003 installed at once. Not, apparently, in under 20G of disk space, though. From: To: Time: Wed Feb 18 18:48:07 2009 with or without MSDN reference library? From: To: Time: Wed Feb 18 18:48:34 2009 That's the bit that was going to push it over the edge. From: To: Time: Thu Feb 19 14:25:16 2009 I just looked at a test run I kicked off last night. The kprop.exp test worked okay for me. Any idea yet what last night's problem was? From: To: Time: Thu Feb 19 14:25:44 2009 no clue. went away after a clean rebuild. maybe version mismatch of some sort. From: To: Time: Thu Feb 19 14:25:53 2009 i hate it when that happens. From: To: Time: Thu Feb 19 14:25:58 2009 I hate it when th... yeah. From: To: Time: Thu Feb 19 16:17:51 2009 My Windows-driven gssmonger test is running a lot longer, and generating a lot more output, than the Linux-driven one. Though (a) the log file on Windows is XML instead of plain text, and (b) there seem to be some small delays that make me suspect the delayed-ack+Nagle workaround I tried isn't quite right for Windows. From: To: Time: Thu Feb 19 16:18:39 2009 (Or maybe for Mac too, hard to say.) From: To: Time: Fri Feb 20 12:27:33 2009 What PGP key server URL do people normally use? From: To: Time: Fri Feb 20 12:28:09 2009 x-hkp://pgp.mit.edu is what i use From: To: Time: Fri Feb 20 12:29:58 2009 Thanks. From: To: Time: Fri Feb 20 14:45:52 2009 not feeling too hot today, going to head home early. From: To: Time: Fri Feb 20 14:46:08 2009 may be online later. From: To: Time: Sun Feb 22 02:02:33 2009 This room is not anonymous. From: To: Time: Mon Feb 23 15:03:35 2009 Off to pick up car from garage, back in a little while... From: To: Time: Mon Feb 23 15:46:04 2009 *vroom* Back... From: To: Time: Tue Feb 24 14:30:08 2009 I'm in a position to help. From: To: Time: Tue Feb 24 14:31:40 2009 I'm mostly trying to avoid getting messed up by the slight differences between asn1_k_decode vs krb5_decode (the main one seems to be that if I need an asn1buf as an argument I belong in asn1_k_decode, but the macros seem to be slightly different) and things like the difference between setup and setup_buf_only From: To: Time: Tue Feb 24 14:34:49 2009 And when do I need my own if(retval) clean_return(retval)? Only if I call asn1_decode_something myself? I guess getfield and friends handle error exits directly? From: To: Time: Tue Feb 24 14:35:11 2009 (Sorry, simultaneously talking about preauth stuff in person.) From: To: Time: Tue Feb 24 14:36:14 2009 If you use a macro, you don't need to process retval. If you call a function which returns an error, you need to do the if (retval) clean_return(retval). Unless there's something odd about your structures you shouldn't need to directly call functions. From: To: Time: Tue Feb 24 14:37:38 2009 There seem to be a lot of things for which there is something odd and functions get called directly:-) From: To: Time: Tue Feb 24 14:40:37 2009 Arrays, generally. From: To: Time: Tue Feb 24 14:41:06 2009 (Also, some of the decoders expanded out the macros because the person writing the code wasn't clever enough to put a * in front of one of the arguments, I think. And there are no test cases so I couldn't safely fix that.) From: To: Time: Tue Feb 24 14:46:00 2009 O, yeah, I just found one of those. From: To: Time: Tue Feb 24 16:03:45 2009 How do these decoders free structure members on error? From: To: Time: Tue Feb 24 16:06:22 2009 Well, I see how asn1_k_decode does it. but not so much krb5_decode From: To: Time: Tue Feb 24 16:08:21 2009 Actually it seems like a lot of the decoders are fairly leaky From: To: Time: Tue Feb 24 16:12:50 2009 No, it's just easy to write a leaky encoder From: To: Time: Tue Feb 24 17:49:15 2009 I made a fairly comprehensive pass over the ASN.1 decoders and plugged hopefully most of the leaks. From: To: Time: Tue Feb 24 17:51:02 2009 In krb5_decode, the general approach is to null out all of the fields, then call krb5_free_foo(NULL, rep) in the cleanup handler, under the assumption that our freeing routines will be okay with null fields and don't actually require a context. From: To: Time: Wed Feb 25 12:18:23 2009 Yes, eight items, all marked closed. Most of them just indicate that a support request you had me file has been transferred into their bug database. And, one discussing how the current version of Safari doesn't play nicely with the web site for uploading files, but Firefox seems to work fine. From: To: Time: Wed Feb 25 12:18:43 2009 Okay, I won't ask in that case. From: To: Time: Wed Feb 25 12:20:47 2009 Oh, and I filed one other report about something I noticed while I was playing with some non-Kerberos software. If you use something like #define foo(X) (0 ? (*(int *)0 = (X) : (X)) to force type checking/conversion, it doesn't recognize early enough that the assignment won't ever get executed, so printf("%d%d", foo(a), foo(b)); gets a bogus defect report about an undefined evaluation order. From: To: Time: Wed Feb 25 12:24:29 2009 Oh, and one more you didn't see... const const int x = 42; ... confuses the parser code, and it fails to analyze the file. We were getting a report of two parse errors buried in the middle of the output, but a zero exit status so we happily continue on and analyze the rest of the files. I fixed those in our sources and we should have no parse errors now. They did suggest a tweak to coverity_config.xml to work around it in case we couldn't alter the sources. From: To: Time: Thu Feb 26 11:25:18 2009 Can I use DEFFIELDTYPE(..., FIELDOF_NORM)) to handle a single arm choice in the encoder? From: To: Time: Thu Feb 26 11:26:05 2009 Encoder is more Ken's department, but checking if I can answer that... From: To: Time: Thu Feb 26 11:26:10 2009 I think it should work, yeah. From: To: Time: Thu Feb 26 11:32:14 2009 As best I recall, a CHOICE doesn't add any additional wrapping, you just encode the chosen element, and the constraints imposed on how you can use CHOICE make that sufficient. So that sounds like the right thing to use, until there's real CHOICE support. From: To: Time: Thu Feb 26 11:33:07 2009 Now I need to figure out how to deal with unwrapping a context tag (instead of an app tag) around a sequence for the decoder. From: To: Time: Thu Feb 26 11:36:05 2009 It looks like I can just call next_tag() and then check tagnum? From: To: Time: Thu Feb 26 11:37:33 2009 Depends. Some of the macros finish with a call to next_tag so you might already be all set. From: To: Time: Thu Feb 26 11:38:04 2009 Oh, but if this is the start of your CHOICE decoder, yeah, you probably need to start with next_tag yourself. From: To: Time: Thu Feb 26 11:38:26 2009 Yeah, this will be just before begin_structure From: To: Time: Thu Feb 26 11:38:53 2009 What's the right error return for arm of choice we don't know how to deal with? From: To: Time: Thu Feb 26 11:39:48 2009 Probably ASN1_BAD_ID. From: To: Time: Thu Feb 26 11:40:43 2009 OK, not a new error? From: To: Time: Thu Feb 26 11:44:46 2009 There are other places where we return that for an unexpected tag value. Certain other cases produce ASN1_MISSING_FIELD or ASN1_MISPLACED_FIELD, but I think that's usually to do with numeric ordering of tags in a sequence. If a CHOICE has an unexpected value, MISSING_FIELD doesn't apply; I guess you could use MISPLACED_FIELD if you want. I don't see a need for a new error code for this case. From: To: Time: Thu Feb 26 11:46:24 2009 Yeah, it looks like currently MISPLACED_FIELD is only used in the same places as MISSING_FIELD; one for a tag number lower than expected, the other for one too high. From: To: Time: Thu Feb 26 11:46:34 2009 I think the new encoder structure is a major improvement. From: To: Time: Thu Feb 26 11:47:00 2009 Thanks, that's good to hear. I was afraid the learning curve and the warts it still has might be too much... From: To: Time: Thu Feb 26 11:47:23 2009 Now, if we could only get the decoders rewritten too... :-) From: To: Time: Thu Feb 26 11:48:12 2009 I'm reasonably good at learning DSLs quickly. I've spent two hours 15 minutes on the decoders an an hour on the encoders and am at about the same point in both From: To: Time: Thu Feb 26 11:48:17 2009 And I think we'd eventually have enough data describing the C structures that we could probably fold in the "free" functions too, actually, or nearly enough. From: To: Time: Thu Feb 26 11:48:36 2009 DSLs? From: To: Time: Thu Feb 26 11:49:23 2009 domain specific languages From: To: Time: Thu Feb 26 11:49:42 2009 Ah, which is what a pile of macros effectively is. From: To: Time: Thu Feb 26 11:49:51 2009 I thought a little about trying to produce a more logical and readable DSL for this, rather than C macros, but haven't much experience designing DSLs, and it really should encompass the decoder parts too which I hadn't tackled, so I didn't think too much about it. PRobably also more work than it would be worth... From: To: Time: Thu Feb 26 11:51:22 2009 I propose ASN.1 abstract syntax as a candidate starting point if you are going to do a DSL for this:-) From: To: Time: Thu Feb 26 11:52:13 2009 My biggest complaint about DSLs is that no one ever gets to the point of writing the domain-specific debugger. From: To: Time: Thu Feb 26 11:53:22 2009 It certainly either would have been the starting point, or would have been one of two inputs (with the second describing just the correlation and not so much the ASN.1 type details). But unless someone wants to pay me for it, it's not gonna happen now.... From: To: Time: Thu Feb 26 11:53:41 2009 (Well, someone else could tackle it, obviously.) From: To: Time: Thu Feb 26 11:54:41 2009 So, hmm. FIELDOF_NORM doesn't quite work because I don't want a structure subfield; is it worse for me to introduce a union or to decompose FIELDOF_NORM or what? From: To: Time: Thu Feb 26 11:55:41 2009 Oh. Hm, let me see... From: To: Time: Thu Feb 26 11:56:22 2009 Or do I want FIELDOF_ENCODEAS From: To: Time: Thu Feb 26 11:56:58 2009 I was just looking at that. Either FIELDOF_ENCODEAS or maybe FIELD_SELF. From: To: Time: Thu Feb 26 11:58:55 2009 Might the choice get new entries in the future? A union of one element might be more forward-looking if so. From: To: Time: Thu Feb 26 11:59:30 2009 (I *think* all the offset-handling stuff there should work okay for unions, but haven't had anything to try it out on.) From: To: Time: Thu Feb 26 12:00:45 2009 It's an internal structure. I doubt it will get more arms, but will deal with that when it happens. I'm having difficulty understanding the difference between FIELD_SELF and FIELD_ENCODEAS From: To: Time: Thu Feb 26 12:01:14 2009 Is it that FIELDOF_ENCODEAS allows me to cast the struct? From: To: Time: Thu Feb 26 12:01:34 2009 Yeah, no reason to complicate an internal structure for the sake of changes which might never happen. From: To: Time: Thu Feb 26 12:06:45 2009 In fact, I can't see any difference between FIELD_SELF and FIELD_ENCODEAS other than FIELD_SELF seems to have less type checking From: To: Time: Thu Feb 26 12:07:00 2009 Does anyone know the limitations of our Coverity license? (Wondering if it would be kosher to run it over OpenSSH with and without the gss-keyex patch.) From: To: Time: Thu Feb 26 12:09:53 2009 Steve probably knows the best. And I'm not sure if it's one of those licenses where you're not supposed to talk about the details... From: To: Time: Thu Feb 26 12:12:50 2009 Yeah, FIELD_SELF probably should've been a FIELDOF_SELF with type checking. From: To: Time: Thu Feb 26 12:13:50 2009 One of the arguments for a DSL might be that the processing of it could allow you to give the C container (or whatever) type once, instead of in each FIELDOF_* macro invocation. From: To: Time: Thu Feb 26 12:14:10 2009 Come to think of it, even some simple m4 processing on C-like input code could do that. From: To: Time: Thu Feb 26 12:17:28 2009 Actually, yeah, FIELD_SELF with the container type would just be FIELDOF_ENCODEAS, wouldn't it. *sigh* From: To: Time: Thu Feb 26 12:18:54 2009 FIELD_SELF is only used in one place. It could probably just go away, in favor of FIELDOF_ENCODEAS, which is used in several places. From: To: Time: Thu Feb 26 12:19:54 2009 Anyhow, off to lunch now... From: To: Time: Thu Feb 26 16:23:48 2009 FTR, I'm carefully reviewing the gss-keyex patch for security, since one of the things that came up in 2003 was review. This will wind up consuming several days. I'm probably also going to do a Coverity scan with and without the patch. From: To: Time: Fri Feb 27 12:29:59 2009 Well, my implementation of krb-fx-cf2 passes the first sanity check: if you pass in the same key and pepper for k1 and k2 you get 0 out. In related news, the output seems deterministic, which is also good. From: To: Time: Fri Feb 27 13:32:22 2009 I sent results of my gss-keyex patch audit to Simon. Nothing attackable; some stuff which should be fixed. From: To: Time: Fri Feb 27 13:33:02 2009 He's on honeymoon until the 15th, so nothing further is likely to happen until then. From: To: Time: Fri Feb 27 13:39:22 2009 It's amazing how much of a difference it makes if, when testing the delegation of credentials, you ACTUALLY ASK FOR FORWARDABLE CREDENTIALS from the KDC. After days tracing through XML and text files describing (not via the XML structure, of course) a hierarchy of message blocks with insufficient description of what they're testing aside from source file and line number notations, it comes down to credentials never getting the right flags in the first place. From: To: Time: Fri Feb 27 13:40:43 2009 When I first got gssmaster running to completion on UNIX, there were a huge number of errors being logged. After (1) disabling tests of expected Windows behavior and (2) fixing the get_init_creds call to actually heed the supplied flags, there are no errors being logged. From: To: Time: Fri Feb 27 13:40:58 2009 So now, finally, I get to start looking at adding some tests... From: To: Time: Fri Feb 27 13:41:20 2009 (Well, after checking in the last round of fixes.) From: To: Time: Fri Feb 27 14:02:17 2009 Well, that's a nice choice of subject line on krbdev. From: To: Time: Fri Feb 27 14:38:01 2009 Why don't we consider missing prototype and implicit declaration errors? From: To: Time: Fri Feb 27 14:40:35 2009 Because the versions of gcc we're using most places don't let you do that, despite the documented existence of -Werror= flags. I have changed the Sun compiler options we use to make implicit decls an error. From: To: Time: Fri Feb 27 14:40:55 2009 (And I put in the necessary changes so that my Solaris build would complete again.) From: To: Time: Fri Feb 27 14:41:05 2009 But we're using -werror= for some things right? From: To: Time: Fri Feb 27 14:41:31 2009 We pass that command-line option. In at least some of the compiler versions, though, it just doesn't seem to work. From: To: Time: Fri Feb 27 14:42:06 2009 Oops, krbdev seems to be having disk space problems? From: To: Time: Fri Feb 27 14:42:41 2009 Oh. /var/www is on the 7G root partition. From: To: Time: Fri Feb 27 14:46:46 2009 Deleted January's results. That frees up some 80M; still takes up almost 45M. From: To: Time: Fri Feb 27 14:52:25 2009 I had suggested a while back we could make our "compiler" be a script that invokes gcc, scanning the output for certain warning message regexps, and errors out if they show up. It would be pretty ugly, and probably fragile, so it wasn't taken (or suggested) all that seriously. Though, given that we're enabling some -Werror= options if the compiler appears to support them, it wouldn't be a bad idea to cobble something together to verify that things will still build when we encounter a compiler version that actually implements -Werror= correctly. From: To: Time: Fri Feb 27 15:03:56 2009 Yi just forwarded me some gssmonger docs. (Sending back email to ask if they should be considered public.) One of David's footnotes says, "I started to work up an equation to describe this number, but suffice it to say that it takes several hours with two principals, two slaves, and using the default settings (delegation depth=3, all context flags). Sometimes it’s easy to get carried away with the equation editor." My tests usually complete in under a minute; I wonder what I'm missing. (Well, longer if they're not on the same machine.) From: To: Time: Fri Feb 27 15:04:58 2009 But those warnings are not even ones we try to make errors. From: To: Time: Fri Feb 27 15:05:46 2009 I was trying, but gcc was failing me. From: To: Time: Fri Feb 27 15:06:57 2009 OK, in the current trunk, we have some -Werrs but it seems like an odd set. From: To: Time: Fri Feb 27 15:06:58 2009 Oh, I see... the -Werror= options I was trying to add were for C99 constructs that were causing some problems in contributed code. From: To: Time: Fri Feb 27 15:07:34 2009 Some of the other warnings probably should be added to the set. From: To: Time: Fri Feb 27 15:07:36 2009 c99 allows declaration after statement? From: To: Time: Fri Feb 27 15:07:41 2009 Yes. From: To: Time: Fri Feb 27 15:08:06 2009 And the C++ style for statement: for(int i = 1; i < 10; i++) ... From: To: Time: Fri Feb 27 15:09:15 2009 And some other fun stuff. But between Windows and some other configurations, we can't assume C99 by default even now. From: To: Time: Fri Feb 27 15:09:16 2009 Yes. IIRC, a declaration after a statement has the same scope as if it had appeared at the top of the block, though I can't remember whether you are actually allowed to refer to the name prior to the declaration. From: To: Time: Fri Feb 27 15:10:08 2009 I don't think you can. I'd have to check. From: To: Time: Fri Feb 27 15:10:40 2009 Eh, who uses Windows anyway?:-) From: To: Time: Fri Feb 27 15:13:58 2009 Nobody in our group, based on my attempts to build the code recently. :-( From: To: Time: Fri Feb 27 15:15:17 2009 Yeah. I realized that Luke's changes were going to be complicated on Windows, and while I roughly know how to set up a build environment 1) I'm not sure I still have access to the cvs part 2) I did not have enough hours to set one up 3) I don't own VS From: To: Time: Fri Feb 27 15:16:38 2009 The world would be a different place if every windows box came with make and a C compiler. From: To: Time: Fri Feb 27 15:16:51 2009 To make it extra fun, some bits of our instructions on how to set up the build environment don't quite work any more. Like, we point to plink.exe (ssh for Windows) in jaltman's home directory to get gssapi support, but it's not there; as a fallback, I think we recommend the one with TortoiseSVN, but the one they're shipping now has no gssapi support AFAICT. From: To: Time: Fri Feb 27 15:17:14 2009 cygwin From: To: Time: Fri Feb 27 15:18:08 2009 No, _every_ windows box, out of the box. You know, sort of like UNIX, or at least before certain vendors stopped shipping useful compilers. From: To: Time: Fri Feb 27 15:18:15 2009 (Sun, SGI, HP) From: To: Time: Fri Feb 27 15:19:26 2009 Well, yeah. But that might encourage people to, you know, write their own software, and share it with their friends, and stuff. Can't have that, when there's money to be made. From: To: Time: Fri Feb 27 15:20:00 2009 No, no we can't. From: To: Time: Fri Feb 27 15:22:07 2009 I'm not sure any modern Linux distribution ships a compiler by default. From: To: Time: Fri Feb 27 15:22:40 2009 But are there any where it's not ~trivial to get a decent one for free? From: To: Time: Fri Feb 27 15:23:11 2009 It's ~trivial to get a command line compiler for Windows. You can get cygwin or the MS command line compiler From: To: Time: Fri Feb 27 15:23:35 2009 Uh...? What modern Linux distribution _doesn't_ ship a compiler by default? From: To: Time: Fri Feb 27 15:23:44 2009 For at least some of them all you have to do is check "developer" on the list of uses for the system you're installing. From: To: Time: Fri Feb 27 15:24:01 2009 Well, if you install just the most basic system, you probably won't get a compiler. From: To: Time: Fri Feb 27 15:24:16 2009 Sure, but it's on the install media. From: To: Time: Fri Feb 27 15:24:26 2009 Pretty sure Ubuntu, Fedora, and RHEL won't include a compiler if you don't ask for one. (Ubuntu doesn't let you ask for one at install time with the default installer, either.) From: To: Time: Fri Feb 27 15:25:47 2009 Whether it's on the install media doesn't seem very relevant to me. From: To: Time: Fri Feb 27 15:26:16 2009 Fedora certainly includes a compiler on the install media. I don't remember which collections I picked setting up the machine, but gcc wasn't one of the handful of packages I selected manually. From: To: Time: Fri Feb 27 15:28:54 2009 In any case, here's the distinction... If I have a Linux box with no compiler, and some piece of software written for that platform, complete with interesting use of GUI and platform-specific features, all I have to do to get a compiler is {yum,apt-get} install gcc From: To: Time: Fri Feb 27 15:29:22 2009 Sure. cygwin being insufficient for "real" Windows development is the key factor. From: To: Time: Fri Feb 27 15:29:31 2009 If it's windows, I have to shell out money for a compiler and Windows SDK, and then spend a couple of days installing it all. From: To: Time: Fri Feb 27 15:30:06 2009 It doesn't take that long to install. But not being able to use the base system plus free products to develop new apps for that system is disappointing. From: To: Time: Fri Feb 27 15:30:16 2009 You definitely do not need to shell out money for an SDK and I don't think you need to for a complier From: To: Time: Fri Feb 27 15:30:47 2009 Interesting... but does that statement apply to, say, Windows XP Home Edition? From: To: Time: Fri Feb 27 15:30:55 2009 Really? Oh, maybe it's just VS I'm thinking of. From: To: Time: Fri Feb 27 15:31:30 2009 Yes, I believe so. From: To: Time: Fri Feb 27 15:31:51 2009 Now I don't know if you can build a VS project without vs From: To: Time: Fri Feb 27 15:32:21 2009 I'm reasonably sure I've installed a new SDK without needing to pay for it or log in. I've never played with the aleged free complier From: To: Time: Fri Feb 27 15:42:42 2009 I wonder if VS is actually needed for building KfW. I don't think it's a VS project. (GssMonger is, currently, but probably doesn't need to be.) From: To: Time: Sun Mar 1 02:02:33 2009 This room is not anonymous. From: To: Time: Mon Mar 2 10:25:27 2009 I need to make available FAST state like the armor key to preauth systems. I'm looking at the KDC here. I had been hoping to use the get_entry_data function in the plugin interface. However that only takes a kdc request and a db entry as arguments. Options include: * extending the kdc request structure within the KDC (ugly because it is produced by an decoder) * extending the db_entry (I'm rejecting because that's just wrong) * adding state to the krb5_context and assuming that the same context will be used * Creating a new plugin interface version with a different get_entry_func protoype From: To: Time: Mon Mar 2 10:26:57 2009 Greg, as we've discussed this earlier, have you had chance or do you plan in the near future to add the identifiers in the body of the functions to mark the entry and exit points from the routine? I want to use them to id functions that are (more or less) covered by our tests. From: To: Time: Mon Mar 2 10:38:04 2009 I've been reluctant to add tracing infrastructure because I'm not sure quite how to document it (like, do we eventually want every function in the libraries marked up with tracing calls?). gcc function instrumentation turned out not to be useful; it's hard to use it in the presence of shared libraries. valgrind does have a tool called "callgrind" which does call graph tracing. From: To: Time: Mon Mar 2 10:39:06 2009 (Looking at Sam's issue...) From: To: Time: Mon Mar 2 10:39:18 2009 Won't profiling also give you that information (although may be tricky with shared libs) From: To: Time: Mon Mar 2 10:42:04 2009 Not sure. From: To: Time: Mon Mar 2 10:48:07 2009 My first inclination is to extend krb5_kdc_req and have the decoder null out the new fields. Assuming that wouldn't present ABI issues. From: To: Time: Mon Mar 2 10:53:50 2009 Well, it does appear in krb5.h but there are no APIs there that use it. We have already extended it in 1.7 with a field we're not using. (I sent mail to krbdev; one of Luke's changes) From: To: Time: Mon Mar 2 10:56:31 2009 I agree that sounds like the simplest solution to that problem. However I've discovered another issue as I've been looking at the plugin interface. FAST and our code have somewhat different ideas about how e_data are handled. the plugin interface assumes that a plugin will return an e_data which makes its way directly into the error. FAST assumes that basically everything uses padata in the error. And I'm still working through the implications of that on the plugin interface From: To: Time: Mon Mar 2 10:57:08 2009 (I'm also evaluating whether FAST might be wrong in its re-characterization of the erro data) From: To: Time: Mon Mar 2 10:57:41 2009 My initial inclination is that FAST is making the right choice. From: To: Time: Mon Mar 2 10:58:17 2009 I haven't yet internalized what padata is so I'm not prepared to comment on that. From: To: Time: Mon Mar 2 11:00:18 2009 The "text" vs. "e_data" distinction in krb5_error escapes me. From: To: Time: Mon Mar 2 11:01:41 2009 padata is basically just a type-length-value hole in Kerberos requests and responses. Kerberos errors however have a length-value hole called edata. In particular it is untyped, and it is a singleton. (padata always come in sequences) The idea was that the error code would tell you what type of thing to expect in edata. For some errors defined in the base spec, the thing you expect is a sequence of padata to appear in edata From: To: Time: Mon Mar 2 11:02:05 2009 For most error defined in the spec, the edata field is undefined and is typically absent from the encoding. From: To: Time: Mon Mar 2 11:02:34 2009 The text is a human readable description of the error. From: To: Time: Mon Mar 2 11:02:45 2009 Yeah, apparently we don't use e_data for anything *except* preauth errors. From: To: Time: Mon Mar 2 11:04:09 2009 However people started to realize that you might want more than one item of machine readable data associated with an error. A concept called typed data was introduced. It is a type-length-value container that happens to have types assigned from the same namespace as padata. It has a very similar encoding; possibly identical although the abstract syntax is different From: To: Time: Mon Mar 2 11:04:19 2009 (Aside: I *still* don't have an acceptably working gnome-terminal. What a pain in the butt.) From: To: Time: Mon Mar 2 11:06:25 2009 pkinit uses typed data a fair bit and I think MS uses it or something else in errors that don't define e-data. Larry and I thought it was really insane to have two different type-length-value containers drawn from the same namespace that sometimes went in the same field and rather than supporting FAST going in both containers we said you should always use padata and you should especially use padata if the spec told you to use typed data. From: To: Time: Mon Mar 2 11:07:27 2009 It's actually not clear what to do in FAST if you have an error that uses neither padata nor typed data. As far as we can tell no such errors exist that actually specify something to go in e-data From: To: Time: Mon Mar 2 11:08:44 2009 I have two issues for the FAST implementation. 1) dealing with existing plugins that give me something back to stuff in e-data. 2) the plugin interface should give a plugin the ability to return padat in the verify callback From: To: Time: Mon Mar 2 11:11:53 2009 Why is (1) an issue for you? From: To: Time: Mon Mar 2 11:13:29 2009 Well, from a correctness standpoint it seems like plugins should continue to work or we should break the interface and drop support for v1 plugins. I was assuming we wanted plugins to continue to work. I guess we could argue that if no one is using that part of the interface it is acceptable to break From: To: Time: Mon Mar 2 11:13:51 2009 I'll check in a bit but I'd expect pkinit to use that part of the interface From: To: Time: Mon Mar 2 11:15:12 2009 I think I'm missing something. From: To: Time: Mon Mar 2 11:21:22 2009 What seems confusing/inconsistent From: To: Time: Mon Mar 2 11:22:53 2009 So, we have (maybe) existing plugins which supply e_data. What about your work would conceivably break that? (This is something I might know the answer to if I had finished reviewing your project proposal, as I had been planning to do today but might not get to.) From: To: Time: Mon Mar 2 11:25:00 2009 As I mentioned, Larry and I decided that in FAST everything should be handled as padata. From: To: Time: Mon Mar 2 11:25:38 2009 So, if the request is using fast, I need to convert whatever I get from the plugin into a padata item From: To: Time: Mon Mar 2 11:28:01 2009 Okay, I guess what I don't understand is how existing preauth mechanisms interact with FAST. From: To: Time: Mon Mar 2 11:28:09 2009 Which is a big question. From: To: Time: Mon Mar 2 11:28:27 2009 Fast creates an encrypted tunnel over which all non-fast padata is carried. From: To: Time: Mon Mar 2 11:29:23 2009 Lovely, the encoding of padata and typed-data is gratuitously incompatible. The type has tag 1 in pa-data and 0 in typed-data From: To: Time: Mon Mar 2 11:52:51 2009 Going back to function call instrumentation: it looks like valgrind --tool=callgrind is the easiest way to get a call graph with function names. Processing the output may be a bit of a challenge. From: To: Time: Mon Mar 2 12:07:13 2009 Of course, our plugin interface makes it really difficult to handle multiple function tables. If I want to write a plugin that supports v1 and v2 I can do that. But I'll get called twice for each request. From: To: Time: Mon Mar 2 12:39:34 2009 The "scan all modules for symbol X" interface was intended to be pretty simplistic. Feel free to write a more appropriate interface for this case. From: To: Time: Mon Mar 2 13:11:17 2009 oh oops. krbdev.mit.edu disk space issues are partially due to nightly database dumps not being purged. From: To: Time: Mon Mar 2 13:11:55 2009 Which database? From: To: Time: Mon Mar 2 13:14:27 2009 the rt database From: To: Time: Mon Mar 2 13:16:28 2009 now purged and set to only keep the last 30 days' worth of dumps From: To: Time: Mon Mar 2 13:37:01 2009 I think that's out of scope for what I have planned. And I'm already on tight scheduling/budget. I think I'll document the issue and try to avoid introducing a new plugin version. From: To: Time: Mon Mar 2 14:37:02 2009 wow. raid1 sync on my Dell is doing nearly 80Mbytes/sec. From: To: Time: Mon Mar 2 16:12:59 2009 gssmonger password-changing tests pass, after another tweak to the logging code... run time is up over a minute again, not sure what's up with that, but i don't think it's a priority, certainly not vs the "several hours" that davidchr described in his document. From: To: Time: Mon Mar 2 17:47:03 2009 gssmonger might be simpler to work on if it used xdr and rpc. it's all hand-coded now. From: To: Time: Tue Mar 3 13:13:49 2009 Ken in 21564 why did you add an assert that status !=0 It seems possible to use the get_error_message code below in that case From: To: Time: Tue Mar 3 13:14:06 2009 Rather impossible From: To: Time: Tue Mar 3 13:16:16 2009 (We're on the conference call now.) From: To: Time: Tue Mar 3 15:43:30 2009 looking... From: To: Time: Tue Mar 3 15:46:13 2009 I put that in in two places; which are you looking at, Sam? From: To: Time: Tue Mar 3 15:49:12 2009 In do_as_req.c, it's at the "errout" label that should only be reached if an error happened, and at the error site "status" should've been set to a string. From: To: Time: Tue Mar 3 15:49:52 2009 In do_tgs_req.c, it's at the "cleanup" label, and even in the success case "status" should be set to some string. From: To: Time: Tue Mar 3 15:50:40 2009 Both of them. Why do you believe that status should be set rather than relying on krb5_get_error_message? From: To: Time: Tue Mar 3 15:50:44 2009 The two files use different conventions for handling "status", and synchronizing them wasn't part of my logging-handling work. In do_as_req.c, NULL is used on success, and in do_tgs_req.c, the string is "ISSUE" on success. From: To: Time: Tue Mar 3 15:51:49 2009 "status" is the short string used in logging, like ISSUE or KDC_RETURN_ENC_PADATA or LOOKING_UP_SERVER, not the long error message. From: To: Time: Tue Mar 3 15:53:46 2009 The separate tracking of error code and status string has been around for a long time. I don't think I changed that significantly. At least, that was the intent. From: To: Time: Tue Mar 3 15:54:39 2009 The code is clearly incorrect as it stands. There is code below your assert to deal with status being null in error cases in both functions. ANd I'm not seeing an argument that code isn't more correct From: To: Time: Tue Mar 3 15:56:34 2009 In do_as_req, after the assert there's another label used for successful exit cases, so the test of status being null still makes sense. (The assertion was there basically to check for any error cases not setting the short string for logging.) From: To: Time: Tue Mar 3 15:58:37 2009 In do_tgs_req, yes, it looks like there's code that could be cleaned up because status should never be null. (Though looking at the branches, if we get the "more than one entry in the database" error that should never be possible, perhaps status can be null.) There are two calls to krb5_get_error_message in that code, though; the other only depends on errcode. From: To: Time: Tue Mar 3 15:59:41 2009 There are places where status is not directly set on error, but generally the function raising the error is passed &status as an argument and should be setting it. From: To: Time: Tue Mar 3 16:00:11 2009 Right. I'm still not seeing the argument that the assert is desirable. From: To: Time: Tue Mar 3 16:00:26 2009 But right now I'm panicing about this PRF issue. From: To: Time: Tue Mar 3 16:01:17 2009 It's a matter of taste, I think. I wanted it to help trap errors; logging "(null)" or crashing in the logging code would work too, if a bug still exists that can lead to a null value there. From: To: Time: Tue Mar 3 16:02:38 2009 Right. I'm wondering why the correct fix is not to move the get_error_message up From: To: Time: Tue Mar 3 16:03:42 2009 Our code does not comply with the PRF spec (good) because the prf spec seems insecure. I'd appreciate though someone looking at dk_prf.c and confirming that the aes enctypes do not have 256 possible outputs for a given key From: To: Time: Tue Mar 3 16:07:30 2009 What does your code do? From: To: Time: Tue Mar 3 16:07:44 2009 Particularly, does it do what Marcus suggests? From: To: Time: Tue Mar 3 16:07:53 2009 I think it truncates the hash to 128 bits From: To: Time: Tue Mar 3 16:08:28 2009 It certainly looks that way. From: To: Time: Tue Mar 3 16:09:17 2009 What marcus suggests breaks the proof that it is a prf because aes-cbc is not a prp while aes-ecb is From: To: Time: Tue Mar 3 16:10:23 2009 I don't understand. How does truncating the minimum amount to make it a multiple of m break the proof? From: To: Time: Tue Mar 3 16:11:02 2009 RFC 3961 specifies encrypting the truncated hash to a multiple of the "message block size", which for AES would be one byte. From: To: Time: Tue Mar 3 16:12:21 2009 Yeah. All numbers are multiples of m, so I think Marcus is right -- that means doing no truncation, because it is already a multiple of m. It doesn't say to truncate it _to_ m, just to a multiple of m. From: To: Time: Tue Mar 3 16:12:58 2009 krb5int_dk_prf is using enc->block_size, which is the cipher block size, which for AES is 16 bytes. From: To: Time: Tue Mar 3 16:13:13 2009 Because the output of CBC has structure. It's clearly distinguishable from random From: To: Time: Tue Mar 3 16:13:16 2009 It's not actually truncating to m, it's truncating to a multiple. From: To: Time: Tue Mar 3 16:14:11 2009 Oh, I see; hadn't seen his email yet. He's right, it should've said "make the smallest truncation...", including perhaps no truncation at all. From: To: Time: Tue Mar 3 16:14:56 2009 Uh. What structure does the output of CBC have? It better not be distinguishable from random. From: To: Time: Tue Mar 3 16:15:11 2009 Looks like a second erratum needed for 3961. (First is the checksum length thing brought up recently.) From: To: Time: Tue Mar 3 16:16:27 2009 I really need to head out. But basically I cannot think of a way to prove that if AES is a prp AES|aes^AES is a PRF. and I suspect it is not. From: To: Time: Tue Mar 3 16:16:54 2009 I'm fairly sure what our code does is secure. And we've been shipping it for a while. From: To: Time: Tue Mar 3 16:18:32 2009 I believe it's generally accepted that XOR does not discard entropy. CBC on one block is the same as ECB on a single block, and both are PRP's. Neither is a PRP on multiple blocks, because a change in block 2 of the input does not result in a change in block 1 of the output. But in the krb5 PRF construct, we work around that by applying a hash to the input. From: To: Time: Tue Mar 3 16:29:48 2009 Yes, we're dependent on (unproven, I believe) properties of the hash function. From: To: Time: Tue Mar 3 16:31:55 2009 In the single block case all you care about is second preimage resistance, which is a reasonable assumption for sha-1. Go work through the proof for CBC. I doubt you can make it work. I'm also sure it is broken because the second block does not range over the full set of inputs. From: To: Time: Tue Mar 3 16:34:00 2009 If it were CBC, we wouldn't be using a partial block. CTS is a little different, and that may be important. But yeah, if we ignore the hash function and just use AES-CTS, I agree you wouldn't get a PRF. From: To: Time: Tue Mar 3 16:34:08 2009 So you have 160-bits in to something you hope is a prp. you have 256-bits of output. Therefere it is clearly not a PRP. It may be a PRF but you don't yet have an argument that is true From: To: Time: Tue Mar 3 16:34:58 2009 Do you argee what we're doing today is secure? From: To: Time: Tue Mar 3 16:35:49 2009 Since we're (incorrectly) truncating to one 16-byte block, yes, I think it is. Well, aside from possible issues in our key derivation. From: To: Time: Tue Mar 3 16:38:59 2009 OK. I'm going to argue on the list to standardize what we're doing because it's secure and we don't have an argument that trunking to 160-bits is. Sorry about my typing. This cell phone connection sucks. From: To: Time: Tue Mar 3 16:39:52 2009 If you can come up with reasoning that truncation to 160 bits is secure, then we would need to consider possible deployed base issues. We may need to anyway if anyone else has shipped a PRF From: To: Time: Tue Mar 3 16:39:55 2009 Does Heimdal implement this? Or MS? From: To: Time: Tue Mar 3 16:40:31 2009 I don't know. Love has never responded to my messages about confirming test vectors from 2004 From: To: Time: Tue Mar 3 16:40:44 2009 Looking back at the CTS spec now, will think about it. Like I said, I think it's going to depend on additional properties of the hash function -- as I think it would if the hash function output were more than two blocks long and we truncated to two blocks. From: To: Time: Tue Mar 3 16:40:47 2009 I'm fairly sure MS does not ship this From: To: Time: Tue Mar 3 16:41:51 2009 Going to log out and wait for my train From: To: Time: Tue Mar 3 16:43:56 2009 Sam, you think the right thing to do is truncate to the underlying block cipher size? I think that's clearly OK for the 3962 enctypes, but I also think it assumes too much knowledge about what E() does to be OK for the general case. Maybe not, if we're clear that 'c' must be a size for which E() is a PRP, and perhaps set some minimum on it (after all, for RC4, 'c' really is 1, and that still produces too few outputs) From: To: Time: Tue Mar 3 16:44:34 2009 Figures I just missed him. From: To: Time: Tue Mar 3 16:53:17 2009 Right, AES-CTS definitely not a PRP. Even with only two blocks (the second possibly incomplete), altering the second input block doesn't change the second output block. That's where we'd depend on the hash function properties. From: To: Time: Tue Mar 3 16:54:29 2009 Known collisions in SHA-1 could generate collisions in the AES PRF output as specified (and as implemented, both). From: To: Time: Tue Mar 3 17:00:49 2009 From a quick glance through fisheye, it looks like Heimdal implement the AES PRF with truncation to 16 bytes. From: To: Time: Sun Mar 8 03:02:33 2009 This room is not anonymous. From: To: Time: Mon Mar 9 13:14:50 2009 Luke's code breaks LDAP realm creation. From: To: Time: Mon Mar 9 13:17:59 2009 Do you know why? From: To: Time: Mon Mar 9 13:24:27 2009 (Sorry, distracted.) Yes. krb5_dbekd_encrypt_key_data became a virtual function, indirected through the lib_handle. kdb5_ldap_util does its work with a dal_handle containing a null lib_handle, assuming that because it's calling directly into libkdb5_ldap it doesn't need a valid lib handle. From: To: Time: Mon Mar 9 13:25:52 2009 Hmm. I would have expected that change more from Will's code than from Luke's code, but I believe that both Novell and Will need that for different reasons. From: To: Time: Mon Mar 9 13:26:23 2009 It's r21690, which is the merge of Luke's code. From: To: Time: Mon Mar 9 13:27:08 2009 OK. Well, I'm sorry that I had forgotten about how kdb5_ldap worked. From: To: Time: Mon Mar 9 13:28:25 2009 Would you recommend making kdb5_ldap initialize the lib handle somehow, or making it possible to call krb5_dbekd_def_encrypt_key_data directly somehow? From: To: Time: Mon Mar 9 13:28:43 2009 (Meant to say kdb5_ldap_util in the first clause.) From: To: Time: Mon Mar 9 13:29:50 2009 I'd initialize the lib handle somehow. In Novell's implementation they would like to move away from having a master key at all so it seems likely there will be ldap-like backends that do actually want to override that function From: To: Time: Mon Mar 9 13:30:25 2009 Although I don't remember how hard that is. I.E. whether something is going to complain that you don't have a database yet From: To: Time: Mon Mar 9 13:31:02 2009 It's been years since I've looked at the kdb5 library itself. Looking From: To: Time: Mon Mar 9 13:37:39 2009 It seems like you could call kdb_setup_lib_handle if it were exported. I'm now looking into the module init function for ldap From: To: Time: Mon Mar 9 13:44:15 2009 If I'm reading this right, the module init function will barf if the container or realm doesn't exist. From: To: Time: Mon Mar 9 13:46:04 2009 I'm getting to that code. There are some comments that make me think that's not true and others that make me think it is From: To: Time: Mon Mar 9 13:50:15 2009 However the code distinctly seems to fail. I think you may be better off exporting kdb_setup_lib_handle. From: To: Time: Mon Mar 9 13:51:13 2009 Okay. From: To: Time: Mon Mar 9 15:01:29 2009 Out for a few hours; will be back around 7 and working this evening. From: To: Time: Mon Mar 9 15:54:47 2009 How do you free the result of decode_krb5_typed_data? From: To: Time: Mon Mar 9 15:56:34 2009 I'm amazed Cybersafe is still around From: To: Time: Mon Mar 9 15:58:29 2009 First you go to the market and get three live chickens (four, if you have more than 256 bytes of typed-data to free)... From: To: Time: Mon Mar 9 15:59:01 2009 You know, I realize that we shouldn't say that certain products are bad. However there are times when I'm tempted to point out very publicly that certain vendors never attend interop events From: To: Time: Mon Mar 9 15:59:46 2009 Yeah, I think the answer here is to implement krb5_free_typed_data From: To: Time: Mon Mar 9 15:59:54 2009 I suspect they mostly deploy closed systems, and don't care about interop. From: To: Time: Mon Mar 9 16:00:32 2009 Oh, if you want to build an interface like that once and then be able to just call it whenever you want, you'll need to start with many more chickens. And a sheep. From: To: Time: Mon Mar 9 16:02:54 2009 the fact that a vendor doesn't attend mit's interop event doesn't mean they are not actively performing interop testing. the vendor you are referring to is at least as active as mit is at performing interop with microsoft, novell, and sun. they just do it as a participant of the early adopters program for each vendor's product. From: To: Time: Mon Mar 9 16:07:29 2009 Jeff, I believe you are incorrect. However I believe we have different confidential information here. (I believe you may be correct they participate in those programs; I believe you are incorrect that they do as complete or thorough of testing as most of the consortium members) From: To: Time: Mon Mar 9 16:08:22 2009 That is, based on your claims, I believe you must have confidential information of the vendor in question. I have no such information but I have other information that is probably confidential to parties they test against. From: To: Time: Mon Mar 9 16:08:31 2009 So it's hard for us to usefully have this conversation From: To: Time: Mon Mar 9 18:02:28 2009 OK, so I have fast-insecure working for the AS-req request and error paths. response should be easy. The KDC side integration is mostly there for TGS, although not the client side. This is going quite well. (fast-insecure avoids all that bother with encryption and checksum verification and actually having to use the armor keys.) From: To: Time: Mon Mar 9 18:06:55 2009 The request mangling and management seems far harder in this project than the actual crypto or security. So, I'd say I'm well on schedule From: To: Time: Mon Mar 9 19:55:22 2009 So does a KDC have to have a krb5.conf (+kdc.conf) specifying its own realm as the default realm? I'm looking at how kdb_get_library_name works. From: To: Time: Mon Mar 9 19:57:12 2009 Also, not that I really need to know, but what does the dbekd stand for in dbekd_encrypt_key_data? From: To: Time: Mon Mar 9 20:37:28 2009 Are tickets 6403 and 6404 the same problem? From: To: Time: Mon Mar 9 20:41:10 2009 Yes. Odd coincidence if Will discovered the problem on the same day. From: To: Time: Mon Mar 9 20:43:14 2009 How do I resolve my ticket as a duplicate? From: To: Time: Mon Mar 9 20:43:43 2009 There's an option for merging tickets, that's probably the best way. From: To: Time: Mon Mar 9 20:44:21 2009 I don't see it. From: To: Time: Mon Mar 9 20:44:50 2009 Ah, there it is. From: To: Time: Mon Mar 9 20:44:56 2009 I forget which option it's under, but "jumbo" would have it From: To: Time: Mon Mar 9 20:45:51 2009 You click on "relationships". From: To: Time: Mon Mar 9 20:47:36 2009 So I have the fix coded up and testing where we expose kdb_setup_lib_handle (renamed to krb5_db_setup_lib_handle), which partially constructs dal_handle. It doesn't seem very elegant, but the alternatives I know about are either less elegant or much more work. From: To: Time: Mon Mar 9 20:47:45 2009 Er, tested, not testing. From: To: Time: Mon Mar 9 20:50:14 2009 This fix may also put more constraints on what krb5.conf has to look like before kdb5_ldap_util will function. From: To: Time: Mon Mar 9 22:09:41 2009 kdbekd probably expands to kdb entry key data You need to either have default_realm set or use the -r arguments to krb5kdc and kadmind From: To: Time: Mon Mar 16 12:10:11 2009 intermittent iprop.exp test failures i have been seeing have something to do with state remaining in the tmpdir. haven't traced it farther than that. From: To: Time: Mon Mar 16 12:11:36 2009 also, in what may or may not be related, Mac OS doesn't seem to update mmap()ed files' mtimes on writes. From: To: Time: Mon Mar 16 14:01:50 2009 Are the files' mtimes not getting modified at all, or just not immediately when the content is written? I'd hope msync would update it, at least, as required by posix... From: To: Time: Mon Mar 16 14:02:07 2009 not modified at all. apparently similar bugs exist in Linux From: To: Time: Mon Mar 16 14:02:31 2009 Okay, that's broken... From: To: Time: Mon Mar 16 14:04:50 2009 Maybe we need to call utimes() when we call msync() then, just to be safe. From: To: Time: Mon Mar 16 14:05:42 2009 If you've got a reference for the problem, please at least make a note in RT, if you're not going to address it now. From: To: Time: Mon Mar 16 14:06:28 2009 which, mmap or iprop? From: To: Time: Mon Mar 16 14:06:59 2009 if the mmap thing is an OS bug we should get it fixed through the OS at least eventually From: To: Time: Mon Mar 16 14:07:54 2009 I guess, the mmap/msync bug which causes the iprop test failures. The workaround would have to be in the iprop code. (If we really need the workaround; I'm not 100% sure we do, but we are testing for the "busy" functionality right now, and I assume that's what's failing.) From: To: Time: Mon Mar 16 14:08:07 2009 i'm not sure it's what's causing the test failures yet. From: To: Time: Mon Mar 16 14:08:40 2009 Ah. From: To: Time: Mon Mar 16 14:09:11 2009 I found at least one reference complaining about mtime updates not happening with MS_ASYNC, but that seems to make sense; I'd only depend on MS_SYNC mode, and that's what we're using. From: To: Time: Mon Mar 16 14:40:15 2009 Okay, this program isn't behaving quite right.... gssmaster 96099 raeburn 251w REG 45,4 597298 4313992 /afs/athena.mit.edu/user/r/a/raeburn/dev/krb5/gssmonger/trunk/b/gssmaster.log gssmaster 96099 raeburn 252w REG 45,4 597298 4313992 /afs/athena.mit.edu/user/r/a/raeburn/dev/krb5/gssmonger/trunk/b/gssmaster.log gssmaster 96099 raeburn 253w REG 45,4 597298 4313992 /afs/athena.mit.edu/user/r/a/raeburn/dev/krb5/gssmonger/trunk/b/gssmaster.log gssmaster 96099 raeburn 254w REG 45,4 597298 4313992 /afs/athena.mit.edu/user/r/a/raeburn/dev/krb5/gssmonger/trunk/b/gssmaster.log gssmaster 96099 raeburn 255w REG 45,4 597298 4313992 /afs/athena.mit.edu/user/r/a/raeburn/dev/krb5/gssmonger/trunk/b/gssmaster.log From: To: Time: Mon Mar 16 14:41:01 2009 I've been chasing down why the log file seems to be missing large amounts of data, but isn't truncated. If each block is using a new file descriptor, that would explain the behavior perfectly... From: To: Time: Mon Mar 16 14:41:03 2009 what is that output from? From: To: Time: Mon Mar 16 14:41:16 2009 lsof From: To: Time: Mon Mar 16 14:42:09 2009 Yeah. It's rushing right up to 255 fds, 248 of which seem to be used for different "blocks" in the logging, and later blocks don't seem to be able to log anything. From: To: Time: Mon Mar 16 14:42:30 2009 oh From: To: Time: Mon Mar 16 14:42:47 2009 does this problem happen on windows? From: To: Time: Mon Mar 16 14:42:48 2009 No wonder the UNIX log file was coming out so much shorter. :) From: To: Time: Mon Mar 16 14:44:08 2009 No, it doesn't look like it. I think it's just how the logging stuff is done on UNIX via log4cpp. From: To: Time: Mon Mar 16 15:58:55 2009 gssmonger with two slaves now makes over 2000 KDC requests ... in my test case, within a window of 77 seconds. From: To: Time: Mon Mar 16 15:59:27 2009 384 AS_REQ, 1664 TGS_REQ From: To: Time: Mon Mar 16 15:59:38 2009 That's without testing password-changing. From: To: Time: Mon Mar 16 15:59:50 2009 is it constrained by KDC performance, or something else? From: To: Time: Mon Mar 16 16:00:48 2009 Unknown. All communications are on the same host and OS (no virtualization), so that should be quick, but it wouldn't surprise me if there were other factors. From: To: Time: Mon Mar 16 16:04:23 2009 Actually... everything is serialized, so I'm pretty sure at some points it was blocked on the KDC. At other times, blocked on maggots doing client-type operations, etc. So improving the performance of any component is likely to speed things up a little. At least, I don't *think* it was blocked on disk i/o for the log file. From: To: Time: Mon Mar 16 16:05:29 2009 My machine was still about 75% idle while it was running, but it is an 8-core machine. From: To: Time: Mon Mar 16 16:25:49 2009 Another run: test run time: 72s real cpu time usage: 51s master: 3s user 14s sys maggot: 7s user 9s sys (each) kdc: <1s user <1s sys To chase down the missing 21s across so many processes, I'd probably have to learn dtrace... From: To: Time: Mon Mar 16 16:29:03 2009 Ah, kernel_task cpu usage is around 28% during this time. Assuming that's fairly steady for the whole test, 28% of 72s is 20s. So, I think we're pretty much CPU bound. Some of it is waste like repeatedly calling write() for small bits of data, so there's definitely room for improvement. From: To: Time: Mon Mar 16 16:29:37 2009 is that inside gssmonger or inside our library? From: To: Time: Mon Mar 16 16:30:03 2009 In gssmonger. The network i/o stuff for transmitting values back and forth. From: To: Time: Mon Mar 16 16:30:21 2009 We may have some of that too, of course. But I know gssmonger has a lot. From: To: Time: Mon Mar 16 16:31:06 2009 On multiple machines, that may also introduce delayed-ack/Nagle interactions. I'm not sure the code I dropped in there will turn things off correctly; haven't exercised that much. From: To: Time: Tue Mar 17 18:00:08 2009 ew. mangled MIME. From: To: Time: Wed Mar 18 13:54:52 2009 *special* The return_proc takes a client dbentry and the get_entry_proc function pointer. That function requires a client dbentry, server dbentry and request. The return_proc never receives a server dbentry. From: To: Time: Wed Mar 18 13:55:36 2009 Clearly I should have done a better job of reviewing some aspects of this plugin interface when I approved it. It is actually fairly good, but there are a few rough edges like that. From: To: Time: Wed Mar 18 15:11:45 2009 krbdev.mit.edu SSL cert expires tomorrow; i'm requesting a new one. From: To: Time: Thu Mar 19 13:38:54 2009 There's really no good reason for etype-info to be a list, is there? From: To: Time: Thu Mar 19 13:40:42 2009 What do you mean? From: To: Time: Thu Mar 19 13:43:33 2009 I mean, you'd never actually have a compelling reason to provide more than a single etype-info or etype-info2 entry, so (if we had a time machine) it may as well have been a single value instead of a list. From: To: Time: Thu Mar 19 13:43:47 2009 Do you mean there's no good reason for a KDC to send more than one element? From: To: Time: Thu Mar 19 13:44:49 2009 So, in the AS reply case, that's true. The preauth framework draft makes a weaker version of the argument you're making for the preauth_required error case. A couple weeks ago I believed that, but now I'm not sure. From: To: Time: Thu Mar 19 13:45:16 2009 What has made you less sure? From: To: Time: Thu Mar 19 13:45:39 2009 (I believe the MIT KDC only ever sends one element.) From: To: Time: Thu Mar 19 13:45:47 2009 Larry claims that it is unclear whether the ktypes member of the kdc request body refers to the available enctypes the client would use as a session key or the available enctypes the client supports for the long-term key. (our code assumes both) For passwords these are the same. From: To: Time: Thu Mar 19 13:48:11 2009 Oh, I see, if you have a keytab, you might say you support AES and DES, but you might only have a DES key in the keytab. (But our code would only say you support DES, and thus would only get a DES session key.) From: To: Time: Thu Mar 19 13:48:18 2009 I'm reasonably sure the MIT KDC actually will send back multiple elements; take a look at get_etype_info2 in kdc_preauth.c From: To: Time: Thu Mar 19 13:49:07 2009 No, our code would say you support aes and des get back something encrypted in aes and flail madly, or at least I believe that's what it does. However that's a bug:-) From: To: Time: Thu Mar 19 13:49:42 2009 Ah, but that would rarely happen because if the KDC has an AES key for your principal, you probably have that key in your keytab. From: To: Time: Thu Mar 19 13:50:11 2009 (I think you're right about the MIT KDC; I was reading a different piece of code, etype_info_as_rep_helper.) From: To: Time: Thu Mar 19 13:50:43 2009 Larry says that if the kdc sends back all the etype-info2 elements you can then choose which key to use in your enc_timestamp preauth and then the KDC can figure out which key you meant. I don't think our kdc does that either: I don't think that the KDC will allow the key you use for enc-ts to influence the reply key From: To: Time: Thu Mar 19 13:51:23 2009 So it's a possibility that the FAST draft might be changed not to make that argument about narrowing etype-info2 to a single element? From: To: Time: Thu Mar 19 13:51:55 2009 Yeah, in the as_rep case you definitely only return one key. That's true for our KDC. However if we're talking to a KDC that bases keys off passwords the set of keys that the KDC could have for us is different than the set of keys we may have for ourself. From: To: Time: Thu Mar 19 13:54:21 2009 In the current FAST code I'm writing, here is the behavior: * if you use encrypted challenge and don't use pkinit or something else that implements replace reply key then the response will be encrypted in a random key (not implemented yet) given to you in the fast_response * All the keys we currently give back in etype-info2 are still given back * we'll respond with the same long-term key you used in your request for the encrypted challenge response So, I think that will work in the keytab case correctly if you happen to be using FAST. We probably want to revisit the general issue. From: To: Time: Thu Mar 19 13:56:09 2009 It's certainly a possibility that we might change that. However I'm still unconvinced that it's a real issue and conceptually dealing with one reply key makes things much easier to think about. My guess is that unless someone has a strong opinion on either side of the issue we will not focus on that text From: To: Time: Thu Mar 19 13:57:23 2009 The preauth code is very complicated Even this week I'm finding new twists to it. From: To: Time: Thu Mar 19 13:57:54 2009 And this is about the third time I've delved significantly into it. Each previous time I thought I understood it:-( From: To: Time: Thu Mar 19 17:00:04 2009 I seem to have encrypted challenge working. From: To: Time: Fri Mar 20 10:46:11 2009 Huh. I only see two LDAP searches per kinit. (One for the client principal, one for krbtgt/realm@realm.) From: To: Time: Fri Mar 20 10:47:48 2009 Would you expect more? From: To: Time: Fri Mar 20 10:48:21 2009 I was wondering if maybe RH had preauth enabled; in certain modes it looks for additional database entries to decide what preauth system to use. From: To: Time: Fri Mar 20 10:48:55 2009 Red Hat reports seeing seven in their tests. From: To: Time: Fri Mar 20 10:59:43 2009 Also, we defined NOCACHE (which disables the lookaside cache) if --disable-kdc-replay-cache is given at configure time. So if they used that option to disable the replay cache, then the lookaside cache should also have been disabled. From: To: Time: Sun Mar 22 02:03:08 2009 This room is not anonymous. From: To: Time: Sun Mar 22 14:29:21 2009 "Significant problems have resulted in the specification of Kerberos protocols because much of the KDC exchange is not protected against authentication." (From the FAST draft.) I think that last word wants to be something else. From: To: Time: Sun Mar 22 17:38:00 2009 the word should probably be "alteration" or "modification" From: To: Time: Mon Mar 23 15:18:16 2009 The krb-wg meeting is at 1520 local time. The conference is in... California? So it should be 1820 eastern time. Does that sound right? Steve put it on my calendar for 1220 for some reason. From: To: Time: Mon Mar 23 15:40:55 2009 Yes, 18:20 is krb-wg, 20:10 is kitten, 12:00 is sasl, if you're interested... From: To: Time: Mon Mar 23 15:41:07 2009 (eastern time, according to my calendar) From: To: Time: Tue Mar 24 12:59:37 2009 krb5_c_fx_cf2_simple? What's simple about it? From: To: Time: Tue Mar 24 13:00:26 2009 Oh, I guess that's what the comment says. From: To: Time: Tue Mar 24 19:10:11 2009 Simon has a krb5 implementation? From: To: Time: Tue Mar 24 19:10:26 2009 yes, the gnu implementation is called shishi. From: To: Time: Tue Mar 24 19:27:24 2009 oh, looks like mit doesn't have des3 prf ... the function ptr field in krb5_enctypes_list is null. From: To: Time: Tue Mar 24 19:27:39 2009 neither does heimdal From: To: Time: Thu Mar 26 14:20:07 2009 The new FAST protocol error is 93? How did that number get chosen? (Just curious.) From: To: Time: Thu Mar 26 14:35:07 2009 Hm, I see Sam is an if (retval == 0) { ... } coder. From: To: Time: Thu Mar 26 15:08:11 2009 if (retval==0) { ... } is not used everywhere by him, i think. From: To: Time: Thu Mar 26 15:08:35 2009 also, error numbers were assigned by me, or at least i'm fairly sure 93 was. From: To: Time: Thu Mar 26 16:27:01 2009 was there ever a published rationale for why we truncate the SHA1 HMAC in rfc3962? From: To: Time: Thu Mar 26 16:30:06 2009 In the PRF? From: To: Time: Thu Mar 26 16:30:27 2009 no, for the authenticated encryption. From: To: Time: Thu Mar 26 17:08:43 2009 I don't think we published a reason. As far as I recall, people just thought it was good enough, and the full HMAC would have been kind of long. From: To: Time: Thu Mar 26 17:12:46 2009 Go look at the ESP specs. They truncate the hmac and there is some discussion about whether truncating an hmac may increase strength. From: To: Time: Fri Mar 27 16:14:57 2009 Do we have a consistent ruling on using calloc to null out pointer fields? Some of Sam's code appears to be relying on that. From: To: Time: Fri Mar 27 16:15:45 2009 tolerated for the sake of consistency until we have a better solution for initializing pointers, i think. From: To: Time: Fri Mar 27 16:21:53 2009 Okay. (A better solution? As far as I know, either you rely on calloc to work or you initialize pointers explicitly.) From: To: Time: Fri Mar 27 16:22:57 2009 structures containing large numbers of pointers may cause initialization sections to occupy lots of space (in source and object code). From: To: Time: Fri Mar 27 16:46:08 2009 Code to initialize the pointer fields after calling calloc or memset(,0,) would be reasonable, and a good enough compiler -- I think gcc isn't there yet -- could infer that the pointer field setting was redundant and eliminate it from the generated code. From: To: Time: Fri Mar 27 16:47:28 2009 alternatively, a static const instance of the structure, used for initializing other instances by structure assignment. gcc doesn't optimize that either. From: To: Time: Sun Mar 29 02:02:58 2009 This room is not anonymous. From: To: Time: Mon Mar 30 11:40:48 2009 Why does encrypted challenge replace rather than strengthen the reply key? From: To: Time: Mon Mar 30 11:45:08 2009 I'm concerned that if one is using a host key as armor, anyone with knowledge of the host key could observe an AS exchange using encrypted challenge and pull out the user's credentials, without knowing the user's long-term key. There might be something about the armor exchange which prevents this, but it feels unnecessarily fragile. From: To: Time: Mon Mar 30 12:15:36 2009 (Asking in mail to ietf-krb-wg.) From: To: Time: Mon Mar 30 12:27:16 2009 Hm. If you strengthen rather than replace the client key, then an attacker who knows the host key would be able to conduct a dictionary attack on the password. I'm not sure if that's better or worse than giving the attacker a credential. From: To: Time: Mon Mar 30 12:38:56 2009 Ah, the attacker can do that anyway using the messages encrypted in either challenge key. From: To: Time: Mon Mar 30 13:25:58 2009 if the attacker knows the host key, then many other, worse, things are possible. From: To: Time: Mon Mar 30 13:28:22 2009 Maybe. But my main point is that the relationship of the armor ticket to the client ticket is not spelled out in the security considerations, and that it may be possible to decouple them further than is currently done. From: To: Time: Mon Mar 30 13:29:10 2009 ah From: To: Time: Mon Mar 30 18:22:01 2009 Hi. I re-emerge from communications silence. I'm going to arrive in Redmond shortly From: To: Time: Tue Mar 31 11:31:38 2009 How does the RFC errata process work? (Just curious, low priority question.) From: To: Time: Tue Mar 31 11:31:46 2009 (In the IETF, if that isn't clear.) From: To: Time: Tue Mar 31 11:33:21 2009 Nevermind, I think I mostly figured it out via google search. From: To: Time: Tue Mar 31 12:03:40 2009 whee From: To: Time: Tue Mar 31 12:03:45 2009 Note that the relevant section in 3961 is not a list that is intended to be used directly; it's instructions to IANA regarding the initial registry contents. So, I'm not sure an erratum is really necessary, as long as the actual registry gets updated. From: To: Time: Tue Mar 31 12:03:55 2009 (sorry if that was a dup) From: To: Time: Tue Mar 31 12:38:07 2009 Boy, some of our function names could use work. process_tgs_req starts out by calling kdc_process_tgs_req. (The "kdc_" prefix means pretty much nothing since both are KDC functions.) From: To: Time: Tue Mar 31 12:41:51 2009 yes, they could use work From: To: Time: Tue Mar 31 13:11:29 2009 kdc_progess_tgs_req is something close to kdc_tgs_rd_req in what it does. From: To: Time: Tue Mar 31 13:11:58 2009 Or perhaps better kdc_process_pa_tgs_req From: To: Time: Tue Mar 31 13:12:16 2009 By "pa_tgs_req" you mean the AP req inside the padata? From: To: Time: Tue Mar 31 13:13:24 2009 Yes. That function seems to do all the work of validating that ap-req and extracting any information you need. From: To: Time: Tue Mar 31 13:35:11 2009 I don't think the checksum size data should ever have been in the IANA registry. We need registries of encryption or checksum type numbers, names (probably), and where the specification is given. Other data like checksum or key sizes can be determined from the specs. From: To: Time: Tue Mar 31 13:35:25 2009 I just don't know whether or how we can easily fix that. From: To: Time: Tue Mar 31 13:35:44 2009 We can approve an RFC removing it. From: To: Time: Tue Mar 31 13:37:04 2009 Sure, but that seems like a heavyweight approach. Nothing simpler? (And, procedurally, I'm not entirely sure how that works -- would this RFC be standards track? Informational?) From: To: Time: Tue Mar 31 13:38:37 2009 Informational or BCP From: To: Time: Tue Mar 31 13:46:43 2009 You could potentially have the IESG direct iana, but the easiest way to do that is to get an RFC From: To: Time: Tue Mar 31 13:47:07 2009 Okay. Maybe that's what we ought to do then. From: To: Time: Tue Mar 31 13:48:10 2009 Hm, is svk installed on athena anywhere? From: To: Time: Tue Mar 31 13:54:07 2009 I believe I found it too difficult to install in the svn locker. From: To: Time: Tue Mar 31 13:55:09 2009 From my experience, I'm not surprised... From: To: Time: Tue Mar 31 13:55:33 2009 it's full of icky perl stuff that doesn't play nicely with athena or afs From: To: Time: Tue Mar 31 13:55:54 2009 I think it's mostly that I don't know how to deal with perl dependencies in a locker. I don't think it's rocket science. From: To: Time: Tue Mar 31 13:56:44 2009 it's annoying enough to install it locally without overwriting bits of athena's perl installation From: To: Time: Tue Mar 31 13:58:21 2009 Yeah, last time I tried installing my own copy, I wound up starting with a new perl installation in an alternate location. Installing just extra packages in a new location may not be rocket science, but I couldn't puzzle it out at the time, with the time I was willing to invest in it. From: To: Time: Tue Mar 31 14:08:41 2009 Oh, we aren't handling AD-KDCIssued currently, are we? I think the spec has some inconsistencies. From: To: Time: Tue Mar 31 18:08:54 2009 (It should be a complete hang, not slowness.) From: To: Time: Tue Mar 31 18:09:50 2009 oh. i'm seeing lots of slowness. From: To: Time: Tue Mar 31 18:10:29 2009 Oh, wait, two different bugs. One is slowness. From: To: Time: Tue Mar 31 18:10:35 2009 http://mailman.mit.edu/pipermail/krbdev/2009-January/007437.html From: To: Time: Tue Mar 31 18:13:24 2009 http://pastebin.com/d2f89f1a1 is the patch I used. From: To: Time: Fri Apr 3 14:24:50 2009 Oh, hey, yet another way of handling resource cleanup. We can collect the whole set. From: To: Time: Fri Apr 3 14:33:56 2009 (CLEANUP_PUSH and related macros, used only in mk_priv/mk_safe/rd_priv/rd_safe.) From: To: Time: Sun Apr 5 02:02:30 2009 This room is not anonymous. From: To: Time: Tue Apr 7 21:12:55 2009 i could've sworn i had checked this multiple times, but it appears that the 1.6.x patch for CVE-2009-0846 has the problem that the test case segfaults, due to fun with kfree.c functions not checking for null pointers. not a problem on the trunk due to Greg's cleanup. From: To: Time: Wed Apr 8 11:45:21 2009 protocol error codes? From: To: Time: Wed Apr 8 11:45:45 2009 or are you looking at krb5_err.et? From: To: Time: Wed Apr 8 11:47:00 2009 API error codes; yes, I'm looking at krb5_err.et. From: To: Time: Wed Apr 8 12:10:45 2009 Free IPA coding style is somewhat amusing in places From: To: Time: Wed Apr 8 12:10:52 2009 http://www.freeipa.org/page/Coding_Style From: To: Time: Wed Apr 8 12:16:02 2009 Is there anything to #6203 (GSS_C_DELEG_POLICY_FLAG) besides review and commit? It looks pretty simple and straightforward. From: To: Time: Wed Apr 8 12:16:23 2009 nothing really, unless someone wants to insist on a project review for it. From: To: Time: Wed Apr 8 12:16:35 2009 the real interesting thing is the corresponding database change From: To: Time: Wed Apr 8 18:52:40 2009 Hm. I heard someone state very confidently what the expansion of PAC is and now I can't remember what it was. (The internets are reluctant to give up the answer.) From: To: Time: Wed Apr 8 18:57:18 2009 "Privilege Access Certificate" is looking plausible. From: To: Time: Sun Apr 12 02:03:38 2009 This room is not anonymous. From: To: Time: Mon Apr 13 11:12:28 2009 -a is used for address{ful|less} From: To: Time: Mon Apr 13 13:31:43 2009 krb5_mkt_resolve's error-handling is impressively broken. On the bright side, very little is likely to go wrong. From: To: Time: Mon Apr 13 13:58:39 2009 I have not missed the announcement of the beta have I? From: To: Time: Mon Apr 13 13:59:47 2009 there has not been one yet. still groveling over changes. From: To: Time: Mon Apr 13 15:49:15 2009 Oh, I bet encrypted padata is only used for a successful KDC reply, not for errors, so for a FAST-protected exchange it wouldn't be used until the reply key is finalized. From: To: Time: Mon Apr 13 15:49:25 2009 (In reference to my recent mail to krb-wg.) From: To: Time: Mon Apr 13 15:50:29 2009 which asn.1 memory management cleanups are prereqs for the FAST changes, if any? From: To: Time: Mon Apr 13 15:52:04 2009 I made a ticket marked for pullup with the ASN.1 changes; I believe they are all required unless you want to backport. From: To: Time: Mon Apr 13 15:53:28 2009 ok. it's just that the ordering of the tickets gets a bit weird. From: To: Time: Mon Apr 13 16:14:46 2009 looks like r21969 is also needed as a prereq for the ASN.1 cleanup From: To: Time: Mon Apr 13 16:26:22 2009 incoming... From: To: Time: Mon Apr 13 16:37:04 2009 Are we going to schedule a dev call tomorrow, or are we letting the IS&T all-hands trump our group meeting this week? From: To: Time: Mon Apr 13 16:37:22 2009 we are to attend the all-hands From: To: Time: Mon Apr 13 16:37:27 2009 i'll cancel the dev call From: To: Time: Mon Apr 13 16:38:20 2009 Thanks. (I'll likely come in anyway for the earlier call.) From: To: Time: Tue Apr 14 10:34:38 2009 Is there any ordering to the kinit usage message and do people have any preference about where the ticket armor option goes? From: To: Time: Tue Apr 14 10:34:56 2009 I haven't been able to discern any ordering. (I'm not the most qualified to answer, though.) From: To: Time: Tue Apr 14 11:26:06 2009 Yes, kinit could stand to be refactored now that krb4 support is gone. From: To: Time: Tue Apr 14 11:26:32 2009 we also need to reconcile with the KfM kinit (which has KIM support) From: To: Time: Tue Apr 14 11:29:01 2009 Don't forget the kfw kinit From: To: Time: Tue Apr 14 11:30:29 2009 I'm fairly sure that the kinit that gets used on kfw does not come from the krb5 tree even though the krb5 tree kinit does build as part of KFW From: To: Time: Tue Apr 14 17:06:56 2009 incoming... From: To: Time: Tue Apr 14 17:41:32 2009 send_tgs.c has gotten soundly thrashed. i'm going to pull up some changes not marked for pullup in order to make things merge more nicely. From: To: Time: Tue Apr 14 17:50:44 2009 argh. that still didn't do it. From: To: Time: Wed Apr 15 09:13:11 2009 ouch. fedex "express saver" was ~$107 for the mac From: To: Time: Wed Apr 15 09:38:40 2009 more like "express ripper" From: To: Time: Wed Apr 15 09:39:23 2009 i'm sure overnight would have been much worse From: To: Time: Wed Apr 15 13:11:19 2009 krb5_dbe_def_search_enctype is a little perplexing. First, before the big loop, if kvno == 0, it finds the max kvno of the key entries and sets kvno to that. Then, inside the loop, it has logic for if kvno isn't >= 0, which I think can only happen if there are no key entries or if there are only key entries with a kvno <= 0, neither of which should happen. From: To: Time: Wed Apr 15 13:18:58 2009 The comment indicates that kvno==0 means use the highest-numbered kvno the principal has, hence the first part, and kvno<0 is ignored for matching purposes (though there's a line early on that changes kvno to 0 if it is -1). Multiple magic values in a numeric field often make for messy code... From: To: Time: Wed Apr 15 13:20:09 2009 The <0 handling should be if you ask for a kvno of, say, -2, so as to fetch anything matching the other parameters (enctype for example). I'm not sure when you'd ask for that, instead of either a specific kvno or the most recent. From: To: Time: Wed Apr 15 13:21:09 2009 I don't think it would mean key entries would be stored with negative kvno values. From: To: Time: Wed Apr 15 13:21:21 2009 I think I see. kvno < 0 and valid stype or ktype means highest matching key, so we need the maxkvno logic. kvno == 0 means the result must be the highest kvno as well as matching. From: To: Time: Wed Apr 15 13:22:23 2009 The first case devolves to the second if you aren't searching for a specific ktype or stype, so the code sets kvno to 0 for efficiency. From: To: Time: Wed Apr 15 13:22:39 2009 If that doesn't cry out for a comment, I don't know what does. From: To: Time: Wed Apr 15 13:31:11 2009 feel free to tweak internal representations of key sets to be more intuitive... From: To: Time: Wed Apr 15 13:32:15 2009 I'm also a bit confused by the use of the variable name ktype to hold an enctype. I thought a key type was an enctype plus a salt type? From: To: Time: Wed Apr 15 13:33:05 2009 ktype used to mean enctype, except when it didn't, as in the case of the single-DES enctypes, which could share a single key among multiple DES cryptosystems (des-cbc-crc, des-cbc-md4, des-cbc-md5...) From: To: Time: Wed Apr 15 13:38:30 2009 I think it's not crying out for a comment so much as a new interface, but, well.... From: To: Time: Wed Apr 15 13:41:01 2009 "ktype" is presumably "key type", from when we treated the key type and encryption algorithm as somewhat distinct. From: To: Time: Wed Apr 15 13:41:27 2009 we didn't quite successfully stamp out "key type" from various bits of documentation and source From: To: Time: Wed Apr 15 13:49:34 2009 When I was originally testing the salt brokenness with aliases, Ken told me how to create a key with an explicit salt. What was that again? From: To: Time: Wed Apr 15 13:50:19 2009 using what program? kadmin.local? you give a "-e enctype:salttype" option but that only sets the salt type, not an explicit salt string. From: To: Time: Wed Apr 15 13:52:32 2009 With kadmin.local, yes. It was a specific -e enctype:salttype option which would result in the KDC sending a salt string to the client instead of leaving it blank. (I'm asking this just to help me understand salt types a little faster.) From: To: Time: Wed Apr 15 13:53:10 2009 i think using "onlyrealm" as the salttype is sufficient to force sending a salt string. From: To: Time: Wed Apr 15 13:53:20 2009 Oh... some of the salttype options can get the KDC to send a salt string. I don't think we have a way to set a specific salt string. From: To: Time: Wed Apr 15 13:53:53 2009 "normal" would mean nothing gets sent; "norealm" or "onlyrealm" should cause strings to be sent. From: To: Time: Wed Apr 15 13:54:15 2009 [i'm still in merge conflict hell but at least git is making things a little easier] From: To: Time: Wed Apr 15 13:54:22 2009 There's also "v4", "afs3", "certhash", and "special" in the salt-type name table, but they're, uh, special. From: To: Time: Wed Apr 15 13:54:42 2009 salt type being something that appears in the API but not in the protocol... From: To: Time: Wed Apr 15 13:54:49 2009 Yes. From: To: Time: Wed Apr 15 13:55:13 2009 Ah, so Ken's idea to generate a random salt for principals would require extending DB entries? From: To: Time: Wed Apr 15 13:56:14 2009 I think there's already room in the db entry, we just don't have a good way to use it. (Which may mean it's not getting exercised and could be horribly broken.) From: To: Time: Wed Apr 15 13:56:44 2009 one of the renaming patches tries to store the right thing into it, i thnk. From: To: Time: Wed Apr 15 13:56:52 2009 Though if the rename-principal functionality is complete i... yeah, what Tom said. From: To: Time: Wed Apr 15 13:57:16 2009 Ah, I see the space for it in my notes on the DB entry format. From: To: Time: Wed Apr 15 13:57:35 2009 But we never put anything there when creating a new principal, currently? From: To: Time: Wed Apr 15 13:57:45 2009 Not as far as I know. From: To: Time: Wed Apr 15 13:58:07 2009 certain salttypes mean that you assume that a certain string is already there. saves space, presumably. From: To: Time: Wed Apr 15 13:59:35 2009 Yeah, the space would probably add up, though by modern standards it's probably not all that much to worry about. From: To: Time: Wed Apr 15 14:00:51 2009 I don't see any principal renaming code in our tree. From: To: Time: Wed Apr 15 14:01:18 2009 there is an open ticket containing a patch, i believe From: To: Time: Wed Apr 15 14:04:13 2009 It looks like if we did ever store a salt in a DB entry, we would use KRB5_KDB_SALTTYPE_SPECIAL as the salt type? From: To: Time: Wed Apr 15 14:13:30 2009 Ah, #6323 from Apple is the rename patch. From: To: Time: Wed Apr 15 14:15:21 2009 And yes, it uses SALTTYPE_SPECIAL as the target salt type for NORMAL and NOREALM. (Not immediately sure what it's doing for ONLYREALM.) From: To: Time: Wed Apr 15 14:15:46 2009 probably doesn't matter as long as the principal remains in the same realm From: To: Time: Wed Apr 15 14:18:29 2009 It's leaving the key data type alone and copying in the realm name from the principal. I'm not sure what the reasoning is. From: To: Time: Wed Apr 15 14:21:32 2009 you could conceivably execute a realm rename one principal at a time if you did that, but it would suck... From: To: Time: Wed Apr 15 14:23:29 2009 Well, no, not really. get_salt_from_key ignores the data value in an ONLYREALM salt, so it's weird for the rename patch to be filling it in. I wonder if Love meant to change the salt type to special and missed it. From: To: Time: Wed Apr 15 14:23:47 2009 hm From: To: Time: Wed Apr 15 16:06:19 2009 incoming... From: To: Time: Wed Apr 15 16:35:36 2009 should 6454 be pulled up? From: To: Time: Wed Apr 15 17:03:09 2009 now that everyone on cvs-krb5 is thoroughly spammed by commit messages.... From: To: Time: Thu Apr 16 16:25:57 2009 do we think Love's patch for GSS_C_DELEG_POLICY_FLAG does the right thing for cross-realm? From: To: Time: Thu Apr 16 16:27:01 2009 I think as written, it only checks the flag on the service ticket, and I believe his blog discussed checking the flag on all of the intermediary tgt tickets. From: To: Time: Thu Apr 16 16:27:19 2009 as does his internet-draft From: To: Time: Thu Apr 16 16:27:40 2009 is there a way to do this without writing a new krb5 api to perform the check? From: To: Time: Thu Apr 16 16:29:47 2009 Probably not. (Checking on the i-d.) From: To: Time: Thu Apr 16 17:05:06 2009 Let me see what Heimdal does. From: To: Time: Thu Apr 16 17:09:22 2009 r23846 | lha | 2008-09-20 07:16:33 -0400 (Sat, 20 Sep 2008) | 2 lines Strip of ok-as-delegate for the tgt/service if the cross ticket didn't have one. From: To: Time: Thu Apr 16 17:09:42 2009 is that in the krb5 library or gss library? From: To: Time: Thu Apr 16 17:10:11 2009 In the krb5 library. From: To: Time: Thu Apr 16 17:10:40 2009 Basically, credentials won't have the ok-as-delegate flag set, even if the foreign KDC sets them, if the TGTs in the path don't also have it set. From: To: Time: Thu Apr 16 17:10:45 2009 oh so it's stripping the flag as it stores the flag data from the encpart of the kdc reply? From: To: Time: Thu Apr 16 17:15:00 2009 Not exactly; the logic is in get_cred.c. From: To: Time: Thu Apr 16 17:15:24 2009 so as early as possible... From: To: Time: Thu Apr 16 17:15:44 2009 i guess it precludes an implementation of a more permissive policy, but that may not be a bad thing. From: To: Time: Thu Apr 16 18:14:55 2009 (Pursuant to -c sipb conversation:) One of the things I'd like to eventually have for MIT krb5 is protocol tracing, since you can't easily trace an encrypted protocol with a third-party tool. Sort of like the ssh -v option, where it displays a human-readable interpretation of all of the things it sends and receives. From: To: Time: Thu Apr 16 18:15:24 2009 i thought wireshark had places where you could plug in a keytab From: To: Time: Thu Apr 16 18:16:07 2009 obviously this could become useless when we get forward secrecy implemented, though. From: To: Time: Thu Apr 16 18:16:25 2009 Hm, possibly and true. From: To: Time: Fri Apr 17 18:04:19 2009 RT/krbdev.mit.edu: Bugs fixed in krb5-1.7 Total: 345 ...wow From: To: Time: Sun Apr 19 02:02:27 2009 This room is not anonymous. From: To: Time: Wed Apr 22 14:12:44 2009 Goodness, KDB support for ok-as-delegate is a total mess at this point. From: To: Time: Wed Apr 22 14:13:02 2009 how so? From: To: Time: Wed Apr 22 14:17:07 2009 Sandia gave us a (fairly broken) patch using the flag value 0x10000 and the kadmin attribute name allow_ok_to_delegate. Sam sat on the patch in his inbox for some length of time. Later, Red Hat submitted a patch to our RT system, also using the flag value 0x10000 and the kadmin attribute name ok_as_delegate. Sam suggested switching the kadmin attribute name to match the Sandia attribute name, but at any rate, the patch sat there for two years. In the meantime, Luke's work added KDC support (but no kadmin support) using the flag value 0x100000 (five zeros). From: To: Time: Wed Apr 22 14:17:52 2009 do we have any indication whether Novell is using that flag value? From: To: Time: Wed Apr 22 14:18:49 2009 No; that part of the work wasn't documented in any fashion that I could see. From: To: Time: Wed Apr 22 14:19:48 2009 Luke's work added a header named kdb_ext.h which is described as a "KDB extensions SPI", but what that means is anyone's guess. From: To: Time: Wed Apr 22 14:45:58 2009 On the bright side, Red Hat hasn't shipped their patch, so the problem is probably contained to Sandia's deployment. From: To: Time: Wed Apr 22 15:30:59 2009 do we think there's any advantage in continuing the practice of making a tarfile containing the .tar.gz and the .tar.gz.asc PGP signature? From: To: Time: Wed Apr 22 15:31:31 2009 I thought the reason we did that is that the old distribution system required it. From: To: Time: Wed Apr 22 15:32:24 2009 not sure. there were some mime-type screwages that we experienced, but part of it was that some browsers of the time "helpfully" unpacked the .tar.gz files thus leaving the downloaders with no easy way to validate the signatures. From: To: Time: Thu Apr 23 04:08:49 2009 Wow. Three different bits of code (one in Heimdal, two in MIT krb5) using the same broken logic to compare krb5_data structures. I don't think it matters since everyone just wants equality or inequality, but ugh. From: To: Time: Thu Apr 23 04:09:04 2009 The Heimdal one is: if (data1->length != data2->length) return data1->length - data2->length; return memcmp(data1->data, data2->data, data1->length); From: To: Time: Thu Apr 23 05:16:46 2009 not sure i know what you mean about "broken logic". i guess for something returning other than a boolean result, you'd probably want something that could be used to generate a total order over a set of strings, and i'd not really thought about that, but I think that function would still work. Or am I overlooking something really obvious? Are you thinking that these should do more, like give you a normal alphabetical sorting of strings? From: To: Time: Thu Apr 23 05:17:36 2009 It's not a lexical ordering. From: To: Time: Thu Apr 23 05:18:21 2009 I mean, if there's a reason to always treat longer data values ordered after shorter ones, fine, but absent such a reason, I think it's broken to change the ordering just because your data structure is a counted string. From: To: Time: Thu Apr 23 05:24:00 2009 At least when I wrote such a thing (before disabling it because it was more efficient under gcc to actually test for equality than to see if this function returned 0), I was thinking only of total ordering, because in many cases krb5_data objects would not be strings and thus lexical ordering would be irrelevant. For example, using a tree for a lookaside cache. Not that such a thing wound up getting written anyways.... From: To: Time: Thu Apr 23 05:24:54 2009 If a comparison function wound up getting used in a place where lexical sorting would help, yes, sorting by length first would be a poor choice. From: To: Time: Thu Apr 23 05:26:10 2009 I guess "broken" is an overstatement, but it's at least odd in that it's not consistent with strcmp over C strings. One of the places this logic is used is in comparing principals; if you were ordering a set of principals, I would think you would want a lexical ordering of the components. From: To: Time: Thu Apr 23 05:26:38 2009 Oh, wait, we only do boolean principal comparison. From: To: Time: Thu Apr 23 05:27:02 2009 No argument there. But ... yeah, we don't do "<" comparisons on data objects currently, only equality, AFAIK. From: To: Time: Thu Apr 23 05:27:29 2009 Okay, weird. cmp = p1->length == p2->length ? strncasecmp(p1->data, p2->data, p2->length) : p1->length - p2->length; but the result is only checked for being 0. From: To: Time: Thu Apr 23 05:27:38 2009 (and I think I should've said "strict total order"...) From: To: Time: Thu Apr 23 05:27:39 2009 That third clause could be "1" or something. From: To: Time: Thu Apr 23 05:29:29 2009 Yeah. Performing a full "compare" operation and then only testing for equality is inefficient and needlessly general, unless you actually need ordering. From: To: Time: Thu Apr 23 14:06:57 2009 so should we rename the APIs so they more clearly indicate that they are a "test for equality" rather than "comparison/ordering"? From: To: Time: Thu Apr 23 14:12:30 2009 I don't think so especially for the public apis From: To: Time: Sun Apr 26 02:03:01 2009 This room is not anonymous. From: To: Time: Mon Apr 27 16:59:50 2009 for what reasons did we decide that the added complexity of CTS was worth the limited benefits? From: To: Time: Mon Apr 27 17:43:46 2009 The block size of AES is bigger than for DES, so the size reduction from eliminating padding is larger with AES. And it's not much more complexity in implementation, aside from anything coded with a "we only know how to do CBC with padding" mindset. (Though that probably does include some hardware and software-library implementations. But, implementing CTS on top of CBC-with-padding isn't that tough.) From: To: Time: Mon Apr 27 17:44:41 2009 when it came up in discussions in the IEEE 1619 effort, there were some concerns about its effects on pipelined implementations. From: To: Time: Mon Apr 27 17:46:05 2009 of course IEEE 1619 uses a parallelizable cipher mode, so the impact of CTS would be greater. still, it's not inconceivable that there is a pipelined CBC implementation that would suffer performance degradation when used to implement CBC-CTS. From: To: Time: Mon Apr 27 17:48:07 2009 I'm sure you could come up with a CBC implementation that suffers when munged to do CBC-CTS. For example, a hardware CBC implementation that can feed its output directly into NIC buffers, but can't be made to automatically munge the last couple of blocks. From: To: Time: Mon Apr 27 17:48:11 2009 anyway i was thinking of this while i was dissecting the opensolaris implementation of RFC 3962. From: To: Time: Mon Apr 27 17:50:01 2009 Some of the AEAD modes do arrange for efficient parallel and/or pipelined implementation. Not something we were thinking about when RFC 3962 was in the works. From: To: Time: Mon Apr 27 17:51:07 2009 i think we should consider such efficiency for future modes. (we will want something stronger than SHA-1 soon but not immediately) From: To: Time: Mon Apr 27 17:53:44 2009 What sort of environment makes pipelined Kerberos encryption important? I've mostly seen such concerns in the IPsec context; Kerberos tends to have random unaligned data buried in ASN.1 where the CPU has to get involved well before you could point hardware encryption at it. And I don't think our messages tend to be big enough for multicore parallelism to be worth the synchronization cost. From: To: Time: Mon Apr 27 17:55:18 2009 maybe less so for the core krb5 protocol, but GSS-CFX tokens use RFC 3961 crypto for bulk data. From: To: Time: Mon Apr 27 18:00:02 2009 Yeah, but there too you've got CFX and application wrapping around the ciphertext. My impression is that for serious performance you'd probably want to bind to an IPsec association (handwave handwave) and let the people working on optimizing that (via hardware or kernel code) do so. Then forego encryption in the application protocol. From: To: Time: Mon Apr 27 18:14:20 2009 also, FIPS-140-x certified modules are not generally going to have an interface for doing CTS. we can of course ask NIST to consider including it as an approved mode. From: To: Time: Mon Apr 27 18:14:46 2009 Yeah... I thought Russ was supposed to be working on that a long time ago. From: To: Time: Mon Apr 27 18:24:35 2009 also, there is a NIST proposal for recommending CTS mode, but it looks old-ish, and does not involve the swapping of the last two ciphertext blocks. From: To: Time: Mon Apr 27 18:25:55 2009 If it's isomorphic to CTS as we use it -- so that you can implement RFC 3962 on top of an implementation of the NIST mode -- that should be good enough. From: To: Time: Mon Apr 27 18:26:30 2009 well it's not published officially as part of a recommendation yet. From: To: Time: Mon Apr 27 18:27:28 2009 Poke Tim and find out what's up... From: To: Time: Mon Apr 27 19:16:05 2009 Can someone take a look at krb5_mk_ncred's handling of KRB5_AUTH_CONTEXT_RET_SEQUENCE? If that flag is present but DO_SEQUENCE is not, it looks like the sequence number is never incremented, but can be decremented on error. Is there something I'm missing? From: To: Time: Wed Apr 29 13:45:06 2009 has anyone built krb5-1-7 on Windows recently? From: To: Time: Wed Apr 29 13:45:55 2009 or head for that matter From: To: Time: Wed Apr 29 13:51:04 2009 I believe Ken did some work on getting it to build before he left. From: To: Time: Wed Apr 29 13:51:32 2009 the reason I ask is that at the present time it can't build From: To: Time: Wed Apr 29 13:53:04 2009 there are some Makefile issues and some fussy compiler things. From: To: Time: Wed Apr 29 13:53:38 2009 CCAPI is either missing files, does cci_stream.[ch] exist ? From: To: Time: Wed Apr 29 13:54:35 2009 the Windows compiler won't permit assignment of a (void *) typed object to a non-void * variable without a cast. [src/include/k5-platform.h] inline functions do that From: To: Time: Wed Apr 29 13:55:41 2009 I was looking at some problems but IIRC there were still some broken pieces when I left. From: To: Time: Wed Apr 29 13:55:51 2009 src/include/k5-ipc_stream.h creates a struct and a typedef with the same name From: To: Time: Wed Apr 29 13:56:06 2009 "k5_ipc_stream" From: To: Time: Wed Apr 29 13:56:32 2009 there are new error tables that are not preprocessed From: To: Time: Wed Apr 29 13:57:03 2009 The void* thing came up before... if we're working in C++ that's not allowed. I thought it got fixed, maybe not, or maybe not in enough places... From: To: Time: Wed Apr 29 13:57:27 2009 Microsoft's compiler doesn't permit it in C mode either From: To: Time: Wed Apr 29 13:57:34 2009 Then it's buggy. From: To: Time: Wed Apr 29 13:59:16 2009 So we have to cast the return value of malloc everywhere? We have tons of code which doesn't do that, and I don't think it's all new in 1.7. From: To: Time: Wed Apr 29 13:59:54 2009 It doesn't complain about malloc() From: To: Time: Wed Apr 29 13:59:58 2009 Yeah, if this is a problem in compiling C code on Windows, we should've run into it long ago. From: To: Time: Wed Apr 29 14:00:03 2009 it complains about k5-platform.h From: To: Time: Wed Apr 29 14:00:35 2009 Which function? It's a big header. From: To: Time: Wed Apr 29 14:01:17 2009 Index: krb5-1-7/src/include/k5-platform.h =================================================================== --- krb5-1-7/src/include/k5-platform.h (revision 22288) +++ krb5-1-7/src/include/k5-platform.h (working copy) @@ -536,7 +536,7 @@ static inline void store_16_be (unsigned int val, void *vp) { - unsigned char *p = vp; + unsigned char *p = (unsigned char *)vp; #if defined(__GNUC__) && defined(K5_BE) PUT(16,p,val); #elif defined(__GNUC__) && defined(K5_LE) && defined(SWAP16) @@ -549,7 +549,7 @@ static inline void store_32_be (unsigned int val, void *vp) { - unsigned char *p = vp; + unsigned char *p = (unsigned char *)vp; #if defined(__GNUC__) && defined(K5_BE) PUT(32,p,val); #elif defined(__GNUC__) && defined(K5_LE) && defined(SWAP32) @@ -564,7 +564,7 @@ static inline void store_64_be (UINT64_TYPE val, void *vp) { - unsigned char *p = vp; + unsigned char *p = (unsigned char *)vp; #if defined(__GNUC__) && defined(K5_BE) PUT(64,p,val); #elif defined(__GNUC__) && defined(K5_LE) && defined(SWAP64) @@ -583,7 +583,7 @@ static inline unsigned short load_16_be (const void *cvp) { - const unsigned char *p = cvp; + const unsigned char *p = (unsigned char *)cvp; #if defined(__GNUC__) && defined(K5_BE) return GET(16,p); #elif defined(__GNUC__) && defined(K5_LE) && defined(SWAP16) @@ -595,7 +595,7 @@ static inline unsigned int load_32_be (const void *cvp) { - const unsigned char *p = cvp; + const unsigned char *p = (unsigned char *)cvp; #if defined(__GNUC__) && defined(K5_BE) return GET(32,p); #elif defined(__GNUC__) && defined(K5_LE) && defined(SWAP32) @@ -609,7 +609,7 @@ static inline UINT64_TYPE load_64_be (const void *cvp) { - const unsigned char *p = cvp; + const unsigned char *p = (unsigned char *)cvp; #if defined(__GNUC__) && defined(K5_BE) return GET(64,p); #elif defined(__GNUC__) && defined(K5_LE) && defined(SWAP64) @@ -621,7 +621,7 @@ static inline void store_16_le (unsigned int val, void *vp) { - unsigned char *p = vp; + unsigned char *p = (unsigned char *)vp; #if defined(__GNUC__) && defined(K5_LE) PUT(16,p,val); #elif defined(__GNUC__) && defined(K5_BE) && defined(SWAP16) @@ -634,7 +634,7 @@ static inline void store_32_le (unsigned int val, void *vp) { - unsigned char *p = vp; + unsigned char *p = (unsigned char *)vp; #if defined(__GNUC__) && defined(K5_LE) PUT(32,p,val); #elif defined(__GNUC__) && defined(K5_BE) && defined(SWAP32) @@ -649,7 +649,7 @@ static inline void store_64_le (UINT64_TYPE val, void *vp) { - unsigned char *p = vp; + unsigned char *p = (unsigned char *)vp; #if defined(__GNUC__) && defined(K5_LE) PUT(64,p,val); #elif defined(__GNUC__) && defined(K5_BE) && defined(SWAP64) @@ -668,7 +668,7 @@ static inline unsigned short load_16_le (const void *cvp) { - const unsigned char *p = cvp; + const unsigned char *p = (unsigned char *)cvp; #if defined(__GNUC__) && defined(K5_LE) return GET(16,p); #elif defined(__GNUC__) && defined(K5_BE) && defined(SWAP16) @@ -680,7 +680,7 @@ static inline unsigned int load_32_le (const void *cvp) { - const unsigned char *p = cvp; + const unsigned char *p = (unsigned char *)cvp; #if defined(__GNUC__) && defined(K5_LE) return GET(32,p); #elif defined(__GNUC__) && defined(K5_BE) && defined(SWAP32) @@ -692,7 +692,7 @@ static inline UINT64_TYPE load_64_le (const void *cvp) { - const unsigned char *p = cvp; + const unsigned char *p = (unsigned char *)cvp; #if defined(__GNUC__) && defined(K5_LE) return GET(64,p); #elif defined(__GNUC__) && defined(K5_BE) && defined(SWAP64) From: To: Time: Wed Apr 29 14:02:04 2009 Looks familiar... I hope that's not something I dropped on the floor when I left. Don't know if the windows vms are still around to check. From: To: Time: Wed Apr 29 14:02:19 2009 So, that's functionally not different from the malloc case. Is that header being included in C++ code, perhaps? From: To: Time: Wed Apr 29 14:03:00 2009 if you have C++ code in the source tree then it would be From: To: Time: Wed Apr 29 14:03:03 2009 My recollection was of running into it in C++ code. From: To: Time: Wed Apr 29 14:03:23 2009 k5-ipc_stream.h calls its structure k5_ipc_stream_s and its typedef k5_ipc_stream. Those are two different names. From: To: Time: Wed Apr 29 14:03:46 2009 not in src/include/k5-ipc_stream.h From: To: Time: Wed Apr 29 14:04:03 2009 I checked out krb5-1-7 from svn last night From: To: Time: Wed Apr 29 14:04:10 2009 the struct has no _s From: To: Time: Wed Apr 29 14:04:14 2009 Yeah, there's C++ code in the Windows-specific support. I don't think this is a C issue, even on Windows. From: To: Time: Wed Apr 29 14:04:33 2009 Ken fixed the k5-platform.h issue in r21902 (Feb 5) but did not mark it for pullup. From: To: Time: Wed Apr 29 14:05:02 2009 the answer to my question then is "no one has built krb5-1-7 on Windows" From: To: Time: Wed Apr 29 14:05:09 2009 Ken fixed the k5-ipc_stream.h issue in r21918 but did not mark it for pullup. From: To: Time: Wed Apr 29 14:05:19 2009 So, I guess, yes for head, no for 1.7. From: To: Time: Wed Apr 29 14:05:43 2009 does MIT have an intention that .1.7 should build on Windows? From: To: Time: Wed Apr 29 14:07:01 2009 I haven't seen a clear declaration of our Windows strategy since I signed on. Tom might have an answer. I can put together a ticket referencing Ken's Windows build fixes and mark it for pullup as a stopgap. From: To: Time: Wed Apr 29 14:07:04 2009 Ah, okay. I thought I got something checked in. We'd never discussed 1.7 for Windows (vs continuing with separate KfW branches), so I wouldn't have bothered marking for pullup. From: To: Time: Wed Apr 29 14:07:59 2009 There may be other stuff on the trunk needed to make it build for Windows. From: To: Time: Wed Apr 29 14:10:33 2009 We really need a Windows VM set up somewhere to automatically run builds and report results. Something like buildbot may be worth looking at. From: To: Time: Wed Apr 29 14:11:12 2009 there was such a machine that the pismere team had. it ran night builds of the trunk and various branches From: To: Time: Wed Apr 29 14:12:01 2009 Yeah. We only got results indirectly and rarely. And couldn't do things like tell it to build from the 1.7 branch. From: To: Time: Wed Apr 29 14:12:21 2009 (by ourselves... we could poke pismere people, when there were any) From: To: Time: Wed Apr 29 14:12:40 2009 the machine had a remote command interface that permitted arbitrary builds to be kicked out From: To: Time: Wed Apr 29 14:12:43 2009 s/out/off From: To: Time: Wed Apr 29 14:12:53 2009 Qing wrote it From: To: Time: Wed Apr 29 14:14:00 2009 news to me. the krb5 team needs to have such info and access. but it really needs to be more automated -- run command foo, then we get nightly or continuous builds from branch x. From: To: Time: Wed Apr 29 14:14:22 2009 it was written for the krb5 team From: To: Time: Wed Apr 29 14:15:01 2009 oh. From: To: Time: Wed Apr 29 14:15:39 2009 I do not remember there ever being separate kfw branches. Perhaps that is a new release model. When I was working on kfw, there were separate kfw release tags but all kfw releases were off of the standard release branch From: To: Time: Wed Apr 29 14:16:43 2009 I will try building the head. From: To: Time: Wed Apr 29 14:17:35 2009 Well, if we want to move towards a model of having releases that build on both UNIX and Windows, we should have the ability to test the current release branch, and whatever we're still making patches for. From: To: Time: Wed Apr 29 14:18:53 2009 s/we/MIT/ :-) From: To: Time: Wed Apr 29 14:19:11 2009 no disagreement from me From: To: Time: Wed Apr 29 14:25:07 2009 We don't have any configure tests for C99 support currently, do we? From: To: Time: Wed Apr 29 14:26:30 2009 I think there are tests for one or two C99 features, but not for C99 in general. You should be able to test the value of __STDC_VERSION__ (or whatever it's called) though. From: To: Time: Wed Apr 29 14:26:45 2009 we might test for individual c99 features, as it appears to be getting implemented piecemeal. From: To: Time: Wed Apr 29 14:27:20 2009 __STDC_VERSION__ would be 199901L for C99 (or higher for future updates). From: To: Time: Wed Apr 29 14:40:20 2009 Huh, I can't figure out how to get gcc to define __STDC_VERSION__ at all. From: To: Time: Wed Apr 29 14:41:05 2009 try -std=c99 or -std=gnu99 From: To: Time: Wed Apr 29 14:41:59 2009 I tried -std=c89 and that didn't seem to cut it, but -std=c99 works. We don't pass that when building stuff, though, so that wouldn't work for us. From: To: Time: Wed Apr 29 14:42:22 2009 Yeah, __STDC_VERSION__ wasn't added until C99. From: To: Time: Wed Apr 29 14:42:55 2009 for c89 you mostly get variations on exactly what __STDC__ gets defined as From: To: Time: Wed Apr 29 14:48:10 2009 We probably don't want to start using options for standards specifications when we can avoid it. Telling a compiler to adhere to standard X often means also disabling the OS extensions. It'd probably best be done on a case by case basis when one can confirm that we're not accidentally disabling stuff we need or want. From: To: Time: Wed Apr 29 14:49:50 2009 If you're looking at the line-number stuff you sent email about, you could test for __VA_ARGS__ support in configure. Probably most of the (non-Windows) systems we care about will be running recent enough versions of gcc for it to be okay. I don't recall if the Sun compiler supports it... From: To: Time: Wed Apr 29 14:49:57 2009 Yeah, I wouldn't want to start passing -std=c99. Basically, I can either (a) test for __STDC__VERSION__ >= whatever || __GNUC__ >= whatever, or (b) add a configure test for C99-style variadic macro support. From: To: Time: Wed Apr 29 14:52:09 2009 It seems like something easy enough to test with configure, and that'll help with vendor compilers. From: To: Time: Wed Apr 29 14:53:28 2009 Google found me an example configure test pretty easily. From: To: Time: Wed Apr 29 14:54:20 2009 The autoconf archive is also a good place to look. From: To: Time: Wed Apr 29 14:56:44 2009 Last release three days ago? Slackers. From: To: Time: Wed Apr 29 15:12:34 2009 So, if I'm writing a configure test, I have to test once for C and once for C++. I'm not sure how to integrate that into our configure.in. From: To: Time: Wed Apr 29 15:13:15 2009 My understanding is that you use AC_LANG to select a language to run tests for, but we never seem to use that declaration. From: To: Time: Wed Apr 29 15:13:43 2009 (I guess the default of C works for us, but how do we test for C++ features currently?) From: To: Time: Wed Apr 29 15:18:59 2009 I don't think we test much in the way of C++ features, mostly just assume any C feature test results apply. Which isn't true for some GCC warning options. From: To: Time: Wed Apr 29 15:21:58 2009 Do we build any c++ code with autoconf? From: To: Time: Wed Apr 29 15:23:56 2009 Test programs. From: To: Time: Wed Apr 29 15:24:09 2009 Which isn't terribly interesting. I can just assume no variadic macros for C++, or something. From: To: Time: Wed Apr 29 15:24:25 2009 (C99-style variadic macros are not part of C++, although gcc supports them when compiling C++ code.) From: To: Time: Wed Apr 29 15:55:40 2009 Some of the Windows code is written in C++. But since you'd almost certainly not get variadic macros for VS2003 C++ either, testing for them only for C is probably fine. From: To: Time: Wed Apr 29 15:56:01 2009 Oh, with autoconf... no, just test programs, right. From: To: Time: Wed Apr 29 18:25:23 2009 *sigh* So, we've got two tickets in RT that propose specific patches for adding des3 PRF. Both assume a prf output size of 16 not 8. If I do what e agreed in SF, I will break interop with KINK implementations. From: To: Time: Wed Apr 29 18:28:19 2009 Wait, you want to truncate to the block size, not the closest multiple of it? From: To: Time: Wed Apr 29 18:28:45 2009 I don't see why you'd want a 3des PRF to be breakable with a 2^64 brute force attack. From: To: Time: Wed Apr 29 18:33:06 2009 I want to use ECB mode. From: To: Time: Wed Apr 29 18:33:51 2009 What do you mean breakable by a 2^64 attack? Yes, you can construct a code book in 2^64 calls to the PRF and you can build a distinguisher in 2^32 calls. From: To: Time: Wed Apr 29 18:33:58 2009 I don't see that as a big deal. From: To: Time: Wed Apr 29 18:34:33 2009 But in terms of attacks on the key--as opposed to oracle attacks--I think it's got 2^112 strength From: To: Time: Wed Apr 29 18:36:41 2009 It only has 2^64 outputs, right? From: To: Time: Wed Apr 29 18:38:07 2009 Yes. From: To: Time: Wed Apr 29 18:39:08 2009 But I don't see that as a problem for a PRF. From: To: Time: Wed Apr 29 18:40:14 2009 If we're using it to generate a key, we'll only generate 2^64 different keys, right? From: To: Time: Wed Apr 29 18:40:38 2009 Let's consider a common use case: a constant number of calls to the PRF used to determine some new key. From: To: Time: Wed Apr 29 18:42:38 2009 That depends. There are literally only 2^64 possible 8-byte values. No 8-bypte-range function can give you better performance. If you are generating an 8-byte key, then yes, you can only generate 2^64 keys. From: To: Time: Wed Apr 29 18:44:29 2009 Of course. But say you're generating another 3DES key with multiple calls to the PRF. From: To: Time: Wed Apr 29 18:45:07 2009 A perhaps more interesting case is using the 3des PRF to generate a 3DES key. Since ECB is a permutation, there exists some input to DES3 that will give you any given output. Assume you're combining two blocks, which is what you're probably doing. So, there is some sequence of inputs that will give you any valid 128-bit key. (This all assumes SHA-1 is well distributed) From: To: Time: Wed Apr 29 18:47:54 2009 I don't think that follows. Let's say we used to the same input for both blocks (we don't, I know). Obviously not all 128-bit values would be generated. So clearly ECB being a permutation is not sufficient; that only tells us there are 2^64 possibly values for each block. From: To: Time: Wed Apr 29 18:49:05 2009 Yes, you're correct. Using different inputs does matter. From: To: Time: Wed Apr 29 18:49:50 2009 We're assuming ECB is a pseudo-random permutation. That means that without knowing the key, we cannot distinguish ECB from a random function. From: To: Time: Wed Apr 29 18:50:50 2009 We know that assumption falls apart if we make too many calls to ECB. I think if you see more than 2^32 PRF outputs, you're likely to have enough data to guess that it is not a PRF. From: To: Time: Wed Apr 29 18:52:46 2009 You're proposing encrypt(truncate(sha1(1 || input), 64 bits)) || encrypt(truncate(sha1(2 || input), 64 bits)), right? And I'm effectively proposing encrypting the first 64 bits of sha1(1 || input) and then the next 64 bits. From: To: Time: Wed Apr 29 18:53:14 2009 But if we're generating multiple keys, we have a construction that has a key index. We're looking at ecb(sha1(1|key_index))|ecb(sha1(2|key_index)) From: To: Time: Wed Apr 29 18:54:20 2009 Sort of. Note that in my construction, it is up to the application to turn the prf into a prfplus From: To: Time: Wed Apr 29 18:54:39 2009 I guess this boils down to whether sha1-trunc64(1|blah) | sha1-trunc64(2|blah) is as good of a hash function as sha1-trunc128(1|blah). From: To: Time: Wed Apr 29 18:54:53 2009 But in practice your summary is correct. From: To: Time: Wed Apr 29 18:56:23 2009 Right. And depending on the attack we care about second preimage or collision resistance From: To: Time: Wed Apr 29 18:58:47 2009 Well, actually, in your construction it is the CBC encryption not the ECB encryption of the sha-1. From: To: Time: Wed Apr 29 19:00:41 2009 I think I should go forward with what we decided in SF, but I also think I should send mail From: To: Time: Thu Apr 30 11:47:16 2009 I usually do a "merge into" operation. Then looking up the dup gets you the other ticket, instead of a "closed as duplicate" page. From: To: Time: Thu Apr 30 11:51:55 2009 Crud, I probably should have merged that into #3089. From: To: Time: Thu Apr 30 11:52:15 2009 Well, it's not too bad. From: To: Time: Thu Apr 30 11:55:28 2009 It appears that Tom's procedure is to add a comment to the ticket and add a "depended on" relationship. Unfortunately, I don't see any way to undo a merge, which is part of why that answer is now unattractive to me. From: To: Time: Thu Apr 30 11:56:35 2009 Yeah, undoing a merge requires fiddling around in the database directly. Tom's figured out how. From: To: Time: Thu Apr 30 12:57:11 2009 I merged into the wrong ticket. I can't undo that. If I had simply added a dependency, I could have fixed it easily. From: To: Time: Thu Apr 30 12:57:58 2009 (It was also entirely too easy to perform an irreversible operation on the DB.) From: To: Time: Thu Apr 30 13:11:35 2009 OK, got patches for DES from KAMADA-san (The all caps part of the name is a sir-name, right?) which will be good because I can review them. It's less likely both of us will make the same mistake From: To: Time: Thu Apr 30 13:12:07 2009 Yes, all-caps is a convention to distinguish the surname. From: To: Time: Thu Apr 30 13:34:53 2009 which merge needs undoing? From: To: Time: Thu Apr 30 13:35:00 2009 One second... From: To: Time: Thu Apr 30 13:38:13 2009 I merged #3235 into #4805. It would have been better to add a dependency on #4805 or merge it into #3089. From: To: Time: Thu Apr 30 13:40:33 2009 ok, unmerged. the reason why it's irreversable through the UI is partly because once the merge occurs, any future transactions get put in the merge target ticket, so unmerging afterward can take cleanup. From: To: Time: Thu Apr 30 13:40:58 2009 rt2=> update tickets set effectiveid=3235 where id=3235; basically From: To: Time: Thu Apr 30 13:41:05 2009 Thanks. From: To: Time: Thu Apr 30 13:41:41 2009 of course use extreme caution because SQL makes it far too easy to accidentally apply an update to every row in a table... From: To: Time: Thu Apr 30 13:44:29 2009 The RT CLI for RT2 does too. I remember once doing rt --status=foo not --limit-status=foo From: To: Time: Thu Apr 30 13:46:06 2009 I think it would be sort of cool to have a bug-tracking system backed by flat files in a version control system, instead of an SQL database. (Trac has a wiki page talking about doing this, but I don't think it will ever happen.) From: To: Time: Thu Apr 30 13:46:41 2009 GNATS might have been the most likely one to do that, but it has other issues From: To: Time: Thu Apr 30 13:47:28 2009 in other news, working on writing up ciphertext stealing is hurting my brain From: To: Time: Thu Apr 30 13:50:01 2009 Tom, what ever happened to those AEAD IOV GSS issues you ran into at MS? Have you had time to reproduce/debug? From: To: Time: Thu Apr 30 13:59:03 2009 if you mean the shim-exercise stuff, not yet. From: To: Time: Thu Apr 30 14:04:01 2009 disappointingly but not surprisingly, the wikipedia article on CTS is misleading and/or wrong in a few places. From: To: Time: Thu Apr 30 14:09:19 2009 What are you writing up CTS for? Do you think anything you saw there may be a 1.7 blocker? From: To: Time: Thu Apr 30 14:10:17 2009 writing it up for feedback to NIST From: To: Time: Thu Apr 30 14:10:34 2009 nothing with regard to CTS that would be a 1.7 blocker. From: To: Time: Thu Apr 30 14:13:20 2009 the main variation is whether to swap the two final blocks. From: To: Time: Thu Apr 30 14:16:27 2009 In general, or just for messages that are multiples of the block size? From: To: Time: Thu Apr 30 14:16:28 2009 it doesn't help that the ciphertext blocks are numbered differently by different authors. From: To: Time: Thu Apr 30 14:16:33 2009 in general From: To: Time: Thu Apr 30 14:17:58 2009 Weird. I hadn't seen variants that don't swap them. I wonder what the advantage of not swapping is... From: To: Time: Thu Apr 30 14:18:05 2009 for example one author may use C[n-1] to mean the ciphertext output by encrypting P[n-1] XOR C[n-2], while another may use it to mean the ciphertext from encrypting the short block that gets swapped From: To: Time: Thu Apr 30 14:18:45 2009 the tradeoffs aren't obvious to me, but apparently makes some difference to storage encryption implementors. From: To: Time: Thu Apr 30 14:19:55 2009 the most reasonble and consistent notation i've seen uses C[n-1] to mean the ciphertext corresponding to the encryption of P[n-1] regardless of where it ends up, and denotes partial blocks by using asterisks or similar. From: To: Time: Thu Apr 30 14:21:47 2009 No, anything in the shim results that is a 1.7 blocker. I'm concerned about cases where the AEAD APIs don't behave interoperably with the normal APIs From: To: Time: Thu Apr 30 14:22:07 2009 so you have C[n-1] = E(P[n-1] XOR C[n-2]) = C*[n-1] || C**[n-1] C[n] = E((P*[n]||pad) XOR C[n-1]) and then you can send either ...C[n-2]||C*[n-1]||C[n] or ...C[n-2]||C[n]||C*[n-1] From: To: Time: Thu Apr 30 14:22:23 2009 Much sadness. From: To: Time: Thu Apr 30 14:22:24 2009 oh i see. do you have reason to believe that's actually the case? From: To: Time: Thu Apr 30 14:26:06 2009 Tom, the behavior you were seeing certainly sounded like that to me From: To: Time: Thu Apr 30 14:26:47 2009 We have a problem. In its infinite clarity, RFC 3961 says that DES's key seed is 8 bytes long and that random-to-key is parity-fix on that eight byte string. That's not particularly what our code does. From: To: Time: Thu Apr 30 14:27:30 2009 We ran into this as MS when we tried to use DES pkinit with Windows. It's kind of a bigger problem for the DES PRF From: To: Time: Thu Apr 30 14:27:31 2009 oh, a different RFC 3961 problem. From: To: Time: Thu Apr 30 14:27:57 2009 and we need to do something about 8 vs 16 for DES3 PRF as well? From: To: Time: Thu Apr 30 14:28:36 2009 As far as I can tell Kamada-san is OK with us breaking KINK. From: To: Time: Thu Apr 30 14:29:05 2009 If someone ever needs that to work we can define a local enctype that is a 16-byte 3DES PRF. From: To: Time: Thu Apr 30 14:29:34 2009 And do the same for DES. (They assume that the length of a DES PRF output is 16 as well. From: To: Time: Thu Apr 30 14:30:31 2009 It turns out little in Kerberos actually uses the random-to-key operation. Besides CF2 and PKINIT, random-to-key is an implementation matter. From: To: Time: Thu Apr 30 14:31:06 2009 because we mostly use it to implement session key generation and similar? From: To: Time: Thu Apr 30 14:31:17 2009 Exactly From: To: Time: Thu Apr 30 14:33:41 2009 *sigh* RFC 3961's DES PRF is ill-defined: it is des-cbc of a 128-byte value From: To: Time: Thu Apr 30 14:33:57 2009 O, no, not ill-defined. Simply not what I was talking about here From: To: Time: Thu Apr 30 14:34:23 2009 Let's go see what heimdal does From: To: Time: Thu Apr 30 14:34:24 2009 so is that a raw des-cbc encryption with zero IV? From: To: Time: Thu Apr 30 14:34:51 2009 Yes From: To: Time: Thu Apr 30 14:35:16 2009 well perhaps key-as-IV for des-cbc-crc if we want to be consistently broken in that regard From: To: Time: Thu Apr 30 14:39:19 2009 No. OK, so heimdal 1.2 doesn't seem to do either DES or 3DES PRF From: To: Time: Thu Apr 30 14:39:41 2009 i think i remember seeing that From: To: Time: Thu Apr 30 14:42:07 2009 So, unless they have added support in a later release, we're actually unconstrained for DES and 3DES. From: To: Time: Thu Apr 30 14:42:42 2009 perhaps we should try to coordinate with them From: To: Time: Thu Apr 30 14:42:55 2009 I have patches basically ready to commit. Any of the behaviors under discussion with the exception of changing the des or des3 random-to-key behavior are relatively easy. From: To: Time: Thu Apr 30 14:43:06 2009 But I do kind of need to know what to do. From: To: Time: Thu Apr 30 14:47:23 2009 I don't kno if I have time to run the political riddle trail of figuring out what all the constraints are here and building consensus. I can write up the issue and send mail but I don't know how much time I have to bring it to closure From: To: Time: Thu Apr 30 14:50:32 2009 what besides KINK and FAST use the PRF? From: To: Time: Thu Apr 30 14:54:55 2009 The GSS pseudo-random function, probably the OTP preauth draft. From: To: Time: Thu Apr 30 14:55:08 2009 MIT and Heimdal expose it as a public interface From: To: Time: Thu Apr 30 15:09:59 2009 I'd really appreciate input on what we *should* do if interop is not an issue From: To: Time: Thu Apr 30 15:10:19 2009 That is, if we can get others to interop with whatever From: To: Time: Thu Apr 30 15:10:40 2009 are there significant security tradeoffs? From: To: Time: Thu Apr 30 15:12:42 2009 I don't think so. I understand how to do the proof better if you use ECB mode, but I've basically convinced myself that CBC mode is probably OK too. From: To: Time: Thu Apr 30 15:13:25 2009 The CBC approach looks at first glance like it is better because it provides more output, but I think I'm mostly convinced myself that is also false From: To: Time: Thu Apr 30 15:13:47 2009 I mean, obviously it does provide more output, but I don't think it matters From: To: Time: Thu Apr 30 15:17:08 2009 If CBC is okay, then I don't see any reason to gratuitously break the written spec for DES and DES3. (I do think there is a reason to break the written spec for AES-CTS, and we covered that in krb-wg; I don't think there was careful consideration of the impact on DES3 or DES.) From: To: Time: Thu Apr 30 15:17:12 2009 single-DES PRF output is 128 bits, right? From: To: Time: Thu Apr 30 15:17:46 2009 I think that's the question at hand. Sam's understanding of what we decided at krb-wg is that it should be 64 bits (the block size). From: To: Time: Thu Apr 30 15:19:06 2009 No, I don't think we discussed DES PRF at all. I think that we decided the output for 3DES should be 64-bits. From: To: Time: Thu Apr 30 15:19:13 2009 Amusingly, if it doesn't matter how small the output size of the PRF is, I wonder if Sam's original misinterpretation of the written spec for AES (truncate to 1 byte) would have been okay to implement, aside from Heimdal compatibility. From: To: Time: Thu Apr 30 15:19:19 2009 I don't remember deciding that explicitly. From: To: Time: Thu Apr 30 15:20:17 2009 one of the stated purposes of the PRF is to produce output suitable for key generation. outputting one byte doesn't exactly help much with that. From: To: Time: Thu Apr 30 15:21:25 2009 I think the interpretation was the truncate the hash to one byte, but not truncate the output. That might have been secureish for FAST, but it would make me highly uneasy... We'd have to make sure that none of the prf inputs for FAST happened to hash to the same first byte. From: To: Time: Thu Apr 30 15:21:44 2009 No, we discussed things in terms of the simplified profile with AES and 3DES as affected enctypes From: To: Time: Thu Apr 30 15:23:23 2009 i'm not sure what you mean by "truncate the hash to one byte, but not truncate the output" From: To: Time: Thu Apr 30 15:23:44 2009 Larry's writeup: We then discussed an issue involving the RFC3961 PRF for AES. We found that all current implementations truncate the output to multiple of AES cipher block size 16 bytes while the specification in RFC3961 does not truncate. We decided to adopt the PRF with truncation as the official PRF but we are to find out what is the right process to do this and we will involve the document author Ken and security AD Tim Polk. The decision is to be verified on the list. From: To: Time: Thu Apr 30 15:24:47 2009 I believe that writeup is highly biased because AES is the only simplified profile cipher Larry implements From: To: Time: Thu Apr 30 15:25:16 2009 i'd have to go back and listen to the session audio to find out, probably, but i think we also talked about "truncate to one cipher block" vs "truncate to nearest smaller multiple if not already a multiple of cipher block size" From: To: Time: Thu Apr 30 15:25:25 2009 My understanding was that the only discussion of 3des was Ken bringing it up in the chatroom and it not being carefully considered. From: To: Time: Thu Apr 30 15:26:32 2009 I tend to agree with Greg though. In terms of what to say in the spec, you could either say truncate downward to the nearest multiple of the blocksize of the underlying block cipher, not truncating at all if the hash is already a multiple of the blocksize. Or if you want to continue to be general and support things that are not block ciphers, have the enctype provide a length that you truncate both the hash and output to From: To: Time: Thu Apr 30 15:27:13 2009 simplified profile is only for block ciphers, right? From: To: Time: Thu Apr 30 15:29:57 2009 No, simplified profile does not require the cipher have a block size From: To: Time: Thu Apr 30 15:30:13 2009 It does prepend a confounder From: To: Time: Thu Apr 30 15:31:27 2009 ok, some of the text in section 5 assumes a block cipher in a CBC-like mode, and some doesn't. the title says "CBC Ciphers" though. From: To: Time: Thu Apr 30 15:31:27 2009 We did sort of assume (or explicitly require?) that the confounder would randomize the rest of the ciphertext, so ECB mode or a simple XOR stream cipher wouldn't be desirable. From: To: Time: Thu Apr 30 15:33:55 2009 Hmm. The minutes reflect Greg's understanding. I believe they are incorrect, but since no one objected, they do stand as the record of the meeting. From: To: Time: Thu Apr 30 15:34:49 2009 http://jabber.ietf.org/logs/krb-wg/2009-03-24.txt is the chatroom archive. I don't think the audio stream brought up 3des in any conclusive manner. From: To: Time: Thu Apr 30 15:35:53 2009 simplified profile requires that there be a cipherblock-size equivalent parameter for ciphers that are not block ciphers, i think. From: To: Time: Thu Apr 30 15:36:57 2009 Sounds right. I think we waved our hands a bit about the specifics, but the intent was that it should work securely with CBC mode, and any mode similar enough that, well, it would work securely... From: To: Time: Thu Apr 30 15:38:21 2009 if we want to be consistent between simplified profile and single-DES, i will note that the single-DES PRF definitions do not truncate to a single DES cipher block. (but MD5 outputs 128 bits so it wouldn't truncate under either interpretation) From: To: Time: Thu Apr 30 15:38:51 2009 No, 3DES was discussed. [23:10:27] for 3des it also uses sha1 but m=8. so you are trun cating to 64 bits. From: To: Time: Thu Apr 30 15:39:14 2009 Yes, but Simon was using the faulty interpretation of "truncate to a multiple of m". From: To: Time: Thu Apr 30 15:40:02 2009 and as i recall, neither Heimdal nor MIT implement PRF for DES3 or single-DES. From: To: Time: Thu Apr 30 15:40:06 2009 What's wrong with that interpretation? From: To: Time: Thu Apr 30 15:40:13 2009 Okay, back up. From: To: Time: Thu Apr 30 15:40:20 2009 If you have 1001 and you truncate to a multiple of 100, you get what? From: To: Time: Thu Apr 30 15:41:06 2009 Apparently you and Simon think the answer is 100. To most of us, that makes no sense. The word "multiple" is not cosmetic, and the answer is 1000. From: To: Time: Thu Apr 30 15:41:26 2009 O, sorry, Greg, brain falt; thanks From: To: Time: Thu Apr 30 15:41:52 2009 you could be unambiguous and say "truncate to the nearest multiple of n" From: To: Time: Thu Apr 30 15:53:27 2009 OK, so both DES and 3DES have 16-byte PRF output? From: To: Time: Thu Apr 30 15:53:44 2009 as i read it, yes. From: To: Time: Thu Apr 30 15:56:59 2009 I am asking about what we are proposing, not what the spec says. From: To: Time: Thu Apr 30 16:05:53 2009 16-byte is easier to implement and the security tradeoffs are probably negligible, so go with 16-byte. (also backward compatibility with KINK is nice) From: To: Time: Thu Apr 30 16:06:33 2009 I have about 20 minutes left to work on Kerberos before Monday. From: To: Time: Thu Apr 30 16:08:33 2009 Tom, going for it. I strongly recommend that we get a response from Love before shipping even if it means hunting him down on the phone From: To: Time: Thu Apr 30 16:20:27 2009 oh, hm. Sam, you sent your PRF message to Love at his Apple address. i think he wants to use his KTH address when he's wearing his Heimdal hat. From: To: Time: Thu Apr 30 16:32:22 2009 Sorry bout that. He can ((and may well) yell at me From: To: Time: Thu Apr 30 16:32:40 2009 i'm writing a follow-up From: To: Time: Thu Apr 30 16:36:24 2009 oops. Sam got there first. i'll read and then decide whether my follow-up is redundant. From: To: Time: Sun May 3 02:02:28 2009 This room is not anonymous. From: To: Time: Mon May 4 12:14:14 2009 krb5_get_cred_from_kdc_opt may win the award for biggest monster function in libkrb5. (Although krb5_unparse_name is still up there.) From: To: Time: Mon May 4 12:14:48 2009 i made it smaller, but then referrals support happened. From: To: Time: Mon May 4 18:09:15 2009 what was the intended random-to-key for single-DES, anyway? From: To: Time: Mon May 4 18:09:46 2009 (also, our single-DES string-to-key is rather untidy) From: To: Time: Mon May 4 18:13:03 2009 the text in section 6.2 of rfc3961 makes it clear that at least at some point the intent was to use des_random_to_key as the random-to-key. the individual enctype definitions conflict with that. From: To: Time: Mon May 4 18:19:19 2009 also, 3961 doesn't specify which parity is used for DES key bytes, though the examples and external sources imply odd parity. From: To: Time: Tue May 5 12:07:57 2009 Are we having a call at 3pm today or 4pm? My calendar says 4pm but my email says 3pm. From: To: Time: Tue May 5 12:08:18 2009 (Not a dev meeting call.) From: To: Time: Wed May 6 12:13:06 2009 no response yet on krb-wg list about what RFC 3961 really says about single-DES random-to-key. From: To: Time: Wed May 6 12:28:30 2009 the three main implementations (MIT, MSFT, Heimdal) do different and incompatible things for single-DES random-to-key. no matter what else, two must change for there to be interop... From: To: Time: Mon May 11 12:11:45 2009 i have evidence that the IOV_SHIM_EXERCISE issue is only on the unwrap side (which is consistent with it being unable to talk to itself) From: To: Time: Mon May 11 12:31:10 2009 OK. The problem we saw (the stream iov stuff not handling mixed cfx/non-cfx) definitely fell into that class From: To: Time: Mon May 11 12:32:38 2009 it also clearly contains or is the result of implementation bug because turning on the shim for only unwrap causes gss callers to segfault. From: To: Time: Mon May 11 12:34:56 2009 OK. So it's probably located only in the stream IOV code? If so, sounds like not a blocker for 1.7 From: To: Time: Mon May 11 12:35:48 2009 i haven't nailed down the exact location yet, but it does seem likely to be in the stream IOV code. From: To: Time: Mon May 11 12:36:31 2009 Well, we confirmed the stream iov code was broken by inspection at the interop From: To: Time: Mon May 11 12:38:10 2009 so the observation that iov-shimmed gss_wrap can talk to non-shimmed gss_unwrap is reasonably convincing that it shouldn't be a release blocker? From: To: Time: Mon May 11 12:41:55 2009 Good enough for me From: To: Time: Mon May 11 12:44:17 2009 1.7 beta1 is now in ubuntu and Debian's development releases. From: To: Time: Mon May 11 12:44:32 2009 cool From: To: Time: Mon May 11 12:45:03 2009 (Which is how we found the Heimdal oops) From: To: Time: Mon May 11 14:30:28 2009 i prefer my testing infrastructure to be deterministic unless there's a good reason for it not to be. From: To: Time: Mon May 11 14:30:50 2009 ==tlyu From: To: Time: Mon May 11 14:32:34 2009 Sure. A static boolean variable flipped on each check would do that. But you need to make sure you have at least two uses in the same process. From: To: Time: Mon May 11 16:55:29 2009 incoming... From: To: Time: Tue May 12 13:01:09 2009 Could someone jabber me the bridge info? From: To: Time: Tue May 12 19:18:02 2009 tagged 1.7b2; now building tarballs. From: To: Time: Tue May 12 19:28:00 2009 (right; copy file into place before updating link) From: To: Time: Tue May 12 19:40:03 2009 done From: To: Time: Tue May 12 21:01:34 2009 ppc-darwin is big-endian, isn't it? there should still be some around there... From: To: Time: Tue May 12 21:12:07 2009 running a ppc-linux build now. slow machine though. From: To: Time: Tue May 12 21:18:30 2009 wow, compiling with one sub-gigahertz core is annoyingly slow. :) From: To: Time: Tue May 12 21:20:00 2009 ok, t_pac ran fine for me. From: To: Time: Tue May 12 21:20:16 2009 going away again now :) From: To: Time: Wed May 13 10:44:37 2009 Now, Debian reports that we completely break the nfs server with 1.7. From: To: Time: Wed May 13 11:49:50 2009 Hmm, did that last message go here From: To: Time: Wed May 13 11:50:04 2009 If not, see http://bugs.debian.org/528514 From: To: Time: Wed May 13 11:50:45 2009 So, it definitely looks like the error handling path is broken in export_lucid_context. Seems like it can leak contexts. However looks like I'll need to construct a test case From: To: Time: Wed May 13 12:12:00 2009 My read is that the NFS server is passing a bogus third argument to gss_krb5int_export_lucid_sec_context which would cause a crash in generic_gss_oid_decompose. But that seems amiss; if that's right, I need to understand what these functions are and whether we used the wrong API. From: To: Time: Wed May 13 12:12:13 2009 (Where "we" is Luke.) From: To: Time: Wed May 13 12:12:35 2009 Hm, maybe not Luke. From: To: Time: Wed May 13 12:13:33 2009 Okay, yes Luke. r21690 completely changes the API of that function. From: To: Time: Wed May 13 12:19:46 2009 I'm looking at the mskrb logs and it seems to have been related to the mechglue work, but I'm not sure how; sometimes the changes to that file don't seem to have anything to do with the log messages. From: To: Time: Wed May 13 12:25:58 2009 Greg, how do you get the nfs server passing an invalid argument from that backtrace? From: To: Time: Wed May 13 12:27:27 2009 Luke added an extra layer of indirection. The calling convention between the export_lucid_context in krb5_gss_glue.c and lucid_context.c should preserve the API. I have not verified this From: To: Time: Wed May 13 12:37:31 2009 I'll look again. From: To: Time: Wed May 13 12:41:22 2009 I was looking at the wrong file. From: To: Time: Wed May 13 12:45:41 2009 An aside: what is an "extended" backtrace? From: To: Time: Wed May 13 12:47:53 2009 Oh, I think I understand what he means. From: To: Time: Wed May 13 13:03:26 2009 To me, it sounded like that backtrace was after lucid_context returned From: To: Time: Wed May 13 13:06:26 2009 Yeah. I'm not sure what you're saying about the error path; it seems to be a bug in the success path where the result is set inappropriately (but I'm not sure specifically how; gss_inquire_sec_context_by_oid is a reading barrier). From: To: Time: Wed May 13 13:08:40 2009 In the error path, it looks like the code can allocate a lucid context structure and then fail to add it to the buffer set and fail to free it From: To: Time: Wed May 13 13:09:18 2009 That's not what is happening here. From: To: Time: Wed May 13 13:10:26 2009 gss_inquire_sec_context_by_oid takes an OID and then calls gss_inquire_sec_context_by_oid in the implementation of the mechanism that is used for the given context From: To: Time: Wed May 13 13:11:07 2009 It's basically a complicated function dispatch mechanism that implements something similar to C++ virtual tables. From: To: Time: Wed May 13 13:13:09 2009 You should start in the mech_glue implementation of gss_inquire_sec_context_by_oid discover that you have a krb5 context, fix up the context pointer to be a krb5 context not a union context and then call the krb5 implementation of gss_inquire_sec_context_by_oid. That should look at the oid, notice it is a lucid context oid and call the krb5 lucid context export function. I'm being vague about function names here because I don't remember whether gss comes before or after krb5 or whether it is krb5 or krb5int From: To: Time: Wed May 13 13:13:15 2009 Oh, sure, I get what it does. It's just, if you're reading the code, you have no idea where that's going to go, so you sort of have to make it happen and step through. From: To: Time: Wed May 13 13:37:14 2009 Ken's success re t_pac on ppc implies it's not an endianness issue. From: To: Time: Wed May 13 13:43:58 2009 the EINVAL comes from deep in the unicode support. From: To: Time: Wed May 13 14:24:01 2009 i did run make depend From: To: Time: Wed May 13 14:24:09 2009 not sure that anything else changed From: To: Time: Wed May 13 14:24:24 2009 Let's see if I can reproduce From: To: Time: Wed May 13 14:25:18 2009 Bugs with -j builds are nondeterministic, right? So it could have been buggy in beta1 and you got lucky. From: To: Time: Wed May 13 14:26:03 2009 Bugs with -j builds can be non-deterministic. From: To: Time: Wed May 13 14:34:20 2009 And this one seems to be non-deterministic. *sigh* From: To: Time: Wed May 13 14:34:45 2009 how important is making the build work with parallel make? From: To: Time: Wed May 13 14:35:53 2009 For modern multicore/multiprocessor systems? I think it's pretty important. I kind of thought we had the -j bugs worked out though. From: To: Time: Wed May 13 14:36:36 2009 they're going to keep reappearing unless we make an enforceable way to keep the build system safe for parallel make From: To: Time: Wed May 13 14:37:16 2009 Where did it blow out? Maybe if it's in one of the newer bits of code... e.g., Luke's unicode stuff did some odd things to short-cut having to write real makefile support... From: To: Time: Wed May 13 14:37:24 2009 The Debian and Ubuntu build farms tend to do parallel builds unless explicitly told not to do so. From: To: Time: Wed May 13 14:37:48 2009 installing profile.h From: To: Time: Wed May 13 14:38:31 2009 Well, that's not quite true. Debian autobuilders tend to request parallel builds and policy says you should support them if possible From: To: Time: Wed May 13 14:38:48 2009 What was the command run? I have noticed that something like "make -j9 all install" doesn't work right because it tries to do "install" in parallel with "all", and we don't always have "install" construct the targets properly; you really need to do "all" first. From: To: Time: Wed May 13 14:39:41 2009 make -j3 all From: To: Time: Wed May 13 14:40:37 2009 Then what do you mean by "installing profile.h"? Copying to BUILDTOP/include ? From: To: Time: Wed May 13 14:48:25 2009 yes From: To: Time: Wed May 13 14:48:41 2009 Weird. Looks like we use different techniques on Windows vs non-Windows for expressing to make that we want to copy profile.h to the include directory. And I think maybe we waste too much effort on making sure we don't update the timestamp if the file content hasn't changed. But if we do want to do that, that's definitely something where we should have a consistent technique that we're confident works with parallel make. From: To: Time: Wed May 13 14:51:53 2009 Ah... the copying is done by the "includes" rule on UNIX, and the .o targets don't explicitly depend on that. Though if the "deps" file is up to date, it would express dependencies on the profile.h in the include directory. I'm not sure if $(BUILDTOP)/include/profile.h in the dependencies will match $(PROFILE_HDR) as a target though (order of expansion vs when strings are compared). From: To: Time: Wed May 13 14:52:46 2009 That would give us two different rules doing copying. From: To: Time: Wed May 13 14:53:22 2009 Try "make depend" and see if that helps. From: To: Time: Wed May 13 14:54:18 2009 Well since I can't reproduce it at all :-) From: To: Time: Wed May 13 14:55:34 2009 Ah. Hm... From: To: Time: Wed May 13 15:11:26 2009 right. i'm looking at a "how did this _ever_ work" scenario in the utf8 conversion code. From: To: Time: Wed May 13 15:20:54 2009 ok, we don't get SWAP16 on Solaris, i think. take a look at k5_ucs2s_to_utf8s in util/support/utf8_conv.c, and tell me if something looks fishy to you as well. From: To: Time: Wed May 13 15:29:13 2009 Ohh... this sounds familiar, actually. If I didn't bring it up on our lists, I think I brought it up with Luke. Don't remember the outcome. Maybe I still have the email... From: To: Time: Wed May 13 15:30:38 2009 the rest of that file and utf8.c don't really look encouraging either. From: To: Time: Wed May 13 15:30:39 2009 Yeah, it was at least in a list I emailed to you (Tom) on Jan 9. From: To: Time: Wed May 13 15:34:10 2009 And (without explicitly mentioning SWAP16, but mentioning this code) to krbcore on Jan 12, forwarded by Tom to krbdev-release; subject "some issues and questions on new work". Still looking through the discussion. From: To: Time: Wed May 13 15:35:50 2009 Hm, that issue kind of got dropped in the discussion. Though, I'd initially had the impression that at least some of the faulty code wasn't reachable, and was presumably just there for completeness. From: To: Time: Wed May 13 15:36:16 2009 That was also the impression I walked away with. From: To: Time: Wed May 13 15:36:43 2009 Oh, wait... My krbcore email talked about storing big-endian values on a little-endian system. From: To: Time: Wed May 13 15:37:52 2009 Ah... from my list to Tom: "And SWAP16 isn't guaranteed to be defined at all, but I've worked around that already, at least as long as we stay in the BMP." So, I guess something broke there? From: To: Time: Wed May 13 15:38:54 2009 look carefully at the fallback definition of SWAP16 in utf8_conv.c and how it's used. From: To: Time: Wed May 13 15:39:17 2009 Oh. Yeah. In utf8_conv.c, if K5_BE is defined (a condition Luke's code had already) and SWAP16 isn't defined, I defined it. Did I botch it? From: To: Time: Wed May 13 15:39:44 2009 look at line 272 for instance. From: To: Time: Wed May 13 15:40:17 2009 Oh, that's just doomed. Bad Luke. From: To: Time: Wed May 13 15:40:35 2009 (No reason to assume a system-provided swap-16 macro is going to be safe there either.) From: To: Time: Wed May 13 15:40:59 2009 given that this produces a factor-of-two read overrun, i think we need to fix it before final release. From: To: Time: Wed May 13 15:42:02 2009 not to mention that these functions are full of questionable signedness handling. From: To: Time: Wed May 13 15:42:45 2009 Is this luke's code or ldap's code? From: To: Time: Wed May 13 15:43:11 2009 Well, you're going to need to fix the NFS issue too. So you're already into needing beta3 From: To: Time: Wed May 13 15:43:16 2009 It's also going to give wrong results on any big-endian platform where we don't get K5_BE defined (which is not guaranteed to happen, only that we don't define both that and K5_LE). From: To: Time: Wed May 13 15:43:44 2009 ldap, with tweaks to use our byte-swapping macros/fns From: To: Time: Wed May 13 15:44:08 2009 i would think OpenLDAP would deal with sane byte-swapping From: To: Time: Wed May 13 15:44:26 2009 or does nobody try to run OpenLDAP on a big-endian platform? From: To: Time: Wed May 13 15:44:53 2009 Probably needs to pull in whatever infrastructure they're using, duplicating work. Or maybe they do something like determine byte order at configure time, which we can't do for Mac builds. From: To: Time: Wed May 13 15:49:39 2009 valid range of UCS-2 includes 0x8000-0xFFFF, right? From: To: Time: Wed May 13 15:50:27 2009 Yes. From: To: Time: Wed May 13 15:51:44 2009 right. Unicode-4.0 tells me 0x8000 is smack in the middle of the CJK area. it looks like the ucs2s_to_utf8s will fail badly with those characters because krb5_ucs2 is a signed type. From: To: Time: Wed May 13 15:52:27 2009 Ugh. From: To: Time: Wed May 13 15:52:44 2009 do you agree with my analysis? From: To: Time: Wed May 13 15:54:23 2009 Hmm... is it also a 16-bit type? Certainly looking at this code I'd assume it could handle 0xFFFF without sign-extending. From: To: Time: Wed May 13 15:55:03 2009 Ah, it's short, and signed. Bleah. Yeah, that looks broken. From: To: Time: Wed May 13 15:55:16 2009 how many more problems are lurking in here?? From: To: Time: Wed May 13 15:56:57 2009 I totally missed the signedness issue when reviewing that code. :-( Sorry about that... From: To: Time: Wed May 13 16:18:14 2009 so it seems like krb5_ucs2 should probably be an unsigned type, but that seems like an awfully risky change without a lot more in-depth knowledge of this code. From: To: Time: Wed May 13 16:25:31 2009 I'll look into the implications. From: To: Time: Wed May 13 16:25:45 2009 thanks From: To: Time: Wed May 13 16:30:40 2009 So, one obvious problem is that there is a distinguished value KRB5_UCS2_INVALID which is defined to be a valid character (0x8000). From: To: Time: Wed May 13 16:46:11 2009 that's patently bogus. i'm fairly sure U+8000 is a valid character From: To: Time: Wed May 13 16:46:37 2009 oh you mean that the sentinel value is for some reason a valid Unicode character? From: To: Time: Wed May 13 16:49:00 2009 I'm not sure what the difference between those two statements is. I believe it's bogus. From: To: Time: Wed May 13 16:49:49 2009 ok, i somehow misinterpreted your first statement about UCS2_INVALID but i am at a loss to succinctly describe how. From: To: Time: Wed May 13 16:51:03 2009 Does "UCS2_INVALID" imply that the value is not a valid code point, or that it's a code point chosen for use as an "invalid" flag in the code? ... I think was the confusion? In any case, 8000 looks like a valid code point according to my mac. From: To: Time: Wed May 13 16:51:59 2009 it looks like UCS2_INVALID was chosen by analogy with UCS4_INVALID as a sentinel value, because the conversion functions try to return ucs4 or ucs2 characters. From: To: Time: Wed May 13 16:52:02 2009 But if it's looking at sign-extended 16-bit values in 32- or 64-bit land, 0x8000 wouldn't be possible as it would've been sign-extended; kind of like using 0..n or -1 for "invalid" From: To: Time: Wed May 13 16:54:07 2009 An example usage is krb5int_utf8_to_ucs2, which returns KRB5_UCS2_INVALID if you pass it invalid UTF-8. From: To: Time: Wed May 13 16:54:13 2009 It might be wise to ask Luke what he was thinking. From: To: Time: Wed May 13 16:54:34 2009 I can do that if no one else wants to. From: To: Time: Wed May 13 16:54:52 2009 which calls utf8_to_ucs4, and translates its return from UCS4_INVALID to UCS2_INVALID if needed. From: To: Time: Wed May 13 16:55:19 2009 or we could summon him to the chatroom :-) From: To: Time: Wed May 13 16:55:46 2009 That function also restricts the return value to being in the positive range of 16-bit values, chopping off the upper half of what can be represented in real-life UCS2. From: To: Time: Wed May 13 16:56:39 2009 A possible alternative for the "invalid" value is something in the surrogate range. (UCS2 does not include surrogate pairs; for that you use UTF16.) From: To: Time: Wed May 13 16:57:16 2009 hm. the surrogate idea sounds useful but kludgey From: To: Time: Wed May 13 16:58:03 2009 Too bad we -- er, you -- don't have anyone on staff trying to use CJK characters in passwords. Or... um... musical symbols at U+1D100? From: To: Time: Wed May 13 16:59:06 2009 I think we only use UCS2 in the PAC functions at the moment; the corresponding Windows code presumably uses wchar_t, which Wikipedia thinks holds UCS2 values. I don't know what it does about characters that can't be represented in UCS2. From: To: Time: Wed May 13 17:02:23 2009 I think that's one of the problems -- as we've seen it described, you only get to use the BMP, not full Unicode. From: To: Time: Wed May 13 17:04:21 2009 RC4 string-to-key uses it as well From: To: Time: Wed May 13 17:04:31 2009 I'm failing to google "the BMP". From: To: Time: Wed May 13 17:04:45 2009 basic multilingual plane From: To: Time: Wed May 13 17:04:53 2009 I see it now. From: To: Time: Wed May 13 17:05:30 2009 the thing is Microsoft will probably want to enable the use of characters outside the BMP for some applications, so i would imagine that they have worked on this problem. From: To: Time: Wed May 13 17:06:53 2009 I'm sending mail to Luke. From: To: Time: Wed May 13 17:09:56 2009 inconclusive stuff online suggests that Microsoft moved their OSes from UCS-2 to UTF-16 around Windows 2000 or so. From: To: Time: Wed May 13 17:13:59 2009 Ah, good. It would really have been silly for them not to. Of course that means even with a 16-bit wchar_t, variable-length encodings are needed. From: To: Time: Wed May 13 17:14:02 2009 I'm going to cc krbcore in case I get something wrong. From: To: Time: Wed May 13 17:14:36 2009 I think we certainly want to avoid using 16-bit character widths except when we have to for Microsoft compatibility. Either UTF8 or UCS4 makes sense. From: To: Time: Wed May 13 17:15:47 2009 i suspect that the right answer is to make utf8_to_ucs2 actually return ucs4 and do exception-handling, or to change all the callers to do something sane using ucs4 instead. From: To: Time: Wed May 13 17:16:59 2009 Probably reasonable. From: To: Time: Wed May 13 17:18:42 2009 Well, the PAC support needs to do things like convert a principal from a UTF8 string to a little-endian UCS2 string. I assume we can't just make that use a UCS4 string instead. But we don't need a distinguished not-a-character value inside strings, so we could use UCS4 for singleton characters or something. From: To: Time: Wed May 13 17:19:24 2009 that's what i was thinking. of course the utf8_to_ucs2 doesn't handle generating surrogate pairs. From: To: Time: Wed May 13 17:21:06 2009 It's not a huge deal if we don't support characters outside the BMP in our PAC handling functions, but it's a bigger deal if our API support precludes doing so in the future. From: To: Time: Wed May 13 17:21:34 2009 I wonder what Heimdal does here. From: To: Time: Wed May 13 17:23:27 2009 we could just give up and start requiring libintl, but that seems like an awfully big hammer. (not sure it's a bigger hammer than what we've got already) From: To: Time: Wed May 13 17:29:39 2009 Looks like Heimdal uses uint16_t for UCS4 strings, and avoids defining any APIs which need a distinguished invalid character value. From: To: Time: Wed May 13 17:30:14 2009 I guess the API situation in our code base isn't that bad; we don't export any of the UTF/UCS types or APIs. From: To: Time: Wed May 13 17:30:37 2009 (They're all defined in k5_utf8.h which isn't installed.) From: To: Time: Wed May 13 17:31:57 2009 What's wrong with NULL as a distinguished value for singleton characters? It doesn't work so well in strings From: To: Time: Wed May 13 17:32:46 2009 some of the APIs here can use explicit-length strings From: To: Time: Wed May 13 17:32:59 2009 Well, the key function here is krb5int_utf8_to_ucs4, and it seems like it might be nice to know if the return value is 0 because the UTF8 value is 0, or because the UTF8 value was invalid or doesn't fit in the BMP. From: To: Time: Wed May 13 17:34:02 2009 Uh, krb5int_utf8_to_ucs2, rather. From: To: Time: Wed May 13 18:07:47 2009 Maybe our strings should be strings. :) I mean, when things are conceptually character strings and not octet strings, ruling out NUL (and maybe SOH, EOT, BS, TAB, etc) seems reasonable. From: To: Time: Wed May 13 18:17:20 2009 If you want to check for nul to input, that's easy enough. You can create bool krb5int_utf8_is_nul From: To: Time: Wed May 13 18:19:15 2009 True, and you don't even really need that; UTF nul is just a 0 byte. From: To: Time: Wed May 13 18:19:52 2009 Oh, but we wouldn't want to hard-code such implementation details all over our code... From: To: Time: Wed May 13 18:21:39 2009 I can't tell if you're kidding. The whole point of UTF8 is that ASCII maps directly. From: To: Time: Wed May 13 18:22:27 2009 some protocol elements use character strings that are not null-terminated and also do not explicitly exclude null characters. From: To: Time: Wed May 13 18:23:14 2009 Yeah, the function would be simple enough that I assumed Sam was kidding, so... From: To: Time: Wed May 13 18:24:24 2009 Do we have such protocol elements where we aren't trying to constrain to IA5String or something? Doesn't that exclude NUL? Oh, but the UTF8String version maybe would permit it; hmm... From: To: Time: Wed May 13 18:27:10 2009 No, I was assuming that the utf8 side might contain multiple characters potentially and so it might be as complicated as a call to strlen. If people find that convenience function valuable, I don't object to it existing. From: To: Time: Wed May 13 18:27:21 2009 IA5String is register entries 1, 6, plus DELETE and SPACE. entry 1 is the ASCII C0 control character set, which includes NUL. From: To: Time: Wed May 13 18:27:30 2009 But yes I would object to a function that checked the first character of a string to see if it is nul From: To: Time: Wed May 13 18:28:35 2009 Ah, my bad then. We probably should've blocked out control characters, I suspect. From: To: Time: Wed May 13 18:29:14 2009 probably From: To: Time: Wed May 13 18:29:44 2009 newlines are control characters, and there might be parts of the protocol where they could plausibly appear. probably not inside a principal name though. From: To: Time: Thu May 14 11:40:53 2009 k5-platform.h says it takes care of [u]int{8,16,32}_t and it makes use of them (as does some of our code), but I don't see any logic in there to ensure that they exist. autoconf.h.in doesn't seem to go any further than defining HAVE_INT32_T and friends depending on configure tests. From: To: Time: Thu May 14 11:58:38 2009 it could be that it's k5-int.h that takes care of that. it's been a while since i last dealt with that stuff. From: To: Time: Thu May 14 12:02:23 2009 I was just wondering if I could simplify the type definitions in k5-utf8.h, but it's not important. From: To: Time: Thu May 14 12:11:40 2009 Weird. ucdata.c is full of functions using krb5_ui_4 instead of krb4_ucs4. From: To: Time: Thu May 14 12:11:55 2009 Which generates some warnings if they don't happen to be the same 32-bit type. From: To: Time: Thu May 14 12:11:59 2009 that is odd. From: To: Time: Thu May 14 12:12:24 2009 the way we choose krb5_int32 etc are not completely consistent with C99/POSIX intNN_t types From: To: Time: Thu May 14 12:18:31 2009 Okay, back to Sam's bug report. From: To: Time: Thu May 14 12:24:48 2009 The interlaced version ended up 1M smaller From: To: Time: Thu May 14 12:24:59 2009 mix From: To: Time: Thu May 14 12:35:41 2009 I'm about 90% certain I see the fix for the NFS problem. From: To: Time: Thu May 14 12:37:29 2009 What do you think the problem is? From: To: Time: Thu May 14 12:37:29 2009 I will see if I can get Bastian to test the fix so I don't have to construct a test case. From: To: Time: Thu May 14 12:38:00 2009 Do you want me to build packages? From: To: Time: Thu May 14 12:38:23 2009 Line 110 of lucid_context.c should assign &lctx to rep.value, not lctx. It's copying the first sizeof(void *) bytes of the context itself into the data set, not the pointer to the context. From: To: Time: Thu May 14 12:38:58 2009 Does it make sense for you to build packages with a patch before the patch is committed and pulled up? I guess that's what Debian package patches are for. From: To: Time: Thu May 14 12:40:00 2009 Well, I was going to build a package just for him, to make it easier for him to test. That definitely makes sense although he can probably do that too. From: To: Time: Thu May 14 12:40:30 2009 I was not going to upload until we hear back From: To: Time: Thu May 14 12:40:45 2009 Okay. Do you want me to send you a patch or is my description good enough? From: To: Time: Thu May 14 12:43:03 2009 This is what you're looking at? diff --git a/src/lib/gssapi/krb5/lucid_context.c b/src/lib/gssapi/krb5/lucid_con index 32b0e13..ff8fe6e 100644 --- a/src/lib/gssapi/krb5/lucid_context.c +++ b/src/lib/gssapi/krb5/lucid_context.c @@ -107,7 +107,7 @@ gss_krb5int_export_lucid_sec_context( goto error_out; } - rep.value = lctx; + rep.value = &lctx; rep.length = sizeof(lctx); retval = generic_gss_add_buffer_set_member(minor_status, &rep, data_set); From: To: Time: Thu May 14 12:43:35 2009 Yes. From: To: Time: Thu May 14 12:45:34 2009 OK, I'll send him a patch. He doesn't tell me what architecture he's using so I don't know what to build for. From: To: Time: Thu May 14 12:45:38 2009 how did that get there? From: To: Time: Thu May 14 12:46:22 2009 It's a bug in Luke's mechglue work. From: To: Time: Thu May 14 12:46:25 2009 Actually, regardless of whether or not this fixes the problem, by inspection, the patch clearly improves the situation. I'll just upload From: To: Time: Thu May 14 12:48:08 2009 By the same token, I'll commit my patch but leave the ticket open until we get a response back from Bastian. From: To: Time: Thu May 14 13:18:43 2009 wait, how is that fix correct? you're copying the address of an automatic variable into an output. From: To: Time: Thu May 14 13:25:14 2009 *sigh* you're right. not the problem From: To: Time: Thu May 14 13:26:04 2009 hm. still trying to figure out how many levels of indirection need to go on here. is the lucid context supposed to be a void* that is a handle? or is it supposed to be a blob of bytes? From: To: Time: Thu May 14 13:28:36 2009 in 1.6, export_lucid took a void** argument, which i guess is supposed to be the address of a void* variable into which it would copy the lctx pointer? From: To: Time: Thu May 14 13:30:22 2009 Correct. As far as I can tell, the code was correct before the patch. From: To: Time: Thu May 14 13:31:09 2009 It's not a handle, but depending on the version you request, you may in future need to cast to a different struct pointer From: To: Time: Thu May 14 13:32:06 2009 but wait... add_buffer_set_member copies what the input member_buffer points to, not the pointer. From: To: Time: Thu May 14 13:35:57 2009 In addition, cleaning up the context in krb5_gss_glue.c seems wrong because I think at that point you have a union context not a krb5 context, right? From: To: Time: Thu May 14 13:35:59 2009 Yes. From: To: Time: Thu May 14 13:36:07 2009 right. in export_lucid_sec_context, lctx is a void* that may be cast to a lucid_context_v1_t From: To: Time: Thu May 14 13:36:13 2009 Uh, my yes was to Tom, not to Sam. From: To: Time: Thu May 14 13:36:30 2009 do we have any documentation for the buffer_set stuff? From: To: Time: Thu May 14 13:37:07 2009 Tom, that's in the krb5 mechanism definition, not the mechglue stub. I agree with you there From: To: Time: Thu May 14 13:37:41 2009 I believe there is an expired globus draft From: To: Time: Thu May 14 13:38:04 2009 so what we actually want to do is to copy the pointer value around, i think, so the patch looks correct. From: To: Time: Thu May 14 13:40:13 2009 I agree with the first half of that sentence From: To: Time: Thu May 14 13:40:36 2009 What do you think is wrong with the patch? From: To: Time: Thu May 14 13:40:55 2009 I still think it's correct. From: To: Time: Thu May 14 13:41:22 2009 i thought it was wrong until i took a close look at what add_buffer_set_member was doing. From: To: Time: Thu May 14 13:44:28 2009 OK. I agree that patch is correct as far as it goes. Actually, yes, this makes sense. I think the context deletion is wrong still. From: To: Time: Thu May 14 13:45:31 2009 I need to quickly eat lunch and make a 2 PM call From: To: Time: Thu May 14 13:45:40 2009 I don't understand what a union context is, so I don't know what's wrong with the context deletion. From: To: Time: Thu May 14 13:45:49 2009 i agree that the context deletion in krb5_gss_glue.c looks wrong. From: To: Time: Thu May 14 13:46:07 2009 "union context" is the mechglue-layer context handle. it contains a context handle for the actual underlying mechanism. From: To: Time: Thu May 14 13:46:35 2009 I think 1.6 has the same problem if it is a problem. From: To: Time: Thu May 14 13:47:29 2009 from 1.6 krb5_gss_glue.c /* XXX need to delete mechglue ctx too */ OM_uint32 KRB5_CALLCONV gss_krb5_export_lucid_sec_context( From: To: Time: Thu May 14 13:48:42 2009 also, the 1.6 version of gss_krb5int_export_lucid_sec_context deleted the krb5 gss context. the "XXX" comment refers to the leakage of the mechglue "union" context. From: To: Time: Thu May 14 13:54:18 2009 also, this could be a nominee for silly commit log messages: "remove some old code for debugging the debugging code" From: To: Time: Thu May 14 14:33:00 2009 oh. mechglue's inquire_sec_context_by_oid passes the internal_ctx_id. unfortunately, there is no way for the mech to signal to the mechglue to delete the mechglue context. From: To: Time: Thu May 14 15:33:11 2009 the debian bug has a comment implying some SPNEGO breakage. From: To: Time: Thu May 14 15:46:04 2009 Would it be good enough to call gss_delete_sec_context from gss_export_lucid_sec_context in the krb5_gss_glue? I.E. call the mechglue delete context at that layer? From: To: Time: Thu May 14 15:46:14 2009 iirc the int32_t stuff in k5-platform.h is just inclusion of the correct system headers, or win-mac.h for windows, and all the systems i looked at had the definitions in the system headers. (stdint.h for c99 systems, inttypes.h for ... something else not c99 compliant.) but i could be remembering wrong. From: To: Time: Thu May 14 15:46:39 2009 the mechglue doesn't pass the mechglue context handle to the mech From: To: Time: Thu May 14 15:47:00 2009 oh wait let me rethink that. From: To: Time: Thu May 14 15:47:39 2009 krb5_gss_glue.c's gss_export_lucid_context is a mechglue level function airc From: To: Time: Thu May 14 15:48:14 2009 right. so it's probably correct to call the mechglue delete_sec_context from there because that copy gets the mechglue context. From: To: Time: Thu May 14 15:48:58 2009 Yeah, lucid_sec_context is an exported entry point From: To: Time: Thu May 14 15:49:27 2009 any news on what Russ was reporting about SPNEGO breakage? what is the mapping of "pre1" and "pre2" to our releases? From: To: Time: Thu May 14 15:49:47 2009 rather gss_krb5_export_lucid_sec_context which is the krb5_gss_glue.c function From: To: Time: Thu May 14 15:50:42 2009 i was wondering why that didn't fail catastrophically before but that might be because the krb5 mech functions do this strange pointer validation thing. From: To: Time: Thu May 14 15:52:42 2009 Looking. From: To: Time: Thu May 14 15:58:39 2009 He means beta2 vs beta1. From: To: Time: Thu May 14 15:58:54 2009 And probably doesn't have ok_as_delegate set on his tgt From: To: Time: Thu May 14 15:59:19 2009 ah. do we know if his version of windows supports setting ok-as-delegate on cross-realm tgts? From: To: Time: Thu May 14 16:00:48 2009 I suspect the user ticket is MIT. So the question is whether he's running a 1.7 KDC (almost certainly not) From: To: Time: Thu May 14 16:01:25 2009 but his app isn't going to be setting DELEG_POLICY_FLAG for gss, is it? From: To: Time: Thu May 14 16:03:28 2009 Except that I don't see that delta in 1.7 beta2 From: To: Time: Thu May 14 16:03:53 2009 No, but I think that firefox looks at the ticket flag explicitly From: To: Time: Thu May 14 16:04:21 2009 beta2 added the "strip ok-as-delegate if not in cross-realm tgt" change From: To: Time: Thu May 14 16:06:02 2009 so is the issue that his AD server was setting ok-as-delegate but were weren't stripping the flag until beta2? From: To: Time: Thu May 14 16:06:32 2009 Yes. Hmm, what revision was the pullup? From: To: Time: Thu May 14 16:06:46 2009 At least, that's my guess From: To: Time: Thu May 14 16:08:10 2009 pullup was r22327 From: To: Time: Thu May 14 16:12:58 2009 so are we going to need a config variable to avoid breaking people for whom this stuff works? From: To: Time: Thu May 14 16:14:56 2009 Possibly. You could have a realm specific variable indicating whether to trust delegations issued by that realm. (Well, use the libdefault_boolean function that permits both realm-specific and global setting) From: To: Time: Thu May 14 16:15:12 2009 I don't think that is a 1.7 blocker though From: To: Time: Thu May 14 16:15:58 2009 It seems weird that Firefox would be looking at the ok-as-delegate flag given that MIT KDCs had no support for setting it before 1.7. From: To: Time: Thu May 14 16:16:26 2009 if it's talking to an IIS in an AD domain, it might look at the flag in a useful way. From: To: Time: Thu May 14 16:18:09 2009 The Firefox source packages confuses me, so I'm not immediately sure how to find the relevant Firefox code. From: To: Time: Thu May 14 16:18:38 2009 protocol-wise, can firefox know what software the server is running before it does negotiate-auth? From: To: Time: Thu May 14 16:22:31 2009 It could, yes. From: To: Time: Thu May 14 16:23:43 2009 Well, Russ says that's not his problem From: To: Time: Thu May 14 16:23:51 2009 oh From: To: Time: Thu May 14 16:24:47 2009 Perhaps we broken spnego From: To: Time: Thu May 14 16:25:37 2009 if it's a beta1 to beta2 regression, that's not too many changes From: To: Time: Thu May 14 16:28:43 2009 So, apparently, works to mod-auth-kerb but *not* IIS. Not related to delegation. We know firefox is trying in both cases From: To: Time: Thu May 14 16:45:26 2009 is the end service ticket being obtained in all cases? From: To: Time: Thu May 14 17:00:12 2009 That is my understanding From: To: Time: Thu May 14 18:06:59 2009 is the affected mod-auth-kerb server in the same realm as the IIS? From: To: Time: Thu May 14 18:18:30 2009 Presumably not, but unsure From: To: Time: Thu May 14 18:24:39 2009 Did we (Luke and I) manage to break everything that it is possible to break in libgss? So, looks like the set_enctypes call doesn't to the right thing any more. For Greg's info, NFS in Linux only supports single-des. There is a gss krb5 call to set the allowed enctypes. My guess is that either mechglue changes broke the call or that enctype negotiation changes cause the key type to be different than expected because we have more complexity ssurrounding what keys are used for what in the context or that enctype negotiation is causing CFX to be used From: To: Time: Thu May 14 18:25:29 2009 Now, the etype negotiation stuff *should* honor the set of etypes you set using the gss call. From: To: Time: Thu May 14 18:53:19 2009 As best I can tell, the etype negotiation call should respect the call. IT may be a des-cbc-crc vs des-raw issue From: To: Time: Thu May 14 20:31:20 2009 some older mailing list traffic indicates that firefox does look at ok-as-delegate. it's the only plausible thing we changed between beta1 and beta2 that would affect russ. From: To: Time: Thu May 14 20:33:03 2009 now i'm sorry i looked at unseal_token_v3... From: To: Time: Fri May 15 13:56:07 2009 oh. the nfsv4 kernel stuff only supports des-cbc-raw, it looks like. From: To: Time: Fri May 15 13:56:26 2009 or at least that's what it looks like from some version i pulled from somewhere random on the net. From: To: Time: Fri May 15 14:03:18 2009 also in 2.6.29 http://lxr.linux.no/linux+v2.6.29/net/sunrpc/auth_gss/gss_krb5_mech.c From: To: Time: Fri May 15 14:08:15 2009 oops, sam's not here. From: To: Time: Fri May 15 14:14:57 2009 in krb5-1.6, DES and DES3 keys got their enctypes smashed to the _RAW versions in the context. not sure whether there is a failure to do that in 1.7. From: To: Time: Sun May 17 02:02:29 2009 This room is not anonymous. From: To: Time: Mon May 18 11:16:20 2009 ANother potentially very concerning bug from Debian, filed in RT as 6490 From: To: Time: Mon May 18 11:34:05 2009 I'm trying to see if I can replicate this using Stanford's infrastructure. It's weird that http://www.stanford.edu/services/kerberos/install/krb5.conf has domain_realm mappings pointing at IT.WIN.STANFORD.EDU but no definition of the realm. From: To: Time: Mon May 18 11:34:51 2009 is there DNS for the realm? From: To: Time: Mon May 18 11:35:10 2009 Signs point to no. From: To: Time: Mon May 18 11:35:33 2009 curious... From: To: Time: Mon May 18 11:36:00 2009 Looks to me like there is: _kerberos._udp.it.win.stanford.edu. 600 IN SRV 0 100 88 itdc1.it.win.stanford.edu. From: To: Time: Mon May 18 11:36:27 2009 Huh, I wonder why I'm getting this error, then. From: To: Time: Mon May 18 11:39:04 2009 Oh, different error. I guess we have no cross-realm key with Stanford? From: To: Time: Mon May 18 11:40:03 2009 looks like probably not, but i haven't poked at it very hard. From: To: Time: Mon May 18 11:40:05 2009 Correct. (I was wondering why it was going to work for you:-) From: To: Time: Mon May 18 11:40:33 2009 ask Russ to give you a test principal? :-) From: To: Time: Mon May 18 11:42:02 2009 I could do that, or try to reproduce it without AD, or ask Russ to try code changes (kind of painful). From: To: Time: Mon May 18 11:42:34 2009 Ask Russ to commit a correct patch:-) From: To: Time: Mon May 18 11:44:16 2009 Does anyone here know the password for a test principal like sipb0? in the athena realm? From: To: Time: Mon May 18 11:45:01 2009 I know systest's. From: To: Time: Mon May 18 11:45:48 2009 Ah, I was hoping for something someone could give me. I have an xvm machine which I'd like to play with against win.mit.edu to see if I can reproduce but am not entirely comfortable typing my athena password into that From: To: Time: Mon May 18 11:45:56 2009 Let me see if I can give you a kvno command From: To: Time: Mon May 18 11:47:10 2009 do we think the problem Russ is seeing is related to the NFS problem? From: To: Time: Mon May 18 11:47:15 2009 Not really, no. From: To: Time: Mon May 18 11:48:17 2009 Does kvno ldap/w92dc2.win.mit.edu@WIN.MIT.EDU work? From: To: Time: Mon May 18 11:49:17 2009 and how about kvno HTTP/w92dc2.win.mit.edu@WIN.MIT.EDU (upper case HTTP) From: To: Time: Mon May 18 11:51:07 2009 One moment, test environment failure... From: To: Time: Mon May 18 11:52:21 2009 Both work, but those aren't multi-hop. From: To: Time: Mon May 18 11:53:19 2009 in the klist output from Russ's successful kvno run, note WIN.STANFORD.EDU is des-cbc-crc while IT.WIN.STANFORD.EDU is rc4-hmac From: To: Time: Mon May 18 11:53:23 2009 Right. I was afraid of server principal canonicalization in the w2k style (not w2k3 style) causing problems From: To: Time: Mon May 18 11:53:37 2009 Which we haven't ruled out--we don't know stanford's configuration From: To: Time: Mon May 18 11:54:13 2009 Yes, I'd expect that. It meas the MIT trust is DES, but within the AD forest rc4 is used From: To: Time: Mon May 18 11:54:59 2009 enctype nego isn't implemented in earlier Windows? From: To: Time: Mon May 18 11:55:40 2009 Enctype nego doesn't affect the kdc From: To: Time: Mon May 18 11:56:14 2009 And I believe enctype nego was introduced in Vista From: To: Time: Mon May 18 12:23:12 2009 just how many different places in the gss context do we stash the session key now?? From: To: Time: Mon May 18 12:25:06 2009 I think two, down from three. From: To: Time: Mon May 18 12:25:55 2009 subkey, enc, seq, acceptor_subkey. that's at least four. From: To: Time: Mon May 18 12:26:40 2009 export_lucid only copies subkey for rfc1964, i think. From: To: Time: Mon May 18 12:27:30 2009 Well, one of enc and seq typically is not bit identical to the session key. From: To: Time: Mon May 18 12:27:57 2009 And I would not expect acceptor_subkey and enc to typically be used at the same time. From: To: Time: Mon May 18 12:28:20 2009 sure, but i think it's very likely that some parts of the library are not setting all of the keys that they should be setting. From: To: Time: Mon May 18 12:28:25 2009 You can derive anything from subkey and acceptor_subkey From: To: Time: Mon May 18 12:28:44 2009 I think that is very unlikely From: To: Time: Mon May 18 12:29:18 2009 Given that you and I audited that at Microsoft. enc and seq are 1964-specific. acceptor_subkey is mostly CFX specific From: To: Time: Mon May 18 12:31:19 2009 I'm concerned that Luke's patch seems to choose a key based on ctx info. That's semi-correct for 1964 but always wrong for CFX. And I have not verified how it is constrained From: To: Time: Mon May 18 12:32:08 2009 In retrospect, it would be a good idea to grab the e-mail that discusses how this all should work from the enctype nego discussion and put it in a comment somewhere From: To: Time: Mon May 18 12:32:33 2009 Or on the wiki or something. From: To: Time: Mon May 18 12:32:36 2009 it is also not very clear what kg_setup_keys is trying to do, and it's not really commented at all. From: To: Time: Mon May 18 12:33:55 2009 Yes. It does the part of setting up keys that can be abstracted out of init_sec_context and accept_set_context. What that actually is changed multiple times over a period of a couple of days From: To: Time: Mon May 18 12:36:55 2009 I think it does everything besides set acceptor_subkey, subkey and have_acceptor_subkey From: To: Time: Mon May 18 12:37:27 2009 so export_lucid maybe should copy ctx->enc instead of ctx->subkey? From: To: Time: Mon May 18 12:38:26 2009 I think the invarients are that cfx-> proto == 0 and ctx->established == 1 implies ctx->enc and ctx->seq established ctx->established == 1 implies ctx->subkey is set. ctx->have_acceptor_subkey implies ctx->acceptor_subkey and the acceptor subkey cksum type are set From: To: Time: Mon May 18 12:38:48 2009 No, that definitely seems wrong From: To: Time: Mon May 18 12:42:34 2009 In the 1.6 code base, the lucid context 1964 key will have an enctype of des-cbc-raw and will have the contents of the ctx subkey. (assuming des enctype) It will not be the contents of the enc key, which has been xored by something From: To: Time: Mon May 18 12:43:52 2009 but ctx->subkey is not adjusted by kg_setup_keys, so export_lucid will always produce the wrong enctype in its output for single-DES From: To: Time: Mon May 18 12:44:01 2009 In the current 1.7 code, you'll get something like des-cbc-crc not des-cbc-raw. From: To: Time: Mon May 18 12:46:08 2009 That should break NFS. I'm confused though why one of the people reported that this all worked against a lenny server... From: To: Time: Mon May 18 12:48:07 2009 does lenny have a kernel that does DES3? From: To: Time: Mon May 18 12:48:26 2009 lenny is debian-stable? From: To: Time: Mon May 18 12:48:57 2009 lenny has the same or an older kernel than sid, which failed From: To: Time: Mon May 18 12:50:31 2009 sid contains krb5-1.7? From: To: Time: Mon May 18 12:51:09 2009 yes From: To: Time: Mon May 18 12:51:38 2009 was the error message logged on the nfs client or the server? From: To: Time: Mon May 18 12:57:59 2009 I do not know From: To: Time: Mon May 18 13:08:43 2009 I wish RT wasn't such a pain in the butt about requiring logins to view tickets. From: To: Time: Mon May 18 13:09:51 2009 if you got kicked out recently, the postgres server may have crashed, requiring a restart of apache. (the DBI stuff doesn't recover cleanly for reasons i haven't fully investigated) From: To: Time: Mon May 18 13:10:51 2009 No, I'm fine. But I feel bad about handing out URLs pointing to RT tickets because I know if people follow them, they'll just hit the login wall. (And then if they hit "guest login" they have to enter the ticket number again, because something goes wrong.) From: To: Time: Mon May 18 13:11:27 2009 workaround is appending "?id=guest&login=guest", possibly From: To: Time: Mon May 18 13:11:57 2009 err, look at one of the autogenerated "fixed bugs list" pages to see what the actual variables are. From: To: Time: Mon May 18 13:13:52 2009 Ah, good to know. From: To: Time: Mon May 18 13:14:11 2009 actually it's almost certainly not "id=guest" because "id" is used for the ticket id. From: To: Time: Mon May 18 13:32:31 2009 wait, i thought we did pull in the ok-as-delegate KDC support From: To: Time: Mon May 18 13:36:31 2009 If you mean kadmin support, it's r22281, #5596, and I didn't tag it for pullup. From: To: Time: Mon May 18 13:37:02 2009 Ah, you pulled it up anyway. From: To: Time: Mon May 18 13:37:27 2009 i think i did pull it up anyway, motivated by some other discussions. From: To: Time: Mon May 18 13:46:10 2009 so, yeah, the nfs problem does appear to be des-cbc-raw vs crc. Where is the right place to fix? setup_keys? callers to setup_keys or my preference the lucid context code itself From: To: Time: Mon May 18 13:46:42 2009 that depends on what the intended use of the various keyblock fields in the context is. From: To: Time: Mon May 18 13:46:55 2009 this probably actually ties in with the iov_stream mess. From: To: Time: Mon May 18 13:55:33 2009 would it be wrong for export_lucid to copy gctx->seq in the rfc1964 case? From: To: Time: Mon May 18 13:56:03 2009 So, I set up a three-realm delegation path (using capaths) and I got a "KDC policy rejects request" error, which is interesting, although it may just indicate a misconfiguration on my part. From: To: Time: Mon May 18 14:00:29 2009 could be a mismatch between expected capaths From: To: Time: Mon May 18 14:00:32 2009 Yeah, it's just a misconfiguration. KDC will check capaths too unless you ask it not to From: To: Time: Mon May 18 14:01:13 2009 I think it would be wrong to copy seq, but only in some abstract sense, not in functionality From: To: Time: Mon May 18 14:01:42 2009 ok. or something could explicitly smash the enctypes somewhere. From: To: Time: Mon May 18 14:04:06 2009 You know, copying seq always produces the correct behavior and is a really simple change From: To: Time: Mon May 18 14:04:55 2009 true. it's just wrong in an abstract sense and should get documented in a comment to avoid further (!) confusion. From: To: Time: Mon May 18 14:10:51 2009 code archaeology -- seeing Sabre-C directives in GSS code From: To: Time: Mon May 18 14:11:12 2009 Okay, with capaths on both sides, kvno works across three realms, even if ok-as-delegate is set on the cross tgt between the second and third realms. So I can't reproduce that bug without AD. Fortunately, Russ should be able to get me a Stanford principal. From: To: Time: Mon May 18 14:11:54 2009 There's a reason I mentioned Saber C as an example of the negative consequences of marking up code. From: To: Time: Mon May 18 14:12:21 2009 another example would be the lclint markup in the com_err code. From: To: Time: Mon May 18 14:13:36 2009 (hm, ok, the company spells it the US way, possibly) From: To: Time: Mon May 18 14:15:14 2009 I propose the following documentation of the keys: +++ b/src/lib/gssapi/krb5/gssapiP_krb5.h @@ -188 +188,2 @@ typedef struct _krb5_gss_ctx_id_rec { - krb5_keyblock *subkey; + krb5_keyblock *subkey; /*One of two potential keys to use with RFC + * 4121 packets; this key must always be set.*/ @@ -192,2 +193,3 @@ typedef struct _krb5_gss_ctx_id_rec { - krb5_keyblock *enc; - krb5_keyblock *seq; + krb5_keyblock *enc; /*RFC 1964 encryption key;seq xored with a + * constant for DES, seq for + krb5_keyblock *seq; /*RFC 1964 sequencing key*/ @@ -205 +207 @@ typedef struct _krb5_gss_ctx_id_rec { - /* Protocol spec revision + /* Protocol spec revision for sending packets @@ -207,2 +209,4 @@ typedef struct _krb5_gss_ctx_id_rec { - 1 => draft-ietf-krb-wg-gssapi-cfx-01 - No others defined so far. */ + 1 => RFC 4121 + No others defined so far. It is always permitted to receive + tokens in RFC 4121 format. If enc is non-null, receiving RFC From: To: Time: Mon May 18 14:16:36 2009 some stuff looks truncated on the right From: To: Time: Mon May 18 14:19:02 2009 Yeah, artifact of how I pasted From: To: Time: Mon May 18 14:19:55 2009 git diff truncates to terminal width if you output to a terminal, right? From: To: Time: Mon May 18 14:22:24 2009 diff --git a/src/lib/gssapi/krb5/gssapiP_krb5.h b/src/lib/gssapi/krb5/gssapiP_k\ rb5.h index 3c4f7e0..a1073f3 100644 --- a/src/lib/gssapi/krb5/gssapiP_krb5.h +++ b/src/lib/gssapi/krb5/gssapiP_krb5.h @@ -188 +188,2 @@ typedef struct _krb5_gss_ctx_id_rec { - krb5_keyblock *subkey; + krb5_keyblock *subkey; /*One of two potential keys to use with RFC + * 4121 packets; this key must always be set.*/ @@ -192,2 +193,4 @@ typedef struct _krb5_gss_ctx_id_rec { - krb5_keyblock *enc; - krb5_keyblock *seq; + krb5_keyblock *enc; /*RFC 1964 encryption key;seq xored with a + * constant for DES, + * seq for other RFC 1964 enctypes */ + krb5_keyblock *seq; /*RFC 1964 sequencing key*/ @@ -205 +208 @@ typedef struct _krb5_gss_ctx_id_rec { - /* Protocol spec revision + /* Protocol spec revision for sending packets @@ -207,2 +210,4 @@ typedef struct _krb5_gss_ctx_id_rec { - 1 => draft-ietf-krb-wg-gssapi-cfx-01 - No others defined so far. */ + 1 => RFC 4121 + No others defined so far. It is always permitted to receive + tokens in RFC 4121 format. If enc is non-null, receiving RFC + 1964 tokens is permitted.*/ From: To: Time: Mon May 18 14:23:16 2009 ctx->proto doesn't affect what protocol is in use when receiving packets? From: To: Time: Mon May 18 14:23:46 2009 not any more From: To: Time: Mon May 18 14:25:37 2009 is the GSS enctype nego stuff all buried in the AP-REQ handling, or is additional stuff exposed to the GSS implementation? From: To: Time: Mon May 18 14:26:32 2009 The gss implementation does end up looking at the negotiated enctype From: To: Time: Mon May 18 14:27:02 2009 but all the dust has settled by that point? From: To: Time: Mon May 18 14:29:51 2009 IN particular, if we negotiate to a non-CFX enctype we do not want to return an acceptor subkey (unless using DCE) because doing so would make the receiver's life hard. They'd have to figure out which subkey to use in a non-CFX context. From: To: Time: Mon May 18 14:30:53 2009 So, in accept_sec_context.c just above line 932 we sometimes turn off using the negotiated enctype before sending the ap_rep From: To: Time: Mon May 18 14:32:34 2009 oh, you mean if we started using rfc1964, we have no way of knowing whether the client knows how to do CFX? From: To: Time: Mon May 18 14:33:09 2009 (and the function is 840 lines long. yuck.) From: To: Time: Mon May 18 14:35:46 2009 No, that's not really the same as what I said. I think it is sort of true. If we started with 1964 and did not end up with a CFX-only enctype, we don't know whether CFX is supported From: To: Time: Mon May 18 14:39:29 2009 but yeah, proposed header patch looks fine. From: To: Time: Mon May 18 14:41:38 2009 SHA-1 collisions allegedly down to 2^52 From: To: Time: Mon May 18 14:43:18 2009 Isn't that old news? From: To: Time: Mon May 18 14:43:37 2009 could be From: To: Time: Mon May 18 14:44:08 2009 I *think* we still don't care that much From: To: Time: Mon May 18 14:44:09 2009 Yeah. See -c sipb May 5 22:28 From: To: Time: Mon May 18 14:44:50 2009 it's collisions, so we shouldn't care *that* much, but we should start working on improved integrity algorithms anyway. From: To: Time: Mon May 18 14:45:49 2009 Hmm. I hear we have an implementation of aes-ccm From: To: Time: Mon May 18 14:46:07 2009 i thought you preferred GCM for parallelizability From: To: Time: Mon May 18 14:46:30 2009 I do. I am also lazy. From: To: Time: Mon May 18 14:46:57 2009 And the crypto community seems twitchy about the gcm problems you run into with counter reuse From: To: Time: Mon May 18 14:47:08 2009 That reminds me, why do we truncate the SHA1 hash to 96 bits for the AES enctypes? It seems weird to have the key require 2^128 or 2^256 effort to break but the integrity code require only 2^96 effort. From: To: Time: Mon May 18 14:47:15 2009 or we could do aes-cts-hmac-sha256 :-) From: To: Time: Mon May 18 14:48:00 2009 re GCM, i saw that the public comments on the NIST proposal did include concerns on the counter issue From: To: Time: Mon May 18 14:48:12 2009 (I mean, we do it because the protocol says to do it. But why did it get specified that way?) From: To: Time: Mon May 18 14:50:40 2009 the key requires 2^128 or 2^256 to brute-force, but the use of a CBC mode means that the block size will put some bounds on the amount of data you can safely encrypt using a single key as well. both key sizes of AES use a 128-bit block size. From: To: Time: Mon May 18 14:56:17 2009 Okay, I have a stanford.edu principal and can, as expected, reproduce the message stream modified error. From: To: Time: Mon May 18 14:57:15 2009 so the report from Russ implied that the error was coming from the KDC, since he was getting it even when asking for a nonexistent principal. From: To: Time: Mon May 18 14:58:32 2009 Yeah, seems likely. I'm going to try reverting the ok-as-delegate stripping change to see if it's related to that. From: To: Time: Mon May 18 15:02:46 2009 Seems unrelated to that. Walking the code path... From: To: Time: Mon May 18 15:06:40 2009 Confirm that you are getting a kdc error not generating the error locally From: To: Time: Mon May 18 15:07:31 2009 96-bit truncation: IPsec does it. What does it mean to break the integrity with a work factor of 2**96? From: To: Time: Mon May 18 15:09:10 2009 Well, say I want to compute a second preimage which matches a mic (but it's okay if it's garbage). I only need to try 2^96 times before I'm expected to find one, right? From: To: Time: Mon May 18 15:13:18 2009 So, if you do the three-realm kvno with krb5 1.7 and watch it fail, and then try again with krb5 1.6, it succeeds. So the second TGT isn't corrupted in the ccache or anything. (Still following the code path to verify the origin of the error.) From: To: Time: Mon May 18 15:13:28 2009 Yeah, I agree that if you would find a garbage result acceptable then 2**96 hashes is sufficient. And I guess that is a break From: To: Time: Mon May 18 15:14:19 2009 so 2^96 is only 2^32 times larger than the expected 2^64 ciphertext blocks you would need to find a ciphertext block collision. not clear what significance that has for the MIC though. From: To: Time: Mon May 18 15:14:20 2009 Ah, I'd use wireshark to verify the error rather than walking through the code:-) That or set a breakpoint on decode_krb5_error From: To: Time: Mon May 18 15:17:44 2009 Oh, cool, an unrelated bug. From: To: Time: Mon May 18 15:18:48 2009 send_tgs.c calls decode_krb5_error and then compares err_reply->error to KRB_ERR_RESPONSE_TOO_BIG. But err_reply->error is a protocol error code; it hasn't been translated to a com_err code yet. From: To: Time: Mon May 18 15:18:59 2009 Er, unless I'm confused. From: To: Time: Mon May 18 15:19:50 2009 aren't KRB_ERR_* the macros for the untranslated protocol error numbers? From: To: Time: Mon May 18 15:20:12 2009 Yes, and I was confused. But I still don't know where KRB_ERR_RESPONSE_TOO_BIG is getting defined. Anyway, I shouldn't get too sidetracked. The error is coming from the KDC. From: To: Time: Mon May 18 15:20:24 2009 ok From: To: Time: Mon May 18 15:20:56 2009 it's defined in k5-int.h for some reason. From: To: Time: Mon May 18 15:21:45 2009 Okay, unconfused about that. From: To: Time: Mon May 18 15:22:24 2009 Do you want guesses as to what is going on? From: To: Time: Mon May 18 15:24:02 2009 i just noticed that we can't return KRB_AP_ERR_MODIFIED from our KDC, but then again this is AD.... From: To: Time: Mon May 18 15:25:35 2009 Sure, guess away. From: To: Time: Mon May 18 15:25:38 2009 There are cases where FAST returns that from our KDC, but clearly not applicable to AD From: To: Time: Mon May 18 15:25:42 2009 oh. according to rfc4120 we are supposed to return that for AP-REQ checksum validation failure. From: To: Time: Mon May 18 15:26:43 2009 At this point, I could either try to compare what we're sending in 1.6 and 1.7, or do a binary search on the revision history. From: To: Time: Mon May 18 15:27:06 2009 is this a beta1->beta2 delta? From: To: Time: Mon May 18 15:27:11 2009 Well, a couple of things have changed on the TGS path. 1) We're now using a different checksum type for the ap-req checksum 2) we're now sending a subsession key From: To: Time: Mon May 18 15:27:30 2009 Actually, heck, let's try before and after the mskrb-integ branch, just for fun. From: To: Time: Mon May 18 15:28:03 2009 If you have that handy, go for it. No, we thought it was beta1 to beta2 but turns out not to be the case From: To: Time: Mon May 18 15:28:57 2009 So if you have ms-krb-integ then try that My guess is that just after ms-krb-integ merged to trunk will work. If that turns out false then I need to rethink probable causes From: To: Time: Mon May 18 15:31:01 2009 Trying just after the merge. From: To: Time: Mon May 18 15:33:30 2009 Works. Next guess is subkey. From: To: Time: Mon May 18 15:34:21 2009 checksum type change was with the FAST changes, not the mskrb-integ changes. From: To: Time: Mon May 18 15:35:09 2009 well actually contemporaneous with FAST but mostly unrelated. ticket #1624. From: To: Time: Mon May 18 15:35:11 2009 Yes; I haven't gotten to checksum type change. From: To: Time: Mon May 18 15:35:17 2009 ah From: To: Time: Mon May 18 15:39:13 2009 Great, r21993 (just after the first subkey commit) produces a different error message and r21992 blows out with glibc detecting a double free. That's not very conclusive. From: To: Time: Mon May 18 15:39:37 2009 fun From: To: Time: Mon May 18 15:42:57 2009 What's the different error message? From: To: Time: Mon May 18 15:44:37 2009 "Bad encryption type", I think; I foolishly lost it. From: To: Time: Mon May 18 15:47:08 2009 You may need 22148 as well From: To: Time: Mon May 18 15:52:39 2009 I've screwed up my test environment somehow; those last two results aren't meaningful. From: To: Time: Mon May 18 15:53:40 2009 are you on a Linux system? skewed library versions can hurt you if you don't disable rpaths From: To: Time: Mon May 18 16:02:06 2009 That's not it; I'm just playing too fast and loose with the build system. From: To: Time: Mon May 18 16:02:15 2009 ok From: To: Time: Mon May 18 16:11:21 2009 r22148 gave me a decrypt integrity check failure, so that version of AD may have the same bug as Heimdal. From: To: Time: Mon May 18 16:15:31 2009 Disabling the checksum change is probably relatively easy on trunk. Just add an arcfour arm to the switch in send_tgs.c From: To: Time: Mon May 18 16:16:58 2009 Wait. Are you getting a local ap_err_modified or are you getting an ap_err_modified from the KDC without the code to extract its error text? From: To: Time: Mon May 18 16:17:13 2009 (I think message stream modified is MS for decrypt integrity check failed) From: To: Time: Mon May 18 16:20:17 2009 Current trunk: KDC ap_err_modified. r22148: local decrypt integrity check failure. From: To: Time: Mon May 18 16:21:55 2009 the local decrypt integrity check failure is probably because we hadn't yet applied the workaround for heimdal kdcs From: To: Time: Mon May 18 16:22:25 2009 Right. Except this is some version of AD. From: To: Time: Mon May 18 16:22:52 2009 i think Sam said AD may have the same issue with subkeys From: To: Time: Mon May 18 16:23:31 2009 I'd be surprised if AD had the same issues with subkeys, but perhaps From: To: Time: Mon May 18 16:24:48 2009 note that rfc4120 explicitly says that AP_ERR_MODIFIED is to be used if the AP-REQ checksum is invalid. i think we don't actually return it in that situation. From: To: Time: Mon May 18 16:26:24 2009 If I disable the checksum change on trunk, I get a decrypt integrity check failure instead of a message modified error from the KDC. From: To: Time: Mon May 18 16:27:49 2009 With the heimdal change? From: To: Time: Mon May 18 16:27:51 2009 so it sounds like it's both From: To: Time: Mon May 18 16:28:08 2009 That's with the Heimdal change. From: To: Time: Mon May 18 16:28:41 2009 the KDC is sending the decrypt integrity error? From: To: Time: Mon May 18 16:28:47 2009 No. From: To: Time: Mon May 18 16:29:39 2009 (WAG) key usage? From: To: Time: Mon May 18 16:29:54 2009 I believe the progression is: r21992 (before subkeys) works. With subkeys, decryption of the response fails (even with the Heimdal workaround). With the checksum change, you get an error response from the KDC. From: To: Time: Mon May 18 16:30:01 2009 OK. This is kind of unfortunate. Let's see if we can reproduce against win.mit.edu now that we know what's going on From: To: Time: Mon May 18 16:33:35 2009 Key usage is plausible From: To: Time: Mon May 18 16:38:12 2009 root@hartmans-ubuntu:~# kvno http/w92dc2.win.mit.edu@WIN.MIT.EDU kvno: Message stream modified while getting credentials for http/w92dc2.win.mit. edu@WIN.MIT.EDU From: To: Time: Mon May 18 16:40:10 2009 Hmm. What's the RC4 RFC? I don't have afs handy From: To: Time: Mon May 18 16:41:10 2009 4757 From: To: Time: Mon May 18 16:51:21 2009 AFK for about two hours, will see how far Sam has gotten after. From: To: Time: Mon May 18 16:54:01 2009 OK, so, we follow the spec. From: To: Time: Mon May 18 16:55:05 2009 as far as key usage numbers? From: To: Time: Mon May 18 16:55:45 2009 Yes. From: To: Time: Mon May 18 17:00:30 2009 I'm getting an on-campus build environment From: To: Time: Mon May 18 17:14:34 2009 i wonder if AD is sending back something encrypted in a KDC-chosen subkey From: To: Time: Mon May 18 17:16:17 2009 You can't do that in 4120.. And remember that we interop with aes using subkeys. From: To: Time: Mon May 18 17:16:55 2009 we could work around by not sending a subkey when using an RC4 enctype? From: To: Time: Mon May 18 17:19:40 2009 That would kind of break FAST From: To: Time: Mon May 18 17:20:07 2009 Which we might have to do to get the release out. But let me figure out if I can fix From: To: Time: Mon May 18 17:28:17 2009 Hmm. Ubuntu karmic doesn't seem to support gdb so much From: To: Time: Mon May 18 17:28:33 2009 wacky From: To: Time: Mon May 18 17:31:20 2009 does "unstable" change names with release cycles? From: To: Time: Mon May 18 17:31:44 2009 I get the impression that ubuntu development releases can be far less stable than debian unstable.... For example, a few days ago, builds requiring libc were not working From: To: Time: Mon May 18 17:32:24 2009 for debian, sid is always unstable From: To: Time: Mon May 18 17:33:05 2009 i still haven't figured out how Debian releases relate to Ubuntu releases; i should at some point. From: To: Time: Mon May 18 17:35:20 2009 Let's try with gcc 4.3 instead of 4.4 From: To: Time: Mon May 18 17:35:38 2009 They do not From: To: Time: Mon May 18 17:42:32 2009 No, this debugging environment does not work at all. From: To: Time: Mon May 18 17:43:16 2009 hm. is there a particular reason you are using Ubuntu? From: To: Time: Mon May 18 17:49:11 2009 I had an ubuntu vm handy. From: To: Time: Mon May 18 18:27:23 2009 has our KDC always encrypted with client subkey when the client sends one? From: To: Time: Mon May 18 18:31:03 2009 I don't know. From: To: Time: Mon May 18 18:31:50 2009 +++ b/src/lib/crypto/arcfour/arcfour.c @@ -47,7 +47,7 @@ case 7: /* tgs-req authenticator case 8: return 8; case 9: /* tgs-rep encrypted with subkey */ - return 8; + return 9; Is enough to get it working if I disable the checksum From: To: Time: Mon May 18 18:32:13 2009 so rfc4757 lies? From: To: Time: Mon May 18 18:32:18 2009 So, an error in the RFC From: To: Time: Mon May 18 18:33:34 2009 so that's half of the problem... From: To: Time: Mon May 18 18:43:43 2009 *grump* Appears that using the subkey not the session key in the checksum makes the checksum work From: To: Time: Mon May 18 18:44:07 2009 is that according to spec? From: To: Time: Mon May 18 18:44:08 2009 I'll call larry From: To: Time: Mon May 18 18:45:07 2009 Very much no. From: To: Time: Mon May 18 18:49:13 2009 We're also going to have to test the authz data path because while we don't rely on it now, we will in the future. It would be bad to box ourselves into a situation where we interop with either our KDC or MS but not both surrounding RC4 From: To: Time: Mon May 18 18:49:56 2009 I'm very puzzled here. It appears that for AES and DES they expect a different key for the checksum than for RC4. At least that is what our given data suggests From: To: Time: Mon May 18 18:52:05 2009 That is pretty odd. From: To: Time: Mon May 18 18:52:17 2009 Wait, no, for DES we don't use a keyed checksum. From: To: Time: Mon May 18 18:52:45 2009 How sure are you about AES? I don't have a test case for that. From: To: Time: Mon May 18 18:53:00 2009 so the authenticator uses the session key, but the checksum uses the subkey? From: To: Time: Mon May 18 18:54:09 2009 Hmm. When did I pull that change into stuff I was testing with them? I am not absolutely sure. From: To: Time: Mon May 18 18:54:24 2009 Do you have a 2008 dc to test against? From: To: Time: Mon May 18 18:54:44 2009 I do not. From: To: Time: Mon May 18 18:55:38 2009 I suggest you get one. From: To: Time: Mon May 18 19:00:35 2009 i can probably set one up but it won't be quick From: To: Time: Mon May 18 19:01:49 2009 Yeah, but are you willing to release with serious questions about windows interop? From: To: Time: Mon May 18 19:02:57 2009 revised timeline is beta3 on or before Friday. tomorrow is going to be eaten up by meetings. i can try on Wednesday. From: To: Time: Mon May 18 19:04:43 2009 and my copy of win2008 is being annoying about activation From: To: Time: Mon May 18 19:15:39 2009 I can't find anything in RFC 4120 about which key should be used for the TGS authenticator checksum. From: To: Time: Mon May 18 19:16:29 2009 session key vs subkey is underspecified in a few places. From: To: Time: Mon May 18 19:23:42 2009 No, but 4757 makes it quite clear From: To: Time: Mon May 18 19:28:53 2009 Yeah, 4120 is lacking in this area, though it is clear about what the reply key should be. I suspect no one considered that the TGS might be any different from any other application in this respect, _and_ no one noticed that we don't say anything about the key used for authenticator checksums in _any_ AP_REQ From: To: Time: Mon May 18 19:30:08 2009 Note that my patch on 6490 means that 1.7 will not interop with a 1.6 KDC using rc4 From: To: Time: Mon May 18 20:32:12 2009 Looks like an erratum should be published for RFC 4757? "T=8" becomes "T=9" in item 9 on page 4? From: To: Time: Mon May 18 20:33:39 2009 seems likely From: To: Time: Mon May 18 20:40:00 2009 Do other people have thoughts on the interop issue with our kdc? From: To: Time: Mon May 18 20:40:12 2009 And 1.7 kdcs with 1.6 clients? From: To: Time: Mon May 18 20:42:08 2009 We're still talking about T=8 vs T=9? From: To: Time: Mon May 18 20:42:18 2009 1.6 clients won't use subkeys and thus aren't at issue, right? It's only 1.7 clients and 1.6 KDCs. From: To: Time: Mon May 18 20:42:56 2009 ==ghudson And 1.7 clients could simply try both values From: To: Time: Mon May 18 20:44:52 2009 ... which I think is reasonably safe From: To: Time: Mon May 18 20:50:03 2009 a bit tricky to code From: To: Time: Mon May 18 20:50:12 2009 But yes reasonable. From: To: Time: Mon May 18 20:50:19 2009 The checksum issue is messier From: To: Time: Mon May 18 20:50:58 2009 Yeah, to work around that we have to try the request twice. From: To: Time: Mon May 18 20:51:03 2009 Perhaps a bit tricky, but it should all be able to be hidden in the rc4 enctype, no? From: To: Time: Mon May 18 20:52:14 2009 I don't think it turns out to be all that tricky. From: To: Time: Mon May 18 20:52:25 2009 You're talking about the heimdal checksum issue? From: To: Time: Mon May 18 20:52:41 2009 (this is what I get for only vaguely paying attention) From: To: Time: Mon May 18 20:52:58 2009 No, two issues, neither related to Heimdal (at least, yet). From: To: Time: Mon May 18 20:53:16 2009 OK, then the checksum issue must be one I missed From: To: Time: Mon May 18 20:54:15 2009 At least for AD 2003 with RC4 keys, the supplied checksum for a tgs-req is checked using the subkey in the authenticator instead of the TGS session key. From: To: Time: Mon May 18 20:54:35 2009 Oh, right. I'd forgotten about that. From: To: Time: Mon May 18 20:54:46 2009 This has been mostly invisible so far since we used to only use unkeyed checksums by default. From: To: Time: Mon May 18 20:55:05 2009 That is messier. For one, I'm not as convinced it's OK. From: To: Time: Mon May 18 20:55:50 2009 One possible answer is to say that we mucked up the specs and you have to use unkeyed checksums, and if that weakens the protocol then we have to fix it with an extension. From: To: Time: Mon May 18 20:56:05 2009 (Since in practice using unkeyed checksums is accepted by all KDCs currently anyway.) From: To: Time: Mon May 18 20:57:25 2009 Oh, we definitely mucked up the specs, and for all AP_REP, not just TGS_REP. But now that I think about it, trying both should be OK, since in the past that's just been an unkeyed checksum anyway. From: To: Time: Mon May 18 20:58:23 2009 It seems a little weird to go out of your way to find a stronger checksum the KDC will accept when you know the KDC would accept something trashier anyway. From: To: Time: Mon May 18 21:00:05 2009 Oh, hm, you're right. If something generated with the wrong key, you could work around it by checking it twice, but as a generator the only way to be sure is to use an unkeyed checksum so it doesn't matter. From: To: Time: Mon May 18 21:01:33 2009 The problem with that is that the available unkeyed checksums won't be strong enough for much longer. From: To: Time: Mon May 18 21:01:36 2009 I wonder if MS and Heimdal clients have been using unkeyed checksums all along as well. From: To: Time: Mon May 18 21:02:14 2009 Actually, is the MIT KDC checking the checksum? Is Heimdal's? From: To: Time: Mon May 18 21:06:20 2009 We appear to be checking it, using the session key. So (at least for RC4, we're not 100% sure about AES) you can't interoperate with both MIT and MS in one try with a keyed checksum. From: To: Time: Mon May 18 21:06:58 2009 Heimdal definitely checks it, with the TGT session key, as far back as 0.6.3 From: To: Time: Mon May 18 21:08:06 2009 But it almost certainly generates requests using unkeyed checksums, since IIRC you couldn't interoperate with Microsoft using single-DES and a keyed checksum. From: To: Time: Mon May 18 21:10:43 2009 heimdal 0.6.3 generates AP_REQ checksums this way: - If enctype is DES-CBC-CRC, use RSA-MD4 - If enctype is RC4-HMAC-MD5, use RSA-MD5 - else use the default From: To: Time: Mon May 18 21:11:18 2009 Where's that code in Heimdal? From: To: Time: Mon May 18 21:13:01 2009 The ap_req code is in lib/krb5/mk_req_ext.c From: To: Time: Mon May 18 21:13:26 2009 We can similarly special case RC4. The important question is whether this affects AES, which may take us a bit to find out. From: To: Time: Mon May 18 21:14:55 2009 ... and the TGS-REQ-making code is in lib/krb5/get_cred.c, mostly in init_tgs_req() From: To: Time: Mon May 18 21:15:06 2009 (it uses krb5_mk_req_internal) From: To: Time: Mon May 18 21:19:43 2009 Heh. Heimdal also translates key usage 9 to 8 for RC4. See lib/krb5/crypto.c:usage2arcfour() (that code may have been restructured by now; it used to be that all supported enctypes were implemented in one giant file (not the primitives, of course)) From: To: Time: Mon May 18 22:30:43 2009 However Heimdal does not generate ap-req subkeys for TGS. From: To: Time: Mon May 18 22:31:21 2009 And I think unkeyed checksums are very problematic because there is or can be significant attacker controlled plaintext in the kdc-req From: To: Time: Mon May 18 22:32:08 2009 we've already got that problem in spades for all the single-DES enctypes From: To: Time: Mon May 18 22:33:36 2009 It's *single des* We marked it weak for a reason From: To: Time: Mon May 18 22:34:26 2009 yeah, but the checksum weakness makes it weaker than it would otherwise be even taking into account the fact that it's single-DES From: To: Time: Mon May 18 22:47:10 2009 BTW, I'm going to try to continue contributing to these issues, but I don't have sufficient time to commit to being responsible. I will try to get an answer out of Larry and will send e-mail tomorrow but people should not assume I own making sure 6490 gets resolved From: To: Time: Tue May 19 16:48:44 2009 win2008 server appears to work with trunk with ciphers constrained to rc4. From: To: Time: Tue May 19 16:49:18 2009 going to install 2003r2 to test checksum breakage From: To: Time: Tue May 19 16:55:20 2009 we do have confirmation of fixing the gssd problem? From: To: Time: Tue May 19 17:32:58 2009 I took Sam's getting NFS to work as confirmation of gssd being fixed. From: To: Time: Tue May 19 17:35:57 2009 confirmed Server 2003 R2 has the keyed checksum failure From: To: Time: Tue May 19 18:10:32 2009 also do we want to enable the unkeyed-when-rc4 workaround for the export-castrated rc4? From: To: Time: Tue May 19 18:15:10 2009 Likely. From: To: Time: Wed May 20 07:06:39 2009 Presumably we want the same unkeyed checksum for rc4-exp. Larry called me at midnight. I was already very asleep; he's calling back today From: To: Time: Wed May 20 10:26:09 2009 Restarting httpd on krbdev since RT isn't letting me in. From: To: Time: Wed May 20 10:26:37 2009 Okay, better now. From: To: Time: Wed May 20 10:42:32 2009 Okay, so, what is this third potential subkey issue Sam wanted to look into? From: To: Time: Wed May 20 10:44:16 2009 Is it AD-KDCIssued? From: To: Time: Wed May 20 10:50:30 2009 No, authz data included in the TGS request From: To: Time: Wed May 20 10:50:37 2009 Want a patch to generate some? From: To: Time: Wed May 20 11:00:58 2009 Sure. From: To: Time: Wed May 20 11:06:49 2009 Sent in email to you From: To: Time: Wed May 20 11:09:29 2009 The commenting out of fast_tgs_armor is to test whether the KDC fails? From: To: Time: Wed May 20 11:13:14 2009 Um, let me make sure I sent you the right thing From: To: Time: Wed May 20 11:14:51 2009 Yes. However I'm not sure that patch will apply cleanly to the trunk; I don't think fast_tgs_armor exists there and I'm not sure how much reorganization it depends on From: To: Time: Wed May 20 11:15:41 2009 Anyway, this is just a piece of authdata included in the TGS authenticator. It's encrypted as part of the authenticator; where does the potential issue arise? From: To: Time: Wed May 20 11:16:05 2009 But if you can make that patch apply, it should be a useful test case against ws2003 and ws2008 and would be a really bad idea to commit to the trunk because it should cause us to fail against any FAST kdc From: To: Time: Wed May 20 11:16:46 2009 It's not encrypted as part of the authenticator From: To: Time: Wed May 20 11:17:12 2009 O, hmm. From: To: Time: Wed May 20 11:17:17 2009 Right, forgot about that. From: To: Time: Wed May 20 11:17:49 2009 You already have a better test case look at t_ad_fx_armor.c in lib/krb5/krb From: To: Time: Wed May 20 11:18:26 2009 Our code confuses what is encrypted in the authenticator and what is in the kdc-req. Basically we tend to send authorization data twice From: To: Time: Wed May 20 11:20:34 2009 So what is the concern? From: To: Time: Wed May 20 11:23:15 2009 See the definition of the kdc-req-body sequence from RFC 4120 enc-authorization-data [10] EncryptedData OPTIONAL -- AuthorizationData --, From: To: Time: Wed May 20 11:23:31 2009 That sequence contains authorization data to be included in the issued ticket From: To: Time: Wed May 20 11:25:48 2009 Rather that encrypted data. According to the spec, it needs to be encrypted with the subkey. From: To: Time: Wed May 20 11:25:53 2009 Okay, I see it, although I'm confused why it's there in addition to the authenticator authorization-data. From: To: Time: Wed May 20 11:27:47 2009 The authenticator authorization data applies to the current request. The KDC should look at it. The enc-authorization-data should be included in the ticket. For example, you might have a restriction you want added to a ticket that an app server would honor but that if present would be sufficient to prevent the ticket from being issued. So, you want it copied into the ticket but not considered now From: To: Time: Wed May 20 11:29:44 2009 Okay. So, the concern is that some implementations might not use the subkey to decrypt enc-authorization-data on receipt of a tgs-req? From: To: Time: Wed May 20 11:30:04 2009 Also, a restriction expressed in the authenticator applies to the request but not the issued ticket From: To: Time: Wed May 20 11:30:26 2009 Yes, that's the concern From: To: Time: Wed May 20 11:30:50 2009 Have phone call From: To: Time: Wed May 20 11:46:21 2009 Back From: To: Time: Wed May 20 11:46:43 2009 The patch you sent me appears to put something into the authenticator authdata, not into enc-authorization-data. From: To: Time: Wed May 20 11:47:39 2009 Yes. I think t_ad_fx_armor is a much more correct test From: To: Time: Wed May 20 11:48:50 2009 By code inspection, Heimdal's KDC appears to do the right thing. (Uses the subkey to decrypt enc-authorization-data if present, makes key usage dependent on whether it's using a subkey.) From: To: Time: Wed May 20 11:49:09 2009 You use it by building (there is a make rule but it is not in make all) and then running t_ad_fx_armor principal It will obtain a ticket for principal with ad-fx-armor in the ticket. so t_ad_fx_armor krbtgt/AD2008@ad2008 and krbtgt/ad2003@ad2003 would be interesting tests. If you succeed in getting the ticket and using the ticket all is well From: To: Time: Wed May 20 11:49:41 2009 I actually think getting the ticket is enough of a test. I've already run krbtgt/HEIMDAL@HEIMDAL where CS.CMU.EDU is a good approximation of HEIMDAL From: To: Time: Wed May 20 11:53:03 2009 I need an actual principal in an AD domain to do this, I think (the cross-realm access I have to Stanford's AD2003 isn't useful, nor is WIN.MIT.EDU unless I have a principal there that I don't know about). Presumably I can get one from Tom for AD2008. From: To: Time: Wed May 20 11:53:30 2009 Why would you need a principal? From: To: Time: Wed May 20 11:53:54 2009 You do have a principal in win.mit.edu; there is a web page that lets you set its password. From: To: Time: Wed May 20 11:54:05 2009 But this should work fine cross-realm From: To: Time: Wed May 20 11:56:18 2009 So, say I use ghudson@stanford.edu, and do cross-realm into WIN.STANFORD.EDU. My intuition is that the AD element will be in enc-authorization-data for the initial request to the stanford.edu KDC (MIT code), which will stuff the AD element into the ticket, and the request to the AD KDC won't have any enc-authorization-data in it. From: To: Time: Wed May 20 11:56:38 2009 Oops, I was bad and used AD as an abbreviation for two different things there. From: To: Time: Wed May 20 11:58:44 2009 Hmm. Hmm. I don't think that's what the code does. However it's probably easier to reset ghudson@WIN.MIT.EDU than to be absolutely certain of that From: To: Time: Wed May 20 11:59:14 2009 I mean, I can step through the code and find out. From: To: Time: Wed May 20 12:01:07 2009 Or you can search for win.mit.edu change password From: To: Time: Wed May 20 12:01:41 2009 Oh, finding the page was no problem; I have ghudson@WIN.MIT.EDU tickets now. From: To: Time: Wed May 20 12:05:07 2009 You suggested using krbtgt/REALM@REALM; wouldn't that just retrieve the TGT from the cache? From: To: Time: Wed May 20 12:08:44 2009 At least against my realm, no. I believe that the cached credentials don't match because of authdata From: To: Time: Wed May 20 12:09:14 2009 But you could use some other principal like host/w92dc1.win.mit.edu@WIN.MIT.EDU From: To: Time: Wed May 20 12:17:42 2009 Yes, because of authdata. So, it succeeds against WIN.MIT.EDU, but the resulting ticket doesn't seem to have any authdata in it. Is that expected? From: To: Time: Wed May 20 12:21:32 2009 How can you tell if the ticket has authdata? From: To: Time: Wed May 20 12:22:49 2009 It would not entirely surprise me if W2K3 did not honor enc-authzdata but that was not my experience testing against w2k8 From: To: Time: Wed May 20 12:24:43 2009 Because if I run it again, authdata_match (in cc_retr.c) gets called with data == NULL and fails again, so I get a new credential each time. From: To: Time: Wed May 20 12:26:15 2009 Uh, this is sort of interesting. It's failing against ATHENA.MIT.EDU with "Decrypt integrity check failed". From: To: Time: Wed May 20 12:28:44 2009 Not writing out the authdata to the cache sounds like a local side library bug and probably is not important. It's encrypted so the client really cannot see it. From: To: Time: Wed May 20 12:31:53 2009 See 6438 for the Athena issue. From: To: Time: Wed May 20 12:32:28 2009 Which is to say we got this wrong. From: To: Time: Wed May 20 12:35:12 2009 Hmm. That's actually going to be really annoying isn't it. I'll admit that when I committed 6438 I was not thinking through all the implications; I believe that 6438 contains a correct fix to the KDC side, but it raises questions about how to handle fast negotiation From: To: Time: Wed May 20 12:36:07 2009 I guess what we'll have to do in cases where we're using fast tgs is include the AD, if we get decrypt integrity check, resend encrypting with the subkey but still including the AD From: To: Time: Wed May 20 12:36:48 2009 We'll be trying fast TGS even if we didn't do fast AS? From: To: Time: Wed May 20 12:37:17 2009 Or depend on the enc-padata stuff to give us hints. From: To: Time: Wed May 20 12:37:44 2009 1) we don't have a way to store that state currently 2) cross realm From: To: Time: Wed May 20 12:39:45 2009 You mean if we get decrypt integrity check failed, resent encrypting with the session key? From: To: Time: Wed May 20 12:40:27 2009 Yes. Although I'd need to think more about the use cases for fast TGS to determine how important I think it is. From: To: Time: Wed May 20 12:41:16 2009 After your #6438 fix, the server appears to try the decrypt the wrong way (unless there's no subkey present, in which case it's the right way), then the right way if that fails? From: To: Time: Wed May 20 12:42:20 2009 Also, can client_key be NULL there, and will we crash out if so? From: To: Time: Wed May 20 12:42:21 2009 Don't remember. Are you suggesting that optimizing for correct implementation would be an improvement? If so, that seems reasonable From: To: Time: Wed May 20 12:43:38 2009 It seems to me that we could try exactly once, since we aren't aware of any subkey-using clients which do it wrong. From: To: Time: Wed May 20 12:43:56 2009 This is more about understandability and correctness than performance. From: To: Time: Wed May 20 12:47:05 2009 Answer: no, client_key cannot be NULL there, because the caller passes the TGS session key if a subkey wasn't present in the request. However, as a consequence, it's hard for the code to know whether client_key is a subkey or a TGS session key. From: To: Time: Wed May 20 12:49:37 2009 Agreed From: To: Time: Wed May 20 12:51:40 2009 I'll admit that I like trying twice because it does work around that implementation flaw, and doing it right might break potential situations where the old code worked. I don't have enough confidence in what all Kerberos implementations do that I know there aren't ones we haven't tested against. From: To: Time: Wed May 20 12:55:04 2009 (after untangling multiple negatives...) Between cybersafe and the docsis folks, I'm pretty sure there are implementations we're not testing against regularly. Did cybersafe even show up for the interop session? From: To: Time: Wed May 20 12:57:49 2009 Out to lunch. I understand the conservatism argument, although "nobody uses TGS subkeys except for a few implementations we know about" seems like a fairly safe assumption to me. From: To: Time: Wed May 20 12:58:34 2009 I don't object to changing it. From: To: Time: Wed May 20 12:59:55 2009 As long as it's well documented somewhere From: To: Time: Wed May 20 13:38:04 2009 I'll add a comment. From: To: Time: Wed May 20 13:47:34 2009 Tom, if you can get me a principal in your AD 2008 test realm, I can finish testing this. From: To: Time: Wed May 20 13:53:19 2009 AD 2008: t_ad_fx_armor works but the returned ticket again doesn't seem to contain any authorization data. Checking against an MIT trunk KDC... From: To: Time: Wed May 20 13:54:02 2009 Greg, that's going to be a local library bug From: To: Time: Wed May 20 13:57:36 2009 I'm interested in review of the technical correctness of the following: In performing interoperability testing, there was significant ambiguity surrounding pseudo-random operations. These test vectors assume that the AES pseudo-random operation is aes-ecb(trunk128(sha-1(input))) where trunc128 truncates its input to 128-bits. The 3DES pseudo-random operation is assumed to be des3-cbc(trunc128(sha-1(input))). The DES pseudo-random operation is assumed to be des-cbc(trunc128(md5(input)). As specified in RFC 4757, the RC4 pseudo-random operation is hmac-sha1(input). From: To: Time: Wed May 20 13:59:45 2009 Versus trunk KDC: test program succeeds; resulting tickets do not appear to have authorization data according to authdata_match, but are clearly different somehow, because trying to use them fails with "KDC policy rejects request". Checking why... From: To: Time: Wed May 20 14:01:00 2009 Remember that the client has no way to know what authdata are in a ticket as that is encrypted. My guess is that library never records authdata in the cache From: To: Time: Wed May 20 14:01:58 2009 it could compare the ciphertext lengths ;-) From: To: Time: Wed May 20 14:03:07 2009 The client doesn't even get told what the authdata are, right? From: To: Time: Wed May 20 14:04:19 2009 Right. From: To: Time: Wed May 20 14:04:31 2009 the EncKDCRepPart does not contain a copy of the ticket authorization data From: To: Time: Wed May 20 14:05:58 2009 So the client could store the authdata it asked for, but it can't store the authdata it actually got, since it doesn't know what that is. From: To: Time: Wed May 20 14:06:30 2009 Anyway, it sounds like the "KDC policy rejects request" failure trying to use the resulting tickets against a trunk KDC is expected, given the specific AD requested by the test case. From: To: Time: Wed May 20 14:06:32 2009 unless we make a protocol extension to make that possible From: To: Time: Wed May 20 14:07:09 2009 So, results: AD 2003 works, AD 2008 works, Heimdal works (Sam's test and my code inspection), MIT krb5 1.7 works, MIT krb5 pre-1.7 fails. Sound consistent? From: To: Time: Wed May 20 14:09:45 2009 sounds consistent. if you want to obtain an authorization data element that doesn't produce the policy rejection, i think wrapping in the "if-relevant" container should do it. (but then you don't necessarily have a way to distinguish whether it made it into the ticket) From: To: Time: Wed May 20 14:11:03 2009 No, the policy rejection happens because the test case requests FX_ARMOR authdata, which makes the ticket only valid for use as an armor ticket. From: To: Time: Wed May 20 14:11:10 2009 ah From: To: Time: Wed May 20 14:11:15 2009 So, entirely expected. From: To: Time: Wed May 20 14:17:42 2009 This all sounds consistent. From: To: Time: Wed May 20 14:23:40 2009 So, as previously discussed, the test case you mailed to me doesn't use enc-authorization-data. Does that mean TGS FAST won't actually need to exercise that field? From: To: Time: Wed May 20 14:26:51 2009 Expanding on earlier: I think it would be handy if we had documentation of all the protocol "errors" (incorrect implementations) that we try to interoperate with, in one place. Preferably with details so we can (theoretically) decide at some point in the future when we can dispose of one interoperability hack or another. From: To: Time: Wed May 20 14:30:00 2009 This is sort of an argument for YAGNI as applied to protocols. From: To: Time: Wed May 20 14:30:29 2009 it is applied (in theory) in the IETF as part of the standards track advancement of a specification From: To: Time: Wed May 20 14:32:19 2009 Well, for instance, the FAST draft specifies authentication sets and multi-hop mechanisms. There is no current use case for those features as far as I know. Is anyone going to bring that up against advancing it to standard? From: To: Time: Wed May 20 14:33:35 2009 the elimination of unused protocol features is usually a part of the Proposed Standard -> Draft Standard progression. FAST is being submitted for Proposed Standard (or at least that is the intent) From: To: Time: Wed May 20 14:37:42 2009 It seems quite unlikely fast could advance without either removing or implementing authentication sets From: To: Time: Wed May 20 14:38:13 2009 Greg, good point. So, yes, fast TGS will not be a problem after all From: To: Time: Wed May 20 14:48:36 2009 Okay, mail send to the krb-wg list. I think the book is closed on subkey interop issues. Peering at Sam's request about PRNG stuff now. From: To: Time: Wed May 20 14:49:30 2009 aes and des3 parts of the PRF text look right. i haven't looked into the rc4 stuff recently. From: To: Time: Wed May 20 14:51:08 2009 There's a typo where you wrote trunk128 instead of trunc128. For DES, MD5 produces 128 bits, so the trunc128 is a no-op. From: To: Time: Wed May 20 14:51:56 2009 Other than that, it appears correct. I'll double-check the RC4 part. From: To: Time: Wed May 20 14:52:35 2009 if we want to be really pedantic, specifying all-zeroes ivec for the cbc encryptions is probably a good thing. From: To: Time: Wed May 20 14:54:55 2009 The RC4 part appears to agree with RFC 4757. From: To: Time: Wed May 20 15:10:22 2009 OK, fixed typo. Going to submit draft 11 of fast From: To: Time: Wed May 20 15:10:57 2009 are you clarifying the random-to-key as well? From: To: Time: Wed May 20 15:14:46 2009 O, hmm. Apparently not From: To: Time: Wed May 20 17:30:08 2009 having an automated test case for the lucid_context problem would be a good thing. not sure we have time to make one before 1.7 releases. From: To: Time: Thu May 21 06:54:14 2009 Much not goodness on the FAST front. Well, it would have been easy to fix if I had noticed Love's mail on April 29 when he sent it. However I suspect a lot of scramble today From: To: Time: Thu May 21 07:40:19 2009 Write up sent. From: To: Time: Thu May 21 08:54:14 2009 I don't understand Love's argument for making the outer body optional, unless it's completely unrelated to the rest. I do think I understand your arguments related to using the inner checksum instead of the outer, even in my somewhat sleep-deprived state. Nothing wrong pops out at me, but I don't know how meaningful that is. I can't promise I can give a more complete response today. From: To: Time: Thu May 21 09:11:53 2009 I was not able to relate the two parts of the message. That's why I split my response From: To: Time: Thu May 21 10:08:31 2009 OK, I've done the generate a CA and generate pkinit certificates dance. I'm so glad I had my config file around from the last time. It's rather non-obvious. Next up: configure pkinit From: To: Time: Thu May 21 10:22:56 2009 Hmm. If I were pkinit I'd require kdc configuration wouldn't I? From: To: Time: Thu May 21 10:28:30 2009 O, hey, and I'd be documented in the obvious place with credible examples. From: To: Time: Thu May 21 12:02:07 2009 I don't believe so. From: To: Time: Thu May 21 12:04:22 2009 Well, hmm. Something definitely seems wrong here. From: To: Time: Thu May 21 12:04:51 2009 I think I'm sending a pkinit as-req and neither the return nor verify server entry point in the kdc is called From: To: Time: Thu May 21 12:11:13 2009 great. do we need to update our docs to mention the "use trailing dot on hostnames in config files"? From: To: Time: Thu May 21 12:12:41 2009 It does reduce DNS lookups. It normally doesn't matter From: To: Time: Thu May 21 12:21:34 2009 I'm beginning to believe we have a serious problem in KDC pkinit support From: To: Time: Thu May 21 12:22:01 2009 as in worse than pre-FAST? From: To: Time: Thu May 21 12:22:07 2009 As far as I can tell, I'm definitely sending a pkinit request and hitting none of the pkinit breakpoints. From: To: Time: Thu May 21 12:22:45 2009 As is doesn't seem to work. From: To: Time: Thu May 21 12:23:17 2009 oh From: To: Time: Thu May 21 12:23:19 2009 I'm not using FAST currently. I have not tried a pre-fast build. From: To: Time: Thu May 21 12:27:12 2009 Downgrading to 1.6 From: To: Time: Thu May 21 12:29:04 2009 I see the same behavior with 1.6. So, it's probably something I'm doing wrong. From: To: Time: Thu May 21 12:50:06 2009 1.7 seems to segfault. That is perhaps not promising. From: To: Time: Thu May 21 12:50:36 2009 Rather assertion fail From: To: Time: Thu May 21 12:51:42 2009 krb5kdc: ../../src/kdc/kdc_authdata.c:577: handle_authdata: Assertion `enc_tkt_reply->authorizatio n_data == ((void *)0)' failed. From: To: Time: Thu May 21 12:54:41 2009 I have fairly high confidence in that. I've tried to rule out debian changes and mixed libraries etc. From: To: Time: Thu May 21 13:25:27 2009 I was planning on working on speculative patches in case people believe that changing the fast checksum is a good idea. However that sort of depends on being able to test pkinit to make sure the patches work. So, I'm going to work on non-krb5 stuff until pkinit is fixed. From: To: Time: Thu May 21 13:55:24 2009 I've grabbed #6491 since pkinit is on my plate anyway, but given the sparseness of our pkinit documentation, and the complexity of the change which likely broke it (mskrb-integ merge), I'm not optimistic about being able to fix it quickly. From: To: Time: Thu May 21 13:59:52 2009 I actually found the pkinit documentation fairly good as far as it goes. It does not exactly tell you how to generate pkinit certs though From: To: Time: Thu May 21 14:00:44 2009 You're talking about the stuff in admin.texinfo? From: To: Time: Thu May 21 14:07:03 2009 Yes. From: To: Time: Thu May 21 14:07:15 2009 I can probably help with the cert generation From: To: Time: Thu May 21 14:14:01 2009 I have notes on how to create a CA with OpenSSL; I assume I want to start with that. From: To: Time: Thu May 21 14:16:24 2009 Yes. Once you have that working, you then need to create KDC and user certs. I'll send you openssl extensions to do that. From: To: Time: Thu May 21 14:19:58 2009 I'm told that there may be an easier way to do this now; my extensions file is quite old. However it works. From: To: Time: Thu May 21 14:45:17 2009 so it's not clear how that assertion is failing unless something is reaching through an alias and touching something in a bad way. From: To: Time: Thu May 21 14:49:36 2009 The pkinit spec does involve producing authorization data, but our client doesn't do that. From: To: Time: Thu May 21 14:51:10 2009 how does client behavior affect that assertion? From: To: Time: Thu May 21 14:53:54 2009 s/client/implementation From: To: Time: Thu May 21 14:54:28 2009 Sorry. So, basically I don't understand how our pkinit should be messing with authorization data From: To: Time: Thu May 21 14:55:50 2009 could it be some other preauth mechanism? From: To: Time: Thu May 21 14:58:08 2009 Greg is saying that no one should be able to touch authdata yet. I haven't examined the code, but am not surprised From: To: Time: Thu May 21 15:01:06 2009 I said what? From: To: Time: Thu May 21 15:04:20 2009 I thought you said that no one should be manipulating the authorization data in the encrypted part of the ticket before that assertion From: To: Time: Thu May 21 15:06:47 2009 return_padata gets called prior to handle_authdata. the verify_* functions can supply an authzdata From: To: Time: Thu May 21 15:07:22 2009 ...supply an authzdata through the enc_part2 in the reply, it looks like From: To: Time: Thu May 21 15:07:51 2009 I believe Tom said that. From: To: Time: Thu May 21 15:08:49 2009 so it appears that i was wrong. which leads to the question of why the assertion is there, and how did we manage not to trip it before? From: To: Time: Thu May 21 15:10:54 2009 It's probably there because something doesn't merge things correctly. Would be my guess. But who is returning an authzdata? From: To: Time: Thu May 21 15:11:44 2009 pkinit_server_verify_padata, it looks like. From: To: Time: Thu May 21 15:11:57 2009 O, I'm wrong. Our pkinit kdc side does actually support returning authorization data From: To: Time: Thu May 21 15:12:52 2009 Ugh. So, now I need to swap in handle_authdata into my brain. I seem to recall that was kind of tricky and complicated From: To: Time: Thu May 21 15:17:50 2009 Hmm. That assertion may be spurious. Looking at merge_authdata From: To: Time: Thu May 21 15:19:18 2009 I believe that assertion can simply be removed. From: To: Time: Thu May 21 15:23:02 2009 KDC request handling should get refactored. From: To: Time: Thu May 21 15:26:51 2009 That would probably not be on my top 20 hit list, but I agree it should happen. From: To: Time: Thu May 21 15:27:10 2009 Luke added the assertion in r21566 while playing with the authorization data handling interfaces. Doesn't appear to be the result of code movement or a merge; I think he just thought authorization data should be empty at that point and added the assertion. From: To: Time: Thu May 21 15:28:25 2009 So I agree that we can probably just take it out. From: To: Time: Thu May 21 15:30:48 2009 pkinit now works but not with fast. May 21 15:28:39 luminous krb5kdc[11121]: ASN.1 encoding ended unexpectedly - while dispatching (ud p) From: To: Time: Thu May 21 15:34:27 2009 Changing to TCP and setting udp_preference_limit to 1 fixes that error. I'm confused about what's going on in that case. I'm guessing it was a largish request (pkinit+fast) but how does it get truncated? From: To: Time: Thu May 21 15:40:18 2009 Actually, I'm not sure that changing to tcp fixes the error. From: To: Time: Thu May 21 15:58:34 2009 Is someone keeping an eye on the mailing list moderation queues? kerberos, krbdev, and krb5-bugs-incoming were up over 130 messages each, and some old enough that the server is automatically expiring them (over a dozen in each of those queues). I just went through and cleaned out various lists, but saw nothing worth forwarding. From: To: Time: Thu May 21 15:59:20 2009 i've been tracking the incoming messages individually because it's easier to scan through the list, ID the ones that need approval, and ignore the rest. From: To: Time: Thu May 21 15:59:27 2009 So, no, actually using TCP doesn't help that error. I'm very confused From: To: Time: Thu May 21 15:59:37 2009 So I shouldn't worry about the accumulation in the moderation queue, and just let them expire? From: To: Time: Thu May 21 15:59:59 2009 yeah, unless you're feeling inspired to double-check :-) From: To: Time: Thu May 21 16:00:22 2009 so what was the behavior change with TCP? From: To: Time: Thu May 21 16:01:02 2009 Not especially. Okay, I'll stop checking all but kdc-info and kdc-schema, which are configured differently, with just Donna Skibbie and me as admins at the moment, though maybe that should be changed... From: To: Time: Thu May 21 16:01:40 2009 None. I managed to screw up the config file and that caused a behavior change but once fixed we're back to that error (including the claim that it is UDP) From: To: Time: Thu May 21 16:02:11 2009 i wasn't aware of kdc-info and kdc-schema From: To: Time: Thu May 21 16:04:28 2009 Those were for the separate work on the info model and schema, outside the WG, after our post-WG-session chat with Donna and Love and others many years ago. The last real traffic on either appears to have been in 2006. (And they often got the same mail to both, duplicated. Kind of a waste...) From: To: Time: Thu May 21 16:06:31 2009 announced in http://osdir.com/ml/ietf.krb-wg/2003-01/msg00005.html From: To: Time: Thu May 21 16:12:19 2009 (hm, I was thinking they were set up after a London meeting, but it looks like I'm wrong, it was after Atlanta... whatever....) From: To: Time: Thu May 21 16:22:12 2009 Anyway I'm lost here. Removing the assertion allows non-fast pkinit to work. fast pkinit doesn't seem to work; not sure if it is kdc or client side. Not sure what people think of the priorities of fixing fast pkinit, fixing Love's issue etc and how they fit into the release schedule. I'll definitely take ownership for any changes to the ietf draft and will try and help with the rest as time permits. From: To: Time: Thu May 21 16:22:49 2009 what are the risks if we release krb5-1.7 with the remaining issues unresolved? From: To: Time: Thu May 21 16:29:02 2009 fast pkinit: If it's exploitable that's probably bad. fast pkinit: makes it harder to universally deploy fast--I don't really think that's a big deal at all. Love FAST: may limit our options for fixing, complicate the interop picture or get us into a situation where 1.7' does not interop with 1.7. If enough people would read and comment on my analysis of Love's message it might be clear what direction people were leaning, and I believe that there is a simple fix. However testing the simple fix depends on fast pkinit From: To: Time: Thu May 21 16:29:46 2009 Another option is of course to disable fast advertizements in the KDC and possibly completely disable in the KDC From: To: Time: Thu May 21 16:30:17 2009 Obviously I'd rather not see that happen. But I also understand the release needs to ship From: To: Time: Thu May 21 16:39:03 2009 so as i understand it, Love thinks that making req-body optional will help pkinit work with FAST? From: To: Time: Thu May 21 16:39:55 2009 Yes. From: To: Time: Thu May 21 16:40:16 2009 Well, pkinit be secure From: To: Time: Thu May 21 16:40:49 2009 the FAST-pkinit breakage is protocol breakage or implementation breakage? From: To: Time: Thu May 21 16:41:10 2009 And not req-body Love is talking about a mode where a KDC accepts a fastarmoredreq *instead of* a as-req or tgs-req From: To: Time: Thu May 21 16:41:37 2009 implementation breakage as best I know From: To: Time: Thu May 21 16:42:50 2009 However solutions to Love's issues involving changing how FAST and pkinit interact at the protocol level From: To: Time: Thu May 21 16:43:09 2009 how well are these interactions currently specified? From: To: Time: Thu May 21 16:43:38 2009 In my opinion, quite well, although I believe also insecurely From: To: Time: Thu May 21 16:44:07 2009 Or rather, in my opinion, the specification is interoperable. I believe there are security issues not documented in the spec From: To: Time: Thu May 21 16:44:20 2009 oh. i prefer that we not release known-insecure stuff. how bad is it? From: To: Time: Thu May 21 16:44:28 2009 And I believe that fixing those issues might involve changing the interactions in a non-interoperable way From: To: Time: Thu May 21 16:44:52 2009 which means coordinating with the other implementors? From: To: Time: Thu May 21 16:45:03 2009 Take a look at the in brief section of the message I forwarded you today with urgent in the subject From: To: Time: Thu May 21 16:46:13 2009 i do not recall seeing such a message. let me check my spam folder. From: To: Time: Thu May 21 16:46:49 2009 Yes you would need to coordinate and of course with ourselves From: To: Time: Thu May 21 16:47:08 2009 wait it would break interop with plain pkinit? From: To: Time: Thu May 21 16:47:28 2009 May 21 07:44:02 live postfix/smtp[27478]: 8690A415C: to=, orig_to=, relay=W92- 130-BARRACUDA-3.mit.edu[18.7.21.224]:25, delay=1.4, delays=0.05/0.02/0.91/0.43, dsn=2.0.0, status= sent (250 Ok: queued as 7D44B1F25919) From: To: Time: Thu May 21 16:47:55 2009 got flagged as spam with score 7.78 From: To: Time: Thu May 21 16:47:58 2009 No. It might break interop with something we released if we do it after the release From: To: Time: Thu May 21 16:48:06 2009 oh i see. From: To: Time: Thu May 21 16:51:09 2009 do you have input from Larry on this issue yet? From: To: Time: Thu May 21 16:51:10 2009 For those following along at home, the interesting content in my message to Tom is also in https://lists.anl.gov/pipermail/ietf-krb-wg/2009-May/007638.html From: To: Time: Thu May 21 16:51:33 2009 I do not; have sent him the mail, the WG email and an SMS From: To: Time: Thu May 21 16:54:17 2009 this sounds reminiscent of an earlier pkinit protocol vulnerability discovered by Jaggard et al, doesn't it? From: To: Time: Thu May 21 16:55:35 2009 Yes, yes it does. And I have a sinking feeling that we may have explicitly broken the mechanism introduced to fix that in choosing to bind only the outer request. From: To: Time: Thu May 21 17:05:08 2009 how risky is making explicit the behavior that FAST and pkinit are mutually exclusive in our implementation for krb5-1.7, possibly changing in 1.7.x? From: To: Time: Thu May 21 17:18:10 2009 If you do that, I'd probably do that both in the client and server. Basically, I'd use the callback for obtaining the armor key. If the armor key is present, then indicate the mechanism is not available. The inverse of what encrypted_challenge does From: To: Time: Thu May 21 17:19:08 2009 Explicitly disabling fast pkinit is probably the best strategy I've seen so far. From: To: Time: Thu May 21 17:19:51 2009 But if the solution is binding FAST to the inner kdc-req body, we'll break compatibility with all FAST, not just pkinit FAST, right? From: To: Time: Thu May 21 17:19:53 2009 and if we adopt that strategy, can we later enable a new FAST-integrated pkinit in a backward-compatible way? From: To: Time: Thu May 21 17:20:24 2009 (I hope to be in a better position to comment on the protocol issue tomorrow.) From: To: Time: Thu May 21 17:20:51 2009 i'm rereading rfc4556 and the FAST draft and it's going slowly From: To: Time: Thu May 21 17:27:11 2009 No, this only affects pkinit in practice. Or other legacy methods that include checksums of the request. So, we will not break fast with encrypted challenge. With that strategy we can enable fast pkinit later ->dinner From: To: Time: Thu May 21 17:33:17 2009 Then I think I favor disabling the combination of fast+pkinit in 1.7 and letting the protocol work itself out on a slower timescale. But I'd like to understand the issue better before I'm sure of that opinion. From: To: Time: Thu May 21 17:33:34 2009 (Hopefully I can do that tomorrow.) From: To: Time: Thu May 21 17:33:40 2009 i'm leaning in that direction as well From: To: Time: Fri May 22 09:38:10 2009 Anyone paying attention to the nightly testing runs? I just tweaked the script in AFS to start testing 1.7 snapshots. Results from last night include failures on a1 and dcl (which often fail because they detach file systems mid-run if no one is logged in -- now I'm logged in to both under a screen session on a1) and on opteron-prime (failed to forward tickets in one rsh test, for no obvious reason), and success on sparc-netbsd. From: To: Time: Fri May 22 09:38:57 2009 Actually, deactivation may not have caused the dcl failures. In 64-bit mode: LD_LIBRARY_PATH=`echo -L../../lib | sed -e "s/-L//g" -e "s/ /:/g"`; export LD_LIBRARY_PATH; ./t_prf <./t_prf.in >t_prf.output Assertion failed: krb5_c_prf(0, key, &input, &output) == 0, file t_prf.c, line 70 *** Error code 134 From: To: Time: Fri May 22 09:42:31 2009 And in 32-bit mode: KRB5_CONFIG=./t_krb5.conf ; export KRB5_CONFIG ;\ LD_LIBRARY_PATH=`echo -L../../../lib | sed -e "s/-L//g" -e "s/ /:/g"`; export LD_LIBRARY_PATH; ./t_keytab Testing miscellaneous error conditions Adding initial entry: Invalid argument Starting test on WRFILE:/tmp/kttest.2168 Type is: WRFILE Name is: WRFILE:/tmp/kttest.2168 *** Error code 1 make: Warning: Target `check' not remade because of errors From: To: Time: Fri May 22 09:43:46 2009 The x86_64 rsh forwarding failure happened for one enctype pass, but the same test appears to have passed for all the others. From: To: Time: Fri May 22 09:45:27 2009 All of those seem not so good. From: To: Time: Fri May 22 09:45:33 2009 Also, some tests use printf format attributes unconditionally. The Sun compiler doesn't understand them, but merely gives a warning. From: To: Time: Fri May 22 09:46:36 2009 Yeah. We're talking about interoperability testing, when we're not even looking over our existing test results enough? We need to do better on both scores... From: To: Time: Fri May 22 10:23:58 2009 Where does the term "lucid" originate from in gss_export_lucid_sec_context etc.? From: To: Time: Fri May 22 10:25:06 2009 It's an exported representation that's not opaque. From: To: Time: Fri May 22 10:26:04 2009 Ah, as in "translucent". Okay. From: To: Time: Fri May 22 12:07:53 2009 Do I really not have a working debugger on Athena 9.x suns? Man. From: To: Time: Fri May 22 12:09:34 2009 Ah, gdb-6.0 from the gnu locker seems to work acceptably. From: To: Time: Fri May 22 12:09:56 2009 I spoke too soon. From: To: Time: Fri May 22 12:16:54 2009 I'm debugging the prf problem. Been having some disconnection issues. t_prf.c uses "unsigned int i" but prf_length wants size_t* so we get length 0, _prf errors out. From: To: Time: Fri May 22 12:17:14 2009 Also have aclocal.m4 tweaks in works to make Sun cc error out on bad attributes, so I can clean those up. From: To: Time: Fri May 22 12:17:58 2009 Was going to make calls to _set_error_message_fl in _prf to report length error issue, but test passes null context ptr. From: To: Time: Fri May 22 12:18:12 2009 Going AFK for a bit, will see if connection is okay later. From: To: Time: Fri May 22 12:18:13 2009 Interesting; specific to 64-bit big-endian, so I wouldn't see it on my Ubuntu 64-bit machine. From: To: Time: Fri May 22 12:34:34 2009 The keytab problem is confusing. It's dying on fseek(KTFILEP(id), 0L, SEEK_CUR), but the truss output says lseek(3, 0xFFFFFC0C, SEEK_CUR) is being called. is included, so an fseek prototype should be in effect. From: To: Time: Fri May 22 13:07:02 2009 Fixing length to be size_t makes the t_prf assertion failure go away, but the result on sparc64 does not match what's expected. On x86-linux it matches. Building a sparc32-gcc tree... From: To: Time: Fri May 22 13:08:23 2009 What are you using for a debugger? From: To: Time: Fri May 22 13:08:43 2009 dbx and printf From: To: Time: Fri May 22 13:09:25 2009 Oh, my. Our gdb in the gnu locker is over 10 years old. No wonder it's crap. From: To: Time: Fri May 22 13:09:50 2009 Oh, but there's gdb-6.0 in gnu as well. Only six years old. :-) From: To: Time: Fri May 22 13:10:37 2009 I tried gdb-6.0 and it started up okay, but hung when I tried to run the process. dbx from sunsoft complained about some dwarf thing. From: To: Time: Fri May 22 13:11:23 2009 I didn't use dbx for much, just a stack trace. I already had most of the printf-type code in there because I wrote the _set_error_message call before realizing it wouldn't work with the null context handle. From: To: Time: Fri May 22 13:12:42 2009 dbx doesn't like gcc's debugging symbols i think. From: To: Time: Fri May 22 13:13:58 2009 I'll see if I can do a build with cc. From: To: Time: Fri May 22 13:21:50 2009 1.7-beta2 worked on sparc32 and passed tests, except maybe one that i have since committed a change for. From: To: Time: Fri May 22 13:22:46 2009 1.7 should be in nightly results starting tomorrow. From: To: Time: Fri May 22 13:23:28 2009 given athena is desupporting solaris we should come up with a way to run on bare solaris rather than athenized solaris at some point. From: To: Time: Fri May 22 13:23:41 2009 oh, foo, you might want to pick up some of the checkins i've made just now for 1.7 branch, sorry. should've created pullup tickets. i can go back and look up the rev numbers and make a new ticket... From: To: Time: Fri May 22 13:23:51 2009 ok From: To: Time: Fri May 22 13:35:15 2009 ticket opened From: To: Time: Fri May 22 14:16:45 2009 what is our status currently with the FAST + pkinit situation? From: To: Time: Fri May 22 14:19:12 2009 I believe we need to change the KDC to disallow FAST + pkinit. From: To: Time: Fri May 22 14:21:25 2009 (And we need to help resolve the protocol issue, which I've been slowly reading up on.) From: To: Time: Fri May 22 14:22:32 2009 Ugh. From: To: Time: Fri May 22 14:22:41 2009 Also--not critical for 1.7 but important for resolving the protocol issue--we need to debug the ASN.1 parsing failure that results from using FAST pkinit. From: To: Time: Fri May 22 14:22:45 2009 I hope you only think of that as a short-term solution From: To: Time: Fri May 22 14:23:48 2009 Yes. It's actually not clear to me that we should have tried to do FAST in 1.7 at all, but I don't want to reverse that decision now. But FAST pkinit in a 1.7 release on June 1 would definitely be premature in the face of the protocol issue, as I understand things. From: To: Time: Fri May 22 14:30:31 2009 who is going to implement the disabling for 1.7? From: To: Time: Fri May 22 14:33:44 2009 Does MIT Kerberos support config syntax like kdc = tcp/host.name:88 ? From: To: Time: Fri May 22 14:34:57 2009 I could probably do it tomorrow; I'm not yet familiar with KDC configuration for FAST or pkinit, and today is being a bad day. From: To: Time: Fri May 22 14:36:01 2009 i was wondering if Sam was going to have time to do it, but i haven't seen him post anything here recently. From: To: Time: Fri May 22 14:38:17 2009 macos 10.5.7 update broke copy/paste from x11. NOT OK. From: To: Time: Fri May 22 14:41:40 2009 Really? I was doing some cut/paste today, though I don't recall which direction. I think from Cocoa Emacs into X11 Emacs. From: To: Time: Fri May 22 15:12:36 2009 yeah i think it's the X11->OSX direction that's failing. i run a lot of stuff in emacs so thats rather annoying. From: To: Time: Fri May 22 15:12:42 2009 err, x11 emacs From: To: Time: Fri May 22 15:56:41 2009 hm, yeah, copying x11->osx doesn't seem to work. dunno if i'd used that much before though. From: To: Time: Fri May 22 15:57:37 2009 copying from x11 xterm works for me, just not from x11 emacs. might be a cut buffer vs selection thing. From: To: Time: Fri May 22 15:58:46 2009 copying from x-forwarded emacs21 doesn't work. copying from local x11 emacs22 works. From: To: Time: Fri May 22 15:59:43 2009 thought they'd have fixed something like that, yeah. my x11 emacs is remote emacs21 too. From: To: Time: Fri May 22 16:10:57 2009 Greg, are you looking into the weird keytab test bug? From: To: Time: Fri May 22 16:11:31 2009 Slowly. From: To: Time: Fri May 22 16:23:01 2009 Ok. I'm trying to build gdb-6.8 for solaris. From: To: Time: Fri May 22 16:25:49 2009 I did a build with cc and was able to use dbx. With that I stepped through the ktfileint code and noted the stdio operations being performed, which seem pretty innocuous. I'm now going to write a test program performing the same operations to make sure I get the same result (and it's not something else zany going on). I'll also need to figure out what the behavior was before r22278 which I assume introduced the issue. From: To: Time: Fri May 22 16:30:42 2009 I've copied gdb-6.8 into the rw version of the gnu locker, if you want to try it out. It appears to be able to read 32- and 64-bit executables but I haven't tried running stuff under it yet. From: To: Time: Fri May 22 16:34:27 2009 Hm, okay, it doesn't appear to be able to stop and set a breakpoint in a 64-bit process... not good. From: To: Time: Fri May 22 16:34:36 2009 Test program confirms apparent stdio wonkiness on Solaris; /mit/ghudson/tmp/test.c if anyone cares that much. Checking what we used to do differently. From: To: Time: Fri May 22 16:34:51 2009 Is it a 64-bit gdb? From: To: Time: Fri May 22 16:35:06 2009 No, probably why. It's doing better in 32-bit mode. From: To: Time: Fri May 22 16:41:31 2009 I'm afraid I'm coming into this late. What stdio wonkiness? From: To: Time: Fri May 22 16:43:04 2009 If fread pulled in BUFSIZ bytes, fseek to "here" could reposition the underlying fd back to the current location instead of from last_read_loc + BUFSIZ. From: To: Time: Fri May 22 16:43:09 2009 Open an empty file, mode rb+. Write two bytes. Seek to the beginning, read two bytes. Read four more bytes (getting EOF). Write four bytes. Seek to where you are right now, and get an error. (Some steps may be unnecessary.) From: To: Time: Fri May 22 16:43:25 2009 Hm, okay, no... From: To: Time: Fri May 22 16:44:05 2009 What we used to do differently is have more fseek(fp, 0, SEEK_CUR) calls in between steps. This problem is only on trunk, by the way; it shouldn't exist in 1.7. From: To: Time: Fri May 22 16:44:55 2009 i thought we pulled up that change to 1.7-beta2 From: To: Time: Fri May 22 16:44:56 2009 I thought there was some requirement like needing to seek or flush or something when switching between read and write modes. But I could be imagining it. I'm looking and haven't found a reference so far. From: To: Time: Fri May 22 16:45:13 2009 by "seek to where you are right now", you mean fseek(fp,0,SEEK_CUR) ? From: To: Time: Fri May 22 16:45:23 2009 Yes. From: To: Time: Fri May 22 16:45:52 2009 I'm not sure that behavior is well-defined past the attempt to read beyond EOF From: To: Time: Fri May 22 16:46:04 2009 ... but I'm also not sure it's not. From: To: Time: Fri May 22 16:47:51 2009 Hrm. Does inserting fseek(fp,0,SEEK_CUR) directly after the read-past-EOF work? How about fseek(fp,0,SEEK_END) (but that changes the behavior) From: To: Time: Fri May 22 16:50:18 2009 It does work. I'll put that one back in. From: To: Time: Fri May 22 16:52:44 2009 Interestingly, without the intermediate seek, the "write four bytes" call returns successfully but doesn't actually extend the length of the file. From: To: Time: Fri May 22 16:53:32 2009 buffered output? From: To: Time: Fri May 22 16:53:47 2009 Yes, but the file remains at size 2 after the program exits normally. From: To: Time: Fri May 22 16:54:10 2009 hm. From: To: Time: Fri May 22 16:54:35 2009 but if the file handle is in an EOF state, are further read/write operations defined? From: To: Time: Fri May 22 16:55:05 2009 I think fwrite from EOF is defined, but I don't know for sure. From: To: Time: Fri May 22 16:55:52 2009 Correction: the file's length only stays at 2 if you do the fseek-to-here and get an error. From: To: Time: Fri May 22 16:56:05 2009 If you do the fwrite and exit immediately, the file's length goes up to 6 as expected. From: To: Time: Fri May 22 16:56:44 2009 i seem to recall that the precise definitions for stdio operations get complicated From: To: Time: Fri May 22 17:01:14 2009 posix 2008 specifically says fseek causes unwritten buffered data to be written out. From: To: Time: Fri May 22 17:01:29 2009 Well, that'd be if the fseek succeeds From: To: Time: Fri May 22 17:01:54 2009 yeah. there are also various failure conditions described but none jump out at me as applicable. From: To: Time: Fri May 22 17:06:09 2009 In the failure case, the actual system call invoked by fseek is lseek(3, 0xFFFFE004, SEEK_CUR). From: To: Time: Fri May 22 17:06:41 2009 Cool. From: To: Time: Fri May 22 17:06:52 2009 32- or 64-bit binary? From: To: Time: Fri May 22 17:06:55 2009 Wow, that's a pretty big backwards jump. From: To: Time: Fri May 22 17:07:17 2009 Or a _really_ big forwards one, depending. But I guess the forward seek wouldn't have failed. From: To: Time: Fri May 22 17:08:22 2009 I'm assuming this is the 32-bit flavor. That's almost -8K; the library seems pretty clearly confused. From: To: Time: Fri May 22 17:08:31 2009 Yeah, I agree. From: To: Time: Fri May 22 17:22:07 2009 Can't find anything to support what I thought besides a lingering suspicion that some old implementations might not DTRT. Oh well. From: To: Time: Fri May 22 17:35:12 2009 Do I read this right, that we test PRF only for aes128 and no other types? From: To: Time: Fri May 22 17:47:03 2009 input and output on a stdio file open for update needs to be separated by positioning operations or (for output followed by input) fflush. the exception is if the input operation which the output operation follows encounters EOF. From: To: Time: Fri May 22 17:47:16 2009 it may be that solaris is broken about implementing that special case. From: To: Time: Fri May 22 18:02:35 2009 we implemented prf for only aes until recently From: To: Time: Sat May 23 18:28:28 2009 There's no KDC configuration involved for FAST except for the requires_preauth principal bit, right? From: To: Time: Sat May 23 20:23:57 2009 Nightly testing results from last night: sparc-gcc failed (t_authdata doesn't link); sparc64-cc failed (t_prf gets wrong data); x86-linux failed (ftp test timed out); sparc64-netbsd ...uh. The t_prf test aborted there too, but somehow "make -k check" from the top gave a success indication. From: To: Time: Sat May 23 20:28:31 2009 The link failure is because "$<" expanded to empty rather than a particular .o file. The syntax is documented as working for GNU make, but doesn't seem reliably portable, and in particular doesn't seem to be working for /usr/ccs/bin/make. From: To: Time: Sat May 23 20:29:24 2009 Same failure happens on trunk. From: To: Time: Sat May 23 20:39:51 2009 Which rule? $< only works for implicit rules in general, but works for all rules in gmake. From: To: Time: Sat May 23 20:40:17 2009 Building t_authdata and at least one other I noticed, from the various object files. From: To: Time: Sat May 23 20:41:30 2009 Not clear to me why things appear to be passing on salamander (sparc64-netbsd). The make subprocess notes the failure, but the shell loop invoking the make subprocesses continues on as if all is well, never setting a nonzero exit status. From: To: Time: Sat May 23 20:42:12 2009 One other you noticed by inspection of the Makefile, specifically t_ad_fx_armor? From: To: Time: Sat May 23 20:42:15 2009 And which shell loop? From: To: Time: Sat May 23 20:42:48 2009 The recursion step in config/post.in near the bottom. From: To: Time: Sat May 23 20:42:53 2009 Yes, that's the one. From: To: Time: Sat May 23 20:43:41 2009 The shell code looks reasonable (if icky) to me. And the test commands I run on the command line with sh seem to DTRT. From: To: Time: Sat May 23 20:43:47 2009 But now, I have a phone call to go make... From: To: Time: Sat May 23 20:45:46 2009 No real ideas about the shell loop. I'll fix the rules using $<. From: To: Time: Sat May 23 20:58:19 2009 Thanks. I'll try to check the results again tomorrow. From: To: Time: Sat May 23 21:01:50 2009 The trunk t_prf failures -- on sparc64 with both cc (solaris) and gcc (netbsd) suggest another 64-bit big-endian problem. From: To: Time: Sat May 23 21:19:23 2009 How are you doing 64-bit sparc builds? Platform argument to configure? From: To: Time: Sat May 23 21:20:31 2009 http://krbdev.mit.edu/nightly/current/sparc64-netbsd3.0/20090523.0500/index.html From: To: Time: Sat May 23 21:20:39 2009 ooh, maybe ksh is the problem... From: To: Time: Sat May 23 21:20:49 2009 that's the netbsd one. i'm not doing those manually. From: To: Time: Sat May 23 21:21:15 2009 on solaris, i attach -f sunsoft_v12 use CC='cc -m64' CXX='CC -m64' From: To: Time: Sat May 23 21:55:44 2009 hm, looks like it's not using ksh except to run the nightly testing script; other stuff should be sh. From: To: Time: Sun May 24 02:02:34 2009 This room is not anonymous. From: To: Time: Sun May 24 14:20:15 2009 Oh, hm. If a client tries optimistic FAST PKINIT against the KDC, you can't just respond to PKINIT and not FAST, since the client will have put all of the PKINIT padata inside the armored request. From: To: Time: Sun May 24 15:16:40 2009 I'm failing to see how padata within the armored FAST request are processed. I may have to delve into why FAST PKINIT is failing before I can safely disable trying to respond to optimistic FAST PKINIT requests. From: To: Time: Sun May 24 15:21:21 2009 So, when Sam tried FAST PKINIT, he got a truncation-related error. I'm not getting that, probably because the loopback interface is happy to pass the 3820-byte request (?) over UDP, but it then fails with KDC_ERR_PA_CHECKSUM_MUST_BE_INCLUDED. Debugging this will be interesting since I have no hope of getting Wireshark to decode an armored FAST request body without a lot of work. From: To: Time: Sun May 24 15:22:20 2009 Either the client is not presenting the pkinit checksum, or the server is not finding it since it's in the armored request body and not in the outer request. I guess I should be able to tell which is true pretty easily from examining the state at the time the KDC generates the error. From: To: Time: Sun May 24 16:31:26 2009 Okay, the error is deceptive. The auth_pack containing the checksum is present and is found by the KDC, but the checksum doesn't match. From: To: Time: Sun May 24 16:50:16 2009 I'm not sure how this is supposed to work. For a FAST armored request, process_as_req seems to replace the request pointer with the armored request, forgetting about the outer request pointer altogether. Which means, if I'm not confusing myself: (1) pkinit_srv.c computes its checksum over the inner request body, since that's all it has available, and (2) the outer request is never freed. From: To: Time: Sun May 24 17:36:07 2009 (As for #2, kdc_find_fast frees the outer request.) From: To: Time: Sun May 24 18:43:33 2009 UDP packets shouldn't be getting truncated over ethernet, should they? Fragments should get reassembled. And if a fragment never comes through... hm, I'd assume the rest would eventually be discarded and not passed to the application. From: To: Time: Sun May 24 18:44:58 2009 And for packets that large, we should default to trying TCP first anyways, if the config files permit. From: To: Time: Sun May 24 18:59:55 2009 Oh, shoot. Some of my cleanup before leaving mit accidentally got rid of a private copy of dejagnu on dcl.mit.edu that the nightly testing is using. So now the sparc-solaris tests fail because of that. Hard to say, but I think that's causing all of the failures in last night's log. From: To: Time: Sun May 24 19:00:18 2009 64-bit solaris fails the prf test of course, and x86-linux seems to have failed the ftp connect test again. From: To: Time: Sun May 24 19:00:43 2009 x86_64 linux is now running (and passing) tests on 1.7 branch instead of 1.6. From: To: Time: Sun May 24 19:01:05 2009 and sparc64-netbsd is still incorrectly reporting success. From: To: Time: Sun May 24 22:00:08 2009 Yeah, there's clearly something odd going on there. From: To: Time: Sun May 24 22:00:17 2009 (Stark response, oops.) From: To: Time: Mon May 25 00:51:07 2009 I've just had to adjust my mental model of how FAST client integration works. It seems if the application passes in an armor cache, krb5_get_init_creds assumes the KDC supports FAST. From: To: Time: Mon May 25 00:56:48 2009 So, the application needs to know if the KDC supports it? From: To: Time: Mon May 25 00:58:16 2009 Apparently. I'm not sure what the security assumptions are here. I know there's a protocol proposal for negotiating whether the KDC supports FAST which hasn't been implemented yet, but I didn't know that in the absence of such negotiation, we were just assuming the API usage would match the KDC. From: To: Time: Mon May 25 01:03:43 2009 Ah, so you use "kinit -T cachename" if you know your KDC supports it. Hm. From: To: Time: Mon May 25 01:04:21 2009 Though that's only in the kinit usage message, not the longer text that explains the various options. From: To: Time: Mon May 25 01:06:20 2009 And the command-line usage isn't shown with it in brackets, as other optional arguments are. From: To: Time: Mon May 25 01:06:31 2009 Yeah, that should be fixed up. From: To: Time: Mon May 25 01:06:57 2009 kinit -T is really mostly for testing; the expected consumer is pam_krb5. From: To: Time: Mon May 25 01:10:28 2009 Unless you're fixing the usage message now, I'll fire off a bug report. I'm about to wander away... From: To: Time: Mon May 25 01:12:05 2009 I'm off for the night. From: To: Time: Mon May 25 01:12:30 2009 mail sent. and away i go as well... From: To: Time: Mon May 25 01:12:45 2009 good morning :-) From: To: Time: Mon May 25 01:13:06 2009 hi, tom. bye, tom. :-) From: To: Time: Mon May 25 17:28:49 2009 Last night's test results unchanged except x86_64 failed one of the rsh ticket-forwarding tests, with "kcmd: Error getting forwarded creds". Maybe we should have that message print a little more detail... From: To: Time: Mon May 25 17:29:53 2009 x86-linux failed ftp connect test again for some reason. From: To: Time: Wed May 27 14:47:04 2009 Have there really been no release meetings since February? Or are meeting minutes no longer being put up on the wiki? From: To: Time: Wed May 27 14:49:41 2009 We've been lame about minutes. From: To: Time: Wed May 27 14:50:32 2009 (Which I'm personally okay with, honestly. Taking them consumes a lot of one person's attention, which is like 25% of the meeting, and anything substantial which comes out of it should usually be discussed on krbcore or krbdev.) From: To: Time: Wed May 27 14:54:07 2009 Okay. I'm just learning what it's like to be kind of out of the loop. :-) Listening here helps though. From: To: Time: Wed May 27 14:55:20 2009 (Only kind of, since I'm still on some mailing lists too. But, no discussions around the office, no hearing minor points that come up in the meetings and are put off for later consideration, etc.) From: To: Time: Wed May 27 14:58:38 2009 Dejagnu is reinstalled on dcl for solaris testing. 32-bit gcc tests failed in kadm5 tests: FAIL: init 108: bad failure From: To: Time: Wed May 27 14:59:05 2009 "Bad failure" is the most awesome error message yet. From: To: Time: Wed May 27 15:01:14 2009 That's because it failed with KRB5_KDB_NOMASTERKEY instead of failing with KRB5_KDB_CANTREAD_STORED like it was supposed to. From: To: Time: Wed May 27 15:01:26 2009 (Which would've been a good failure, I guess.) From: To: Time: Wed May 27 15:01:50 2009 x86-linux is still failing in the ftp connect test, which I'm unable to reproduce so far. From: To: Time: Wed May 27 15:02:51 2009 I wonder if I ran into that when I was first getting the test suite to work. From: To: Time: Wed May 27 15:03:04 2009 Ah, yes. /etc/shells. From: To: Time: Wed May 27 15:06:26 2009 The krbsnap user and I have the same shell in /etc/passwd. So if it fails for krbsnap it should fail for me... From: To: Time: Wed May 27 15:36:10 2009 Hm, this logistical problem is being harder than I thought. I need a machine which (1) isn't my main development machine, (2) has a working debugging environment, and (3) has OpenSSL 0.9.8 or later (which rules out Athena 9.4 Linux). From: To: Time: Wed May 27 15:36:47 2009 I guess I could use my laptop. From: To: Time: Wed May 27 15:39:12 2009 Hrm. Could there be a solution involving xvm? From: To: Time: Wed May 27 15:53:23 2009 does gdb work on linerva? From: To: Time: Wed May 27 15:53:51 2009 Yeah, that's an option. From: To: Time: Wed May 27 15:58:19 2009 Ah, found the t_prf problem. From: To: Time: Wed May 27 15:58:43 2009 I'd changed a variable from int to size_t, but it's used in two places, one requiring an int-sized value, one requiring a size_t-sized value. From: To: Time: Wed May 27 15:59:01 2009 So it didn't need the type changed, it needed to be split into two variables. From: To: Time: Wed May 27 15:59:43 2009 (And, the bug is in the test code, not the prf implementation.) From: To: Time: Wed May 27 16:06:58 2009 It's sort of eerie doing a build on a local machine and not hearing disk grinding noises. (This laptop has an SSD.) From: To: Time: Wed May 27 16:10:00 2009 Ooh. Is it fast? From: To: Time: Wed May 27 16:11:41 2009 The processor on this machine isn't all that speedy, I think. Builds are pretty zippy nonetheless. From: To: Time: Wed May 27 16:14:44 2009 I mean the disk. From: To: Time: Wed May 27 16:15:55 2009 I don't really know how to measure that. From: To: Time: Wed May 27 16:17:25 2009 Hm, can't reproduce Sam's truncation problem, even over the intertubes. From: To: Time: Wed May 27 16:17:36 2009 (I can reproduce the checksum mismatch.) From: To: Time: Wed May 27 16:25:36 2009 Regarding r22393: why wouldn't you rerun the test program each time "make check" is run? From: To: Time: Wed May 27 16:27:04 2009 And why two rules for vk.txt? From: To: Time: Wed May 27 16:27:28 2009 (Nevermind on that second question.) From: To: Time: Wed May 27 17:03:49 2009 The first rule creates an output file by running the program, and then ... actually, we don't do anything with it. And the exit(1) would only be effective if actually running it. Oops. Okay, that was bad. I was thinking it was like the second set of rules, where we just needed to have generated the output. Will fix that. From: To: Time: Wed May 27 17:06:04 2009 Ugh. The other rules were a bad change too... changing the library won't cause regeneration of the output files. From: To: Time: Wed May 27 17:09:42 2009 Oh. But it will cause relinking of the test program. So, yeah, I think that's okay. I just need to go back and make aes-gen run every time. From: To: Time: Wed May 27 17:10:17 2009 I think you're going down the wrong path. 'make check' should run the test _every time_, not just when the thing under test has changed. From: To: Time: Wed May 27 17:10:49 2009 So, not even assume it's deterministic? I can see an argument for that... From: To: Time: Wed May 27 17:11:47 2009 Correct. Don't try to optimize it away. Unlike other targets, "make check" doesn't mean "make sure the checks have been run"; it always means "run the test" From: To: Time: Wed May 27 17:12:18 2009 Otherwise you frustrate people who are trying to figure out what's going on From: To: Time: Wed May 27 17:13:34 2009 Good point. Though, I sometimes find it frustrating that I can't easily test just the thing I changed, because "make check" does so much and the rules for testing some functionality are rather complicated to run by hand. From: To: Time: Wed May 27 17:13:49 2009 But, breaking up the "check" rules into sub-targets can help with the latter. From: To: Time: Wed May 27 17:15:56 2009 The complexity is exactly why it should always run the tests. Otherwise it gets to be complicated to force it to rerun the part that "successfully" generated wrong output. From: To: Time: Wed May 27 17:18:30 2009 In some of my recent projects, I've taken to supporting a make variable TESTS which, if set, causes only the tests it names to be run. From: To: Time: Wed May 27 17:22:26 2009 Our dejagnu tests work a bit like that. Our other tests sometimes have individual make target names, and sometimes (often) not. From: To: Time: Wed May 27 17:27:55 2009 Anyone seen Tom lately? From: To: Time: Wed May 27 17:29:07 2009 He's traveling. Was in the chat room a little while ago, and I still see his @mit jid online. From: To: Time: Fri May 29 00:40:54 2009 Andreas Hamberger reports a compile error enabling the edirectory support. A quick test shows we've also got link failures one the compile error is fixed. with edirectory support, kdb5_ldap_util needs functions from the ldap library (which it doesn't directly link against) and from libkdb_ldap (which aren't exported because they don't exist in non-edirectory mode and it's not conditionalized). From: To: Time: Fri May 29 00:41:26 2009 But, I'm wanderingaway. May look at it more later. From: To: Time: Fri May 29 14:41:44 2009 Oh, yeah, I was testing the trunk, not 1.6.3. From: To: Time: Sun May 31 02:02:33 2009 This room is not anonymous. From: To: Time: Sun May 31 20:36:15 2009 just checked last night's auto test results. much like before -- solaris fails with "bad failure" (32bit-trunk, 64bit-trunk, 32bit-1.7), or bad t_prf results on the branch in 64-bit mode, a1 fails the ftp connect test. that seems to be pretty persistent... From: To: Time: Mon Jun 1 11:30:01 2009 is r22395 the fix for the eDirectory problem? From: To: Time: Mon Jun 1 11:35:16 2009 It should fix the compilation problem on the trunk (minor typo in Greg's snprintf/asprintf changes). It doesn't address the linking problem on both the trunk and 1.6.3. From: To: Time: Mon Jun 1 11:35:49 2009 Also, since the compilation problem was there for a while -- and since it's eDirectory code -- it hasn't been tested... From: To: Time: Mon Jun 1 11:43:37 2009 have we made any commitments about eDirectory support? From: To: Time: Mon Jun 1 11:45:33 2009 i have mimimal confidence that the automated test failures are meaningful. they seem far too sensitive to environmental issues. From: To: Time: Mon Jun 1 11:49:09 2009 No formal commitments that I know of, though of course it would be nice to keep cooperating with Novell if they want to give us code fixes there. From: To: Time: Mon Jun 1 11:51:10 2009 Often it's environmental issues in the tests, but I think occasionally it's unexpected environmental issues in the programs. From: To: Time: Mon Jun 1 12:43:22 2009 Is the rest of the team still out of town? From: To: Time: Mon Jun 1 12:43:31 2009 i have returned From: To: Time: Mon Jun 1 12:43:43 2009 Steve is also back. From: To: Time: Mon Jun 1 12:43:48 2009 Okay, so dev meeting tomorrow. From: To: Time: Mon Jun 1 12:43:57 2009 yes From: To: Time: Mon Jun 1 12:43:58 2009 (I got confusing mail from techtime.) From: To: Time: Mon Jun 1 13:14:20 2009 I have not received any bug reports from debian for beta3 From: To: Time: Mon Jun 1 13:14:57 2009 we're trying to chase down some mkey rollover issues at the moment, unfortunately. From: To: Time: Mon Jun 1 13:19:06 2009 Are they well defined that you might be able to simply document some things as not working without documenting the entire mkey rollover as broken? From: To: Time: Mon Jun 1 13:19:20 2009 trying to determine that From: To: Time: Mon Jun 1 13:33:13 2009 one of the errors is an unexpected KRB5_KDB_BADSTORED_MKEY. the number of code locations that can produce that is limited, so perhaps i will look at those. From: To: Time: Mon Jun 1 14:01:46 2009 Okay, the "bad failure" test result on Sparc appears to be pretty minor. The test case is attempting to initialize the kadmin service with a nonexistent master key file, and getting KRB5_KDB_NOMASTERKEY when it expects KRB5_KDB_CANTREAD_STORED. There may be something actually wrong there, particularly since it's not a portable failure, but it's probably not a release blocker. From: To: Time: Mon Jun 1 14:05:18 2009 Oh... with a nonexistent master key name, actually. I wonder why this doesn't fail everywhere. From: To: Time: Mon Jun 1 14:13:43 2009 I'm sort of at a loss as to how to go from "kadmin test fails" to actually looking at the code path in gdb (to see why we get different error codes on different platforms), since it looks like we're using tcl bindings to exercise the code. From: To: Time: Mon Jun 1 14:14:58 2009 Can you stick an infinite loop in the right place and gdb attach? From: To: Time: Mon Jun 1 14:15:16 2009 Or probably loop until some file exists as I don't know that I'd want to set a tcl variable from within gdb From: To: Time: Mon Jun 1 15:08:03 2009 OK, purging unused master keys from 'master/key@KRBTEST.COM'... Purging the follwing master key(s) from master/key@KRBTEST.COM: KNVO: 1 kdb5_util: Invalid argument while updating actkvno data for master principal entry From: To: Time: Mon Jun 1 15:08:10 2009 this looks not good. From: To: Time: Mon Jun 1 15:10:59 2009 Although presumably being able to purge unused keys is something you can document as broken. Assuming that the database does not get corrupted etc. From: To: Time: Mon Jun 1 15:11:16 2009 database appears to be uncorrupted From: To: Time: Mon Jun 1 15:14:24 2009 i have confirmed that mkey migration from 1.6 to 1.7 works; haven't checked in the situation where enctypes are changing yet. Greg, are you able to give it a try? From: To: Time: Mon Jun 1 15:15:33 2009 To give what a try specifically? From: To: Time: Mon Jun 1 15:26:07 2009 create a kdb in 1.6 using single-DES master key. try to migrate it to 1.7 and update its mkey to one using AES for example. From: To: Time: Mon Jun 1 15:29:15 2009 unrelatedly (?) i am fairly sure that on 32-bit sparc, i do not see any failures in "make check". From: To: Time: Mon Jun 1 15:33:02 2009 Are you running any dejagnu tests in that make check? From: To: Time: Mon Jun 1 15:33:07 2009 yes From: To: Time: Mon Jun 1 15:33:28 2009 actually that failure is not in tests/dejagnu but a separate dejagnu-based test suite in lib/kadm5 From: To: Time: Mon Jun 1 15:35:37 2009 Yes, but still using dejagnu. From: To: Time: Mon Jun 1 15:36:27 2009 true. the thing is it's not running normal krb5 programs; it's running a specially built tcl interpreter that has tcl bindings for the kadm5 api. (which is separate from the tcl interpreter that is running inside the expect program that is running dejagnu...) From: To: Time: Mon Jun 1 15:37:20 2009 Yeah, I'd gotten about that far. From: To: Time: Mon Jun 1 15:37:50 2009 rebuilding on sparc to see what happens From: To: Time: Mon Jun 1 15:38:13 2009 i think we may want faster sparc hardware but that may be interesting to justify budget-wise. From: To: Time: Mon Jun 1 15:40:10 2009 Maybe Will can arrange a donation or discount. It's not like you really need to get a "standard Athena machine" for sparc testing now. From: To: Time: Mon Jun 1 15:40:38 2009 true. we just have the additional fun of building modern open source software on solaris. ;-) From: To: Time: Mon Jun 1 15:40:56 2009 They ship a reasonable amount of stuff in /usr/sfw/bin now. From: To: Time: Mon Jun 1 15:41:01 2009 how modern is it? From: To: Time: Mon Jun 1 15:42:02 2009 Sun Fire T1000 .... is it made of liquid metal and has the ability to mimic the shape of anything it has touched? From: To: Time: Mon Jun 1 15:44:09 2009 Anything it has touched *that is properly aligned in memory*. From: To: Time: Mon Jun 1 15:46:39 2009 Okay, I have a 1.6 database with a DES master key. From: To: Time: Mon Jun 1 15:49:32 2009 You want me to do the migration to 1.7 with a dump and load per the documentation? From: To: Time: Mon Jun 1 15:54:04 2009 Uri Blumenthal is at MIT now? When did that happen? From: To: Time: Mon Jun 1 15:59:33 2009 I'm afraid I don't understand the steps involved in migrating from 1.6 to 1.7. From: To: Time: Mon Jun 1 16:11:31 2009 1.7 just reads a 1.6 database From: To: Time: Mon Jun 1 16:12:19 2009 ... but we do at least sometimes tell people to dump and reload so we've got the option of changing formats. From: To: Time: Mon Jun 1 16:12:52 2009 We do, in the installation instructions, but those haven't been updated for Will's work, I think, so they're mostly just confusing me. So I'm really not sure what Tom wants me to try. From: To: Time: Mon Jun 1 16:14:13 2009 The old instructions should work, they just don't do the mkey migration. I can't read Tom's mind, but 1.6->1.7 followed by mkey migration and disabling DES should work, shouldn't it? (Or is DES disabled by default again now?) From: To: Time: Mon Jun 1 16:17:08 2009 create a kdb using 1.6 and single-DES as the master key. load it using 1.7 and do mkey migration to a different enctype. dump/reload is probably not required but can be done if you want to be paranoid. From: To: Time: Mon Jun 1 16:18:01 2009 But presumably you're not talking about doing the mkey migration as part of dump/reload, you want to test Will's stuff. From: To: Time: Mon Jun 1 16:19:11 2009 right. From: To: Time: Mon Jun 1 16:19:13 2009 Though it's also good to test that the old option for mkey change during load doesn't break Will's stuff (e.g., by reverting the mkvno to 1). I think I tested that a little, or at least mentioned it to Will for testing. From: To: Time: Mon Jun 1 16:20:05 2009 that falls into the "gravy" category for now, unless it's horribly broken. From: To: Time: Mon Jun 1 16:20:57 2009 user.uri 537848975 RW 39 K On-line PHLEGETHON.MIT.EDU /vicepc RWrite 537848975 ROnly 0 Backup 537848977 MaxQuota 2000000 K Creation Fri Dec 14 00:07:11 2007 From: To: Time: Mon Jun 1 16:21:13 2009 not sure if it's the same Uri we know from IETF and various crypto things From: To: Time: Mon Jun 1 16:21:35 2009 Ah, didn't think of that. So, a bit over a year. From: To: Time: Mon Jun 1 16:21:42 2009 Okay, to do master key migration, I want to start with kdb5_util add_mkey -s? From: To: Time: Mon Jun 1 16:21:54 2009 My guess is it's the same -- I noticed because he's using uri@ll.mit.edu on the cfrg list. From: To: Time: Mon Jun 1 16:22:11 2009 oh. i haven't been paying attention to CFRG at all. From: To: Time: Mon Jun 1 16:22:34 2009 add_mkey adds but maybe doesn't activate a new mkey. From: To: Time: Mon Jun 1 16:23:10 2009 there's a kdb5_util update_princ_encryption command that reencrypts everything in the kdb with the currently active master key. From: To: Time: Mon Jun 1 16:24:25 2009 Okay, adding an AES master key and updating principals seemed to work... From: To: Time: Mon Jun 1 16:24:30 2009 add_mkey to create, use_mkey to set default, update_princ_encryption to re-encrypt, purge_mkeys to get rid of old ones. From: To: Time: Mon Jun 1 16:24:51 2009 and hopefully kadmin.local, krb5kdc, and kadmind all function afterward From: To: Time: Mon Jun 1 16:24:59 2009 purge_mkeys failed with the same error as Tom got. From: To: Time: Mon Jun 1 16:25:17 2009 But the KDC works fine. From: To: Time: Mon Jun 1 16:25:39 2009 what's in the stash file? From: To: Time: Mon Jun 1 16:25:45 2009 Hm... might be a good idea to check that they function, then restart, and check again, in case of caching. From: To: Time: Mon Jun 1 16:25:46 2009 i am wondering if that is the cause From: To: Time: Mon Jun 1 16:26:47 2009 Ah, right, updating the stash file needs to happen in there somewhere... From: To: Time: Mon Jun 1 16:27:06 2009 I started the KDC for the very first time after running purge_mkeys. From: To: Time: Mon Jun 1 16:27:24 2009 The stash file has v2 of the key since I did add_mkey -s. From: To: Time: Mon Jun 1 16:27:32 2009 Uh, I think. From: To: Time: Mon Jun 1 16:28:21 2009 Oddly, the keytab entry reports it as vno 0. From: To: Time: Mon Jun 1 16:29:11 2009 should check that the kdc notices newly added keys ... i.e., launch kdc, get a TGT, add_mkey, use_mkey, update_princ_encryption on the TGT principal, then use the TGT to get a service ticket From: To: Time: Mon Jun 1 16:29:49 2009 kvno 0 -- seems broken. From: To: Time: Mon Jun 1 16:36:13 2009 but if everything functions correctly except for displaying kvno 0, it is arguably a cosmetic flaw. From: To: Time: Mon Jun 1 16:36:17 2009 If I run "kdb5_util use_mkey 2" before purging, I don't get the error. From: To: Time: Mon Jun 1 16:37:08 2009 So this error might be from not having any keys suitable for purging? From: To: Time: Mon Jun 1 16:37:23 2009 if so, it should probably get worded more usefully From: To: Time: Mon Jun 1 16:39:30 2009 No, that's not what's going on. From: To: Time: Mon Jun 1 16:41:11 2009 It looks over the database, decides to purge the old master key, then calls krb5_dbe_lookup_actkvno and gets an empty actkvno_list, which causes krb5_dbe_update_actkvno to barf. I'm not sure which bit of code is wrong. From: To: Time: Mon Jun 1 16:53:56 2009 I have that sequence slightly wrong. From: To: Time: Mon Jun 1 16:56:54 2009 krb5_dbe_lookup_actkvno returns an actkvno_list with one element, which is removed by the for loop, resulting in a null list, which krb5_dbe_update_actkvno barfs on. From: To: Time: Mon Jun 1 17:07:09 2009 but there is a state where purge_mkeys can function correctly? From: To: Time: Mon Jun 1 17:07:30 2009 Should update_actvkvno ever be given an empty list? From: To: Time: Mon Jun 1 17:07:59 2009 (Does it imply that there are no active master keys?) From: To: Time: Mon Jun 1 17:08:02 2009 If you add_mkey, use_mkey, update_princ_encryption, purge_mkeys, it works fine for me. From: To: Time: Mon Jun 1 17:08:20 2009 ok, so it's mostly being somewhat unfriendly to users. From: To: Time: Mon Jun 1 17:09:00 2009 argh. i only just now found out that one of my testing environments on solaris was not actually finding tcl. From: To: Time: Mon Jun 1 17:09:53 2009 I think update_princ_encryption may be wrong in that it updates to a key which isn't active yet, and purge_mkeys doesn't gracefully handle the case where the active keys are all not in use. (What does it mean to have more than one active key anyway?) From: To: Time: Mon Jun 1 17:11:08 2009 i have inferred that "active" means the mkey that is used to encrypt any new key generated by the kadmin system or other kdb interfaces. From: To: Time: Mon Jun 1 17:11:19 2009 Active keys are those used for encrypting any of the keys in the database. For example, start with mkvno 1, add a new one, use_mkey to enable it, change a few passwords. Now a few principals are using 2, others are using 1, so both are active. From: To: Time: Mon Jun 1 17:11:42 2009 there is another list of mkvnos that corresponds to the list of all mkvnos used to encrypt any keys whatsoever in the kdb, but i'm not sure how that's generated. From: To: Time: Mon Jun 1 17:11:44 2009 raeburn: those are "in-use" keys. Active means something else. From: To: Time: Mon Jun 1 17:11:58 2009 Hm. From: To: Time: Mon Jun 1 17:12:13 2009 To answer my question: there can only be one active mkey, but the active mkey can depend on the current time, and actkvno_list is the list of keys which *might* be active depending on what time it is. From: To: Time: Mon Jun 1 17:12:29 2009 fascinating From: To: Time: Mon Jun 1 17:13:27 2009 Ah... right. Sorry, terminology error. From: To: Time: Mon Jun 1 17:14:04 2009 Will's script is far too sensitive to environmental conditions, and not well-isolated. From: To: Time: Mon Jun 1 17:17:29 2009 Ken, can you add me to /var/krbsnap/.k5login on dcl? I had a little trouble getting the dejagnu tests to run on Solaris in my own environment and configuring takes like an hour, so I want to sidestep that. From: To: Time: Mon Jun 1 17:18:28 2009 if he managed to take himself out of the klogin files, i can probably do that too. From: To: Time: Mon Jun 1 17:18:41 2009 It contains raeburn and krbsnap right now. From: To: Time: Mon Jun 1 17:19:04 2009 Oh, but I have root on that machine. I'll do it myself. From: To: Time: Mon Jun 1 17:20:51 2009 Yeah, I think I added you guys to the root klogin files on my old machines. (Except the mac, where I set up a Kerberos admin acct with our usual password and deleted mine.) From: To: Time: Mon Jun 1 17:23:17 2009 ok, i have reproduced the "init 108: bad failure" on sparc/solaris From: To: Time: Mon Jun 1 17:25:11 2009 I can reproduce it on dcl (unsurprisingly) but it just occurred to me that I will have trouble examining the code path with gdb, unless Ken managed to build a working gdb the last time this came up. From: To: Time: Mon Jun 1 17:26:10 2009 and i do confirm that the API invocation in question shows different error codes on sparc/solaris and darwin. From: To: Time: Mon Jun 1 17:26:28 2009 Try gdb-6.8 in the gnu locker. It worked a little better for me, but not all that well. From: To: Time: Mon Jun 1 17:26:42 2009 I tihnk I wound up switching to dbx last time. From: To: Time: Mon Jun 1 17:27:19 2009 dbx is deprecated in favor of mdb on solaris 10, i think. From: To: Time: Mon Jun 1 17:27:40 2009 gdb-6.8 works but the build was done with -O. Ugh. From: To: Time: Mon Jun 1 17:30:58 2009 Okay, rebuilt the source file in question with just -g. From: To: Time: Mon Jun 1 17:31:25 2009 i really hope this isn't a byte order problem. From: To: Time: Mon Jun 1 17:33:39 2009 krb5_db_def_fetch_mkey_stash is succeeding on Solaris and failing on Linux, I think. From: To: Time: Mon Jun 1 17:33:49 2009 interesting. From: To: Time: Mon Jun 1 17:38:26 2009 This is sort of a byte order issue. On Solaris, reading a keytab as a stash file happens to work, while on Linux it fails. From: To: Time: Mon Jun 1 17:38:41 2009 Ouch. From: To: Time: Mon Jun 1 17:38:43 2009 weird From: To: Time: Mon Jun 1 17:38:58 2009 The upshot of having it succeed is that you get a different (reasonable) failure mode later on. From: To: Time: Mon Jun 1 17:39:34 2009 the api test documentation says 108 is only testing that the mkey principal name parameter is obeyed. From: To: Time: Mon Jun 1 17:40:24 2009 so why does reading a keytab as a stash file succeed on sparc/solaris? From: To: Time: Mon Jun 1 17:40:26 2009 It's setting the mkey principle name to does/not/exist and expecting a specific failure code. From: To: Time: Mon Jun 1 17:40:47 2009 which might have been reasonable prior to Will's changes... From: To: Time: Mon Jun 1 17:41:09 2009 Well, it reads a two-byte enctype, then a four-byte length, and then bytes of key. If is larger than the file size, it will fail. From: To: Time: Mon Jun 1 17:41:26 2009 we should minimize architecture-specific behavior, even in failure conditions, i think. From: To: Time: Mon Jun 1 17:41:35 2009 Presumably the third through sixth bytes of a keytab are a small number in big-endian and a large number in little-endian. From: To: Time: Mon Jun 1 17:41:57 2009 oh, and since the first few bytes of a keytab are some version number information... From: To: Time: Mon Jun 1 17:42:09 2009 Yeah, ideally we want to make krb5_db_def_fetch_mkey_stash a little stricter such that it fails on a keytab. From: To: Time: Mon Jun 1 17:42:14 2009 If we can. From: To: Time: Mon Jun 1 17:43:52 2009 We could check if gets us to the end of the stash file; that would be pretty unlikely if it's not actually a stash file. From: To: Time: Mon Jun 1 17:45:52 2009 And we could check if enctype is valid and if is the expected key length for the enctype. From: To: Time: Mon Jun 1 17:45:57 2009 If we have the APIs to do that. From: To: Time: Mon Jun 1 17:46:04 2009 (AFK for a bit.) From: To: Time: Mon Jun 1 17:46:09 2009 first two bytes of a keytab are 0x05 0x02 or 0x05 0x01 From: To: Time: Mon Jun 1 17:46:47 2009 we could be selfish and pre-emptively assign those enctypes in the IETF.... From: To: Time: Mon Jun 1 17:49:04 2009 Or just assume for now that they're not in use. By the time we allocate numbers that high, we'll probably have fully deprecated old-format stash files anyways. From: To: Time: Mon Jun 1 17:50:48 2009 What enctypes? From: To: Time: Mon Jun 1 17:51:06 2009 0x0502 and 0x0501 From: To: Time: Mon Jun 1 17:51:14 2009 to work around an implementation quirk we just discovered. From: To: Time: Mon Jun 1 17:52:09 2009 it is debatable whether reserving protocol numbers for purely internal implementation purposes is a reasonable use of IETF process. From: To: Time: Mon Jun 1 18:01:16 2009 That reminds me. It would be nice to have an IANA considerations document From: To: Time: Mon Jun 1 18:03:00 2009 yes, it would. having the database is a start. (though it needs updating) From: To: Time: Mon Jun 1 18:09:42 2009 While AFK, I realized that we don't have an excuse to be trying to read a keytab file as a stash file in the first place. From: To: Time: Mon Jun 1 18:09:55 2009 why? From: To: Time: Mon Jun 1 18:10:22 2009 At the point in the code where we do so, we just finished successfully parsing the file as a keytab, reading through it, and simply not finding the principal we were looking for. There's no reason to retry as a stash file in that case. From: To: Time: Mon Jun 1 18:11:30 2009 unless there is an old stash file lying around? or is the assumption that it will inherently be out of date in that situation? From: To: Time: Mon Jun 1 18:12:03 2009 Same filename. From: To: Time: Mon Jun 1 18:12:21 2009 ok, that sounds like a bug From: To: Time: Mon Jun 1 18:12:56 2009 Unfortunately, I don't think there's a single error code for "this doesn't look like a keytab"; you might get KRB5_KT_END or some error from fseek. From: To: Time: Mon Jun 1 18:13:19 2009 what happens if the magic number is invalid? From: To: Time: Mon Jun 1 18:14:51 2009 KRB5_KEYTAB_BADVNO. So I guess that's the most likely, if 0x0501 and 0x0502 aren't valid current enctypes. From: To: Time: Mon Jun 1 18:15:13 2009 yeah From: To: Time: Mon Jun 1 18:18:00 2009 Verified that's what I get when trying to read a 1.6 stash file with krb5_db_def_fetch_mkey_keytab. Okay, I'll check for that specific error in the fallback. From: To: Time: Mon Jun 1 18:24:09 2009 Greg, will you open a bug on the init108 issue? From: To: Time: Mon Jun 1 18:26:36 2009 Yeah, just a minute or two, working out the error logic. From: To: Time: Mon Jun 1 18:27:24 2009 meanwhile i think we have multiple known bugs but no release blockers, so i will start tweaking release notes. From: To: Time: Mon Jun 1 18:28:57 2009 Yeah. From: To: Time: Mon Jun 1 18:39:41 2009 Committed. AFK again. From: To: Time: Mon Jun 1 20:25:55 2009 anyone feel like looking over the revised release notes? From: To: Time: Mon Jun 1 20:26:09 2009 (just committed) From: To: Time: Mon Jun 1 20:28:43 2009 Looking. From: To: Time: Mon Jun 1 20:29:21 2009 Is the state of weak cryptosystems for 1.7 still under discussion or has a decision been made? (Sidetracked by the pkinit/fast issues?) From: To: Time: Mon Jun 1 20:30:04 2009 long ago decided to default to "allow weak" for now. we need to create more tools to enable sane transition. From: To: Time: Mon Jun 1 20:30:38 2009 Oh, I see, somehow I wandered into the trunk version instead of the branch. Checking again... From: To: Time: Mon Jun 1 20:36:52 2009 I'm impressed with how short the "known bugs" list is. :) From: To: Time: Mon Jun 1 20:37:16 2009 i would like for it to be shorter but we are running out of time. From: To: Time: Mon Jun 1 20:38:21 2009 I meant, don't we have a bunch more, just not explicitly marked as 1.7 bugs? From: To: Time: Mon Jun 1 20:38:41 2009 it could be. i haven't gone out looking for them. From: To: Time: Mon Jun 1 20:38:52 2009 it's just the ones explicitly marked as 1.7 bugs. From: To: Time: Mon Jun 1 20:39:02 2009 Sure, I figured... From: To: Time: Mon Jun 1 20:39:06 2009 Otherwise, looks good to me. From: To: Time: Mon Jun 1 20:39:10 2009 ok, thanks From: To: Time: Mon Jun 1 20:39:56 2009 (Maybe "new known bugs"? "Known bugs in new features" covers a lot but not all, like #6481. From: To: Time: Mon Jun 1 20:39:59 2009 ) From: To: Time: Mon Jun 1 20:42:06 2009 going afk for a while... From: To: Time: Tue Jun 2 13:44:15 2009 I'm going to have to drop off From: To: Time: Tue Jun 2 18:12:20 2009 Oh, that's cool. I was only looking at group-related functionality. From: To: Time: Tue Jun 2 18:12:37 2009 it's still entirely possible that doxygen will require a great deal of bludgeoning before it will do something resembling what we want From: To: Time: Wed Jun 3 14:33:00 2009 Oops, I just invented the word "unbundingling" through an editing error. From: To: Time: Wed Jun 3 14:33:27 2009 freudian slip? From: To: Time: Wed Jun 3 14:40:44 2009 On a random note, I've been thinking of adding a static inline void *k5alloc(size_t size, krb5_error_code *ret) to k5-int.h just to cut down the size of malloc error handling blocks. (It would call calloc and set *ret to ENOMEM if that fails.) From: To: Time: Wed Jun 3 14:41:47 2009 but being inline, wouldn't it still expand to duplicated object code? (hopefully less than the duplicated stuff that's already there) From: To: Time: Wed Jun 3 14:45:35 2009 I meant the source code size of malloc error handling blocks; this would have no effect (I hope) on the object code size. From: To: Time: Wed Jun 3 14:47:06 2009 Does gcc actually guarantee it will inline an inline function? I agree it will have no negative effect on size of object code, but don't think I can go so far as no effect. From: To: Time: Wed Jun 3 14:49:27 2009 i think c99 says inline guarantees nothing about whether the compiler will actually inline. From: To: Time: Wed Jun 3 14:49:35 2009 No, there's explicitly no guarantee, but I think in practice it would inline this and wind up resulting in basically the same object code. From: To: Time: Wed Jun 3 14:51:50 2009 FWIW, Russ is giving the status report now using Tom's slides From: To: Time: Wed Jun 3 14:52:00 2009 Does someone want to answer questions if there are any? From: To: Time: Wed Jun 3 14:55:27 2009 sure From: To: Time: Wed Jun 3 15:13:11 2009 No questions, just applause. From: To: Time: Wed Jun 3 16:22:49 2009 Something that small is almost certain to be expanded inline. Also interesting might be an inline calloc block, with overflow checking for the multiplication built in. From: To: Time: Wed Jun 3 16:23:35 2009 that gets tricky depending on the types of the expressions involved From: To: Time: Wed Jun 3 16:23:36 2009 Sun's compiler (last I looked) tends to generate static copies for any "static inline" function, so in that configuration the object size would grow. But I think we can just throw that problem over the fence and declare it to be Sun's bug to fix. From: To: Time: Wed Jun 3 16:25:09 2009 What, the overflow checking? You get two size_t inputs, so you don't have undefined signed-operation issues to deal with. Divide the product (forced to size_t) by one of the inputs known not to be zero (the "size" is more likely to be constant and easier to optimize) and see if the result matches the other input. If not, you have an overflow. From: To: Time: Wed Jun 3 16:25:44 2009 oh right. i was thinking of a macro implementation, which could get interesting if you didn't explicitly cast the arguments. From: To: Time: Wed Jun 3 16:26:23 2009 Of course, if there's a simple construct that can convince the compiler to check the CPU's overflow flag, that's ideal. Such a thing probably would involve widening to twice the size of size_t and doing range checking, but maybe not... From: To: Time: Wed Jun 3 16:26:58 2009 It wasn't too long ago I got the gcc maintainers to implement better overflow checking for unsigned addition. Multiplication may still take some work. From: To: Time: Wed Jun 3 16:27:49 2009 But a simple enough and straightforward overflow-checking construct should be just what they aim to optimize when they get around to it, IMNSHO. From: To: Time: Wed Jun 3 16:28:11 2009 multiply with carry? do most CPUs default to "wide" multiply operations? From: To: Time: Wed Jun 3 16:29:28 2009 Not carry -- overflow would be a different flag. From: To: Time: Wed Jun 3 16:30:25 2009 At least, I think some of the common cpus have a separate overflow that could be used. From: To: Time: Wed Jun 3 16:31:04 2009 If you've got a constant multiplier, you can do other checks, like input1 < (2**N / input2). From: To: Time: Wed Jun 3 16:32:22 2009 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30314 is about a failure to do that optimization. :-) From: To: Time: Wed Jun 3 16:36:49 2009 the example code in that bug seems to be a roundabout way of doing an overflow check. yes, it's unsigned integer arithmetic but it still looks inelegant to me. From: To: Time: Wed Jun 3 16:36:53 2009 Oh, x86 docs on Sun's web site indicate both CF and OF are set the same, based on the multiply overflowing. And, x86 mul is 32x32->64 (or 16x16->32 or 8x8->16) so you could test the upper half of the output explicitly; but coding that in C is ugly, and requires having a typedefname for an unsigned integer twice the size of size_t. From: To: Time: Wed Jun 3 16:37:39 2009 What would you do instead? A range check before the multiply? From: To: Time: Wed Jun 3 16:38:14 2009 range check before multiply is a little better, i think. From: To: Time: Wed Jun 3 16:39:37 2009 It might look prettier. I'm less optimistic that it could be combined with the multiply into an overflow check though. But maybe... From: To: Time: Wed Jun 3 16:40:01 2009 There's a point where perhaps using asm is the right answer From: To: Time: Wed Jun 3 16:40:28 2009 yeah, but we shouldn't have to resort to these sorts of contortions just to prevent integer overflow bugs. From: To: Time: Wed Jun 3 16:43:53 2009 Hm, I wonder if 1<=(UTYPE_MAX/n) is optimized away for positive n. I doubt it... From: To: Time: Wed Jun 3 16:44:11 2009 (for calloc with count 1 and variable size) From: To: Time: Thu Jun 4 11:17:16 2009 Grr. Every time I find an interesting code instrumentation tool, I find out that it doesn't support shared libraries. From: To: Time: Thu Jun 4 11:17:26 2009 And we can't do any interesting testing without shared libraries because of plugins. From: To: Time: Thu Jun 4 11:17:42 2009 So, for instance, gcov is an awesome tool for computing code coverage, but using it to compute the code coverage of our test suite seems impossible. From: To: Time: Thu Jun 4 11:28:59 2009 valgrind has the necessary mojo to do code coverage, but as far as I can tell it's still a wishlist item, and the various unpackaged stabs at it are probably not adequate to compute the coverage of something like the krb5 test suite. From: To: Time: Thu Jun 4 11:44:41 2009 And none of this would be a serious problem if you had time to do something fun like finding some tool you like and teaching it to do what you need. From: To: Time: Thu Jun 4 12:33:14 2009 Well, we're not really pressed for time right now, but yak-shaving into development tools territory doesn't seem like a great use of MIT's money regardless of that. From: To: Time: Thu Jun 4 12:34:31 2009 I know that Purify has or had a code coverage tool (PureCoverage, now probably IBM Rational Coverage or something), but I don't know if it would work well for a multi-program test suite like the krb5 test suite, and it would almost certainly be expensive. From: To: Time: Thu Jun 4 12:53:23 2009 we have purifyplus From: To: Time: Thu Jun 4 12:54:05 2009 of course purify has an issue with runtime loading of shared objects if you use the RTLD_GROUP flag. i would imagine that purecoverage would have a similar issue. From: To: Time: Thu Jun 4 12:56:06 2009 So, you could probably hack together a non-shared-library build for testing that 1) imported the needed symbols from the binary 2) plugins had a lot of unresolved symbols 3) didn't cover plugins or something From: To: Time: Thu Jun 4 13:15:38 2009 We no longer have build system support for a static build, and not covering plugins is kind of useless when the KDB back ends are plugins. From: To: Time: Thu Jun 4 13:16:44 2009 Yeah, the kdb issue is kind of a big deal. Getting the static support you need is probably an afternoon's work. From: To: Time: Thu Jun 4 13:25:08 2009 or even setting up renaming stuff so we can do "builtin plugins" From: To: Time: Thu Jun 4 13:31:58 2009 I'll see how invasive it would be to support static testing builds. It would have applications beyond code coverage; anything involving instrumentation (profiling, call graphs, etc.) gets easier. From: To: Time: Thu Jun 4 13:47:31 2009 What is krb5_force_static? I seems to still be there after static build support was removed. From: To: Time: Thu Jun 4 13:48:06 2009 s/I/It/ From: To: Time: Thu Jun 4 13:48:08 2009 i think it is there in part for forcing the building of static libraries for things where building a shared library was inappropriate. it used to be used on a few things like libtelnet etc. From: To: Time: Thu Jun 4 13:48:30 2009 I don't see anything using it. From: To: Time: Thu Jun 4 13:48:42 2009 weird. what are we doing with libtelnet? From: To: Time: Thu Jun 4 13:50:26 2009 We're building a static library (also for libpty), but not using krb5_force_static. From: To: Time: Thu Jun 4 13:51:22 2009 ok. there may be lots of cruft in our build system. From: To: Time: Thu Jun 4 13:52:37 2009 It's just a little odd, because Ken removed the static library support, and then reorganized the krb5_force_static support instead of removing it, so it must have still had a purpose then. From: To: Time: Thu Jun 4 13:53:17 2009 there was some oddity related to AIX, where the shared libraries have the same extension as the static libraries (".a"). From: To: Time: Thu Jun 4 13:53:27 2009 i'm not sure if that was the exact cause From: To: Time: Thu Jun 4 13:54:52 2009 Aha, in r19265 (which slightly postdates r19262 which reorganizes the krb5_force_static stuff), we stopped using krb5_force_static but didn't remove it. From: To: Time: Thu Jun 4 20:49:16 2009 So, there are two basic patterns for plugins: the GSSAPI mechglue layer, and the other types of plugins (preauth, authdata, locate, KDB) which all use the directory interfaces and grab a function table. From: To: Time: Thu Jun 4 20:51:04 2009 There are no GSSAPI plugins yet (there were going to be, but we asked Luke not to make the built-in mechanisms plugins). That pattern is a little difficult to address because each plugin exports 40-odd gss_* functions, but we could put off addressing it, and probably should if there's no way to test the outcome. From: To: Time: Thu Jun 4 20:55:18 2009 For the other types of plugins, static library and plugin support would break down into (1) somehow renaming the function table so that it's not the same for each plugin; (2) somehow replacing the result of krb5int_get_plugin_dir_data with a list defined in the calling module; (3) reintroducing support for building ordinarily shared libraries as static libraries when requested; (4) linking the appropriate modules against the appropriate types of plugins (libkdb against KDB plugins, for instance); (5) possibly going to extra effort to deal with circular references. From: To: Time: Thu Jun 4 20:55:47 2009 All properly conditionalized, of course. From: To: Time: Thu Jun 4 20:56:37 2009 It's conceivably necessary to stub out the dlopen/dlsym calls in libkrb5support when building statically, but I think they can stay (and just not find anything). From: To: Time: Thu Jun 4 21:00:10 2009 Sounds about right. If you want to get fancy, maybe make the renaming and list handling nice and pretty and somewhat automatic... maybe each $srcdir/plugins subdir can automatically generate its own plugin-list data structure and an all-encompassing static library to link against. From: To: Time: Fri Jun 5 00:14:23 2009 (looking a little further back in the logs...) Yeah, I've forgotten just how the shared/static stuff worked exactly, but remember it's always been a mess. It used to use hacks in the per-directory configure scripts to force some directories to build static libraries for some things, but in order to switch to one configure script for the whole tree (never quite finished because of the ever-pending removal of the appl tree), it had to be moved to the makefiles. I think the Makefile.in for a static-only library pulls in an extra (or different) makefile fragment that alters some behavior of the general library support (which defaults to installable shared libraries). From: To: Time: Fri Jun 5 00:15:50 2009 Bringing back static library capability -- at least, if you want to be able to build both in one tree -- means addressing the AIX issue. We changed suffixes and build procedures a while back, but email on the mailing lists now and then suggests to me that it may have been a mistake and the old process might've been more correct for a normal AIX environment. Or, you could punt on AIX support for building both types of libraries. From: To: Time: Fri Jun 5 00:17:33 2009 It sounded like Miguel Sanders was willing to help out with debugging the AIX setup, per his kerberos@mit email from the 15th. From: To: Time: Fri Jun 5 00:23:50 2009 With my background, I have to wonder, though, if fixing gprof to deal with shared libraries would be that tough. Might be tougher in the short term, but the benefits reach wider, and unless you're planning to support installation and use of static krb5 libraries, the makefile hacks for testing would get ugly. From: To: Time: Fri Jun 5 00:25:01 2009 There probably are good use cases for static libraries -- more portable application binaries to systems without Kerberos, certain embedded scenarios. Question is, do people actually want it badly enough? From: To: Time: Fri Jun 5 00:25:49 2009 And, thinking back to JHutz's comments on one of my recent changes to testing code, wouldn't we want to test the code we expect people to actually run -- i.e., the shared libraries? From: To: Time: Fri Jun 5 00:36:39 2009 My thought was that we would build either shared or static libraries, not both, and there would be no particular consideration for installing a static build; it's just for the special cases where you need instrumentation tools like gcov to work. From: To: Time: Fri Jun 5 00:37:18 2009 If you can make all the nifty gcc -f options work just as well with shared libraries as without, great; but this is about the third case where I've found some neat gcc trick we can't use. From: To: Time: Fri Jun 5 00:37:26 2009 So, a special build to do code coverage testing, separate from the builds you can install and use? From: To: Time: Fri Jun 5 00:38:00 2009 Yeah. Just like I use a --disable-rpath build for my test suite runs, but wouldn't want to install it into the prefix and use it from there. From: To: Time: Fri Jun 5 00:39:26 2009 Oh, I'm pretty sure there's some reason gcov isn't going to work well for shared libraries as is. But my guess is it's something that could be fixed, possibly needing a file format change and other support. That would be annoying, but my guess (without having investigated, so don't put too much stock in it :-) is it's probably not too hard to figure out. From: To: Time: Fri Jun 5 00:40:05 2009 A separate build sounds okay. I guess I was imagining it as part of the normal test suite, where those sorts of changes wouldn't really fit. From: To: Time: Fri Jun 5 00:45:08 2009 Yeah. The goal here is to be able to measure the code coverage of the test suite, which doesn't have to be a common operation, but does need to be repeatable occasionally. From: To: Time: Fri Jun 5 00:46:32 2009 A reason this comes up is that if we separate the application tests out into the krb5-appl package, we lose some amount of coverage in the krb5 test suite. If we know how much and what it is, perhaps we can easily make up for that with other tests. But without a way to measure test suite coverage, we'd be mostly guessing at the damage. From: To: Time: Fri Jun 5 00:47:10 2009 Very true. And a bit worrying... I'm glad you're tackling this. From: To: Time: Fri Jun 5 13:42:15 2009 It's a little weird (though convenient for me at the moment) that r19265 stopped using the configure-defined values of LIBLINKS and LIBLIST in pre.in but didn't stop defining them in aclocal.m4. From: To: Time: Fri Jun 5 13:44:48 2009 Also, the comment "# Some of these should really move to pre.in, since [...]" is amusing since it lives in pre.in. From: To: Time: Fri Jun 5 13:48:58 2009 pre.in should probably be broken into smaller pieces From: To: Time: Fri Jun 5 13:56:30 2009 Interesting; libkdb now depends on libgssrpc. From: To: Time: Fri Jun 5 13:57:12 2009 probably due to iprop From: To: Time: Fri Jun 5 13:57:20 2009 wait, how is that not circular From: To: Time: Fri Jun 5 13:57:50 2009 Yes, due to iprop. It's not circular because libgssrpc's dependencies don't need kdb. From: To: Time: Fri Jun 5 13:58:19 2009 Although kpropd specifies the wrong order when linking, apparently. (You don't notice in most environments.) From: To: Time: Fri Jun 5 13:58:46 2009 unless you are using a linker that only makes a single pass over archive libraries? From: To: Time: Fri Jun 5 14:00:21 2009 I believe ELF shared library linking masks ordering problems. Static library linking tends to reveal them, as does shared library linking in certain environments. OSX comes to mind, although presumably 1.7 builds fine on OSX so I must be wrong about something. From: To: Time: Fri Jun 5 14:05:23 2009 OSX shared library issues do exist but i thought that library ordering wasn't necessarily one. From: To: Time: Fri Jun 5 14:09:22 2009 I remember that Subversion would occasionally create circular dependencies between libraries and it would work on most platforms but not OSX. Maybe circular dependencies are a problem but not library ordering. From: To: Time: Fri Jun 5 16:11:24 2009 Plugins would be a little simpler if we had chosen to name them (for example) libdb2.so instead of db2.so, but I wouldn't want to change that now. From: To: Time: Fri Jun 5 16:12:01 2009 there is precedent for the names without the "lib" prefix, right? From: To: Time: Fri Jun 5 16:12:51 2009 I don't know what other projects do. As far as I know you can call the file whatever you want, since you're just passing the filename to dlopen(). From: To: Time: Fri Jun 5 16:15:02 2009 i was thinking of interfaces like nss and pam From: To: Time: Fri Jun 5 16:19:34 2009 On Hardy, PAM uses names like pam_unix.so, while nsswitch uses names like libnss_dns.so. So, precedent both ways. From: To: Time: Fri Jun 5 16:20:34 2009 (I'm not saying there was any global design principal which would favor libdb2.so over db2.so; it would just make it easier to choose between the dynamic and static names when creating plugin libraries.) From: To: Time: Sun Jun 7 02:02:51 2009 This room is not anonymous. From: To: Time: Sun Jun 7 16:34:10 2009 More support for the great reindent: Ezra just reindented a section of code "according to the krb5 c-style" but was apparently using 4-space tabs in his editor. From: To: Time: Mon Jun 8 13:01:38 2009 r17612 stubbed out the library locking functions in kdb5.c, in favor of assuming DB plugins are thread-safe. Is there any reason I shouldn't remove all of the calls? It would make kdb5.c noticeably smaller. From: To: Time: Mon Jun 8 13:02:19 2009 this is for the libkdb layer locking that has historically been implemented with a "lock file"? From: To: Time: Mon Jun 8 13:03:42 2009 No, it was a mutex ensuring that the DB plugin was only entered by one thread. From: To: Time: Mon Jun 8 13:04:07 2009 is the assumption that the DB backends are thread-safe valid? From: To: Time: Mon Jun 8 13:04:51 2009 I believe so. In the DB2 plugin, we added a mutex to ensure that the BDB library was only entered by one thread, and I believe the LDAP plugin was written with thread safety in mind. From: To: Time: Wed Jun 10 15:59:27 2009 I mean, there's a known issue that we've turned some example programs into test programs and they don't do a great job of pulling double duty, but that's out of scope for application unbundling. From: To: Time: Wed Jun 10 16:00:24 2009 Trying again hopefully now with subs: are we keeping or ejecting appl/gss-sample? From: To: Time: Wed Jun 10 16:00:44 2009 Keeping. From: To: Time: Wed Jun 10 16:02:44 2009 Ok, as I just sent in mail that's probably an easy issue to much of your test coverage From: To: Time: Wed Jun 10 16:03:02 2009 Yeah, that should be pretty easy. From: To: Time: Wed Jun 10 16:03:12 2009 gss sample/test apps could easily be modified to test credential forwarding, etc.? From: To: Time: Wed Jun 10 16:03:42 2009 I believe Sam is saying that they already do, and we just need to call them with the right flags. From: To: Time: Wed Jun 10 16:03:48 2009 ah ok From: To: Time: Wed Jun 10 16:03:48 2009 I think more like test scripts could be modified to include command line options to actually do this. From: To: Time: Wed Jun 10 16:04:30 2009 Now it's been a while since I looked at all the options there. And I may be wrong. From: To: Time: Wed Jun 10 16:08:54 2009 Hm, adding -d to gss-client gets me krb5_auth_con_getkey and krb5_fwd_tgt_creds but not the others. From: To: Time: Wed Jun 10 16:11:27 2009 This is pretty awesome. Without pulling up gdb, just looking at fwd_tgt.c.gcov, I can see that it's getting an error from krb5_get_cred_via_tkt and bailing out before krb5_mk_1cred. From: To: Time: Wed Jun 10 16:12:08 2009 fascinating. were the tickets not forwardable? From: To: Time: Wed Jun 10 16:13:12 2009 That's my guess. From: To: Time: Wed Jun 10 16:18:39 2009 Does gcc completely fail if you use the appropriate options on something going into a shared library? I really think something like that would help with the mozilla negotiate performance issue From: To: Time: Wed Jun 10 16:27:07 2009 Everything works fine until you try to run gcov, at which point you find that the .gcda files were named foo.so.gcda instead of foo.gcda and gcov won't find them. From: To: Time: Wed Jun 10 16:27:42 2009 (Which I assume is just a surface-level problem hiding an iceberg of relative-address pain.) From: To: Time: Wed Jun 10 16:30:54 2009 Okay, changing gssapi.exp to use kinit -f and gss-client -d gets me coverage back in the client-side ticket forwarding functions, but the server doesn't appear to process them. From: To: Time: Wed Jun 10 16:31:40 2009 The server doesn't call krb5_rd_cred at least? Surprising. From: To: Time: Wed Jun 10 16:32:37 2009 Does gss_accept_sec_context need a flag to receive forwarded credentials? From: To: Time: Wed Jun 10 16:33:06 2009 No From: To: Time: Wed Jun 10 16:38:01 2009 It doesn't do much with them but it does verify and decrypt them. It does not write them out to a file From: To: Time: Wed Jun 10 16:38:41 2009 I'm not sure why, but the conditional which would cause rd_and_store_for_creds to be called isn't triggering. I'll do a run by hand in gdb. From: To: Time: Wed Jun 10 17:07:22 2009 The conditional triggers and rd_and_store_for_creds is called in my hand test. So I don't know why gcov isn't showing it being invoked in the test case. AFK a while, though. From: To: Time: Thu Jun 11 13:35:50 2009 Huh, I think gss-server as run from gssapi.exp simply isn't being instrumented. (There's no appl/gss-sample/gss-server.gcda.) I wonder if it gets built funny. From: To: Time: Thu Jun 11 13:50:56 2009 Aha. Coverage data is written out when a program exits. gss-server as run by the test suite runs until killed, and data is not written in that case. From: To: Time: Thu Jun 11 13:50:56 2009 as in when the program calls exit()? From: To: Time: Thu Jun 11 13:50:56 2009 Yeah. From: To: Time: Thu Jun 11 13:51:26 2009 i think the purify suite programs have similar problems. one way to work around it is to make a signal handler that exits the program in a clean way. From: To: Time: Sun Jun 14 02:03:02 2009 This room is not anonymous. From: To: Time: Mon Jun 15 15:34:15 2009 Hrm. "NEEDED" and "REQUIRED" do have slightly different connotations; to me, "NEED" implies inability to proceed, while "REQUIRED (of you)" suggests unwillingness. From: To: Time: Mon Jun 15 15:34:57 2009 But I'll not comment on the list because I'm not taking a position on Greg's comment. From: To: Time: Mon Jun 15 15:35:03 2009 in the context of formal dependencies, they are identical, aren't they? From: To: Time: Mon Jun 15 15:35:16 2009 (and this chat room is logged, but whatever) From: To: Time: Mon Jun 15 15:40:18 2009 (I don't mind if it's logged; I just want to be able to have a semi-idle conversation) From: To: Time: Mon Jun 15 15:42:19 2009 Sorry that I missed Greg's comments. Or rather received them and failed to deal. I think the only one I'd like to push back on is the name of encrypted challenge From: To: Time: Mon Jun 15 15:42:26 2009 Hm. Maybe, but we're talking about a protocol message here. In the case of PREAUTH_REQUIRED, there is nothing in the protocol that requires preauth at that point; it's a policy of one of the participants. Whereas MORE_PREAUTH_NEEDED is sent due to a protocol requirement. From: To: Time: Mon Jun 15 15:43:21 2009 I can see the needed/required distinction there, though it's fine. From: To: Time: Mon Jun 15 15:43:59 2009 i will probably reiterate my request for a more uniform naming of protocol constants (C preprocessor style vs ASN.1 style etc.) From: To: Time: Mon Jun 15 15:44:08 2009 Sam: that doesn't surprise me From: To: Time: Mon Jun 15 15:44:11 2009 It's quite possible that "encrypted challenge" makes perfect sense in a certain mindset. I'd just like to know what that mindset is. From: To: Time: Mon Jun 15 15:45:31 2009 we already have something called "encrypted timestamp" that does something different. From: To: Time: Mon Jun 15 15:45:50 2009 yes, it's a fine distinction From: To: Time: Mon Jun 15 15:47:33 2009 The mindset is roughly that Larry came up with something called authenticated timestamp. It didn't really make sense, so I replaced it. It was encrypted, and while it used a timestamp, it didn't matter that the time stamp was related to current time particularly so I wanted to lose timestamp from the name. From: To: Time: Mon Jun 15 15:48:04 2009 And we had a naming conversation somewhere--perhaps -c shadow and encrypted challenge was the best of a bad set of names. From: To: Time: Mon Jun 15 15:49:38 2009 "combined-key authenticator" :-) From: To: Time: Mon Jun 15 15:49:45 2009 Tom, was there any support for your consistent naming proposal? I know I pushed back on it--did anyone speak in favor? From: To: Time: Mon Jun 15 15:50:29 2009 your message to the mailing list only indicated you preferred whatever made the least work for you. there was a "+1" from Henry Hotz. From: To: Time: Mon Jun 15 15:55:10 2009 Mentally I sort of think of encrypted challenge as a challenge/response authentication where the client has a good optimistic guess of the challenge. Admittedly I've not yet actually added support to the MIT code for the client recovering from getting the time wrong. From: To: Time: Mon Jun 15 16:00:08 2009 I was unable to find the naming conversation in chat logs, which might indicate it took place here before I started subscribing, or on a mailing list. From: To: Time: Mon Jun 15 16:01:05 2009 naming of which? From: To: Time: Mon Jun 15 16:02:11 2009 encrypted challenge From: To: Time: Mon Jun 15 16:02:36 2009 i don't remember seeing such a conversation but it's probably not a big deal. From: To: Time: Mon Jun 15 16:08:42 2009 Greg, I'd definitely think it took place before you started subscribing. I'd guess months prior to Dublin IETF From: To: Time: Mon Jun 15 16:12:34 2009 You're talking to Jeff, not to Greg. From: To: Time: Sun Jun 21 02:02:56 2009 This room is not anonymous. From: To: Time: Mon Jun 22 13:33:15 2009 Any reason I shouldn't express support for full tagging in the OTP draft? I think it would be much harder to implement in our code base without. From: To: Time: Mon Jun 22 13:36:01 2009 I guess now isn't the most productive time to ask. From: To: Time: Mon Jun 22 17:18:14 2009 i was going to write something like that (full tagging in OTP) From: To: Time: Wed Jun 24 11:53:34 2009 re our dev meeting discussion, putting an unknown c-file-style setting in an emacs mode line appears to cause an error, but not one that causes catastrophic failure of cc-mode. From: To: Time: Wed Jun 24 11:58:56 2009 I think it would be pretty annoying for casual emacs users to load up our source files and get an error; I'd prefer the c-basic-offset version. The Subversion project has a hook which looks for "svn" in the filename and sets their style if it's present; we could do something similar with "krb5". From: To: Time: Wed Jun 24 12:00:47 2009 in the filename, or somewhere in the directory names in the path to the file? From: To: Time: Wed Jun 24 12:01:31 2009 I meant to say the file path. From: To: Time: Wed Jun 24 12:01:47 2009 Obviously if you call your checkout directory "trunk" or something then it won't work. From: To: Time: Wed Jun 24 12:02:35 2009 we could look for files we think are very likely to be present. From: To: Time: Wed Jun 24 13:16:00 2009 re ticket #6428, does anyone know why the key expiration check precedes the principal expiration check? i am wondering if we had a good reason for doing it that way. From: To: Time: Wed Jun 24 13:33:20 2009 I'll look in a moment. From: To: Time: Wed Jun 24 13:33:29 2009 (Though I probably don't know anything relevant.) From: To: Time: Wed Jun 24 13:54:30 2009 ok. i was composing a message to ask krbdev about it. not sure i'll bother to send it. From: To: Time: Wed Jun 24 14:03:32 2009 Interesting response from Nico on crypto modularity. I don't fully understand the implications. From: To: Time: Wed Jun 24 14:16:32 2009 yeah, looking into that, and rereading parts of FIPS 140-2 as well. From: To: Time: Sun Jun 28 02:03:08 2009 This room is not anonymous. From: To: Time: Sun Jun 28 19:00:00 2009 Is splitting off the applications not still part of The Plan? Neither the Roadmap nor the 1.8 page on the wiki mention it. Or is it just not an important goal? From: To: Time: Sun Jun 28 19:23:34 2009 I've been working on it. It's kind of a housekeeping thing. From: To: Time: Sun Jun 28 19:45:25 2009 So, not specifically planned as part of any particular release? Okay... From: To: Time: Mon Jun 29 12:31:59 2009 oh cool. i can reliably crash Emacs.app from recent GNU Emacs CVS. From: To: Time: Mon Jun 29 13:06:11 2009 Do we think the Mac build goo is relevant to the applications? (The Windows build goo almost certainly isn't.) From: To: Time: Mon Jun 29 13:06:27 2009 which Mac build goo? From: To: Time: Mon Jun 29 13:07:22 2009 In pre.in and post.in, stuff like generate-files-mac-recurse. From: To: Time: Mon Jun 29 13:09:18 2009 those were there to allow a separate pass over the tree to generate all the generated source files. From: To: Time: Mon Jun 29 13:33:25 2009 LD_UNRESOLVED_PREFIX and LD_SHLIBDIR_PREFIX look like vestiges of a bygone era? From: To: Time: Mon Jun 29 13:35:10 2009 Also LDARGS and DEPLIBS (with no prefix). From: To: Time: Mon Jun 29 13:35:42 2009 not sure. where are you seeing those? From: To: Time: Mon Jun 29 13:35:58 2009 pre.in From: To: Time: Mon Jun 29 13:39:10 2009 they might have once been specified explicitly in each directory's Makefile.in but got separate variable names once the configure scripts got consolidated. i didn't look too closely at the configure script consolidation, so might have missed some things there. From: To: Time: Mon Jun 29 13:48:30 2009 sorry, my previous message was in relation to DEPLIBS. haven't investigated the others in detail From: To: Time: Mon Jun 29 13:50:19 2009 It's not important. I may clean them up after further verifying that they aren't used. From: To: Time: Mon Jun 29 13:51:09 2009 ok. at some point in our copious free time we should see whether GNU libtool remains unsuited for our use cases. From: To: Time: Mon Jun 29 13:52:29 2009 I was musing recently about how poor a fit autoconf is for the current world, and wondering how hard it would be to convert to scons (which is what Google Chrome uses). But it doesn't seem like a great use of our time. From: To: Time: Mon Jun 29 13:53:35 2009 i like being able to build on platforms we've never heard of. not sure whether scons is better for that than autoconf. From: To: Time: Mon Jun 29 15:49:10 2009 Our dependency generation refuses to work with the system compile_et, and I can't immediately see why. Anyone know? (I was going to have krb5-appl always use an installed compile_et for libpty's error table... although it's tempting to just make libpty stop using com_err.) From: To: Time: Mon Jun 29 15:52:00 2009 i think it's because you want the correct dependencies generated for the in-tree com_err.h From: To: Time: Mon Jun 29 15:52:22 2009 it probably doesn't place a restriction on normal building, just on developers running "make depend" From: To: Time: Mon Jun 29 15:54:28 2009 Oh, definitely. But there has to be a way to "make depend" for krb5-appl. If the problem is with com_err.h then I can just remove the restriction. From: To: Time: Mon Jun 29 15:55:14 2009 if we're ejecting krb5-appl, and not including a com_err, then indeed it makes little sense to preserve that piece of dependency generation. From: To: Time: Mon Jun 29 16:15:32 2009 That's odd; why does krlogind use daemon() but not any other program under appl? From: To: Time: Mon Jun 29 16:17:35 2009 standalone capability (to work without inetd) From: To: Time: Mon Jun 29 16:17:45 2009 not sure it works very well. From: To: Time: Mon Jun 29 16:18:04 2009 But why only krlogind and not, say, krshd or telnetd? From: To: Time: Mon Jun 29 16:19:29 2009 This comes up because we ensure the existence of daemon through libapputil, which is used by other parts of the krb5 tree but not installed. Pretty easy to deal with, but it's weird that it only comes up in one of the four daemons. From: To: Time: Mon Jun 29 16:34:23 2009 hm. i think because at the time we decided it made the most sense, as the only one of those that has reasonable encryption. From: To: Time: Mon Jun 29 16:47:11 2009 Yes, getting com_err.h is the only reason ... similarly for some other configure options that get checked. For the appl-only tree you can safely remove that check (and probably at least some others). From: To: Time: Mon Jun 29 17:44:10 2009 Tom, did you report the Emacs bug? From: To: Time: Mon Jun 29 17:44:48 2009 i had someone on #emacs verify it for me on an unadulterated HEAD source and they reported it. From: To: Time: Mon Jun 29 17:45:03 2009 http://lists.gnu.org/archive/html/bug-gnu-emacs/2009-06/msg00680.html From: To: Time: Mon Jun 29 17:45:17 2009 Excellent, thanks... From: To: Time: Mon Jun 29 17:46:52 2009 i forget -- are you an emacs developer? From: To: Time: Mon Jun 29 17:50:18 2009 Well, I'm on the devel list, but not really actively contributing towards the release of 23 at the moment. I've been working on sort of a side project, adding Guile (Scheme) support... From: To: Time: Mon Jun 29 17:51:04 2009 (And I've got checkin access, just not much to check in lately.) From: To: Time: Mon Jun 29 17:51:30 2009 So, maybe a mostly-inactive "developer"? From: To: Time: Mon Jun 29 17:52:17 2009 but if you feel like chasing down that bug, there is some indication that it has to do with the nil :style on a :box face attribute (which mode-line-inactive has and the crash doesn't happen if you either delete :box from that face or set :style to something valid) From: To: Time: Mon Jun 29 17:52:17 2009 Sadly, not very familiar with the Cocoa support bits, so I mostly wind up just filing bugs I find. From: To: Time: Mon Jun 29 17:52:36 2009 i think it's actually a general problem not limited to Cocoa but i'm not certain. From: To: Time: Mon Jun 29 17:54:12 2009 I know there's been some per-window-system face and font work done lately, as well as generic. But that's an area of the C code I haven't dug into. Can you reproduce it under X11? From: To: Time: Mon Jun 29 17:54:35 2009 i haven't bothered to build CVS Emacs with X11 From: To: Time: Mon Jun 29 17:54:45 2009 Oh, wait, I might have an x11 build around, not too terribly hacked... From: To: Time: Mon Jun 29 17:55:09 2009 i've already spent enough time debugging pkgsrc, etc. recently From: To: Time: Mon Jun 29 17:55:28 2009 i am impressed that pkgsrc works as well as it does on Mac OS From: To: Time: Mon Jun 29 18:03:14 2009 I'm building an x11 version now. From: To: Time: Mon Jun 29 18:04:34 2009 On another matter, are you familiar with how git deals with tracking upstream repositories? I know you were using it with krb5... From: To: Time: Mon Jun 29 18:05:08 2009 tracking upstream repositories is different depending on whether you're using git or svn or something as an upstream. From: To: Time: Mon Jun 29 18:09:54 2009 Yeah, that's part of what I'm concerned about... I want to track the Emacs sources, for which there's currently a git mirror of the cvs repository. However, at some (unspecified but probably near) point, they're going to switch to bzr. I don't know if they'll still have a git mirror, or if it'd look like one continuous history or have some strange discontinuity because of the conversion (e.g., a freshly generated git mirror that has different hash values because of some subtle difference). I've read there are tools for mirroring a local bzr copy into git, so I could do it myself after the switch, if the FSF doesn't maintain a mirror. But I've no idea if I can make the switch from cvs-mirror-git as the upstream to bzr-mirror-git as the upstream without breaking things.... From: To: Time: Mon Jun 29 18:16:21 2009 The emacs bug doesn't happen for me in x11. The stack trace also looks like it's in Mac-specific code. From: To: Time: Mon Jun 29 18:16:47 2009 Building a fresh Cocoa version... From: To: Time: Mon Jun 29 18:17:18 2009 it strongly resembles an older bug, though. From: To: Time: Mon Jun 29 18:18:40 2009 Perhaps the x11 version of the bug has already been fixed. From: To: Time: Mon Jun 29 18:19:11 2009 could be. From: To: Time: Mon Jun 29 18:33:23 2009 Yeah, this is buried in ns-specific code, and at first glance, it's not really parallel to the x11 code. Think I should probably leave it for someone familiar with that code, probably Adrian Robert or David Reitter, they've been doing ns-specific code hacking recently. *sigh* From: To: Time: Mon Jun 29 21:44:02 2009 http://www.mail-archive.com/emacs-pretest-bug@gnu.org/msg12001.html is the similar bug in x11/xft code From: To: Time: Tue Jun 30 04:43:01 2009 What's the "test suite" page's list of software actually documenting? I would've assumed just tools needed beyond those for building. As far as I recall, bison is only needed for maintainer-mode when building (and changing certain files), but ought not to be needed beyond that for testing. I wonder about libtool and libltd13-dev too; AFAIK we're not using libtool... From: To: Time: Tue Jun 30 08:43:51 2009 I think there are files for which we need to run bison or byacc during a non-maintainer build. But the deltat parser in the krb5 library is the only one needing to be thread-safe and thus processed with bison. Which is the reason it should be rebuilt only in maintainer mode -- so bison isn't required and byacc is generally sufficient. From: To: Time: Tue Jun 30 11:17:56 2009 i think we will want to split off some of the build-specific stuff to another page From: To: Time: Tue Jun 30 14:56:47 2009 oh, now i remember why i wanted the deps to be in a hidden file: filename completion. From: To: Time: Wed Jul 1 12:34:52 2009 Why do we have top_srcdir and also SRCTOP? From: To: Time: Wed Jul 1 12:35:18 2009 I guess top_srcdir is where the configure.in lived? From: To: Time: Wed Jul 1 16:01:18 2009 Yes, top_srcdir is an autoconf thing, and thus per configure script. It's equivalent to SRCTOP only outside of the appl tree. From: To: Time: Thu Jul 2 10:04:48 2009 Ken, I have a question the next time you're around. From: To: Time: Thu Jul 2 10:30:29 2009 Well, I'll go ahead and ask it in case I'm not around then. I'm discovering evidence that parts of the severable application stuff might be built in KfW--specifically the gssftp client, so far. Can you comment on how much of appl was pulled into KfW builds, if you remember? From: To: Time: Thu Jul 2 16:07:42 2009 The windows build is driven from the all-windows target in src/Makefile.in, plus some external stuff from pismere (like krb4 unless that's been fixed). From our appl tree, it looks like only gss-sample and the ftp client are built. I don't think anything else was likely to have been built for Windows. From: To: Time: Thu Jul 2 16:08:24 2009 ...where the "fix" for the build quirk of getting krb4 from pismere is deleting krb4. :-) From: To: Time: Thu Jul 2 16:08:28 2009 New attack on AES: http://www.schneier.com/blog/archives/2009/07/new_attack_on_a.html From: To: Time: Thu Jul 2 16:09:19 2009 Well, and patching up the rest of the tree to cope. Like, the Windows version of kinit may need fixing to not try to to krb4, etc. From: To: Time: Thu Jul 2 16:09:22 2009 Yeah, that might be a motivation to think about (say) Camellia if we specify a new enctype. From: To: Time: Thu Jul 2 16:09:37 2009 Is anyone trying to do Windows builds these days? From: To: Time: Thu Jul 2 16:09:50 2009 we have a student working on Windows builds. From: To: Time: Thu Jul 2 16:10:17 2009 rsilk is doing a couple of KfW projects, one updating KfW 3.2 (based on 1.6) and one creating KfW 4 (based on 1.7). The appl unbundling isn't a problem for either, but it does have implications for whatever KfW is based on 1.8. From: To: Time: Thu Jul 2 16:10:33 2009 Yeah, but it's still upwards of 2**110 work for AES-256, so no rush right now. From: To: Time: Thu Jul 2 16:10:49 2009 In other news, MD6 is withdrawn from the SHA-3 competition. From: To: Time: Thu Jul 2 16:11:29 2009 http://www.schneier.com/blog/archives/2009/07/md6.html From: To: Time: Thu Jul 2 16:13:45 2009 Well, I'll make a note that unbundling the applications will make it kind of inconvenient to include gssftp in future-KfW-based-on-1.8. It may be easiest to just drop it. From: To: Time: Thu Jul 2 16:14:36 2009 i saw something come over the ietf apps-discuss list about possibly reviving a FTP working group or similar effort, i think from someone involved with wu-ftpd. From: To: Time: Thu Jul 2 16:47:10 2009 There was something I was thinking of doing recently that I decided against because it would risk breaking the Windows build and I had no way of testing it, and didn't think anyone else would for a long time, so I punted. I forget which thing it was though... From: To: Time: Thu Jul 2 16:54:53 2009 Possibly merging ccapi/*.[ch] into one cc_api.c like the other ccache back ends. Or testing some gmake stuff. Hm. Whatever. From: To: Time: Thu Jul 2 17:32:55 2009 When people in krb-wg have suggested using an AEAD mode enctype, they generally mention CCM and GCM as options. Is there a reason those are preferred to EAX? (I have no stake in this; I'm just doing a little light reading.) From: To: Time: Thu Jul 2 17:45:56 2009 I don't recall specifically. I think the ability to run operations in parallel sometimes figures into it, though I doubt that's a big deal for Kerberos as much as for, say, IPsec. The appeal for IPsec would also make it more likely that there will be good software or hardware implementations out there, which may be something we can build on. (Similarly for using the same basic cipher as everyone else wants to use. Intel's added an instruction in some of their recent x86-family processors for executing part of the AES inner loop in one shot.) From: To: Time: Thu Jul 2 17:49:48 2009 I think that argues for GCM but not CCM. From: To: Time: Thu Jul 2 17:53:08 2009 I think there's also some argument to be made for a construction based on one block cipher rather than one block cipher plus one hash function. If the mode is good, you're relying on the strength of one primitive rather than two. From: To: Time: Thu Jul 2 17:57:40 2009 Hmm, in looking up CCM, I'm finding references to a CCM* which "adds encryption- and integrity-only features to CCM", though I would've thought those would simply be useable degenerate modes of full CCM. Maybe I'm remembering wrong. It's certainly possible that an AEAD mode might be designed that wouldn't be very safe in integrity-only mode, though it would be very poor if encrypt-only mode weren't safe. From: To: Time: Thu Jul 2 17:59:11 2009 www.ipcores.com has a chip that implements CCM* From: To: Time: Thu Jul 2 18:13:44 2009 Ah, CCM* is specified in 802.15.4-2006, and allows *unauthenticated* encryption and variable-length authentication tags. They also add support for integrity-only protection, but (without going back and looking) I would've thought that would've been built into basic CCM... From: To: Time: Thu Jul 2 18:14:47 2009 EAX depends only on a cipher, not on a hash algorithm. From: To: Time: Thu Jul 2 18:15:31 2009 Yeah, GCM is the one depending on a second algorithm. From: To: Time: Thu Jul 2 18:15:41 2009 I think. From: To: Time: Thu Jul 2 18:16:19 2009 Ah, right, integrity protection uses Galois field multiplication. From: To: Time: Thu Jul 2 18:17:53 2009 There's supposedly another AEAD mode called IAPM but wikipedia doesn't know about it. (And OCB, but it's patented.) From: To: Time: Thu Jul 2 18:18:13 2009 I think I've seen IAPM before too, but I don't remember the details. From: To: Time: Thu Jul 2 18:20:28 2009 Oh, the answer is pretty simple: NIST has approved CCM and GCM but not EAX. From: To: Time: Thu Jul 2 18:21:09 2009 Ah. From: To: Time: Thu Jul 2 18:22:05 2009 I found my downloaded copy of the paper describing IACBC and IAPM. (I think it was an AES contest contribution.) It mentions that IBM has filed for patents. From: To: Time: Thu Jul 2 18:27:52 2009 Both CCM and GCM seem to let you run the encryptions in parallel, but generating the authentication tag seems to be a fully serial operation for both. So it's still O(n) time no matter how much hardware you can throw at it. From: To: Time: Thu Jul 2 18:29:07 2009 "The key feature is that the Galois field multiplication used for authentication can be easily computed in parallel thus permitting higher throughput than the authentication algorithms that use chaining modes, like CBC." From: To: Time: Thu Jul 2 18:33:03 2009 I had thought that was the case. But looking at the description in wikipedia, it looks like the ...oh. Maybe associativity and distributivity let you win. From: To: Time: Thu Jul 2 18:46:43 2009 Something to consider at is the risk of reuse of an IV. We pick them randomly so we don't guarantee non-reuse, it's just of low probability. Which may be enough. But the level of resulting badness should be considered, and may not be the same for different algorithms. From: To: Time: Thu Jul 2 20:30:58 2009 if you look at the public comments on the NIST evaluation of GCM, the allegedly disproportionate risks of IV reuse in GCM were the primary objections. it's basically the same reason that people tend to be suspicious of stream ciphers. From: To: Time: Sun Jul 5 02:02:52 2009 This room is not anonymous. From: To: Time: Mon Jul 6 11:22:24 2009 RT fell over again. i kicked it. From: To: Time: Mon Jul 6 11:35:42 2009 upgrade postgresql for good measure From: To: Time: Wed Jul 8 12:41:16 2009 winsnap is on krbwrite. Is that still desirable? From: To: Time: Wed Jul 8 14:54:58 2009 ok, postgres crashed again. i restarted apache. the offending query appears to run just fine when pasted in to psql. not sure what's going on here. From: To: Time: Wed Jul 8 14:58:51 2009 Is the weird "to" line in RT email, which seems to have just started in the last few days or so, intentional? From: To: Time: Wed Jul 8 14:59:04 2009 how "weird" is it? From: To: Time: Wed Jul 8 14:59:18 2009 To: ;@MIT.EDU, ""@'AdminCc of krbdev.mit.edu Ticket #6525' From: To: Time: Wed Jul 8 14:59:45 2009 It looks kind of like the standard sendmail botching of RFC-compliant "list" syntax. From: To: Time: Wed Jul 8 15:00:08 2009 our mailhubs have always mangled them. that just looks like different mangling than usual. From: To: Time: Wed Jul 8 15:00:12 2009 Or maybe not standard, just MIT-config sendmail, not sure. But I think I've seen the like before. From: To: Time: Wed Jul 8 15:00:34 2009 i see To: ;@"'AdminCc of krbdev.mit.edu Ticket #6525'" From: To: Time: Wed Jul 8 15:01:14 2009 Hm, so not a change on our side? Oh, I wonder if it could be related to the spam-filtering change? Ah... also broken, but not the same as I'm seeing; even weirder... From: To: Time: Wed Jul 8 15:01:31 2009 what mailhub are you on? From: To: Time: Wed Jul 8 15:01:54 2009 You mean po server? 9. From: To: Time: Wed Jul 8 15:02:23 2009 you're getting it from po9.mit.edu... through POP or IMAP? From: To: Time: Wed Jul 8 15:02:37 2009 imap From: To: Time: Wed Jul 8 15:02:52 2009 IMAP may further mangle the headers. i'm not sure. From: To: Time: Wed Jul 8 15:03:14 2009 was that the raw header you pasted, or did your mail reader do stuff to it as well? From: To: Time: Wed Jul 8 15:03:20 2009 and, I'm using raeburn.mail.mit.edu, but that's po9.mail From: To: Time: Wed Jul 8 15:03:44 2009 That's what I see when asking my mail reader to show me raw headers. I haven't tried imtest. :) From: To: Time: Wed Jul 8 15:03:55 2009 Where/how are you reading your copy? From: To: Time: Wed Jul 8 15:04:13 2009 gnus, using POP to download. From: To: Time: Wed Jul 8 15:05:33 2009 Did you see any change? Either recently (it changed for me between 26 Jun and yesterday morning), or when you might've explicitly opted in to the new spam processing system, if you did? From: To: Time: Wed Jul 8 15:06:23 2009 i saw no changes. From: To: Time: Wed Jul 8 15:08:04 2009 So it's been broken for you all along, and I've been seeing ... oh! The email I'm looking at on the 26th shows no "to" header in processed form, but the raw header shows the form you describe: To: ;@"'AdminCc of krbdev.mit.edu Ticket #5916'" From: To: Time: Wed Jul 8 15:08:55 2009 oddly enough, the mailman archives omit the "To:" header. From: To: Time: Wed Jul 8 15:16:18 2009 The raw from headers get a bit ugly too, if the original name is quoted: From: "\"\" Kimmo R.M.Hovi \" via RT\"" though Apple Mail shows it as just "Kimmo R.M.Hovi via RT " (i.e., no quotes). From: To: Time: Wed Jul 8 15:16:44 2009 the quoting is buggy in places too From: To: Time: Wed Jul 8 15:16:57 2009 Looks like it's quoting when unnecessary, too: From: "Greg Hudson via RT" From: To: Time: Wed Jul 8 15:17:51 2009 full blown RFC 2822 address cracking is difficult From: To: Time: Wed Jul 8 15:18:54 2009 The reply-all function gets really unhappy with the "new" to: header; it wants to cc three bogus addresses, two of which are @'AdminCc of krbdev.mit.edu Ticket #6526' (with no local part). From: To: Time: Wed Jul 8 15:27:13 2009 I just checked with imtest. I am, in fact, getting back different "to" headers for the different messages. From: To: Time: Wed Jul 8 15:29:03 2009 oh. what messages? From: To: Time: Wed Jul 8 15:30:44 2009 The ones in particular that I'm looking at are the bug report from Kimmo R.M.Hovi today, and a comment from me on the 26th at 19:01. From: To: Time: Wed Jul 8 15:31:50 2009 Spot-checking a few earlier messages that were initial bug report filings shows the same "old" form of the "to" header. From: To: Time: Wed Jul 8 15:32:31 2009 they have the same form of "to" header in my mailbox. From: To: Time: Wed Jul 8 15:32:32 2009 (Though this time I'm checking in Mail; I'm assuming my test with imtest shows that it's not an IMAP server change affecting all messages and Mail cached some old data.) From: To: Time: Wed Jul 8 15:33:13 2009 Very strange. From: To: Time: Wed Jul 8 15:42:32 2009 And here's another strange one: If I use pop3test and fetch the email from today, it says: To: "'AdminCc of krbdev.mit.edu Ticket #6526'": ; From: To: Time: Wed Jul 8 15:43:15 2009 right, so there's very little way to tell which piece of broken software is doing the mangling. From: To: Time: Wed Jul 8 15:44:10 2009 I'd be curious to see what pop3test and imap show you, though... and I haven't tried webmail yet. :) From: To: Time: Wed Jul 8 15:48:19 2009 And POP shows me a broken header from the 26th: To: ;@"'AdminCc of krbdev.mit.edu Ticket #5916'" From: To: Time: Wed Jul 8 15:48:52 2009 i can't test easily on historical messages because i've already downloaded them. From: To: Time: Wed Jul 8 15:49:09 2009 so in GCM, how is GHASH any better than CRC? they look awfully similar in some ways. From: To: Time: Wed Jul 8 15:49:11 2009 True. From: To: Time: Wed Jul 8 15:54:32 2009 Not sure. It can be run in parallel mode, and might involve less hardware? I have no idea about the security properties offhand. From: To: Time: Wed Jul 8 16:02:17 2009 haven't yet figured out how it's parallelizable. From: To: Time: Wed Jul 8 16:02:59 2009 security-wise, CRC has issues because it's fairly easy to perform partial manipulations of the message and update the CRC accordingly, even if the entire message is not known, as i recall. From: To: Time: Wed Jul 8 16:09:49 2009 In GMAC you do "addition" and "multiplication" in the GF(2**128) field, and can regroup, for example, instead of multiplying by K and adding in the next value, run even and odd blocks in parallel and multiply by K*K, combining at the end. Or three or four sets in parallel, etc. From: To: Time: Wed Jul 8 16:32:01 2009 so CRC is computing the polynomial remainder treating the message bits as the coefficients of a long polynomial. in some sense, it is equivalent to repeated multiplication and addition operations in GF(2**n), just like GMAC. From: To: Time: Wed Jul 8 16:34:06 2009 well, ok, maybe not GF(2**n) if the generator is not irreducible, but i think for CRC it always is. From: To: Time: Wed Jul 8 16:38:27 2009 so probably the main benefit that GMAC gets you is that the hash subkey is repeatedly multiplied in. From: To: Time: Wed Jul 8 16:44:11 2009 What repo is Greg's latest checkin from? The email doesn't seem to distinguish and it's not the krb5 repository. From: To: Time: Wed Jul 8 16:44:54 2009 krb5-appl. How do we distinguish commits for kfm? Separate list? From: To: Time: Wed Jul 8 16:45:02 2009 separate list for kfm commits From: To: Time: Wed Jul 8 16:45:10 2009 we could make a krb5-appl-commits list From: To: Time: Wed Jul 8 16:45:24 2009 Or, do different subjects. From: To: Time: Wed Jul 8 16:46:02 2009 Maybe a separate list so that Lee can be on it. (And maybe not all of us want to be on it.) From: To: Time: Wed Jul 8 16:48:01 2009 Who is Lee? From: To: Time: Wed Jul 8 16:48:56 2009 Lee Hinman, one of Ken Hornstein's coworkers who will be helping out with application maintenance after the unbundling. From: To: Time: Wed Jul 8 16:49:04 2009 Huh, cvs-krb5 is a mailman list? From: To: Time: Wed Jul 8 16:49:25 2009 yes, it is From: To: Time: Wed Jul 8 16:49:26 2009 Ah, okay, good. From: To: Time: Wed Jul 8 16:49:48 2009 being a mailman list makes it easier for outside developers to manage their subscriptions From: To: Time: Wed Jul 8 16:58:10 2009 Request sent for krb5-appl-commits. From: To: Time: Wed Jul 8 17:02:41 2009 also pinged Garry et al. about transitioning the anonsvn.mit.edu service. From: To: Time: Thu Jul 9 11:33:53 2009 Huh, I didn't know that svn blame -x -w worked. From: To: Time: Thu Jul 9 14:14:14 2009 For the krb5-appl configure goo, I'm evaluating whether to keep AC_KRB5_TCL_TRYOLD or punt it, since it draws in KRB5_AC_FIND_DLOPEN. What are the ramifications of punting it? I think the biggest practical issue is if we can't find tcl on Athena Solaris any more. From: To: Time: Thu Jul 9 14:24:38 2009 I never really looked into whether the AC_KRB5_TCL_TRYOLD code actually wound up getting used usefully. It may be you can just toss it... From: To: Time: Thu Jul 9 14:27:21 2009 Huh. I wonder why we have that ugly F_SETOWN test instead of just doing #ifdef F_SETOWN. Maybe it's an enum somewhere? From: To: Time: Thu Jul 9 14:44:14 2009 the tcl locker on athena is so old that i stopped using it for building krb5 many years ago From: To: Time: Thu Jul 9 14:50:53 2009 Hm, maybe I don't need any of this tcl goo at all, if I'm just running runtest. From: To: Time: Thu Jul 9 14:52:50 2009 not for appl, no; mostly just the kadmin and profile tests use tcl libraries directly instead of just using expect. From: To: Time: Thu Jul 9 14:53:51 2009 Okay, that makes the appl aclocal.m4 about 25% shorter. From: To: Time: Thu Jul 9 14:58:21 2009 Why do we give CFLAGS to runtest? From: To: Time: Thu Jul 9 15:02:26 2009 we do? From: To: Time: Thu Jul 9 15:02:52 2009 Yeah, via DEJAFLAGS in pre.in. From: To: Time: Thu Jul 9 15:03:29 2009 That's CLFLAGS, not CFLAGS. From: To: Time: Thu Jul 9 15:03:46 2009 Oh. From: To: Time: Thu Jul 9 15:03:46 2009 Though offhand I don't know what CLFLAGS is. Local CFLAGS? From: To: Time: Thu Jul 9 15:04:10 2009 CLFLAGS appears nowhere else in the source tree. From: To: Time: Thu Jul 9 15:04:23 2009 (Neither does DEJALFLAGS.) From: To: Time: Thu Jul 9 15:05:17 2009 There's also DEJALFLAGS, also used there, and also not ... yeah. Someone was probably trying to pass local (per-directory) versions of DEJAFLAGS and CFLAGS and failing; dunno why. Looks like they can both be nuked. From: To: Time: Thu Jul 9 15:13:54 2009 I think I'm not going to include the priocntl hack stuff. From: To: Time: Thu Jul 9 15:15:46 2009 Remember to send me the call information for 3:30. From: To: Time: Thu Jul 9 15:16:19 2009 Wait, I have it, nevermind. From: To: Time: Thu Jul 9 18:04:53 2009 ok, i think i have found and quashed the leak that was allowing spammers to get our obfuscated internal address for krbdev's incoming RT mail address From: To: Time: Sun Jul 12 02:02:52 2009 This room is not anonymous. From: To: Time: Mon Jul 13 17:25:48 2009 the pre-commit hook i've been working on will not check to see if a file has tabs on unchanged lines if you change the indent-tabs-mode setting in the file local variables in the same commit. do we think this is good enough, or should we be really strict? From: To: Time: Mon Jul 13 17:26:13 2009 actually it will in general not check for whitespace problems on unchanged lines From: To: Time: Mon Jul 13 17:48:40 2009 ok, existing post-commit hook is very much like spaghetti. fortunately it still works at the moment. From: To: Time: Mon Jul 13 18:04:02 2009 installed and restricted to my users/tlyu directory for now. From: To: Time: Mon Jul 13 18:45:56 2009 I think we can trust people to untabify files when changing the indent-tabs-mode setting. From: To: Time: Mon Jul 13 21:58:41 2009 ok, now the whitespace hook will operate on all users/ directories. please test by making a directory under your users/ directory. From: To: Time: Wed Jul 15 11:39:50 2009 Huh. I think my last set of wiki edits made subst:project-vote incomprehensible, and I can't remember all the context. From: To: Time: Wed Jul 15 11:41:08 2009 Maybe it was incomprehensible before. From: To: Time: Wed Jul 15 12:44:48 2009 there is a change history... From: To: Time: Thu Jul 16 15:39:38 2009 ok, one of my elisp batch reindent hacks is running, but it's MUCH slower than gindent. From: To: Time: Thu Jul 16 16:18:25 2009 looks like it might need some manual cleanup too, but it's less invasive than gindent. From: To: Time: Thu Jul 16 22:30:01 2009 Wow, someone's trying to build the applications for Windows?? I didn't think they worked... well, I guess they *could*.... From: To: Time: Fri Jul 17 00:24:10 2009 Just the FTP client, I think. Probably rsilk. From: To: Time: Fri Jul 17 00:54:53 2009 Oh, weird... when I reconnected, the chat history I got appears not to have included my earlier message about Windows, but does have Tom's earlier messages about gindent. I'm not sure if that's from the server or from Adium's local logs (which do include my comment). From: To: Time: Fri Jul 17 00:56:03 2009 And on reconnecting again, my last message is missing again... From: To: Time: Fri Jul 17 00:56:35 2009 Oh... but my previous message is missing too. Maybe it's just my own messages? From: To: Time: Fri Jul 17 00:58:04 2009 And if I connect this way, I see them.... From: To: Time: Fri Jul 17 00:58:54 2009 Yep, looks like it's my messages that are missing, not just the last message generally. Grr. From: To: Time: Fri Jul 17 01:13:40 2009 Ah. It looks like the server is sending them, but Adium is filtering them out of the display for some reason. From: To: Time: Fri Jul 17 12:06:11 2009 KFW builds the FTP client out of appl/gssftp From: To: Time: Fri Jul 17 12:25:52 2009 krb5int_c_free_keyblock vs krb5_free_keyblock was probably an attempt to prevent circular dependencies. From: To: Time: Fri Jul 17 13:43:39 2009 suggestion: instead of krb5_ck_, how about krb5_k_? From: To: Time: Fri Jul 17 14:28:25 2009 Sure. From: To: Time: Sun Jul 19 02:02:50 2009 This room is not anonymous. From: To: Time: Mon Jul 20 11:44:21 2009 Do we think there are systems which supply asprintf and not the prototype for it? (I'm trying to unify and clean up how missing functions are handled in krb5-appl, and am looking at the k5-platform configure goo for asprintf. Right now we specifically handle the case where asprintf exists but is unprototyped.) From: To: Time: Mon Jul 20 12:24:47 2009 i have a vague recollection of this being the case in the past. certainly we've had this sort of OS behavior with other functions. From: To: Time: Mon Jul 20 12:43:00 2009 I think for krb5-appl we can take the approach of "just let the compiler spit out warnings" for cases like that, and eliminate all of the KRB5_NEED_PROTO goo. From: To: Time: Mon Jul 20 12:43:35 2009 hm, how about ABI issues on 64-bit platforms? From: To: Time: Mon Jul 20 13:16:07 2009 Conceivable, but 64-bit platforms tend to be tighter about their prototyping for exactly that reason. From: To: Time: Tue Jul 21 16:07:35 2009 all the MS references about the PAC that i can readily find expand it as Privilege Attribute Certificate. does anyone recall a reference to the alternative Privilege Access Certificate expansion? From: To: Time: Tue Jul 21 17:15:46 2009 hm. considering adding a "big red button" to the whitespace hook and just turning it on for everyone. From: To: Time: Wed Jul 22 09:43:39 2009 So, I'm thinking about enctype configuration--the 1.8 line item where we improve the way we do enctype configuration to allow modifying the default set without entirely replacing it. From: To: Time: Wed Jul 22 09:45:07 2009 One idea I had is to define enctype families (des, des3, rc4, aes) so that people don't have to enumerate all of the enctypes in a family to enable or disable them. But there are some ugly corner cases: +rc4 should probably not include rc4-hmac-exp but -rc4 should probably exclude it; and there is the question of whether a forthcoming aes-gcm would belong in the same family as the current aes-cts enctypes. From: To: Time: Wed Jul 22 10:53:17 2009 The -raw enctypes are for use by applications and you wouldn't want to use them in the actual protocol, right? Also, what is the story on des-hmac-sha1? It's not in the default permitted-enctypes list. From: To: Time: Wed Jul 22 13:43:55 2009 how does OpenSSL deal with this sort of configuration problem? and can we mirror their strategy without importing all of the complexity? From: To: Time: Wed Jul 22 17:46:48 2009 editing mail spool files directly is very ... something. From: To: Time: Fri Jul 24 11:37:47 2009 So, for randomly generating salts, it looks like I want to restrict them to printable ASCII characters, since it needs to fit in a KerberosString (IA5String). From: To: Time: Fri Jul 24 13:12:27 2009 yeah, we don't need to open the i18n can of worms any farther than we have to at this point. From: To: Time: Fri Jul 24 14:37:54 2009 Huh. It looks like we have an undocumented realm option kpasswd_server. From: To: Time: Fri Jul 24 14:38:05 2009 (Well, it's documented in the kpasswd man page.) From: To: Time: Fri Jul 24 14:39:31 2009 i don't know whether to be amused or appalled that our build instructions include things like the following: For example, if you wish to create a build directory for pmax binaries you might use the following procedure: 1. mkdir /u1/krb5-1.7/pmax ....when was the last time anyone built krb5 on pmax hardware? From: To: Time: Fri Jul 24 15:50:07 2009 Does rc4-hmac's string-to-key not use salting? From: To: Time: Fri Jul 24 15:50:59 2009 check the rfc... i think that's the case From: To: Time: Fri Jul 24 15:53:11 2009 Looks like it just does an MD4 over the little-endian UCS2 rep of the password. Okay, that helps explain some stuff. From: To: Time: Fri Jul 24 15:54:12 2009 it also kind of explains the weird salt-related issues on non-rc4 string-to-key From: To: Time: Fri Jul 24 15:55:05 2009 I implemented random salt generation. The kpasswd test suite determined (correctly) that this breaks password history checking. I was unable to reproduce the results because password history checking still worked in a lab environment because rc4-hmac keys are salt-independent. From: To: Time: Fri Jul 24 15:55:27 2009 oh From: To: Time: Fri Jul 24 15:55:44 2009 (I'm not entirely sure why the kpasswd test principal has no rc4-hmac key, but I can verify with kadmin.local that that is the case.) From: To: Time: Fri Jul 24 15:56:02 2009 it may be due to whatever its kdc.conf puts for supported_enctypes From: To: Time: Fri Jul 24 15:57:12 2009 Yeah, I was looking at the krb5.conf for that but not the kdc.conf. Now I see it. From: To: Time: Fri Jul 24 15:57:53 2009 random salt might also cause headaches for people who need to make a keytab for a service that has a password instead of a randomly-generated key. From: To: Time: Fri Jul 24 16:01:04 2009 I noticed in the RFC that you can't (in general) generate a keytab from a password without contacting the KDC, since you don't know the salt a priori. Do we have a way of generating a keytab from a password, with or without contacting the KDC? From: To: Time: Fri Jul 24 16:04:19 2009 I guess we have ktutil's addent -password. From: To: Time: Fri Jul 24 16:06:51 2009 It assumes normal salt (it runs principal2salt). From: To: Time: Fri Jul 24 16:14:16 2009 there is a standard salt... and i believe ktutil can take alternative salt types as well. From: To: Time: Fri Jul 24 16:23:39 2009 No, ktutil just runs krb5_principal2salt unconditionally to generate the salt. From: To: Time: Fri Jul 24 16:25:49 2009 hm, that could be improved From: To: Time: Sat Jul 25 04:34:15 2009 Greg: In your random salt generation, how many random bits are you generating? DES string-to-key uses a fan-fold technique that's likely to make some of the salt bits cancel each other out, depending on the password length; I'd suggest at least 112 bits but you can probably stare at it and figure it out for sure. From: To: Time: Sat Jul 25 04:40:04 2009 DES3 uses 168-fold, where the efficacy of the mixing is again determined in part by the password length. It's better, but I'm not convinced 168 random bits expanded to a salt string will let you cover the whole possible key space (which I think would be desirable... though I suppose not absolutely required). I looked at it a while back but don't remember the specifics. It may just be that when password+salt has a length that's a multiple of 168 the fixed bits due to use of printable ASCII are just doomed to line up and cut powers of 2 off the possible generated key space. From: To: Time: Sat Jul 25 04:54:27 2009 AES uses PBKDF2 with SHA-1; that's probably fine with 160 random bits. (Even for a 128-bit key, I'd probably use 160 random bits, to try to get maximum coverage of the output space for a given password before the truncation, but haven't thought about it much. It's not like it couldn't be changed later if more careful analysis determines that 128 random bits are sufficient.) From: To: Time: Sat Jul 25 05:00:41 2009 Hm.. for DES I take it back -- you don't need 112 random bits, but 16 randomized printable-ASCII bytes; more than that and the non-fixed bits just start getting xor'ed with each other and don't help. You could tune it a bit by looking at the bit-value probabilities for printable ASCII and where they're going to get xor'ed, and see if you can guarantee that at least one of the bits going in has exactly 0.5 probability of being set. From: To: Time: Sat Jul 25 05:07:04 2009 (In case it's not clear why I'm thinking about that, consider two-bit values permitted to vary from 0 to 2. Chosen randomly from the range, the low bit has a 2/3 probability of being set. If you xor two of these together, the low bit has a 2*2/3*1/3 = 4/9 probability of being set, giving uneven distribution across the possible resulting 2-bit strings. For printable ASCII, c&0x70 will range from 2-7 and 0x7f will presumably be left out; it's not as skewed as my example, but it's not an even distribution. Then again, DES is being phased out, and choosing 16 bytes randomly from 0x20-0x7e is still a lot better than what we have now, so, whatever.) From: To: Time: Sat Jul 25 05:17:19 2009 And on the more general salt-length issue, I think I've mentioned it before, but if the salts are big enough to ensure coverage of most or all of the possible key space even with weak passwords, an attacker can't effectively build up dictionaries of common passwords plus all possible salts, or cutting large ranges of possible keys out of a brute-force search. It's probably true that multiplying the work factor by 2**64 or less would be adequate, as long as we can be confident that there aren't classes of salt strings or salt+password combinations that the attacker can handle efficiently for certain cryptosystems (e.g., because certain pairs of bits only influence the result via their xor, making them effectively single bits). Like I already said, the details can be tuned later depending on risk analysis. And sending more bits rather than fewer until the analysis is done doesn't really cost much. From: To: Time: Sat Jul 25 11:18:06 2009 I was going to generate 16 random printable bytes, but (as noted in mail) I'm going to sever this from the enctype configuration project and back-burner it. From: To: Time: Sat Jul 25 16:49:45 2009 That seems reasonable. From: To: Time: Sat Jul 25 16:51:51 2009 Wow. They're making you switch to another mail system, and they *still* can't do Kerberos authentication for mail reading? At least according to the Apple Mail configuration page, it looks like it's password only... From: To: Time: Sat Jul 25 18:29:30 2009 Supposedly, there are problems getting GSSAPI auth to work with the version of Exchange they are running, and they anticipate that an upgrade to a newer version might help, but there is no schedule for that upgrade. And yeah, it's clearly not a priority for them. From: To: Time: Sat Jul 25 19:45:45 2009 Why did the krb5 protocol add the s2kparams concept? How is that different from a salt? (Just curious.) From: To: Time: Sat Jul 25 19:52:58 2009 It was to pass other information, like "use AFS string-to-key" or "iteration count for PBKDF2"; at least in the latter case that's independent of salt value. From: To: Time: Sat Jul 25 19:59:02 2009 That feels fiddly. The iteration count for PBKDF2 is still a non-secret value combined with the secret password to form the key. From: To: Time: Sat Jul 25 19:59:19 2009 Though I guess there would have to be some structure in the salt to get an iteration count from the salt. From: To: Time: Sat Jul 25 21:44:15 2009 Yeah, we didn't want to add that structure, especially since it would be per-cryptosystem. And (in the case of specifying AFS string-to-key) we'd be going back and redefining existing cryptosystems incompatibly. From: To: Time: Sun Jul 26 02:03:55 2009 This room is not anonymous. From: To: Time: Sun Jul 26 02:48:49 2009 Looking over the new project page for randomized salt generation... it looks good... it's not clear to me, though, if you want to eliminate salt types from the administrative interfaces, or from the db as well. (Or just label them "deprecated" and not actually remove anything.) Since some "salt types" indicate things other than salt string generation algorithms, if the field goes away in the database they need to be replaced by something else. From: To: Time: Sun Jul 26 02:49:36 2009 There's also a ticket on this in RT already - 1620. From: To: Time: Sun Jul 26 03:11:33 2009 Thought about the DES case a bit more. I think 16 bytes with the low four bits chosen at random and the top bits fixed will be adequate -- so 64 random bits. The middle bits will combine under XOR and give limited contributions, but we can't know which bytes will XOR with which so as to only use up one bit. The low three bits of each byte in one half will XOR against the fixed upper three of a 7-bit "byte" in the other half and vice versa, giving us seven random bits in each byte of the fan-fold result. From: To: Time: Sun Jul 26 03:13:23 2009 Actually, I *think* the odd-position and even-position bytes may wind up being XORed together regardless of the password length, so we could use only three random bits in, say, the even-numbered positions, but I'd have to work it out more carefully. If so, that would let us use just 56 random bits and cover the whole (intermediate) key space. From: To: Time: Sun Jul 26 03:15:10 2009 Since Greg just copied my earlier notes into the wiki, I'll stick a comment in there... From: To: Time: Sun Jul 26 03:44:46 2009 Also, cross-realm TGT keys should be entered using agreed-upon human-processable passwords, but should not be so easy to attack. There are enough password-authentication protocols that do strong key generation that it should be doable; the tough part may be ensuring maximum convenience for the realm admins. From: To: Time: Sun Jul 26 03:45:38 2009 Hm, I'm still not sure what the "protocol" is for commenting on early-stage project proposals on the wiki.It could be something as simple as: The "remote" realm adds a database entry with a randomized salt and the weak password, and a flag saying that the password needs changing, and another saying the current kvno can't be used for cross-realm TGTs, and a third indicating that strong ZKPP-based preauth must be used. The admin of the "local" realm that would be issuing tickets for the cross-realm service runs a program that asks for the initial password, gets a strong session key in the TGT principal's name for the password-changing service, generates a new, long, strong password or key and sets it in the remote realm while also saving it locally, much like any service running a script to change its long-term key. That's got the (possibly serious) disadvantage that if for some reason the realm admin wants to back up and enter it again, well, the password's been changed on the remote side, so he loses; but when would that be needed? From: To: Time: Sun Jul 26 03:46:34 2009 (Er, that was supposed to start with "It could be something as simple as..." -- the cut-and-paste bindings seemed to have grabbed some old extra text I didn't intend.) From: To: Time: Sun Jul 26 03:49:31 2009 Of course, that whole idea also presumes that we solve the "make service key rollover trivial and robust" and "secure password-based initial authentication" problems first, but there are ideas kicking around for those. From: To: Time: Sun Jul 26 10:49:32 2009 Feel free to edit the early-stage proposal in any way that seems reasonable. Me copying in your comments on salt generation was mostly about minimizing effort; there are better ways for it to be organized. From: To: Time: Mon Jul 27 12:10:42 2009 Oops: ret = copy_ktypes(nctx, ctx->tgs_ktype_count, ctx->tgs_ktypes, &nctx->in_tkt_ktypes); From: To: Time: Mon Jul 27 12:23:08 2009 In krb5_get_permitted_enctypes, should we really be using the tgs_ktypes application defaults? From: To: Time: Mon Jul 27 20:26:31 2009 Urf. That was like two hours down the drain because I typoed ENCTYPE_DES3_CBC_SHA instead of ENCTYPE_DES3_CBC_SHA1. From: To: Time: Mon Jul 27 22:09:00 2009 Hm, we have testing and man page grot related to kdc_supported_enctypes which doesn't seem to exist in the code base. From: To: Time: Tue Jul 28 08:54:48 2009 Need to pick up the name for the configure option for crypto modularity proj. Any objectins against ./configure --with-crypto-impl=IMPL ? Say, ./configure --with-crypto-impl=ossl or ./configure --with-crypto-imp=nss etc? From: To: Time: Tue Jul 28 08:56:13 2009 good enough. we can change it if someone really doesn't like it. From: To: Time: Tue Jul 28 08:57:37 2009 How about moving all crypto tests in on dir under crypto dir. So they can be used cross-impl From: To: Time: Tue Jul 28 08:58:17 2009 into one directory under crypto From: To: Time: Tue Jul 28 08:58:36 2009 some of them depend on implementation internals don't they? From: To: Time: Tue Jul 28 09:02:34 2009 yes, some of them do. From: To: Time: Thu Jul 30 21:43:08 2009 Ooh, interesting. Schneier now recommends against AES-256, in favor of AES-128. Apparently the key schedule for the 256-bit version is poor, and there's an impressive new attack against a reduced-round version (11 rounds instead of 14, not much safety margin). From: To: Time: Thu Jul 30 21:54:58 2009 Hm. I wonder if we should, at a minimum, reorder the algorithms in our default set. From: To: Time: Sun Aug 2 02:03:02 2009 This room is not anonymous. From: To: Time: Mon Aug 3 15:43:20 2009 the question from Marcus Nilsson is potentially problematic From: To: Time: Mon Aug 3 16:58:53 2009 make check currently fails From: To: Time: Mon Aug 3 17:17:53 2009 Fails where? From: To: Time: Mon Aug 3 17:18:35 2009 t_crc had a deplibs problem but i fixed it. currently looking at a problem with destest "can't process key" From: To: Time: Mon Aug 3 17:18:53 2009 Hm, I didn't run into either problem. From: To: Time: Mon Aug 3 17:19:11 2009 (I ran into a t_prf2 problem but fixed it.) From: To: Time: Mon Aug 3 17:37:55 2009 What's the problem with Marcus Nilsson's question? From: To: Time: Mon Aug 3 17:38:22 2009 the kdc shouldn't issue him a tgt if there's a requires_preauth set on the krbtgt principal From: To: Time: Mon Aug 3 17:41:16 2009 I don't think that's true. The AS req path doesn't appear to have a check for that bit on the server DB entry. From: To: Time: Mon Aug 3 17:41:35 2009 has it ever had it? From: To: Time: Mon Aug 3 17:42:53 2009 Not that I'm aware of. I'm really puzzled why the TGS path checks that bit on the server, personally. From: To: Time: Mon Aug 3 17:43:28 2009 so the server can enforce a policy of requiring the client to have used preauth to get its initial ticket? From: To: Time: Mon Aug 3 17:43:46 2009 or rather, so the server can rely on the kdc enforcing it somewhat. From: To: Time: Mon Aug 3 17:43:59 2009 the kdc shouldn't let the client get useless tickets, i think. From: To: Time: Mon Aug 3 17:44:31 2009 Oh, that's documented, now that I check. From: To: Time: Mon Aug 3 17:45:28 2009 It sounds like the as-req path should be checking that as well. From: To: Time: Mon Aug 3 17:48:53 2009 yeah. i was wondering why it doesn't. maybe it's a bug that was introduced during the FAST work. From: To: Time: Mon Aug 3 17:50:38 2009 i'm looking at destest.c an wondering how this ever worked. it's dying on a -2 return from mit_des_key_sched(), which means "weak key"; the corresponding key in the input data file looks intended to be a weak key. From: To: Time: Mon Aug 3 17:55:52 2009 oh i see what's going on. destest.c used to not link with -lk5crypto; it linked explicitly with some but not all of the object files. that allowed it to override mit_des_weak_key() From: To: Time: Mon Aug 3 18:04:24 2009 r21722 (prior to the merge of Luke's work and prior to the FAST work) also doesn't seem to check requires-preauth on the server except in validate_tgs_request(). From: To: Time: Mon Aug 3 18:04:41 2009 hm, ok From: To: Time: Mon Aug 3 18:20:42 2009 but do you agree that preventing the kdc from issuing useless tickets (for preauth policy reasons here) is a good idea? From: To: Time: Mon Aug 3 18:48:24 2009 why oh why is there an nfold.so in my source tree? From: To: Time: Mon Aug 3 18:57:34 2009 I did run into that, but couldn't figure out why. The Makefile looked right. From: To: Time: Mon Aug 3 18:58:49 2009 Going back to the preauth thing: I am not sure that the krbtgt ticket is useless in that situation. It would still have worked for getting other service tickets. From: To: Time: Mon Aug 3 18:59:01 2009 However, I don't think it should have been issued in the first place. From: To: Time: Mon Aug 3 18:59:51 2009 hm. i would think that the TGS, as a kerberos service, would check the preauth flag on the ticket and deny additional tickets if the TGS principal had the preauth flag set. From: To: Time: Mon Aug 3 19:00:10 2009 In libkrb5? From: To: Time: Mon Aug 3 19:00:50 2009 oh, good point. do we have a knob for the app to enforce such a policy in rd_req? From: To: Time: Mon Aug 3 19:02:56 2009 Uh, no clue. Empirically, if I set requires_preauth on krbtgt/realm in my test realm, I can still get service tickets with a TGT (but can't renew my tickets, as expected). From: To: Time: Mon Aug 3 19:11:05 2009 On nfold.so in the source tree: it comes from running make check in lib/crypto/crypto_tests. From: To: Time: Mon Aug 3 19:11:33 2009 that seems poor From: To: Time: Mon Aug 3 19:11:48 2009 I'm not sure exactly how to fix it. It's one of those test programs which builds a static version of an object file and links against it. But in this case, the object file comes from a source file which is now in a different directory. From: To: Time: Mon Aug 3 19:11:59 2009 I'm not clear on why we don't just link against the .so files for such test programs. From: To: Time: Mon Aug 3 19:12:30 2009 it's clear that destest wants to link explicitly against some object files, because it needs to be able to override some stuff. From: To: Time: Mon Aug 3 19:13:12 2009 there's a spurious $(srcdir) in crypto_tests/Makefile.in for t_nfold and t_encrypt From: To: Time: Mon Aug 3 19:13:38 2009 we need to do some cleaning up from the move. From: To: Time: Mon Aug 3 19:14:19 2009 Well, more than that, the rule also switched from objext to dynobjext. From: To: Time: Mon Aug 3 19:14:35 2009 The nfold test isn't overriding anything, though; I think it can use the dynamic object. From: To: Time: Mon Aug 3 19:14:48 2009 i'm wondering why some of those changes happened the way they ddi From: To: Time: Mon Aug 3 19:14:51 2009 s/ddi/did/ From: To: Time: Tue Aug 4 00:50:14 2009 Why does S4U2Self need KDC support? Can't a service print tickets with itself as the server principal? From: To: Time: Tue Aug 4 02:39:41 2009 That doesn't get you PAC info for the user, for one thing... From: To: Time: Wed Aug 5 12:18:09 2009 or we could fix the test programs so they don't do dubious things like overriding internal functions From: To: Time: Wed Aug 5 12:19:51 2009 i really wish that people would stop talking about "ANSI" character encodings. they almost invariably are ambiguous or completely misled. From: To: Time: Wed Aug 5 12:21:31 2009 In the nfold case, the test program is just unit-testing a non-exported symbol, so needs to link against the object file containing that symbol. I think that's legitimate and I don't see any good way to do it besides co-locating the test program and source file. From: To: Time: Wed Aug 5 12:22:17 2009 yeah, alternatives involve exporting the internal symbol, or doing something with function pointers. From: To: Time: Wed Aug 5 12:22:43 2009 Tom, I think ANSI character set has a fairly well defined meaning for win32 that happens to have very little to do with any standards institute From: To: Time: Wed Aug 5 12:23:39 2009 true, it has very little to do with any standards institute, but it tends to refer to a family of code-page based encodings without further specifying. From: To: Time: Wed Aug 5 12:25:26 2009 I thought that it depended on the current system. I.E. was very similar to what would be sent by non-unicode just-send-8 From: To: Time: Wed Aug 5 12:25:49 2009 also, i was somewhat surprised to discover that "shift-JIS" has nothing to do with iso-2022 shift encodings. From: To: Time: Wed Aug 5 12:26:09 2009 yeah, those win32 encodings do have to do with the localization settings of the OS From: To: Time: Wed Aug 5 18:37:59 2009 Hm, somewhere I've got a patch that at least partly addresses the --with-kdc-kdb-update compilation failure. I should track it down. From: To: Time: Wed Aug 5 18:38:27 2009 yeah, i thought we had fixed that for 1.7. From: To: Time: Wed Aug 5 18:41:17 2009 Bleah, my home office is too warm & humid. I'll track it down later after the A/C does its job. From: To: Time: Sun Aug 9 02:06:24 2009 This room is not anonymous.