[21:25] doot doot [21:33] Action: Dymaxion looks around. [21:33] howdy [21:34] hey [21:34] sup? [21:35] not too much. [21:35] loooong day at work today, or at least it felt like it, trying to get stuff wrapped up. [21:36] hehe :) [21:37] brenda just called [21:38] she's still driving [21:38] ok [21:38] eta? [21:38] she didn't know [21:39] but I told her not to worry about it since we do it to her all the time :P [21:39] ok [21:39] I'll keep an eye on channel [21:41] oki ^^ [22:00] i'm here! [22:01] yay! [22:01] yay [22:01] Action: ar4chne *pokes* dym [22:01] ouch! [22:01] Action: Dymaxion grins. [22:02] :D [22:02] so, i think we should do something to make me dispensable [22:02] k [22:02] yeah? [22:03] i mean, not that y'all need ta dispense with me, just that it seems like it would be better to not have me being the critical path item _all_ the time. [22:03] Action: Dymaxion nods. [22:03] ;) [22:03] In the long term, that sounds great; can we do anything towards that in the shorter term? [22:04] well, in an ideal world, how would it go? [22:04] We'd each grab bugs as we had time, fix them, and consult with each other as needed [22:04] i realize i'm going to be the critical path until 1/31, but i was hoping maybe we could Take Steps after that [22:05] or maybe even start before. [22:05] We'd still need to do groupthink for new features and for methodology stuff, but be could definitely work more independently on the actual code [22:05] S, what do you think would be a good way to go about the team thing [22:05] ? [22:05] Action: Dymaxion nods [22:05] no idea :/ [22:06] hey, did hyphos lose some keys? [22:06] lose some keys? [22:06] what? [22:07] I was going to open a tunnel, and it doesn't seem to like my key any more [22:07] hrm [22:07] i'm getting prompted for a password, too [22:07] nice deflection from an uncomfy topic, Dym ;) [22:07] gimme a bit and i'll poke around [22:07] sorry, didn't mean to derail [22:07] well, maybe not uncomfy, but .. difficult [22:08] Action: Dymaxion nods. [22:08] i think we just need tasks [22:08] just asign us something, aspa [22:08] and we'll bang our heads [22:08] ok. so is the big problem lack of parallelization in the coding part? [22:08] and if our heads get too bloody, we'll ask for help [22:08] :) [22:08] Action: Dymaxion grins. [22:09] Action: asparagi doesn't want any bloody heads [22:09] You parceling out stuff might be a good way to start, really, because you're in the best position to know what's going to be the hard stuff... [22:10] I'd like to eventually get to a place where we're sort of picking more cooperatively, but that'll take a while [22:10] I think as far as you being critical path, it's mostly a coding issue [22:10] ok. let's try me being dictator in a polo shirt for a couple weeks til we ship, then re-evaluate? [22:10] haha, awesome [22:11] It's somewhat of a time issue on my part, at least, because I haven't had the time to step up in other places, but hopefully that's gonna change [22:11] Action: Dymaxion grins. [22:11] Works for me. [22:11] (have you heard that song? it's in the shop mix) [22:11] I don't think I have [22:11] it's by the bobs. when i am up next weekend i'll play it for you [22:11] cool. :-) [22:12] https://jail04.gamma.zettai.net/bugs [22:12] is where i will be when GPRS finishes loading [22:12] ok [22:13] first, feature question: do we still want to shoot for XML? [22:13] ok [22:14] I would like to, if possible. [22:14] ok. so, let's discuss file format for the next 45 mins [22:14] ok [22:15] do we have svn back so we can use the example file there? [22:15] (if not, we'll work around it)_ [22:15] i have last week's copy checked out [22:15] ditto [22:15] shall I throw it on dymaxion? [22:15] no svn yet [22:15] i think we should start & when we have svn back, great [22:15] ok, I'll do that [22:15] yah, just link us [22:17] http://dymaxion.org/trike/trike.xml [22:17] ok...you guys work on the xml stuffs and I'll fiddle w/ svn [22:17] oh, nice extra comments [22:18] are we at rules? [22:18] I wanted to clarify stuff instead of just marking it out, because I couldn't figure out what was going on for a while last time when I opened it up after a week [22:18] yes [22:18] i vote type by attribute [22:18] reference vs. attribute typing again. [22:19] I think that's preferable too; just have to enforce that text rules can't have children in the code [22:19] i think S said that's what she'd been arguing to start with [22:19] works for me [22:19] yeah. i don't remember whether that's enforced now. [22:20] duly noted [22:20] maybe we can look up mad xsd tricks & enforce it there [22:20] ok. verb="create" [22:20] yeah... I'm skeptical if that's doable, but [22:20] i think the problem was the word verb [22:20] ok [22:21] i don't have a problem with it now, although i suggest we change some code to use that instead of action [22:21] type again, intead? [22:21] (in the right places) [22:21] Action: asparagi is nervous [22:21] hrm... either one works for me, as long as we're consistent [22:21] it's data, not class.. [22:22] I guess I'd rather do , because it seems more consistent with how we do things. [22:22] hrm. [22:22] ok, good point. [22:22] ? [22:22] Action: asparagi shrugh [22:22] i like verb better... [22:23] I like verb too, but changing too much stuff in the code makes me twitchy... [22:23] or this.... [22:23] i think the refactoring browser can Just Do It. [22:23] if that isn't a big deal and I should not be twitchy, I'm cool with verb -- it certainly fits best [22:23] ok, works for me. [22:23] but you're right, it's awfully close to ship [22:24] let's make that change tonight so we have some time to test [22:24] if you're comfortable doing it in RB, I think that's the right thing to do. [22:24] ok, done [22:24] uh, what's next [22:25] instead of i propose [22:29] oh, right [22:29] for threats, a riskFactor [22:29] sorry [22:31] do threats have a riskfactor? I guess it's calculated; we want to store risk and exposure explicitly though, I suppose [22:31] our existing types (in Squeak) are: regular (effectively, text), and, or, reference, DoS, elev [22:32] yes, threats have an explicit riskFactor: it's what you edit with the pink squares [22:32] oh, duh [22:32] so they have both a risk factor and a risk [22:32] btw i have tried using it on a real project & i completely agree re: color [22:32] Action: Dymaxion grins. [22:32] but in the file format we should only store riskFactor, i think [22:33] you think? [22:33] I think I disagree [22:33] yeah. there's no field for risk in the data model [22:33] It means our data format isn't normalized, but risk is a very complicated number to calculate [22:33] when you read it in, what do you do about inconsistencies? [22:33] I don't want to have to rewrite the graph traversal code to use our output format [22:34] mmm, there is that :) [22:34] it's non-canonical; if you have an implementation which is capable of calculating it, you discard those values. [22:34] gwar [22:34] especially the magic loop breaking part we will eventually have in there.. [22:34] gwar? [22:34] i dont know whats wrong [22:34] your head is bloody because you went to a concert? [22:35] :) not yet [22:35] (don't they throw blood at gwar concerts?) [22:35] implementations should be aware of any manipulations to the data model that may break the saved risk values and do something appropriate to the user if it happens [22:35] yes [22:35] Action: asparagi advocates tickling users who misbehave [22:36] Action: asparagi is tired & silly [22:36] ok. having it be noncanonical makes sense. [22:37] maybe the nonconforming implementations should discard conflicting types of values. [22:38] e.g. user edits 1 riskFactor, all risk values for the whole model are discarded [22:38] yeah, sounds reasonable -- otherwise you have to figure out what's important, and that's just as hard. [22:38] or we could just leave them & next time we read it in, fix them [22:38] but that's a little much on the silent failure front [22:39] well, we'll definitely do that, but I want users of whatever other tool to know that they just fucked up the risk model and that it's broken -- I think that's important [22:39] ara, is it file permissions on the key file? or a containing directory? i've had ssh implementations ignore key files w/ promiscuous permissions [22:39] oh, i see [22:40] the nonconforming tool must announce its lack of coolnes [22:40] s? [22:40] yes [22:41] as soon as the user messes with it, it has to let them know if it can't recalculate [22:41] i wonder how the heck TrikeThreat got an instance variable named ruleIsNil. [22:43] ah. it's an implementation-specific caching thing. [22:44] threats also have an action reference [22:45] reload? [22:45] s/childAttacks/children/? [22:45] oh. [22:45] maybe i don't mean that [22:46] i think we should leave parents out, actually. [22:46] hrm. [22:46] again, I'm not sure if I agree, but much less strongly so this time. [22:46] it's implementation-specific [22:47] and a pain in the wazoo [22:47] It'll save a lot of work for the users of the file, although it's not strictly necessary. [22:47] hrm, ok. [22:47] I guess walking the list of attacks isn't too bad [22:47] i think it will actually cause them more work [22:47] for editing, yeah, you're right [22:48] they will almost always want to trace top-down when asking ?s, and any redundancy will just give interoperating programs more to goof up [22:49] ok [22:49] so then we could call childAttacks attacks [22:50] oooooh [22:50] i have an idea [22:50] that makes me a little twitchy... seems like we're dropping a bit too much information there, but I could be convinced [22:50] except its half-baked [22:50] yeah? [22:51] re: attacks, is children better? [22:51] I think so [22:51] then we cauld do the same thing for rules [22:51] that satisfies my desire for parallelism [22:52] so my idea goes something like this: [22:53] our types of attacks are weird, in that AND, OR, text are parallel, and DoS & Elev are parallel, but they aren't parallel togethe [22:53] r [22:53] we should fix this [22:54] but really the whole point of the threats is that they are the roots of the trees [22:54] Action: Dymaxion nods. [22:54] which we already know becaus they hang off the actions [22:54] so we could do something excessively clever somehow [22:55] hrm [22:55] like make the action be a target of the threat [22:55] so when we get the other little trees working we can slip them right into the file format [22:56] Action: asparagi says deviously [22:56] mmmm. [22:58] what about and, or, text and structured? [22:58] and so perhaps riskFactor becomes DoSRiskFactor and ElvRiskFactor and lives in action (which is fully populated, but some are marked unintended), and then only the optional risk and exposure elements serve to distinguish the fact that a "text" attack happens to be a threat? [22:58] structured? [22:59] reload? [23:01] yeah, like to be parallel to actor, asset [23:06] also, and and or rules should never be negated [23:06] i.e. that field shouldn't appear [23:08] done and done [23:08] wow, it's really coming along [23:08] what do you think of my interpretation of the structured type as shown in the file right now? [23:09] I pulled subtype out as redundant and pushed it into the type of the element in the target sub-element. [23:09] Action: asparagi is still reading [23:10] interesting [23:10] i like moving the risk factor stuff to be a characteristic of action [23:11] it seems like it removes redundant information, but it may involve more read-ahead than we want for dispatching on the target type of the structured action [23:11] yeah -- that just gets noise out of the way -- it's not really an attribute of the attack at all [23:12] i think it should be in a separate element, e.g. 1 [23:12] hrm, I'll buy that [23:12] esp. given how much our risk model is likely to change [23:12] that will be really extensible for extra attack targets [23:13] i'm still thinking about the structured thing [23:13] less mess with optional attributes for the risks then too [23:14] (intended vs. unintended actions) [23:14] yah [23:14] or changes b/c of whether the action has a rule [23:14] yeah [23:15] wrt structured, can we make exposure go away somehow? [23:15] i don't think it makes sense for non-action attack targets [23:15] but maybe it does? [23:15] no, it doesn't, but there's no where else in the model to hang it. [23:16] hrm, maybe we should make a tag there too [23:16] S, are you reading, bored, or...? [23:16] that seems much better, actually. [23:16] well, every attack will have a cached risk, yes? [23:17] will it? [23:17] still trying to fix the problem [23:17] *go team*rahrah* [23:17] sorry :/ [23:17] I dunno, you guys are doing great [23:18] 'sok, just want to make sure you're not sitting around being bored..., [23:18] hehe, nah :) [23:18] we don't have any implementation of risk beyond exposure, actually [23:18] so i have no idea [23:18] ok [23:18] maybe we should just leave it all out [23:19] sorry, I guess "m a bit bummed out and confused about like atm...it's making me a bit untalkative perhaps [23:19] for attaks [23:19] life, too [23:19] yah.... [23:19] putting it in a seperate element like that seems to give us maximum flexibility, which is sort of why I was voting for that [23:19] Action: Dymaxion nods. [23:19] i can see that [23:20] i think leaving it out would be even more flexible than that already flexible solution [23:20] oh dear, time flew. it is way late [23:21] hrm, ok, I'll buy that. Shall we leave exposure as a seperate element? [23:21] why not just mark that unresolved & we can do it saturday? [23:21] heck if i know [23:21] :) I was going to jump in and say "go to sleep" in about 5 more minutes [23:21] Action: ar4chne wags her finger like a mom [23:21] it's not a hard calculation [23:21] (exposure) [23:21] Action: asparagi giggles [23:22] hehe [23:22] yeah... I guess I'd like to avoid the client of the format having to do math whenever possible, even if it is easy [23:22] damn, i wanted to leave 15 min to exercise my newfound power as dictator and assign Bugs. [23:23] Action: Dymaxion grins. [23:23] haha :D [23:23] are we having the other meeting tomorrow, aspa? [23:23] Action: asparagi cackles maniacally [23:23] yah, let's [23:23] we confound your power by talking too much! [23:23] you can work on the dictatorship then and assign via email [23:23] ok [23:23] it'll get me out of work on time [23:23] Action: Dymaxion might be there, might not... no idea what my schedule will look like yet [23:24] ok :) we can make it another shorter session so you can get more sleep [23:24] ok. each of you tell me about how long the bug i give you should take to fix [23:24] I promise I'll be more talkative then [23:24] e.g. 2 bugs, 15 min ea [23:24] or 5 bugs, 10 min ea [23:24] what's our due date? [23:24] i can't guarantee anything under 10 min [23:24] *shrug* whatever...just assign and I'll work to get them done [23:25] altho, I was hoping to be able to demo captain on sat [23:25] um, let's say saturday when we get together [23:25] oh! [23:25] that's much better. [23:25] ok [23:25] i won't give you any bugs [23:25] so if you assign too much, I won't have a demo!!@#$ [23:25] haha, ok [23:25] it's just working on osx atm [23:25] kinda roughly [23:26] wow! [23:26] I'm trying to get images from the clipboard right now [23:26] i am so excited [23:26] i bet i can find like a zillion test users for yau [23:26] and converting from CGImageRef -> wxImage objects is being a bitch [23:26] I'm going to be really conservative and say that I have one hour to burn before saturday (I may have more, but I really don't want to overextend right now) [23:26] everyone has been mentioning problems i think it could solve [23:26] yay demos! [23:26] oh, awesome :) [23:26] ok. i will give you ~1 hr of bugs [23:27] I'll try and get it shiny by then...altho the image support may or may not happen [23:27] cool [23:27] it would be really cool if it did [23:27] in smaller pieces so you can do part more easily, if they take longer than i think [23:27] yay captain! [23:27] cool [23:27] oh, that is so exciting. :) [23:27] :) [23:27] now go to bed! [23:27] Action: ar4chne waggles her finger again [23:27] okay, okay. [23:28] ;) [23:28] Action: Dymaxion giggles [23:28] :) [23:28] awesome work, guys ^^ [23:28] chat atcha both tomorrow [23:28] I'll see you tomorrow, ara, and you via email, dym [23:28] cool [23:28] I'll hop on if I'm around/awake/free [23:29] great :) [23:32] ar: let me know when I should try to check the xml file back into svn [00:00] --- Thu Jan 26 2006