[03:29:32] --- jaltman has left: Disconnected [03:29:42] --- jaltman has become available [05:10:24] --- meffie has become available [05:44:47] --- jaltman/FrogsLeap has left: Disconnected [06:40:22] --- sxw has become available [06:41:42] --- sxw has left [07:14:07] --- deason has become available [07:26:32] --- reuteras has left [07:26:55] --- jaltman has left: Disconnected [07:37:30] --- jaltman has become available [07:50:06] --- Simon Wilkinson has become available [08:13:14] --- Simon Wilkinson has left [08:13:22] --- haba has become available [08:14:39] And if someone would enlighten me how _old_ my AFS client has to be not to be vulnerable I would be pleased as well. [08:27:14] I'm assuming you're talking about cve-2011-0431, then, not 0430 from before [08:27:37] ? [08:36:32] ehm. both [08:37:09] but mostly 0430 [08:38:10] (the double free with the possible execute code "feature") [08:40:35] 0430 doesn't affect clients [08:41:57] and it affects all versions 1.2.8 - 1.4.12.1 and 1.2.8 - 1.4.12.1, inclusive [08:42:03] er [08:42:16] that second one is supposed to be "1.2.8 - 1.5.74" [08:52:49] > 0430 doesn't affect clients does not say clearly in the advisory as it says "in the Rx server process". [08:53:53] As what I contact at port 7001 is an "rx server" (for callbacks and stuff) [08:54:50] so, in other words, we need an announcement that sets everything straight. Is that in the works? [08:55:51] I don't know it simon's comment about ending up grumpy is "in the works". [08:56:03] I doubt it. [08:56:48] it only affects things that run rxkad servers (though the CVE doesn't say that; the person who wrote whatever the CVE came from didn't have the full story, I imagine) [08:57:08] (I don't want Simon grumpy either.) [08:59:32] oh, and to be clear: clients don't run rxkad servers :) [09:07:47] also > does not say clearly in the advisory yeah, well, we didn't write that advisory (at least, if someone here wrote that text, I don't think it was intended to be all that was included in an advisory) [09:09:41] I think it would be very good if we would publish something called "additonal details about CVE-xxx" for both of them, where the scope would be more clear. [09:10:25] As it is now, I feel I know litte and I still know more that other folks that run AFS. You don't even need to know that rx exists to run AFS. [09:12:03] you're not the only one expecting some kind of official announcement [09:28:25] --- rra has become available [09:58:50] --- haba has left [11:11:18] --- lars has become available [11:24:25] Did 1.4.14 change ubik, or something? I just upgraded one dbserver 1.4.12.1 -> 1.4.14, and now I can't get quorum on pt all dbs claim to be clones... [11:25:30] wasabi$/tmp:udebug afsdb1 pt -long Host's addresses are: 130.237.216.11 Host's 130.237.216.11 time is Tue Feb 22 20:25:15 2011 Local time is Tue Feb 22 20:25:16 2011 (time differential 1 secs) Last yes vote not cast yet Local db version is 1298402266.3 I am a clone and never can become sync site Lowest host 255.255.255.255 was set 1298402715 secs ago Sync host 0.0.0.0 was set 410 secs ago Sync site's db version is 1298402266.3 0 locked pages, 0 of them for write Server (130.237.216.12): (db 0.0) is only a clone! last vote rcvd 2 secs ago (at Tue Feb 22 20:25:14 2011), last beacon sent 1 secs ago (at Tue Feb 22 20:25:15 2011), last vote was yes dbcurrent=0, up=1 beaconSince=1 Server (130.237.216.13): (db 0.0) is only a clone! last vote rcvd 2 secs ago (at Tue Feb 22 20:25:14 2011), last beacon sent 1 secs ago (at Tue Feb 22 20:25:15 2011), last vote was yes dbcurrent=0, up=1 beaconSince=1 [11:27:37] (Same with vl, just took a bit longer to break down:-() [11:35:47] and the CellServDB files haven't changed? [11:36:13] Nope. I just reverted to 1.4.12.1 to see if I can get things back, for now. [11:36:28] Where did you get your 1.4.14? official binaries, or elsewhere? [11:36:47] check your CellServDBs; see if you see brackets in them where you do not expect any [11:36:48] Ooops, I'm a moron... [11:37:20] Own-built package. I accidentally overwrote CellServDB on the machine I upgraded... [11:37:25] Thanks! [11:37:45] (I normally re-jumpstart machines, but this time I just replaced the package...) [11:48:56] Ubuntu 11.04 feature freeze is Thursday and its current OpenAFS package doesn’t build against its kernel. So I’d appreciate hearing any opinions from upstream on whether Ubuntu should wait for a 1.4.x release with kernel 2.6.38 suport, or upgrade to 1.6.0pre2. https://bugs.launchpad.net/ubuntu/+source/openafs/+bug/675768 [11:50:22] Offhand, a spring release probably ought to stick with 1.4.x. I thought I heard someone say on Sunday that they'd been working on getting 1.4.x to build on 2.6.38 [11:51:12] Yeah, that would have been me. It’s still waiting on review, though. [11:54:07] Oh, huh. I remembered seeing you, but not where or that it was you who said that. By "waiting on review", you mean there's a patch in gerrit? [11:54:25] Eight of them (3992 through 3999). [11:57:17] is there any requirement that they actually be in the tree before thursday? [12:02:39] Probably not, but a decision on upgrading to 1.6 probably would need to be made before Thursday, and if we’re staying with 1.4, ideally I’d want some kind of reassurance that it isn’t won’t totally break on 2.6.38 and be abandoned by upstream. [12:05:45] you've got +1s on those from the people I think are most likely to know if there's any problems with them, so you're probably in good shape [12:07:15] I don’t know if there are other patches I want too. [12:16:36] --- asedeno has left [13:22:00] --- asedeno has become available [13:34:13] --- asedeno has left [13:38:30] --- Simon Wilkinson has become available [13:41:06] With regards to 1.4.14 vs 1.6.0. I think a distro shipping this spring probably wants to stick with the 1.4.x branch. [13:42:12] Derrick and Jeffrey are travelling at the moment, and Russ doesn't tend to push code changes, so those changes might hang around in gerrit for a bit. Also, I've yet to catch Derrick to ask him about whether he'd rather do 1.4.14.1, or 1.4.15 [13:42:30] We've actually got a fair bit of stuff waiting on 1.4.15, as 1.4.14 was just 1.4.12-with-two-patches. [14:04:56] I can push them if people feel they're safe -- I just don't feel qualified to do the code review myself. [14:05:27] Particularly right now when I'm working with half a brain. :) [14:07:30] I think we're pretty confident that they're safe, and correct. [14:07:46] But I'm not sure whether having those patches in the tree is enough, or do we need to have cut a release with them in too? [14:10:36] --- asedeno has become available [14:14:01] Keeping them as Debian or Ubuntu patches is good enough for now. [14:40:50] --- asedeno has left [14:44:13] --- asedeno has become available [14:51:57] --- Simon Wilkinson has left [15:07:38] --- jaltman has left: Disconnected [15:08:45] What’s up with this? src/afs/LINUX/osi_compat.h:# ifndef KEY_ALLOC_IN_QUOTA src/afs/LINUX/osi_compat.h:# define KEY_ALLOC_IN_QUOTA 0 src/afs/LINUX/osi_groups.c:# ifndef KEY_ALLOC_IN_QUOTA src/afs/LINUX/osi_groups.c:# define KEY_ALLOC_IN_QUOTA 1 [15:12:22] Fortunately, the first one is right. [15:14:53] But KEY_ALLOC_NOT_IN_QUOTA is 2, not 1. [15:25:42] --- Simon Wilkinson has become available [15:26:44] andersk: Let's see if I can find some history. [15:32:25] So, here's the problem. [15:33:04] Those defintions aren't supposed to shadow the Linux ones. Instead, they provide compatibility with the key_alloc function before (Linux commit) 7e047ef5fe2d52e83020e856b1bf2556a6a2ce98 [15:33:30] In that state, key_alloc took a boolean value, which had 0 - in quota, 1- not in quota. [15:35:36] So, for compatibility, those should be KEY_ALLOC_IN_QUOTA 0, KEY_ALLOC_NOT_IN_QUOTA 1 [15:36:04] If Linux has defined its own, then Linux's should win, and we must be using a kernel with a new enough key_alloc to take the new values. [15:36:10] --- jaltman has become available [15:51:56] The "wrong" value in osi_groups.c originally came from sysincludes.h, where it was put as part of one of the first keyring commits. It seems to have been wrong there, and wrong ever since. [16:22:30] But! On openafs-stable-1_4_x, osi_groups.c does not include osi_compat.h, and picks up the wrong value of KEY_ALLOC_IN_QUOTA from sysincludes.h (if the kernel isn’t new enough to define it). [16:23:06] Hmmm. [16:23:46] Some kernel archaeology is going to be required here to check whether the not_in_quota flag of key_alloc ever changed its meaning. [16:25:47] It was called not_in_quota since the introduction of key_alloc (v2.6.10-rc1~20^2~2^2~126). +extern struct key *key_alloc(struct key_type *type, + const char *desc, + uid_t uid, gid_t gid, key_perm_t perm, + int not_in_quota); [16:27:07] and used as expected. + if (!not_in_quota) { + spin_lock(&user->lock); + if (user->qnkeys + 1 >= KEYQUOTA_MAX_KEYS && + user->qnbytes + quotalen >= KEYQUOTA_MAX_BYTES + ) + goto no_quota; + + user->qnkeys++; + user->qnbytes += quotalen; + spin_unlock(&user->lock); + } … + if (!not_in_quota) + key->flags |= KEY_FLAG_IN_QUOTA; [16:31:35] The context, by the way, is that I want to cherry-pick c4537f04 “Don't count root session keyrings against quota” onto openafs-stable-1_4_x. [17:26:12] --- rra has left: Disconnected [17:31:16] --- mfelliott37781 has become available [17:31:16] --- mfelliott37781 has left [17:31:16] --- mfelliott55858 has become available [17:31:16] --- mfelliott55858 has left [17:31:16] --- mfelliott80299 has become available [17:31:16] --- mfelliott has left [17:31:16] --- shadow@gmail.com/owl81329388 has left [17:54:12] --- Russ has become available [18:03:04] --- mdionne has become available [18:05:57] FWIW, I ran some tests with 1.4 + the series of 2.6.38 commits in gerrit on 2.6.38-rc5. No problems. [18:06:34] --- mfelliott80299 has left [18:06:42] --- mfelliott has become available [18:14:07] --- mdionne has left [18:24:04] --- mdionne has become available [18:27:02] * Russ is approving and merging them all now. [18:52:11] --- shadow@gmail.com/owl1FDC9F18 has become available [19:09:55] --- jaltman has left: Disconnected [19:10:10] --- jaltman has become available [19:16:40] --- mdionne has left [19:48:44] --- summatusmentis has left [19:49:56] --- summatusmentis has become available [19:59:27] --- phalenor has left [19:59:33] --- phalenor has become available [21:31:40] --- deason_ has become available [22:47:58] --- phalenor has left [22:48:05] --- phalenor has become available [22:48:08] --- deason_ has left [22:57:33] --- phalenor has left [22:57:39] --- phalenor has become available [23:04:17] --- reuteras has become available [23:39:12] --- Russ has left: Disconnected