[00:47:26] --- dev-zero@jabber.org has left [00:54:17] --- sxw has left [00:54:18] --- sxw has become available [01:19:41] --- dev-zero@jabber.org has become available [01:30:57] --- haba has become available [01:36:51] --- dev-zero@jabber.org has left [01:39:41] --- dev-zero@jabber.org has become available [02:43:25] --- brantgurga has left [03:44:54] --- brantgurga has become available [05:32:38] --- Jeffrey Altman has left: Replaced by new connection [05:32:48] --- Jeffrey Altman has become available [05:41:12] --- mmeffie has left [05:43:41] --- brantgurga has left [05:44:05] Does anyone here happen to know if remctl may forward tickets and if it is configurable? [05:50:40] See 204 [05:51:08] --- Simon Wilkinson has become available [05:51:42] One thing occurs to me, before I stick a load of patches into gerrit ... [05:52:14] What do we want to do about RCSID() - if we want to kill it, then we should do so now, before we end up with a huge number of people having to rebase because we changed the tree ... ? [05:56:12] ooh stdin i remctl - cool [05:56:31] I say kill RCSID [05:59:41] Okay. Changeset on its way ... [06:54:46] i find RCSIDs highly convenient, but, since we can't update, byebye [06:59:03] We _could_ do something with gitattributes, I think. [07:00:24] sxw: (remctl) So the answer is that because GSS_C_DELEG_FLAG is not set, nope, but not that difficult to add I suppose [07:00:58] Yeh, but it's then got to do something on the server side with the credentials it gets given. [07:07:40] sxw: Like put it into a cache file or something ;-) (see rshd/sshd) [07:07:51] --- deason has become available [07:11:42] Anyone fancy reviewing http://gerrit.openafs.org/14 [07:25:47] --- reuteras has left [07:32:44] --- Russ has become available [07:33:58] I've been somewhat resisting adding ticket delegation to remctl since TGT delegation is kind of scary. I suppose some sort of constrainted delegation might be useful, although the client UI would be unappealing. [07:35:23] hm, some of gerrit's emails seem to have the same message-id; that seems odd [07:35:40] If they do, that seems broken. [07:35:54] yes [07:36:18] Can you give examples? Or better yet, open a ticket at jira.source.android.org [07:39:48] the particular ones I'm looking at are the original email for change 9, and an email that came out later saying "Hello Jeffrey Altman, I'd like you to do a code review" [07:39:56] and yeah, I'll file a bug [07:40:16] message-id is ... and I don't like how it looks like they generate that [07:46:54] It looks like all of the messages regarding a change will come with the same message ID. [07:48:08] Actually, not quite true. Everything generated by NewChangeSender will. Anyway, open a bug, and let's see if Shawn will fix it for us :) [07:50:48] It's specific to that case, as far as I can see. The same Java class is used to create the initial 'change created' email, and to send a subsequent email if you add additional reviewers. And that hard codes a message ID based on the change (so it can be used to anchor all subsequent messages into that thread). [07:53:54] --- brantgurga has become available [07:58:44] http://jira.source.android.com/jira/browse/GERRIT-238 [07:59:29] :-/ [07:59:33] uh... sorry [09:02:06] --- haba has left [09:08:41] --- brantgurga has left [09:18:20] WebISO does constrained delegation with a config file on the server that controls what WebISO services can get what service tickets. remctl doesn't have a central server, but you could certainly have a config file (~/.remctl, /etc/remctl.conf) that provided delegation information. [09:18:44] The harder problem is that you don't want "delegation" in the GSS-API sense, which means TGT forwarding. You want to pass credentials for specific services. [09:19:26] I'd argue that in a vast number of cases you don't want GSSAPI 'delegation' - it's just the only hammer we've got. [09:19:30] Right. I want constrained delegation, and I suspect GSS-API doesn't give me a hook into doing that. [09:20:07] WebAuth invented its own protocol for doing it all the way up to its own serialization format for a Kerberos ticket. :/ [09:20:19] In retrospect, that was overkill. [09:20:49] I keep thinking about adding it to cosign. But it makes what's a fairly simple bit of the protocol pretty complex. [09:21:13] I thought Cosign already had it. [09:21:22] Nope. [09:21:28] You delegate your TGT, or you don't. [09:21:34] Oh, gah. [09:22:29] Yeah, WebAuth lets you selectively pick and choose, ask for multiple separate service tickets, etc. The next release will also report to the user on the confirmation page which credentials the remote site is permitted to request on their behalf. [09:22:58] Ah - do you have an OpenID style page which lets the user decide whether the remote site is allowed to request their identity? [09:23:19] Sort of. We have a confirmation page, which can have whatever content each site wants to put on it. [09:23:32] Ours doesn't have a "go away" button, but one could add such a thing. [09:23:55] So, I think if I did this, I'd extend the protocol to allow the server to ask for a ticket for a particular service, which the client then sends as a KRB_CRED (i.e. ignore the GSS-API layer). The remctld configuration would need a way to specify that a particular backend needs a service ticket (should be a simple extension of the existing config), and the client would need similar configuration saying what's allowed (host, command, subcommand, service) [09:24:06] Our cosign implementation aims to be invisible - so you can become authenticated to a trusted site without really being aware of it. [09:24:49] Of course, we're going to suppress that confirmation page for all servers that don't request delegated tickets because people can't cope with a security confirmation page and think it's pointless, but that's an option and people who make better tradeoff decisions than we're making can not turn it on. [09:25:55] jhutz: Yeah, that sounds like the right approach. [09:26:32] * Russ wishes there was more delegation policy built in to UNIX Kerberos implementations and more understanding of delegation in the protocol layer, such as in GSS-API. [09:27:16] I really want to be able to layer policy at the KDC level, the service level, and the user level. [09:27:43] To my mind, the problem is that MIT spent so long pushing back on the idea that any policy could be expressed in the KDC, that we've just ended up in this spectacular mess. [09:28:06] For instance, it would be very nice to disable ticket forwarding by default unless the service principal identifying the service to whom you're forwarding the ticket is blessed in the KDC. [09:28:20] --- stevenjenkins has left [09:28:31] You mean OK-AS-DELEGATE ? [09:28:52] Thus defeating the delegation typo attack that's available to just about any site that allows random host registration and turns on ticket delegation by default in either Kerberos rlogin or ssh. [09:29:29] I'm not sure. At what level does that get applied? [09:29:37] It does exactly what you want. [09:29:49] Then yes. :) [09:29:57] MIT spent around the last 5 years declaring why they weren't going to implement it. [09:30:09] Does Heimdal? [09:30:19] Yes. [09:30:26] Hmmm. [09:30:46] I think there may now be a client site implementation in 1.7 [09:31:11] There are some tricky configuration issues, and upgrade issues. [09:31:20] We're about to start a project to evaluate what KDC we're upgrading to when we upgrade to lenny. [09:31:48] The problem being that you can't tell the difference between a ticket from a realm that doesn't support OK-AS-DELEGATE, and a ticket that you shouldn't delegate to. [09:32:08] We don't do cross-realm, so that actually ends up not being a problem for us. [09:32:58] It's a problem for the few of us who get tickets from other realms, but that's dealable. [09:34:35] --- stevenjenkins has become available [09:35:09] My understanding is that getting OK-AS-DELEGATE support rolled out will also entail client changes. [09:35:27] well, it pretty much has to, right? [09:35:29] Clients which use GSS_C_DELEG_FLAG will always delegate (regardless of the setting of ok-as-delegate) [09:35:39] No, _client_ changes, not library changes. [09:36:05] How do you fix that in the client? [09:36:11] If you wish to respect the flag, you need to use GSS_C_DELEG_POLICY_FLAG to indicate that you're prepared to respect site policy. [09:36:14] well, yes. having the library not do what you think you asked it to isn't exactly quality behavior [09:36:17] Oh, fun. [09:37:00] What about Kerberos rlogin -f? [09:37:06] I'm going to make the change to my OpenSSH code just as soon as I have something I can test against. Basically the delegate credentials option will become on/off/policy [09:37:31] I guess you'd need to make rlogin check the ticket flags itself. [09:37:33] I suppose, specifically, what about the Heimdal Kerberos rlogin -f. Since I know nothing's been touched in the MIT code for years. [09:40:08] I think the big problem here is that it isn't a question of whether your KDC supports it (although, obviously, that helps), but that the libraries and applications on all of your client systems also need to support it. [09:40:32] "flag day or it's of limited value" [09:40:34] For us, our entire OS is built on MIT Kerberos, and we just don't have the man power to rebuild everything to get Heimdal libraries. [09:40:43] Yeah. Well, I mostly only care about ssh, rlogin, rsh, and Firefox/Safari/IE, and IE is pretty much already tied to Active Directory which has this support so it's okay. [09:40:49] It's not a flag day question. Whatever happens, the flag is _advisory_. [09:41:19] It's really rare for us to do any sort of ticket forwarding in anything other than those applications. [09:41:26] And right now we're not even doing it with the web browsers at all. [09:41:41] ssh and rlogin are pretty much the whole of the problem. [09:44:30] MIT 1.7 apparently has "client and KDC support for GSS_C_DELEG_POLICY_FLAG" [09:45:41] http://krbdev.mit.edu/rt/Ticket/Display.html?user=guest&pass=guest&id=5596 [09:48:17] From: Gmane Administrator We have received a request for adding the openafs-cvs@openafs.org mailing list to the Gmane mail-to-news gateway/archive. Does anything even send mail there in the git world? [09:48:38] It's supposed to -- Simon, did you switch it back over already? [09:48:42] Yes. Every submitted change gets a message sent there. [09:49:27] Okay, make that _should_ get a message sent there. [09:50:03] Well, see, here's the thing. You only get to send there if you are cvs@grand.central.org [09:50:17] Derrick said he'd added gerrit@openafs.stanford.edu to the whitelist [09:50:24] Is there stuff in the review queue? [09:50:32] moderation queue, even [09:51:49] It's not on the whitelist. Perhaps he did it wrong. He should have asked. Also, gerrit@openafs.org is not gerrit@openafs.stanford.edu [09:52:18] Ah no, sorry, it should be gerrit@openafs.org [09:52:46] * Russ finishes reading that ticket. Okay, that makes sense. [09:53:59] in fact, i realize i screwed up when i added it [09:54:29] Yes, he did it wrong. He _subscribed_ gerrit@openafs.org to the list, which is not the same as putting it on the list of "these are the only approved posters period". [09:54:54] We probably don't want it subscribed, either - as I doubt that address goes anywhere useful. [09:55:04] Oh, it was subscribed with nomail. [09:55:22] But now, it is unsubscribed, and it is on the whitelist, and I have approved three or four messages that were in the queue. [09:55:32] Great. Thanks. [10:05:26] --- haba has become available [10:25:23] would it be objectionable for vos restore to bump maxvolid if you restore to a volid greater than the vldb's maxvolid? [10:28:05] Well, vos restore certainly shouldn't do it, because it can't guarantee the change is atomic with respect to other people doing the same thing. But it seems like it would be resonable for the vlserver to do so. [10:29:43] okay, so it'd be okay (wrt to protocol standards, etc) for CreateEntry to do so? [10:30:17] (fwiw, syncvldb does bump it without guaranteeing atomicity, but it perhaps makes more sense there) [10:30:18] Personally, I think volume ID allocation is an implementation matter, so I don't think there's a protocol impact. [10:30:32] possibly updateentry/replaceentry, as well? [10:33:34] actually, I've got a few things about this; I think I'll go to -devel instead, since this may get long [10:34:04] That sounds like a plan. You're also more likely to get feedback, I suspect ... [10:34:41] well, feedback can be fast here, which is nice [10:35:11] Yeh - but you only get it from the people who happen to be reading, at that moment in time. I doubt many folk trawl the logs for things to comment on. [10:59:06] --- brantgurga has become available [11:07:58] i trawl [11:34:43] --- brantgurga has left [11:46:42] --- Jeffrey Altman has left: Replaced by new connection [12:02:16] --- brantgurga has become available [12:23:54] If there's anyone around with the required powers, could they kick the openafs-announce moderation queue? [12:33:12] --- Jeffrey Altman has become available [13:10:56] done [13:13:07] You should send me mail detailing any web config changes that should happen to complete the transition, such as redirects and the like. [13:16:52] --- haba has left [14:15:29] --- shadow@gmail.com/owlD195B32A has left [14:33:42] --- Derrick Brashear has become available [14:54:27] --- Derrick Brashear has left [15:11:48] --- dev-zero@jabber.org has left [15:40:11] --- deason has left [15:43:31] --- mdionne has become available [15:45:33] --- deason has become available [15:52:46] --- dev-zero@jabber.org has become available [16:01:19] --- kaduk@mit.edu/owl has left [16:03:24] --- kaduk@mit.edu/owl has become available [16:12:58] --- Russ has left: Disconnected [16:14:29] --- Derrick Brashear has become available [16:26:41] --- brantgurga has left [16:31:08] --- rra has become available [16:46:08] --- brantgurga has become available [16:59:45] --- Derrick Brashear has left [17:27:22] --- Derrick Brashear has become available [17:30:16] does anyone know why cvs.openafs.org (aka grand) is no longer providing access to /cvs ? [17:30:52] I'm fairly sure that we said it would remain up for a while even if no additional commits would go to it [17:32:36] or perhaps I'm losing my mind. [17:33:23] or your computer is [17:41:55] --- kaduk@mit.edu/owl has left [17:42:36] --- kaduk@mit.edu/owl has become available [17:44:38] --- Jeffrey Altman has left: Disconnected [17:48:31] --- pod has left [17:49:14] --- pod has become available [17:49:35] --- pod has left [17:52:01] --- Jeffrey Altman has become available [17:53:28] --- cclausen has become available [17:53:50] msysgit ships with a cvs.exe binary which doesn't work with my cvs trees [17:56:41] jhutz: I did email you awhile back about that surveys.openafs.org CNAME? [17:57:27] and can someone tell me the git / gerrit equiv of this page: for Doug Burgett's photo gallery [17:57:31] err paste fail [17:58:04] and can someone tell me the git / gerrit equiv of this page: http://www.openafs.org/cgi-bin/wdelta/MAIN/index/month/openafs/ [18:08:07] > surveys.openafs.org Uh, I don't remember. What about it? [18:08:18] create it [18:08:25] let me find the email... [18:08:40] I don't think there is an equivalent. Last I knew Simon's new-wdelta didn't support group-by-month. If you don't care about that, you might get something useful from http://git.openafs.org/?p=openafs.git;a=shortlog [18:08:59] surveys.openafs.org CNAMEd to yuengling.your-file-system.com [18:09:28] oh, nice. yeah I don't care about grouped by month [18:10:37] Oh, right. You asked for it the night before the 24-hour road rally. [18:27:08] surveys.openafs.org is done cvs.openafs.org/cvs has never done anything useful Working on www.openafs.org/doc now I am tempted to make cvs.openafs.org and www.openafs.org/cgi-bin/cvsweb/ (but not things below the latter) redirect to git.openafs.org. [18:49:58] OK; www.openafs.org/doc/ now redirects to docs.openafs.org. If you still want to see the old stuff, use www.openafs.org/old_doc [18:50:53] BTW, note that grand has no /afs tonight and part of tomorrow, because it lives in the dementia.org cell, whose root.afs lives on meredith, which lives in Chaskiel's office, which is moving to 311 tomorrow. [18:51:32] can the volume not be moved to different machine before then? [18:51:42] before 3 hours ago? no. [18:51:43] the machine is already down [18:51:46] oh, I see [18:51:58] AFS can't help with that :-( [18:52:21] actually, i might be able to cheat. [18:52:48] afs can't go back in time yet? feh! [18:53:01] no, you need Time Machine integration for that [18:53:25] http://bugs.debian.org/536450 look familiar to anyone? [18:53:27] /usr/src/modules/openafs/src/libafs/MODLOAD-2.6.26-2-686-MP/Kvice.xdr.c: At top level: /usr/src/modules/openafs/src/libafs/MODLOAD-2.6.26-2-686-MP/Kvice.xdr.c:1421: error: expected declaration specifiers or ‘...’ before ‘FsCmdInputs’ [18:53:57] can't say it does. [18:53:58] 1.4.11pre3 [18:54:06] 2.6.26 kernel. [18:54:28] that file is generated; wish they'd have included it [18:54:44] lemme see if mine matches [18:55:06] --- stevenjenkins has left [18:55:08] --- deason has left [18:55:11] --- abo has left [18:55:20] and then everyone leaves [18:55:40] --- abo has become available [18:55:46] * rra also double-checks that they ran m-a clean first. [18:57:58] * rra had no build problems on 2.6.26, so something weird is going on. [18:58:08] That's actually a kernel with which I test. [18:59:09] --- deason has become available [19:02:01] --- stevenjenkins has become available [19:02:53] alycia.dementia.org has a replica, no doubt stale, but good enough. i'll fix the vldb shortly. [19:08:11] I actually was tempted to spin up a VM this afternoon, put a fileserver on it, and move some volumes there. But I ended up not having time, and I forgot that grand had this dependency. [19:08:23] why? [19:08:27] dementia has a fileserver [19:08:31] I don't think it's worth messing with for only ~12 more hours of outage. [19:08:40] sarah-merrit.dementia.org [19:08:54] Oh, for some reason I didn't think that was real, based on what was on it [19:09:05] alice-comfort isn't real. sarah-merrit is [19:09:33] Yeah, and what about 10.254.0.218? [19:09:36] :-) [19:09:46] it's real. *you* just can't see it [19:12:05] BTW, I _am_ considering setting up tuzanor as a more-permanent VM host in my office, connecting the tape drives I already have to it, and using it to do backups for dementia and gco [19:12:47] (I had considered doing that before, but the machine I was going to use as the host was rather flaky and has since been retired. tuzanor's a decent machine, though; it may even still be in warranty) [19:36:11] --- mdionne has left [20:13:42] --- kaduk@mit.edu/owl has left: Lost connection [20:13:42] --- asedeno has left: Lost connection [20:13:42] --- andersk@mit.edu/vinegar-pot has left: Lost connection [21:20:54] --- kaduk@mit.edu/owl has become available [21:27:03] --- asedeno has become available [22:15:47] --- cclausen has left [22:18:48] --- deason has left [22:27:31] --- rra has left: Disconnected [22:54:11] --- dev-zero@jabber.org has left: Replaced by new connection [22:54:12] --- dev-zero@jabber.org has become available [23:03:23] --- reuteras has become available