[00:00] there's a lot of memcache errors [00:02] Indeed. [00:02] Fortunately the access logs are free of such silliness. [00:03] The 9138 librarian.logs are a nice touch, though. [00:03] wgrant: phew [00:03] wallyworld_: ^ [00:03] thanks for lookig guys [00:04] the chances would have been very small given no-one knew about the page anyway [00:06] wallyworld_: yes. Sadly we have journos that follow us stealthily looking for things like this. [00:06] journos and others, but the journos we eventually find out about ;) [00:07] do they work for news corp or something? [00:07] i suppose they tap our phones also [00:08] Nah, they're too busy pirating Foxtel and Austar, aren't they? :) [00:08] wallyworld_: I detect skepticsm. [00:09] which is fine, I don't care if you're skeptical or not. Just as long as you *are* paranoid. :> [00:09] lifeless: none intended. poor attempt at humour [00:09] wallyworld_: kk [00:14] http://morecss.org/ [00:14] wgrant: bug 933839. to me that means revoke all direct grants (pillar and artifact) for team members as well as the team. whereas what it does now is just revoke the team but leaves any member's direct access in place. agree? [00:14] <_mup_> Bug #933839: Share nothing with a user or team < https://launchpad.net/bugs/933839 > [00:14] wallyworld_: Nobody knows how that UI looks, AFAIK [00:15] It can't be implicit. [00:15] I may have missed some mockups, though. [00:15] wgrant: there would be a new radio button otpion [00:15] atm there is "All" "Some" "Nothing" and there would be "Nothing (revoke team)" [00:16] i'm just checking i understand the Nothing (revoke team) behavour [00:16] All | Some | Nothing (except not really) | Nothing (yarly)? [00:16] Right. [00:17] It needs to remove explicit APGs and AAGs for the team, and any APGs or AAGs where the grantee participates in the team. [00:17] This is pretty handy. [00:17] yes, that matches my understanding [00:17] 'cause it means that I, as a random outside observer, can get everyone's access revoked :) [00:18] how? you need to be a project owner to do it [00:18] * wgrant creates a team and subscribes it to a project's private bug. [00:19] * wgrant quietly adds the project team to that team. [00:19] $projectowner says "wtf is this team doing in my sharing view, you should have nothing" [00:19] it would only be direct team members afaiui [00:19] Project team no longer has any privileges :( [00:20] so if it's only direct team members that wouldn't work [00:20] But considering only direct team members puts it in conflict with literally everything else that deals with teams in Launchpad. [00:21] perhaps, but it's the only sane way to do it [00:21] Wait, why would it remove transitively? [00:21] it wouldn't, that's what i'm saying [00:22] rephrase, why would it remove more than the grants that mention that team|person directly ? [00:22] lifeless: The design calls for a way to revoke a team's access and access held by any of the team's members/participants. [00:22] why does it want to do that ? [00:22] s/design/requirements [00:22] I do not know. [00:22] wallyworld_: can you point me at the LEP ? [00:23] just a sec, i find it [00:23] I suspect its an overgeneralisation from one of the oem scripts [00:23] https://dev.launchpad.net/LEP/ManagingDisclosure [00:24] so, Constraints and Requirements/must/4 is the thing [00:24] its got some nuance in there [00:24] It doesn't explicitly say that it requires this. [00:25] the mockups and screenshots they were based on did [00:25] It is the private team requirement, however. [00:26] wgrant: sorry, where is that ? [00:26] lifeless: Requirements/must/4 is the reason the private team expansion is done. [00:27] It's probably also the reason transitive revocation is done, but it doesn't explicitly require that. [00:27] wgrant: the private team expansion does not follow from 4 as I read it. Can you help me understand ? [00:27] "If the user has access via a team, the view must explain how to remove either the user or the team to unshare. " [00:28] i think item #1 explains why private team expansion is required [00:28] That implies that there is a way to see the user who is only participating in sharing by being a member of a team. [00:28] Ah, true. [00:28] a project owner must see who has access [00:28] wgrant: (4) - you can enter a userid and see their teams; this is quite different to expanding the teams. [00:29] lifeless: The leakage implications are only vaguely dissimilar. [00:29] wgrant: there is room to mitigate on one side, not on the other. I agree it has serious complications though. [00:30] so i won't start this today - we can discuss tomorrow at the standup [00:31] on (1), when I reviewed the LEP I read that as 'person', not as implying every concrete user. [00:31] 1. A lists of all the users with all or some things shared. [00:31] The view must also show exactly how the user has access, for example: directly or via a team [00:31] quoting the LEP doesn't help much. [00:32] That pretty clearly implies that it must be transitive. [00:32] yes; its also a major problem [00:32] Certainly. [00:40] lifeless: wgrant: whenever the team has discussed this, we've said that if a private team is granted access to a project via a policy, they are putting themselves in a position where their info has a right to be known to the project owner/drivers and so long as they are warned.... [00:41] we've already done this for subscribing private teams to bugs for example in the current access model [00:41] wallyworld_: The only previous disclosure was LimitedView [00:42] This is effectively full View [00:42] It's not warned about, and is in many cases far worse. [00:42] not warned about yet [00:42] And we need to remove bug-retargetting and multi-pillar bugs. [00:42] and it's only to project owner/drivers [00:42] The latter of which was vetoed. [00:42] and as a project owner, i have a right not to have people spy on my project [00:43] Right,. [00:43] wallyworld_: you need to reconcile that with 'as a private team owner, I have a right not to disclosure the membership of my team' [00:43] lifeless: well, if you want to see someone else's project, then you must be prepared to tell them who is lookiing [00:44] so if a private team is granted access to *my* project, i have every right ti see who they are [00:44] wallyworld_: thats true; but is it the team or the members that are looking ? [00:44] both [00:44] as a member of a team with access, i have access also [00:45] if that's not acceptable, then don't subscribe your private team to a public project [00:45] So [00:46] That argument would potentially hold water if Launchpad wasn't crap. [00:46] But, as I went into slightly with mpt earlier, bugs are too unowned for that to work. [00:46] This whole thing would be far easier if Launchpad wasn't gratuitously different from every other bugtracker in history :( [00:46] wallyworld_: that approach cuts both ways: if you don't trust the admins of ~private-team, don't grant access to ~private-team to your project. [00:47] that's true [00:47] wallyworld_: Mitigating both those risks results in a system where you get limited view in both directions : [00:47] - access grants grant reflexive limitedview on the team (and only that) [00:47] sounds like there's slight disagreement here when we've already embarked on an approved design :-( [00:48] if one wants to be sure that ~someteam is managed well, you can talk to its owner, which limitedview lets you see - and that has to be transitive (clearly) [00:48] well, I say clearly; I think it is. [00:49] i think so [00:49] you can walk up until you get a person you know. [01:39] wallyworld_: We missed one call in terms of the privacy banner, but I have that working. [01:39] StevenK: excellent! [01:40] StevenK: so you are now a yui guru :-) [01:40] wallyworld_: One thing I can't work out is on initial page load, clicking the link the overlay doesn't have a value set, but if I choose a value and then click the link again, it does. [01:41] StevenK: the current value needs to be passed into the choicesource constructor [01:41] so check the value: xxxx bit [01:41] wallyworld_: value: information_type.value, [01:42] and you've logged that just to be sure it is correct? [01:42] Not as yet ... [01:43] take a quick look just to be sure [01:44] information_type.value is undef. That would explain it. [01:44] StevenK: the value should be USERDATA etc, not 2, 3, 4 etc [01:45] And doing it again involves the same object and it keeps track of what was selected. [01:47] wallyworld_: So I'm getting a hold of the element correctly, but how can I return what it is currently showing? .value was my guess, and it's obviously wrong. [01:48] StevenK: you are trying to read the dom value that is not set yet [01:48] you need to seed the initial value from the model [01:48] ie the json request cache [01:48] Ah. [01:48] Back to the Python [02:03] wallyworld_: You have it backwards. It needs to be 3, not EMBARGOEDSECURITY. [02:04] StevenK: in the sharing table widget, it does need to be USERDATA etc. i guess we are using slightly different data models [02:05] Now I'm happy enough with the JS. [02:05] Now to stab Zope's form handling. [02:05] it would be nice to be consistent though [02:06] StevenK: is today auditor day? [02:06] lifeless: I was still deciding if I was going to do something on it, what did you have in mind? [02:07] just touching base to make sure you're not blocked [02:07] Not blocked, just feeling that the light at the end of the tunnel is an oncoming train. [02:13] wgrant: How can I debug why information_type doesn't show up in +filebug, assuming that I've ripped out security_related everywhere I saw it in the browser code. [02:35] lifeless: "Overwhelmed" would be a nicer way to say it. [02:36] StevenK: w.r.t. auditor ? [02:38] lifeless: For both auditor and this disclosure work -- but the difference between the two is I have a clear direction, a clear goal and the steps in terms of the current disclosure work. [02:39] StevenK: well, if you want those things for auditor, I'd be happy to help make them up. [02:40] lifeless: I think that will help. :-) [02:40] I'm available whenever you like to do that then. [02:40] lifeless: After lunch? [02:40] I don't know what that means, but sure :) [02:41] lifeless: 12:40 here, I'll be having lunch for ~30 at 1pm. [02:41] Read as 'in a little bit over an hour' [02:42] lifeless doesn't have lunch? lunchless? [02:42] Haha [02:42] mealless [02:43] i bet lifeless can charge from usb [02:43] haha [02:43] I'm not sure I want to know where his charging indicator is. [02:44] tmi [02:49] StevenK: col [02:49] *cool* [03:27] wallyworld_, jcsackett: Bug #971241 [03:28] <_mup_> Bug #971241: Sharing details page breaks when an inaccessible bug is shown < https://launchpad.net/bugs/971241 > [03:29] hmm. one could argue that a pillar driver should be able to see bugs filed against it [03:29] Most certainly not. [03:29] Owner perhaps. [03:29] But there is no justification for drivers to. [03:30] why not drivers? [03:30] (even owner is debatable) [03:30] i don't agree owner should be debatable [03:30] if i own a prject, i have a right to see what bugs are filed against it [03:30] wallyworld_: Because being someone who manages blueprint priorities shouldn't permit me to see embargoed security bugs. [03:31] wgrant: careful of cause and effect [03:31] but what if that info is required to help manage the priorities [03:31] wgrant: ITYM 'Being someone who manages blueprint priorities does not imply seeing embargoed security bugs.' [03:31] lifeless: Perhaps. [03:31] wallyworld_: then you will have the ability to see those bugs separately. [03:31] wallyworld_: e.g. via a grant to see them. [03:32] Now, the owner can always grant themselves access. But I think having the separation is useful for large projects. [03:32] wallyworld_: our job is to provide solid primitives that let folk drive the system. [03:32] so the sharing details page should just filter out bugs without view access i guess [03:32] (vs preconcluding particular detailed answers). We're writing a fine grained rules toolkit here. [03:32] wallyworld_: It probably needs to say that they exist. [03:33] But it can't say what they are. [03:33] it sounds like a case of limitedview [03:33] LimitedView considered harmful. [03:33] same as duplicate-on-private; see the thing exists but no details. [03:33] Indeed. [03:33] why do you say limitedview considered harmful ? [03:33] i'm not familiar with the implementation details of the sharing details page as i didn't write it, i'd have to look [03:34] lifeless: Well [03:34] lifeless: In a lot of cases it's difficult to do sensibly. [03:35] In some cases it works well. [03:35] But it's not the answer to everything :) [03:35] Anyway. [03:36] Drivers seeing them unconditionally is not open for debate. They must not. [03:36] Owners I suspect can't always see them either, but that is more arguable. [03:37] (eg. it's much easier to audit leaks if the owner has to explicitly add themselves in a logged fashion before they can see the embargoed security stuff) [03:38] i feel sorry for drivers trying to managing priorities in the absence of all required information eg there could be a really important embargoed security bug filed they don't even know about [03:38] i guess if the had limited view and knew the bug number they could ask [03:40] what does the 'sharing details page' do ? [03:40] show the artifacts (bugs and branches) a person can see [03:40] for a pillar [03:40] lifeless: https://qastaging.launchpad.net/launchpad/+sharingdetails/wgrant [03:40] k [03:41] wallyworld_: The Ubuntu drivers are not privy to the security bugs. [03:41] wallyworld_: The security team manages the security bugs. [03:41] From end to end. [03:41] ok [03:42] wallyworld_: so remember the user story: for proprietary projects (the focus), drivers could be either a) granted access to all proprietary bugs or b) granted access to all proprietary+security bugs [03:42] wallyworld_: thats a project policy decision, not ours. [03:42] true [03:42] wallyworld_: in this case, given that anyone can check +sharingdetails, the first iteration probably should just elide inaccessible bugs. [03:43] wallyworld_: (which it would have by default if the stock bug access query constraints were used) [03:43] and branches [03:43] indeed [03:43] lifeless: it wouldn't use the stock bug access queries because it would be done of the flattened table [03:43] off [03:43] we can look at adding limitedview onto this in the future, but it will run into the same complexity-performance things we have today. [03:44] wallyworld_: I would use the same queries. [03:44] s/I/It/ [03:44] Just with an additional constraint to say "wgrant has access" [03:45] looking at the code, it uses findArtifactsByGrantee [03:45] Sure [03:46] so right now it queries directly off the flattened table [03:46] From that it could grab a list of bug IDs [03:46] And feed them into bug search. [03:46] agreed, just saying what it dies now [03:52] * wallyworld_ has to go and get a haircut [03:57] lifeless: Skynet? [04:08] wgrant: Did you miss my earlier question? [04:09] StevenK: Indeed. Do you have a branch? [04:09] wgrant: Locally. I can paste a diff, but it's 4 files changed, 103 insertions(+), 284 deletions(-) [04:10] diffme [04:10] StevenK: yup [04:11] wgrant: http://pastebin.ubuntu.com/911045/ [04:12] StevenK: That's quite the obese diff you have there. [04:12] I told you! [04:12] Also, --syntax=diff :) [04:12] StevenK: waiting for you to come online [04:13] lifeless: I have been for the last ten minutes. [04:13] StevenK: bah [04:13] In fact, I was starting Skype when I queried you with Skynet [04:13] skype fail fail fail [04:13] pkill -9 skype [04:13] lifeless: Book a flight to Sydney? It might be quicker and simpler. [04:14] foad [04:14] though I may come over mid april [04:14] StevenK: heh [04:14] StevenK: What does not working? [04:14] I see the field fine. [04:15] wgrant: The information type doesn't show up in Bug:+filebug [04:15] Oh [04:15] On filebug [04:15] I see [04:19] StevenK: Works better when the template doesn't refer to security_realted [04:19] security_related [04:20] wgrant: Which template? I didn't see that. [04:20] StevenK: The filebug template? :) [04:20] lib/lp/bugs/templates/bugtarget-filebug-guidelines.pt [04:21] Right. I was looking at the filebug.pt I think. [04:21] wallyworld_: which hair? [04:22] StevenK: Also, numeric enum values have no place outside the DB access layer. [04:22] But it looks like you might be using one here in the JS. [04:22] Hard to tell. [04:22] wgrant: Where am I using them? [04:22] + var information_type_by_value = {}; [04:22] But it seems to be by name, not value. [04:22] So it's just a lie, and not wrong. [04:22] * jtv hopes wgrant's mother didn't hear that [04:23] lifeless: I just ran into a funny one with oopstools' date-dir repo. Hope I filed it in the right place: bug 971255 [04:23] <_mup_> Bug #971255: Crash in _findHighestSerialFilename < https://launchpad.net/bugs/971255 > [04:23] wgrant: I get the number back, I need to map it back. [04:23] StevenK: Whatever is returning the number is a horrible person. [04:23] And a bug. [04:23] jtv: thats probably the right place, though that method indicates you're using the old naming scheme which is awful [04:24] lifeless: I don't think we made a conscious choice to do that — isn't this the default? [04:26] lifeless: also, we happen to have other log files in the directory. Their names happen to have dots in them, but not something to rely on. [04:31] jtv: I've commented on the bug; happy to discuss more here, or there, or both as appropriate. [04:31] lifeless: thanks for the fast response. I just summarized your message on there as well. [04:32] lifeless: where do I find out how we constrain our repository object? [04:32] Sorry, constrict. [04:32] No idea what it means actually. :) [04:38] construct [04:38] jtv: ^ sorry, ELOCAL for a minute there [04:38] Sure. [04:38] * wgrant shreds BeautifulSoup [04:38] lifeless: We pass it an error dir and an instance id. [04:39] don't pass an instance id [04:39] pydoc oops_datedir_repo - [04:39] | :param instance_id: If None, OOPS file names are named after the OOPS [04:39] | id which is generated by hashing the serialized OOPS (without the [04:39] | id field). Otherwise OOPS file names and ids are created by [04:39] | allocating file names through a UniqueFileAllocator. [04:39] | UniqueFileAllocator has significant performance and concurrency [04:39] | limits and hash based naming is recommended. [04:39] (easier to have it here to reference) [04:40] jelmer: Can bug #296153 be closed now? [04:40] <_mup_> Bug #296153: does not mirror bzr branches over ftp

< https://launchpad.net/bugs/296153 > [04:40] lifeless: thanks! I guess they'll still have timings in them to order them by time? [04:41] jtv: if you have the default hooks installed there is a timestamper in there,yes. [04:41] Is there anything I need to do to make sure we have the default hooks installed? [04:41] (the filenames don't, though) [04:42] jtv: I urge you to make an oops/ subdir or something though, because oops isn't designed to have other stuff in the repository, and you may well encounter other bugs like this. The robustness that is there is to deal with oops-managed temporary files, for instance. [04:42] I see. Oh well. Thanks for the quick help! [04:43] jtv: (defaulthooks) - they are default :) You have to take action to remove them. [04:43] OK [04:43] Laziness is the most reliable safety mechanism. [04:44] jtv: so based on this, I'm going to close the bug (or do you want to retarget it to maas)? [04:45] Wait — it still shouldn't crash just because we passed a non-recommended option, right? [04:45] the only way it can get crud like this in place is if you combine its own storage area with other content [04:46] its not designed to do that, adding code to handle it would just be cruft, unless we want to design it to handle htat. [04:46] But the problem content was generated by the datedir repo. The other crud was incidental. [04:47] jtv: 'directory' in that call should be a date-named subdirectory [04:47] jtv: not the explicit path you passed in. [04:47] I wonder why it wasn't. [04:47] Oh wait, it was! [04:47] So it was purely the datedir repo that broke itself. [04:47] jtv: one possibility is that you're constructing a datedirepository without an instance id somewhere else [04:48] (perhaps an earlier version on your own machine) [04:48] that would write oopses with hashed names [04:48] (but in the subdirectory) [04:48] Yup! Found it. [04:48] jtv: whats the actual name it is choking on ? [04:48] jtv: again though, this isn't a supported config, I don't see value in trying to handle it [04:48] I don't know what name it was choking on… give me a minute to set things up for breaking again. [04:49] okidoki [04:49] We only found out that this was not a supported config by asking you. [04:50] if it is an interaction between the deprecated naming system and the new, that can be fixed I think by deleting the old style logic [04:50] we shouldn't need it anywhere now, it was purely for migrationary purposes. [04:51] and this bug would indeed be evidence that we need to do that. [04:53] Missed a step. Back to step 1. :/ [05:00] wgrant: Right, that sorted that out. But the default is "(no value)" rather than Public. [05:01] StevenK: Indeed, you'll need to change the default. [05:01] And ensure that the interface forbids None. [05:01] information_type = EnumCol( [05:01] enum=InformationType, notNull=True, default=InformationType.PUBLIC) [05:02] That's no interface, that's a column. [05:03] Doh [05:04] lifeless: gah. Can't reproduce. I have no way of telling what file was breaking it earlier. [05:04] Ah no, maybe I need to start pserv. [05:11] lifeless: having trouble reproducing the problem, because pserv seems to disappear every time I start it. This needs more investigation. But what may be happening is that one process (which constructs its datedir repo without an instance id) oopses out and then another tries to log an oops to a repo on the same directory but with an instance id. [05:17] yes, that would make sense to me [05:17] I think we should remove the old code at this point [05:17] the only reason to keep it was un-upgraded analysis consoles [05:17] of which there are none that will be migrating to the new codebase now; (u1 are upgraded, isd are experimenting with sentry) [05:17] Meanwhile, I don't think the filenames are timestamped. :-( [05:18] jtv: the metadata is inside it [05:18] jtv: you can also capture the oopses directly, either by subscribing to them via rabbit, or using a test specific publisher. [05:18] jtv: (depending on your test environment) [05:19] My rabbit wasn't running earlier. [05:19] (and you may not have a rabbit publisher setup either, but you can do so pretty easily) [05:20] there is a rabbit-oops-fixture in the LP code base that can probably be pulled into oops-amqp (with an optional dep on fixtures) [05:20] What kind of usage would I get out of catching them that way? [05:20] you avoid the ten sorts of mess that happen by going and looking on disk after the fact [05:20] For now I think it'd be good to minimize rabbit dependencies, given the recurring shutdown problems. [05:21] I have to go cook [05:21] Don't let me stop you; I know what to fix. Thanks again. [05:22] but if you want a minimal replacement, you can use repo.republish() to pickup all the oopses that are in a datedir repository and throw them at another publisher [05:22] so [05:22] make a new repo object [05:22] oopses = [] [05:22] repo.publishers.append(oopses.append) [05:22] repo.republish() [05:23] # make assertions about the oopses in 'oopses' here [05:23] * lifeless will be back later [05:59] wallyworld_, StevenK: https://code.launchpad.net/~wgrant/launchpad/wbr-is-void/+merge/100357 is pretty simple if someone has a sec. [06:00] i can look [06:04] wgrant: i always thought it was simply [06:04] wallyworld_: In HTML, yes. [06:04] wallyworld_: But that's not well-formed XML, and lots of people parse us as XML. [06:05] is well-formed XML, XHTML and HTML5. [06:05] And it's valid HTML5 and XHTML5. [06:05] is only well-formed XML and XHTML, not well-formed HTML, and not valid in any of them. [06:06] wgrant: Except that BeautifulSoup doesn't think so? [06:06] ok [06:06] Yeah, BeautifulSoup has an outdated hardcoded list of void elements. [06:06] so do any tests fail that use BeautifulSoup? [06:06] Every other element it assumes the end tag is missing if it's self-closing. [06:07] wallyworld_: Just the one. I replace it with before passing it into BeautifulSoup. [06:07] Search for BeautifulSoup to find the test. [06:07] that seems like an odd behaviour [06:07] wgrant: can you please add an XXX then [06:07] lifeless: It's designed to deal with tag soup. [06:08] lifeless: So it's sort of justified. [06:08] If a non-void element doesn't have an end tag, it should probably assume the end tag is just missing. [06:08] wallyworld_: It isn't really an XXX. [06:08] StevenK: It is. [06:08] wgrant: ... - where would that ever make sense ? [06:09] lifeless: I don't think HTML knows about [06:09] Does it? [06:09] I'm pretty sure that's just an XML thing. [06:10] Regularly used in HTML to make a polyglot document. [06:10] wgrant: is the space before the /> required? my eyes prefer [06:10] But only on void elements, because otherwise the parser cries. [06:10] wgrant: it does for foreign elements [06:10] http://www.w3.org/TR/html5/syntax.html [06:10] lifeless: That's for HTML5. [06:10] Which is a bit more sensible. [06:11] But let's see. [06:11] wgrant@lplucid:~/launchpad/lp-branches/wbr-is-void$ bzr grep '[^ ]/>' | wc -l [06:11] 10623 [06:11] wgrant@lplucid:~/launchpad/lp-branches/wbr-is-void$ bzr grep ' />' | wc -l [06:11] 11095 [06:11] wallyworld_: ^^ I win [06:11]