[05:03:18] --- meffie has become available [06:28:43] --- wiesand has become available [06:57:31] hello [06:57:53] --- wiesand has left [06:57:58] --- wiesand has become available [06:58:03] Hi [07:02:04] --- deason has become available [07:02:33] Hi Andrew. Mike, are you actually here? [07:02:37] hi, yes [07:02:57] I am here, for the moment, but will leave early. [07:03:24] Ben: ok. Anyhting we should discuss now while you're still with us? [07:04:29] that phrasing suggests ben's impending death. hoping not [07:04:30] I don't think there's anything in particular I have input on. [07:05:02] Well, I'm going to the dentist. That's sort of like imminent doom... [07:05:19] drilling, blasting, or both? ;) [07:05:34] Just drilling, I think :) [07:05:55] Let's talk about something else. [07:06:32] Let's start with RT #131852 (crash in dafileserver) [07:07:03] Andrew said it's probably unrelated to the missing keytab for Heimdal? [07:07:18] Is there agreement on this? [07:07:30] well, I just haven't seen anything indicating that's what it is [07:07:38] and I can't reproduce it [07:07:54] We don't know what version of heimdal is in play. [07:08:12] The crash is pretty clearly in libkrb5-land. [07:08:45] Defer 11075 to 1.8.9? [07:08:50] they touched keytab and the crash stopped [07:09:25] > they touched keytab I didn't see anything in the ticket about that [07:09:26] it'd be nice if we could get some more information from the core [07:09:32] is it actually heimdal 1.5.2? [07:11:01] I think we need to get more information from the reporter. [07:11:17] Unless Jeffrey has something to say? [07:11:17] the binary is stripped and an unstripped binary was not available [07:11:18] There seems to be more info than the ticket displays [07:12:59] yeah, and I would like to get more info from the reporter, but I don't wanna step on anyone's toes [07:14:31] strace showed e.g. [07:14:42] 14951/3: issetugid() = 0 14951/3: open64("/usr/afs/etc/rxkad.keytab", O_RDONLY) Err#2 ENOENT 14951/3: Incurred fault #6, FLTBOUNDS %pc = 0x00000000 14951/3: siginfo: SIGSEGV SEGV_MAPERR addr=0x00000000 14951/3: Received signal #11, SIGSEGV [default] [07:14:51] (truss, actually) [07:15:07] that's not an answer, not an explanation [07:15:22] and yes, they observed: "Touching /usr/afs/etc/rxkad.keytab seems to be enough to get it not to crash." [07:15:24] have you tried running the fileserver with heimdal without an rxkad.keytab? it doesn't just crash every single time [07:16:02] or maybe it does, with some specific version of heimdal, but so far nobody has explicitly answered what it was running with [07:16:14] with the heimdal they had, it crashed every time. it does for for the heimdals i have. let me see. [07:16:38] the claim was that version of heimdal was 1.5.2, however, i can't verify that from the information present [07:17:14] I would be happy enough to know the version of heimdal that you have locally which crashes every time. [07:17:50] wait. found more in my email. (gdb) where #0 0x00000000 in ?? () #1 0xff1787e4 in krb5_storage_seek (sp=0x27569f50, offset=0, whence=1) at store.c:173 #2 0xff1511f0 in fkt_next_entry_int (context=0x27569f50, id=0x2756a3b8, entry=0xf7ffb1e8, cursor=0xf7ffb1dc, start=0x0, end=0x0) at keytab_file.c:457 #3 0xff15160c in fkt_next_entry (context=0x27569f50, id=0x2756a3b8, entry=0xf7ffb1e8, cursor=0xf7ffb1dc) at keytab_file.c:512 #4 0xff14f2d4 in krb5_kt_next_entry (context=0x27569f50, id=0x2756a3b8, entry=0xf7ffb1e8, cursor=0xf7ffb1dc) at keytab.c:769 #5 0x00098810 in pick_principal () [07:18:24] isn't that just what's in the ticket? [07:18:58] yeah. seemingly. [07:20:43] What are the opinions on 11075? [07:21:30] i wrote it so mine doesn't count [07:21:30] What happens if that malloc() fails? [07:21:34] well certainly "not yet" at least [07:23:05] then it will crash; yeah, it shouldn't do that [07:23:16] well, that's an easy fix [07:24:42] There's enough added code that I might want to pull it into a helper routine. [07:26:21] Ok, it needs a bit more work. [07:28:44] I'd really like to get out a pre2 soon. At least one site runs pre1 w/o the security fix from 1.6.7. [07:29:37] So I propose we defer 11075, and issue a pre3 if there's hard evidence that the problem may be common. [07:29:44] i think a helper function will actually make the code less clear. if you want me to redo it i will. if you want to wait, fine. [07:29:45] ok [07:30:34] the heimdal krb5_storage stuff looks much different in modern code. i don't expect this is terribly common [07:30:49] Ok. [07:31:10] Next one: the cmd.c potential buffer overflow. [07:31:50] was fixed as 473322a453bbc409d54ab21e1d9637eaf15f085a, yes? [07:31:54] This should already be fixed. [07:32:30] The question is whether we want to pull up such fixes in general. [07:32:35] patch 12 of 11075 looks okay to me at a quick glance, but I'll look more carefully later and (presumably) +1 then. [07:33:16] Ben: ok. [07:33:28] I'm in favor of doing this for two reasons: [07:33:54] These things may bite us later when a new compiler is introduced on some platform. [07:34:04] And it reduces skew w.r.t. master. [07:34:29] the issue here was the fix done for master was not applicable directly. in general i think pulling up this nature of fix is a good call [07:35:59] Of course the fix we have is ok too. (nb at least on linux, strlcpy seems to be part of libc) [07:37:34] Ok, at least I'm not the only one. But I admit it's tedious. [07:37:58] We'll see how review will go for the few dozen coverity fixes already pulled up. [07:38:10] That's all for 1.6.9 of course. [07:38:56] Without Mike present, not much point in discussing the stack reduction changes? [07:38:58] (bye) [07:39:03] Bye Ben. [07:39:25] oh, sorry, was distracted :( [07:39:36] Ah, hello Mike :) [07:40:09] What's the state of those? Close enough to include in pre2? [07:41:14] it is still in progress, chas posted some more comments last night. [07:41:29] it seems close to be merged on master. [07:41:40] i think once he has the top patch tweak for what chas said we're good [07:42:00] ok, excellent. i work on an update now. [07:42:18] Delay pre2 for them? [07:42:31] And then we have 11093. Is that urgent? [07:42:47] Not a recent problem, it seems? [07:43:13] What's actually broken? [07:43:39] 11093 is help for debugging. right now the output you get is nonsense. take it or not. not urgent [07:43:45] i honestly dont know is we should delay pre2 for the stack reduction patches. [07:44:40] Then we shouldn't do it. Unless anyone has strong freelings. [07:45:33] One report I omitted from the agenda was the one that first looked like an MTU issue. [07:46:14] that would be solved by proper pmtu support, which is on the "todo list" [07:47:04] According to the reporter's last mail, it seems to be something else though. [07:47:33] (but it's 1.6.1 anyway) [07:48:13] A single report like this shouldn't block pre2 IMO. [07:48:20] Thoughts? [07:49:15] that's still probably what it is; but yeah, I wouldn't block until we have a better idea of what's going on [07:50:21] if the fix is invasive it's not like we're doing it for 1.6.8 [07:50:42] Right. [07:50:54] Anything else that must make pre2? [07:51:02] nothing here [07:51:16] Could I bother you to look at 10894? [07:52:35] Because it seems to me we should merge that and issue pre2 today? [07:53:36] sounds good to me [07:54:34] News from Marc regarding Linux 3.15rc2 would have been nice. But well, we can make a pre3 if anything comes up there. [07:55:14] Merged 10894. [07:55:44] Next topic: any news on the testing front? [07:57:15] yes, I have around 10 different sites that responded [07:57:24] and I think you said stephen (I assume quinney) was interested? [07:57:25] woot [07:57:48] yes I did [07:58:15] --- Simon Wilkinson has become available [07:58:28] But only if it's not manpower intensive. They're willing to run tests on their system if it's not much work. [08:00:52] What did the other sites say? [08:01:32] that they could run prerelease code in a testing environment of some sort (or if they don't have one, just on a machine or something) [08:02:37] That's what I do too. It's just not comprehensive (no DB servers for example). [08:03:47] We're asking everyone to do this whenever we announce a prerelease. I'm wondering why it's not happening today... [08:05:48] if you ask "everyone" then they assume someone else is doing it? [08:06:17] e.g. human nature. [08:06:52] Probably. How to go forward? [08:08:14] [uploading preliminary 1.6.8pre2 tarballs] [08:08:59] with testing? I'll give them a more specific nudge to do something for 1.6.8pre2 once it goes o [08:09:01] out [08:09:32] I was going to have another round of asking for people, where I ask specific sites I thought might be interested, but this is probably enough people for now [08:10:03] Good. [08:10:45] Regarding pre2, I'd like to do it like the last ones: ask release-team for smoke tests, then ask Daria for the tag, then announce it. [08:12:29] sounds fine [08:12:32] oh, ones of the testing responders asked if we could have repositories that include pre* packages [08:12:39] [upload complete - no srpm yet though, I'll add that later] [08:12:55] specifically he was asking about debian, but for rpms I'm sure some places would find that useful, as well [08:13:33] For redhat, I can do that. [08:14:08] I though Stephen built the pre-releases, if only to check that there wasn't anything in them that would break final on some arcane kernel [08:14:23] He does. [08:14:23] I'll ask russ if there's some way we could add them to maybe debian experimental [08:14:34] or just some other repository, if that's not appropriate [08:15:52] And what Stephen builds, I upload to g.c.o, including repodata. There just were no -release rpms. [08:16:28] And no links making them work for SL/CentOS/RHEL and all variants. But I can add those, no deal. [08:17:02] I can't help with debian though. So yes, appraoching Russ seems right. [08:17:34] Next topic: next stable branches [08:17:48] Simon, I guess that's what you're here for? [08:18:20] Any news, or new thoughts? [08:18:56] Andrew, are you still planning to bring this up on -info and describe the models under discussion? [08:20:20] Hmm, crickets. Well. [08:20:27] yes, although I wasn't thinking (until I read your notes) that I was describing all of the possible options and stuff [08:20:36] I can try to briefly do that, though [08:21:05] It would help me, at least ;-) [08:21:15] and while I know you don't want to delay the discussion, it might make it easier to dedicate a meeting time to that discussion, or something [08:21:36] if we did it right after 1.6.8 was released, in theory we wouldn't have much else to talk about [08:21:49] so you wouldn't be trying to start a discussion on it after we've been here for over an hour :) [08:22:15] yeah [08:23:15] I'll make it item 2 (right after "linux news" next week). Let's see. [08:23:54] So, anything else to discuss today? [08:25:11] Then we're done for today. Thanks a lot everyone! [08:26:27] Bye. [08:26:27] ok [08:26:33] --- wiesand has left [08:27:09] --- deason has left [08:27:24] none here [08:27:39] have a good day [08:29:08] --- meffie has left [13:16:35] --- Simon Wilkinson has left [13:16:41] --- Simon Wilkinson has become available [13:21:43] --- Simon Wilkinson has left [13:21:43] --- Simon Wilkinson has become available [13:21:43] --- Simon Wilkinson has left [13:21:50] --- Simon Wilkinson has become available [13:36:34] --- Simon Wilkinson has left [13:36:41] --- Simon Wilkinson has become available