[00:16:04] --- shadow@gmail.com/barnowlCA9FC336 has left [00:16:13] --- shadow@gmail.com/barnowlCA9FC336 has become available [03:36:41] --- shadow@gmail.com/barnowlCA9FC336 has left [03:36:50] --- shadow@gmail.com/barnowlCA9FC336 has become available [04:27:30] --- Derrick Brashear has left [04:27:38] --- Derrick Brashear has become available [05:31:21] --- meffie has become available [06:14:20] --- Stephan Wiesand has become available [06:17:55] Hello Derrick. Thanks for uploading the ML pre3 installer. [06:20:31] no problem. [06:34:19] --- Stephan Wiesand has left [06:34:19] --- shadow@gmail.com/barnowlCA9FC336 has left [06:34:23] --- shadow@gmail.com/barnowlCA9FC336 has become available [06:35:18] --- Stephan Wiesand has become available [06:42:09] --- Derrick Brashear has left [06:43:10] --- ktdreyer has become available [06:59:50] --- squinney has become available [07:00:03] --- Derrick Brashear has become available [07:00:42] --- paul.smeddle has become available [07:00:55] Hello [07:00:59] hello [07:01:05] Hello All [07:03:38] --- deason has become available [07:03:41] So how are we feeling about pre3? Anyone spot any issues in testing? [07:04:11] i'd good. sorry, by the way, about the tagging confusion [07:04:29] sorry too [07:05:25] Who has actually tested it in some way yet? [07:06:24] smoke testing here was fine [07:06:54] I'm running the linux client on my desktop at work [07:07:04] I've been running a couple of SL5/6 clients and two SL5 DAFS servers for a while now. No problems found. [07:07:47] In addition to testing it on Fedora 18 in my test cell, I tested pre3 on our new fileserver at USGS, and I've installed it on a couple clients there too [07:08:08] I also installed the Mac client last night... didn't get a chance to reboot and test it though [07:10:16] I believe this should be sufficient for inviting public testing? [07:10:32] i agree [07:11:30] There are missing bits for IRIX and Linux 3.8 - not urgent IMHO. [07:11:39] I've successfully built packages for F16, F17 and EL6. Will get onto F18 shortly. [07:12:05] We'll start testing on EL6 clients probably tomorrow. [07:12:27] Good news. [07:12:35] I think we concentrate now on getting 1.6.2 out ASAP. Anything non-critical can wait. [07:12:47] Paul: +1 [07:13:12] I'd like to solicit opinions on the criticality of 8909 [07:14:31] you mean because of the last packet being unencrypted? [07:14:39] not just the last one [07:15:45] is this a regression against 1.6.1? [07:15:50] no [07:15:52] no. [07:15:52] --- Derrick Brashear has left [07:15:58] it's a security issue tho [07:15:59] --- Derrick Brashear has become available [07:16:12] --- Simon Wilkinson has become available [07:16:14] which, mumble mumble we'll have some going out anyway [07:16:20] trying to get simon on line [07:16:23] hello. no scrollback [07:16:32] (or, rather, no useful scrollback [07:16:38] summary: should we be caring about 8909 for 1.6.2 [07:16:46] have a http://jabber.openafs.org/release-team@conference.openafs.org/2013-01-16.txt [07:18:11] I feel like leaving it for 1.6.3. [07:18:54] Not sure. On one hand, it's something that I think it would be difficult to exploit, so forcing some choice bit of traffic to be unencrypted would be hard, if not impossible [07:19:20] On the other hand, sending a window's worth of traffic in clear text when the user thinks it is encrypted is unfortunate, to say the least. [07:19:30] --- Derrick Brashear has left [07:19:34] --- Derrick Brashear has become available [07:22:19] The fix changes RX behaviour. And doesn't look trivial to me. Locking stuff in every line. [07:22:19] derrick gave andew's fix a +1. [07:22:48] but we should have more review i'd think [07:23:30] The fix will crash a fileserver that hits that code. [07:23:47] it did not on mine [07:23:58] There's an assert on call->error ? [07:24:30] you know, i looked at the locking hard and didn't even think about that :\ [07:24:32] there had better be an error on the call when we finish that [07:25:18] Paul, heeelp... [07:25:56] I think it's clear this fix needs more time in the oven [07:26:08] i... actually i don't think it does [07:26:12] and the locking/aborts was copied from the checkpacket error handling, just by the by [07:26:20] ah. ok. [07:26:36] that doesn't mean it's right, but I wasn't just coming up with it [07:26:39] consider ConnectionError is setting CallErrors on all the calls. [07:26:44] Yeah, there should be n error. [07:27:03] simon may have something, but i found no issue with the locks. i didn't look at the assert at all, but i just did [07:27:26] that said, i'd be happier not asserting the error, and avoiding a crash at least for 1.6 [07:27:37] I think the assert is fine. rxi_ConnectionError will set an error on the call, and does so with the appropriate locks. [07:27:42] the assert is there because that interaction was non-obvious; it could use a comment maybe [07:28:06] If the error is then cleared, then we have a bigger problem - it means that the call is being recycled whilst it is still in use. [07:28:17] dropping the assert would imply to me that crashing is worse than leaking that information; I don't think that's true [07:28:22] well, it that happens we already have an issue. [07:28:43] I think I would prefer to not have the assert, just because it's purpose is non-obvious. [07:28:57] The bigger question is whether the risk of taking this change now outweighs its benefits. [07:29:19] i would be happier with no assert, fine with the assert, less happy with no patch at all, but have no firm opinion regardless [07:29:23] At this point I would say yes for anything non-obvious [07:29:41] (re risk outweighing benefit) [07:30:34] IMO, since we have a weekly meeting cadence now, we should be aiming for regular pretty darn good releases, rather than irregular "perfect" ones. [07:30:56] I'm fine with dropping the assert for 1.6; that's obviously not the important part :) [07:32:00] Can we try a little Gedankenexperiment? [07:32:29] Go ahead [07:33:00] If 1.6.2 were ready to ship right now, who would be in favour of just adding this change and release it without further public testing? [07:33:02] shoot... [07:33:13] *hand up* [07:33:39] No [07:35:20] --- Simon Wilkinson has left [07:35:27] --- Simon Wilkinson has become available [07:35:33] Although not that strong a no. Timing changes in RX scare me, because there are bits where the locking is flawed. However, this will only change the timing of calls where the security object returns an error in PreparePacket, which is not going to be a common situation. [07:35:47] I'm not trying to push this hard, but I think I would; I can justify possible breakage since this was trying to fix leaking encrypted data [07:36:13] yes, I also meant to mention that last point by simon; the only time this code engages is during a security layer error [07:36:16] if you hold a lock on a conn you're erroring too long, it will take a long time for clients to realize they lose. here, watch while i cry [07:36:30] If this were a) a regression or b) a situation where an attacker could force particular data could be leaked, then I would be a strong yes [07:36:33] the only time that happens is when tokens expire, or some internal errors can occur [07:36:33] Which makes it hard to test, right? [07:36:50] token expire is not hard. [07:36:52] no. get short lived tokens [07:37:10] Has someone checked the lock hierarchy for all callers? [07:37:27] i think i did. i can go look again [07:37:30] it's easy to induce hitting the code path; but trying to check all possible errors with threading etc isn't feasible, as always [07:38:32] Which makes a good for it being a patch in 1.6.3pre1 -- it'll get all the benefit of the 1.6.3 pre-release testing. [07:38:38] good argument [07:39:06] What timescale are we thinking of for 1.6.3 ? [07:39:27] Shorter than 1.6.2, hopefully. [07:39:46] If we go on like this, by induction we'll never ever get 1.6.2 out. [07:40:01] Yeah, and I think that's an argument for drawing a line in the sand. [07:40:11] I refer to my earlier comment about regular releases. It looks like "regular" will be on the order of 1-2 months [07:40:27] More like 2 realistically [07:40:35] Even if it was 3 months from release to release, I think it would be fine to refer this for one release. [07:40:38] lock hierarchy seems fine; only callers are write, writev, and flush; the only lock held at that point is the call lock, I believe [07:40:41] defer, even [07:41:35] if it doesn't take a year for another release, that would make me feel better about not including this now [07:41:39] I have some concerns around call reference counting, and CheckCall recycling [07:42:00] But I haven't checked through, and that's a real can of worms with RX [07:42:16] Andrew, the idea is to have much more timely releases after 1.6.2. [07:42:44] I would vote to get 1.6.2 out asap, and then roll this into 1.6.3, and make sure that we hit that release in a timely manner [07:42:54] And having changes of some importance in the pipeline will help doing them [07:42:55] i'd be ok with that [07:44:16] I vote for leaving it for 1.6.3 - unless we need another prerelease. Which we hopefully won't. [07:44:21] Any other important/potentially critical patches ? [07:44:58] Public testing may induce some... [07:45:20] re call references/recycling; well, preparesendpacket already drops and reacquires call->lock [07:45:29] oh, but yes, that's fine [07:45:35] deferring, that is [07:46:00] Okay, cool. In that case, any objections to Stephan's announcing 1.6.2pre3 to openafs-announce? [07:46:18] deason: Yeah, I'm not convinced that's actually safe, either :) However, things also change when the call goes into error, iirc. [07:46:19] no objections [07:46:28] No objections to announcing 1.6.2pre3 [07:46:44] Having a few binaries would be nice. [07:46:53] well if broken, no broken than before [07:47:05] all of the callers are in the application thread, though [07:47:54] CheckCall is event thread, so it can race. Generally, it's the activity timeout on CheckCall that saves us from reference counting mistakes [07:48:34] Stephen, any chance we could upload your packages? [07:50:43] Ok, no binaries (besides the OS 10 10.8 dmg) for the time being... will announce them as forthcoming... [07:50:47] I don't know if I'd consider that a "race"; the application is referencing the call; if that means the conn can get gc'd, it's just plain wrong [07:52:09] Stephan: cool [07:52:40] The packages are all available for upload, it's all built in the same way as the "stable" packages [07:53:16] Great. Do you have the credentials for doing that? [07:53:51] It's normally Simon or Derrick who does that [07:54:05] Derrick has to do it. I just kick him from time to time [07:55:01] The idea being tat Paul and me relieve Derrick of some of those chores - could I do it? [07:55:02] They're all in /afs/inf.ed.ac.uk/group/afsbuild/1.6.2pre3 [07:56:29] just rsync them in from there [07:57:30] ok, will do. would it be possible to sign them? [07:57:52] I think everything from the Informatics build machine is signed [07:57:56] they should be signed [07:58:59] ah, ok. I just checked the SRPM, and that isn't. Could you mail me the public key? [07:59:11] ah, sorry, the SRPM won't be [07:59:21] I created that manually [08:00:13] I can safely add a signature to that after running a diff -r. No problem. [08:00:17] if something other than the informatics machine is signing it, it should get its own key [08:00:20] just about to sign the srpm now [08:00:41] like. don't ship the private key around. [08:00:47] Indeed [08:01:15] RIght, don't do that ;-) [08:01:53] the public key is the one in the repo rpm. you should already have it, or be able to get it, from the repo rpm for any previous release. [08:02:21] The SRPM is now signed [08:02:39] In the past, someone diligently prepared a web page for may prereleases. [08:02:52] make_www_release -c [08:03:17] I'll find the public key. [08:04:03] And try make_www_release. [08:04:31] you'll need the -c flag, i suspect, because it won't realize automatically that preX implies candidate [08:05:35] --- Simon Wilkinson has left [08:05:54] Ok. I may not get everything done today, but will try hard being done tomorrow. [08:07:34] --- Simon Wilkinson has become available [08:08:14] AOB? [08:08:40] Minutes... any volunteer? [08:08:54] I can write up minutes again. [08:09:18] Thanks. [08:09:18] They won't be very long ;-) [08:09:32] All the better. [08:11:10] I'll sign off for an hour now, then start working on getting pre3 out. Thanks everyone! [08:11:16] Thanks [08:12:04] --- Stephan Wiesand has left [08:22:01] --- Derrick Brashear has left [08:41:47] --- paul.smeddle has left [09:05:17] --- squinney has left [09:09:56] --- Jeffrey Altman has left: Disconnected [09:15:50] --- Jeffrey Altman has become available [09:38:41] --- Simon Wilkinson has left [09:53:32] --- meffie has left [10:08:36] --- Derrick Brashear has become available [10:16:39] --- Simon Wilkinson has become available [11:03:43] --- ktdreyer has left [11:06:37] --- ktdreyer has become available [11:55:59] --- Derrick Brashear has left [12:00:04] --- Simon Wilkinson has left [12:22:57] --- Derrick Brashear has become available [14:09:48] --- Simon Wilkinson has become available [16:31:44] --- deason has left