[04:28:06] --- Simon Wilkinson has left [06:03:22] --- haba has become available [07:02:53] --- reuteras has left [07:24:41] --- deason has become available [09:07:26] thinking about 1.4.13/1.4.14... any thoughts on where the sol11 ioctl stuff is going in here? [09:08:29] the reasoning for 1.4.13 is that it's something that currently arguably "doesn't work", but a counterargument is that it hasn't really been tested too much yet [09:08:49] i need to get 1.4.13 to builders, so had figured we'd do a .1 for it, or just wait for .14 [09:09:07] but the .1 argument may win if we can push it in the next week or so [09:10:05] s/push/stress/ [09:10:09] you get the idea [09:10:14] --- haba has left [09:10:52] --- haba has become available [09:11:16] well, I don't know how much a 13.1 would matter; I'm not so concerned about people wanting to run it _now_, but I'm more concerned about the number of releases that have incompatible code [09:13:18] but I was just wondering what the current idea was; it doesn't bother me either way [09:20:28] --- deason has left [09:20:49] --- deason has become available [09:28:15] --- haba has left [09:57:55] --- Russ has become available [11:06:23] From Chaskiel, who is currently having trouble joining: illinois.central.org (and thus grand) will be offline for a disk swap for several minutes [11:09:07] --- mfelliott has left [11:46:09] --- jaltman/FrogsLeap has left: Disconnected [11:46:47] --- jaltman/FrogsLeap has become available [12:32:07] --- geekosaur has left [12:32:12] --- geekosaur has become available [13:49:14] --- kula has left [13:52:14] --- geekosaur has left [14:02:24] --- geekosaur has become available [14:24:10] --- Simon Wilkinson has become available [14:25:53] I discussed this with Derrick earlier, but I'm of the view that we shouldn't do a 1.4.13 before New Year. [14:29:12] what is the rationale? [14:30:05] should it wait until after 1.6 is finished? [14:30:29] --- kula has become available [14:30:39] my guess is that this is probably the best time to do the release and have people wait a while before upgrading, which is not what we want [14:31:05] on the other hand, this is a better time for academia to upgrade rather than the middle of a semester, isn't it? [14:31:34] I know of several shops that have downtime planned for xmas day and new years eve for upgrades. [14:31:53] these are not academic or research [14:32:16] I'd rather not do a security release immediately before folk all run off on holiday. [14:32:44] if we wait until Jan 3 we will have screwed those shops; if you do it now you will screw folks that leave tomorrow on holiday [14:32:57] there is no perfect answer. [14:34:16] The problem is once we produce an advisory, the floodgates open. [14:34:17] hmm, but screwing those shops means they take some known downtime; for the people leaving on holiday we screw them by leaving them with an open security problem... [14:34:44] Yes. And I suspect that shops who have scheduled downtime over christmas or new year probably aren't internet accessible. [14:35:16] you leave both shops with a open security problem. a shop that has schedule downtime once every six months is not going to be happy with being forced to have downtime the next weekend [14:36:34] could it be at all helpful to give some forewarning that a security advisory/update is forthcoming, without giving any indication as to what it is? or is that worse? [14:36:38] I find it hard to believe that a shop which only has downtime every six months would accept something into a forthcoming release with less than 7 days of testing. [14:37:03] it depends on what the exploit is. [14:38:25] and it depends on whether the change between what they were going to deploy (1.4.12) and what they need to deploy to patch the security exploit is constrained enough that it can be evaluated quickly. That is of course why we issue a standalone release with just the security fix in it. [14:39:23] Which we've already established that we're not going to do. [14:40:05] that decision was obviously made after I went offline [14:40:09] we can still release a patch for just this issue, though [14:40:27] We can, and we will, as we always do. [14:40:41] It's not just one issue now, btw. [14:40:59] and I think that raises the question again of providing a patch that is more targeted than what we currently have, but makes the exploit more obvious [14:44:21] That's the issue with any discussion of any of the exploits, and why I don't want to get into such here. [14:44:56] Seems wise. (I still am blissfully unaware of the nature of the exploit.) [14:46:05] My concern is that the majority of our "customers" will be winding down for Christmas now. The soonest we could feasibly produce a release with binary builds is this weekend. That is too late to get through any internal release management process, and shipped out to clients before the start of the Christmas break. [14:46:17] Therefore, I believe that we should wait until the first week of January. [14:49:37] (For those following along at home, I should perhaps clarify that neither of the problems we're avoiding calling by name are earth shattering. One is a remote denial-of-service attack. The other is a local denial-of-service attack) [14:50:46] thank you for that clarification. [14:51:00] I'm less concerned with Earth shattering than with Earth collapsing [14:51:21] If one of our bugs produces a black hole within the LHC we are all in deep trouble [14:51:40] if one of our bugs produces a black hole within the LHC we won't know it [14:52:06] the universe will just be replaced with something even more bizarre [15:09:35] --- deason has left [15:09:35] --- deason has become available [15:15:00] --- Simon Wilkinson has left [15:30:47] --- deason has left [15:40:56] ... and inexplicable [15:41:15] For all we know, this has already happened. [15:42:31] In any case, since when do we _not_ have a policy of issuing separate releases for security fixes which contain only the fix? We've always done that, so people who need the fix can upgrade to something that differs from a previous release only in the fix. [17:07:52] --- jakllsch has left [17:22:23] --- pod has left [18:53:55] --- jakllsch has become available [20:20:07] --- deason has become available [22:25:25] --- deason has left [22:33:56] --- jaltman/FrogsLeap has left: Replaced by new connection [22:33:57] --- jaltman/FrogsLeap has become available [22:51:42] --- jaltman/FrogsLeap has left: Disconnected [22:51:50] --- jaltman/FrogsLeap has become available [23:06:29] --- Russ has left: Disconnected [23:45:18] --- reuteras has become available