[00:14:23] --- Russ has left: Disconnected [01:17:14] --- sxw has become available [02:08:56] --- sxw has left [03:04:27] --- jaltman/FrogsLeap has left: Disconnected [05:29:40] --- sxw has become available [05:34:37] --- sxw has left [07:04:15] --- sxw has become available [07:06:56] --- sxw has left [07:07:56] --- deason has become available [07:13:36] --- sxw has become available [07:14:52] --- sxw has left [11:08:06] --- summatusmentis has left [11:08:13] --- summatusmentis has become available [11:15:40] --- rra has become available [11:31:58] --- sxw has become available [11:34:25] --- sxw has left [11:46:07] --- pod has left [11:46:13] --- pod has become available [11:50:40] --- sxw has become available [12:00:35] --- sxw has left [12:03:57] --- Simon Wilkinson has become available [12:35:20] --- summatusmentis has left [12:35:25] --- summatusmentis has become available [12:49:03] --- deason has left [12:49:03] --- deason has become available [13:39:24] --- jaltman/FrogsLeap has become available [14:39:27] So, the only platforms on which we will use the LWP fileserver are AUX, PMAX, HPUX 10 (and older), Next, Sun OS, VAX, Alpha OSF, NCRX86, NetBSD (1 and older) [14:39:51] Given the archaeological nature of that list, is there any reason to keep it in the tree? [14:49:15] Alpha OSF and HP-UX 10 are the only ones on that list I can imagine anyone realistically still having file servers on, and they could just keep using old versions if they absolutely have to. (Derrick's SunOS file server doesn't count.) [14:50:41] (I'm currently dreaming of the day when we have no LWP in the tree at all ...) [14:50:43] there are old-but-slightly-less-old OSes that we work on whose pthread support sucks [14:50:50] OpenBSD something-or-other [14:51:29] You'd have to jump through hoops to get a non-pthread fileserver on OpenBSD - we default to installing tviced on all OpenBSD versions. [14:53:18] iirc the only reason we didn't change the makefile to conditionally do that is I don't know what version the switch happened [14:53:47] but it was old enough not to be a concern... I just don't think it was as old as the other examples [14:54:30] Ah, cool. This isn't something I'm suggesting for 1.6, but I think it should be something we move towards for 1.8, or 2.0. Writing new code that supports two threading libraries is a real pain. [14:56:23] not all of our features work on the lwp viced/volser; if it's not a lot of trouble, I don't think you'll get any complaining if something new doesn't [14:56:30] Once we have a viable pthreaded ubik I believe it will be appropriate to begin the process of deprecating LWP. I don't think we are there yet. [14:57:25] Removing the lwp fileserver from the Unix build would simplify it a lot. [14:58:27] I hope the pthreaded ubik corrections can be pushed to master in a couple of months [14:58:55] I don't think any decisions about the fileserver need wait for pthreaded ubik, though. They're two completely separate kettles of fish. [15:01:42] I'm not aware of significant complexities in the fileserver due to pthread/lwp... or maybe it's just that I feel they are dwarfed by the dafs/nondafs complexities [15:01:46] I suggest that in conjunction with the 1.6 release announcement we announce deprecation for future releases and ask people to report any remaining usage of the LWP fileserver. I'm not expecting that we will receive many responses that say 'yes' [15:02:12] and I hope you're not waiting for us to provide more tubik fixes, because I don't have any to give you [15:02:29] deason: The fact that we build half of util within tviced is an abomination :) [15:03:06] I'm not waiting for SNA [15:05:48] jaltman++ [15:06:30] Cool, so once 1.6 has shipped, and we've waited for the trickle of replies, we can look at pulling that from the tree. [15:07:03] I'd really like to find the time to rejig the build system at that point, so we build things once per set of build options, rather than once per directory (Yes, I'm looking at you, pthreaded ubik) [15:07:49] I'm not sure how getting rid of src/viced helps you not rebuilt util in tviced, though... [15:08:01] Well, it helps start tidying things up. [15:08:39] and if there are more tubik bugs, it sure would be nice to about them [15:08:58] The idea is that at that point you kill off tviced, and move it all into viced. Then you build a pthreaded util library that everything can link to, rather than them all building their own stuff. Doesn't have to be done in that order, but zapping viced first avoids doing things twice. [15:09:34] yeah, but I think that's more of a "get rid of lwp entirely" thing, since we can do that when we don't need lwp stuff using util [15:09:38] we have already discussed them. the code is not thread safe because the assumptions about when lock acquisition and releasing takes place when LWP is in use have little to do with where in the code they are acquired [15:10:41] lock transitions in LWP must be viewed as only occurring when a thread yield takes place (explicit or implicit) [15:10:56] the only thing I've even heard mentioned is "has anyone done an audit of tubik correctness"; I've never seen anyone point out an actual bug [15:11:28] The point I made at the time is that if SNA did not perform such an audit, it was not correct. [15:11:33] (er, well, recently, that hasn't been fixed, etc) [15:16:36] An audit was performed by Jeff Hutzelman which identified a number of issues including gerrit/3764 which was patched by Marc Dionne. Subsequent work will of course be submitted to gerrit as it is completed. [15:21:59] okay, but 3764 was a ReadAnyWrite issue, not a tubik issue per se [15:22:49] correct but it was uncovered during the audit. that was my point. [15:32:54] Yes, an audit was done. Yes, I've been lame about posting it to the list. I'll be fixing that probably tomorrow. [15:39:28] thank you. [15:56:50] --- deason has left [16:01:11] --- jaltman/FrogsLeap has left: Disconnected [16:32:29] --- deason has become available [16:33:26] so, I see CVE-2011-0430 and CVE-2011-0431 were in a debian security announcement today... so I should take that to mean that these issues are public now? [16:34:36] No, I think we just remove Debian from our Christmas card list. [16:35:56] I think they've also made 0431 up. [16:36:47] well, I'm just a little surprised that a DSA is how I find out [16:36:55] Me too. [16:37:22] Well, not that it's how I find out, but that they don't have the good grace to tell us that they're going to go ahead and publish. [16:37:49] I suspect that this is the last occasion that we'll let them see security advisories ahead of time. [17:27:12] I've sent something to openafs-announce. Hopefully when Derrick reappears he will read, and if he thinks it's appropriate, push. [17:30:36] So, to mention, Debian had been in extensive communication with Derrick and I about that, and my understanding of the last exchange was that they should go ahead because we'd already made a public announcement of the vulnerability as part of the 1.4.14 release announcement and there wasn't any reason to wait further. [17:30:48] They definitely asked first, and held off until they got confirmation. [17:31:15] The 1.4.14 release announcement that went out in January did pretty much say "there's a security vulnerability that this release fixes." [17:31:52] Well thank goodness openafs-announce is moderated, or we'd all look like a bunch of clueless idiots who have no communication skills whatsoever. [17:32:51] I missed that we'd announced it in the 1.4.14 release announcement too. :/ The Debian folks approached me with "um, so, upstream already announced the security update, when can we do the same thing?" [17:32:59] Not really those words, but something like that. [17:34:07] Anyway, I'm really sorry about the surprise. Because of work I'm only paying attention with half a brain, and I didn't wrangle communications anywhere near as well as I would have with a full brain. [17:34:42] Oh, it's not you that I'm grumpy at. [17:34:52] Sounds like you're not thinking about what packaging for debian/kfreebsd would look like, then. [17:35:09] kaduk: We don't have kernel support yet, do we? [17:35:22] I suppose we could provide just the userspace stuff. [17:35:38] I didn't think there was a sysname and whatnot, so I hadn't started thinking about how to package it. [17:36:29] rra: sure we do! [17:36:31] Although we could presumably build all the userspace stuff, particularly the servers, right now with a sysname matching the regular i386 and amd64 sysnames. [17:36:43] Well, there's no sysname, right. [17:36:53] kaduk: I probably should phrase it more like "we don't have kernel module build support, do we?" [17:36:59] I have no idea how kernel modules work in debian/kfreebsd. [17:37:20] I know we have FreeBSD kernel support, but I don't know how much that translates to the debian/kfreebsd situation. [17:37:36] I'm not sure where the 1.4.14 release announcement says that it's a security release, btw. So I think Andrew's surprise wasn't misplaced. [17:38:04] All platforms: - Fixes to avoid a double free in the Rx RPC library. [17:38:23] You have to know enough to know "double free" == "security vulnerability", but that's not a big leap. [17:38:26] Yeah. That's not the same as saying "Security release, please upgrade as soon as possible" [17:38:39] That's true. [17:39:00] Which is pretty much what the Debian release has said. [17:39:10] Yeah, that's the standard boilerplate for all security advisories. [17:39:31] Yeah, I have no idea how debian/kfreebsd modules work. But Alejandro has pulled up a VM that I will try to play with at some point. [17:39:57] I now vaguely remember some sort of discussion about being cagey in the 1.4.14 release announcement, but I didn't remember that at the time. :/ [17:40:05] Anyway, have to go home. Will be back on in 30 or so. [17:40:08] --- rra has left: Disconnected [18:02:54] --- Russ has become available [18:02:54] --- Russ has left: Lost connection [18:03:34] --- Russ has become available [20:27:50] Blech, panic on 1.6.0pre2. [20:38:03] In the VM subsystem (page queue lock not held). But this may just be my own fault for running an inconsistent kernel version. [20:48:43] > I've sent something to openafs-announce. then some mail server somewhere has it. i looked 90 minutes ago. i looked again. "nope" [20:52:44] > HP-UX 10 we never supported it. the relevant vfs header never got release for pre-11.0. > Derrick's SunOS :p [21:02:08] The VFS header isn't required for the server build, though, is it? [21:02:22] I was assuming most of those platforms were server-only. [21:03:10] it's not required for the server. but since we never could build the client i don't think we ever bothered to fix the missing server support eoither. well, other than the rx support i recreated [21:55:31] > I've sent something to openafs-announce just noticed this comment; there was text already in the ticket... is it based off of that? [21:56:55] --- deason has left [22:12:26] --- jaltman/FrogsLeap has become available [22:38:46] --- Russ has left: Disconnected [22:42:45] --- reuteras has become available