| === ursula_ is now known as Ursinha | ||
| === ursula_ is now known as Ursinha | ||
| barry | #startmeeting | 15:02 |
|---|---|---|
| MootBot | Meeting started at 09:02. The chair is barry. | 15:02 |
| MootBot | Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE] | 15:02 |
| barry | hello everyone and welcome to this week's ameu reviewers meeting. who's here today? | 15:02 |
| jtv | me | 15:02 |
| mars | me | 15:02 |
| barry | jtv: hai! | 15:02 |
| jtv | barry: learning dutch, I see! | 15:03 |
| abentley | me | 15:03 |
| EdwinGrubbs | me | 15:03 |
| gmb | me | 15:03 |
| barry | jtv: D'r ken geen koekje meer bij | 15:03 |
| jtv | :-) | 15:03 |
| barry | i know we have a bunch of folks at the tl sprint | 15:04 |
| barry | allenap, danilo_ ping | 15:04 |
| gary_poster | me | 15:04 |
| allenap | me | 15:04 |
| barry | bac, BjornT, cprov ping | 15:05 |
| cprov | me | 15:05 |
| mars | salgado, gary_poster, ping | 15:05 |
| bac | me. darn, forgot again. | 15:05 |
| salgado | me | 15:05 |
| barry | intellectronica: ping | 15:05 |
| mars | gary_poster, oops, sorry | 15:05 |
| gary_poster | :-) | 15:05 |
| barry | noodles: ping | 15:05 |
| barry | rockstar: ping | 15:05 |
| noodles | me (sorry) | 15:05 |
| barry | [TOPIC] agenda | 15:06 |
| MootBot | New Topic: agenda | 15:06 |
| barry | * Roll call | 15:06 |
| barry | * Action items | 15:06 |
| barry | * Mentoring update | 15:06 |
| barry | * Peanut gallery (anything not on the agenda) | 15:06 |
| barry | [TOPIC] * Action items | 15:07 |
| MootBot | New Topic: * Action items | 15:07 |
| barry | * allenap to look into storm/sqlobject result set compatibility | 15:07 |
| allenap | I'm going to try and do that today :( | 15:08 |
| gary_poster | barry: re agenda, didn't we have that conversation from a review...trying to recall...two points... | 15:08 |
| gary_poster | barry: what is appropriate to import in a view... | 15:08 |
| barry | gary_poster: yes, it's on the list, sorry didn't move it up | 15:08 |
| gary_poster | barry: cool | 15:08 |
| barry | allenap: np, thanks. we'll leave it on the list | 15:09 |
| barry | * flacoste to work on API reviewer cheat sheet | 15:09 |
| intellectronica | me | 15:09 |
| barry | he's not here today, but does anybody know anything about it? | 15:09 |
| gary_poster | I can guess :-) | 15:09 |
| barry | gary_poster: yeah :) | 15:10 |
| barry | we'll leave it on the agenda | 15:10 |
| barry | [TOPIC] mentoring update | 15:10 |
| MootBot | New Topic: mentoring update | 15:10 |
| barry | noodles: how are things going? any questions/concerns? | 15:10 |
| noodles | barry: I haven't started yet... not sure who my mentor is? | 15:10 |
| noodles | Should I find one myself? What's the normal process...? | 15:11 |
| noodles | (I was away last week) | 15:11 |
| barry | noodles: ah, dang. i will work on that and get back to you. i remember now that henninge is also a mentat | 15:11 |
| noodles | Great! Thanks :) | 15:12 |
| bac | and is deryck an official mentat now? | 15:12 |
| barry | [ACTION] barry to find a mentor for noodles | 15:12 |
| MootBot | ACTION received: barry to find a mentor for noodles | 15:12 |
| barry | bac: not quite. he's going to do js reviews (mentored) for now | 15:12 |
| barry | anything else on mentoring? | 15:13 |
| barry | [TOPIC] peanut gallery | 15:14 |
| MootBot | New Topic: peanut gallery | 15:14 |
| barry | we have something gary_poster wants to bring up. let me paste the discussion notes first | 15:14 |
| barry | gary writes: | 15:14 |
| barry | * What is the goal (are the goals?) of our use of security proxies and the import nazi? My understanding is that they are "belt and suspenders" to try and keep us from revealing private information. | 15:14 |
| barry | * Do we still agree with those goals? | 15:14 |
| barry | * Do we feel that our use of security proxies helps us with these goals? | 15:14 |
| barry | * Do we feel that our use of the import nazi helps us with these goals? | 15:14 |
| barry | As we know, security is very hard, and trying to answer these questions well should not be done lightly or too quickly. | 15:14 |
| barry | I am hopeful that the small, specific question of whether we should import removeSecurityProxies in view code will fall out obviously, if not easily, from our answers to the discussion above. | 15:14 |
| barry | take it away gary_poster the orchestra leader | 15:14 |
| gary_poster | :-) | 15:14 |
| gary_poster | OK so, context | 15:14 |
| gary_poster | barry and I were talking about what is appropriate in a view | 15:15 |
| gary_poster | we agreed on this: | 15:15 |
| gary_poster | "I think view methods should only return immutable Python basics like strings and ints, or security wrapped objects." | 15:15 |
| gary_poster | We disagreed on this: | 15:15 |
| gary_poster | Also, ideally view code would not import removeSecurityProxy. AIUI, This is exactly the kind of import that import nazi is supposed to prohibit: tools that *allow* a view to return unproxied objects. While arguing for the import nazi to be eliminated might be appropriate at a reviewers meeting, we should not make it more and more ineffective without recognizing what we are doing. | 15:15 |
| intellectronica | dicts? | 15:15 |
| barry | intellectronica: dicts, lists, tuples, sets are all basic objects, and okay | 15:16 |
| gary_poster | intellectronica: dicts are problematic because they can contain things that need to be proxied. You typically need them to be proxied so that the viral thing works. | 15:16 |
| intellectronica | ah ok | 15:16 |
| barry | with gary_poster 's caveat about *what* those containers contain | 15:16 |
| gary_poster | right. as a practical matter, disagree with barry's assertion. as a theoretical matter, yeah, kinda sorta | 15:17 |
| gary_poster | so maybe we need to dig into that. but I was just expecting to dig into the import question | 15:17 |
| jtv | What's going to keep us honest w.r.t. interfaces, if not the security proxies? Or is the idea that we don't need to be? | 15:18 |
| barry | gary_poster: so, i've had to deal with this quite a bit lately, with the change in permissions to private membership teams | 15:18 |
| gary_poster | jtv: security proxies don't necessarily keep us honest irt the interfaces. You can open up other things in the zcml, and in fact sometimes you need to | 15:18 |
| barry | there are a lot of places where i've had to unwrap objects to get to their .name attribute. clearly we can't do that in the model. istm that the view is the most natural, *best* place to do it | 15:18 |
| barry | and at least it's clearly obvious! when you see removeSecurityProxy() that's a big red flag that something special is going on | 15:19 |
| gary_poster | barry: and yet what you are implying is that this could in fact be a utility function elsewhere | 15:19 |
| bac | barry: in using the removeSecurityProxy to get at a private team's name you must first be sure that your doing so doesn't in fact leak data | 15:19 |
| jtv | ...which you ensure in the model, not in the view. | 15:19 |
| barry | bac: yes agreed. but isn't the view the right place to ensure that? | 15:20 |
| gary_poster | bac: right. | 15:20 |
| gary_poster | barry: I'd like to step back to principles | 15:20 |
| barry | jtv: i think the model is the wrong place in fact | 15:20 |
| barry | gary_poster: sure | 15:20 |
| jtv | Well here's a counter-example: | 15:20 |
| bac | barry: yes. but i don't want to see a pattern of "oops i can't get to the name, better remove the security proxy" when the proxy is doing it's job | 15:20 |
| jtv | we implement private kumquats. How do we make sure all the pre-existing views respect kumquat privacy? | 15:21 |
| gary_poster | barry: as I said in the discussion notes, this is a question in my mind about our use of the import nazi, and our goals for our own protection in the view | 15:21 |
| gary_poster | views, I should say | 15:21 |
| gary_poster | so, the import nazi has been around a looong time. | 15:21 |
| gary_poster | why is it there? | 15:21 |
| gary_poster | do we still want it? | 15:21 |
| gary_poster | I don't think we're going to resolve those here | 15:21 |
| gary_poster | but I think we need to start the process of resolving them | 15:21 |
| gary_poster | I have guesses as to why they exist | 15:22 |
| gary_poster | sorry, why the import nazi exists | 15:22 |
| gary_poster | and I think they are for belt and suspenders of the views | 15:22 |
| mars | gary_poster, that may be a question for Francis | 15:22 |
| gary_poster | to try to prevent data leaking out | 15:22 |
| gmb | That's belt and braces for the brits in here. | 15:22 |
| mars | gary_poster, or Curtis | 15:22 |
| barry | gary_poster: that's kind of separate from the rSP-in-views issue. afaik, importnazi doesn't enforce that | 15:23 |
| henninge | sorry ... volume turned down ... | 15:23 |
| gary_poster | barry: disagree. | 15:23 |
| gary_poster | barry: I think that we have gradually taken the teeth out of the import nazi | 15:23 |
| barry | gary_poster: just saying, i-n doesn't prevent rSP-in-view. maybe it should, maybe it shouldn't | 15:23 |
| gary_poster | it is a tool that is supposed to help as developers and reviewers conform to code standards, supposed to help us...do something | 15:24 |
| barry | francis has the strongest views about what i-n is for, i believe | 15:24 |
| barry | gary_poster: yes, do something :) | 15:24 |
| gary_poster | if I understand its goal correctly (if!) then it is specifically designed to keep thigs *like* rSP from happening | 15:24 |
| barry | (btw, it's importfascist, strictly speaking :) | 15:25 |
| jtv | barry: right, might be Italian instead of German | 15:25 |
| gary_poster | ah, thank you, that is less potentially offensive. | 15:25 |
| abentley | gary_poster: That presupposes that rSP-in-view is against policy. | 15:25 |
| bac | gary_poster: we don't yet have agreement on the policy regarding rSP in views. if we agree it is forbidden then import socialist can be made to flag it | 15:25 |
| gary_poster | so, I think we, as reviewers, or as a team, or as francis :-) need to decide why the import nazi is there | 15:25 |
| gary_poster | abentley: absolutely. that's the question I'm asking. let me try to sum: | 15:26 |
| salgado | the import nazi is there to make sure browser code can't have access to unsecurity-proxied objects | 15:26 |
| salgado | without explicitly calling rSP | 15:26 |
| gary_poster | salgado: so rSP is in fact the blessed way around this? | 15:27 |
| salgado | yes | 15:27 |
| gary_poster | my concern is that this is not known, written clearly, etc. | 15:27 |
| gary_poster | salgado: ok cool | 15:27 |
| barry | aside: it does other things too, like enforce __all__'s | 15:27 |
| gary_poster | barry: but I think that is still part of the same goal | 15:28 |
| salgado | gary_poster, yeah, it's very likely this is not written clearly anywhere | 15:28 |
| barry | gary_poster: right, in that it's intended to enforce certain coding standards | 15:28 |
| barry | salgado, gary_poster so yes, we definitely need to make it clear in our standards the official way of doing things | 15:29 |
| gary_poster | barry: so, I move that we add a rationale for our use of import fascist, and our use of security proxies, and what the proper way of "breaking glass" is, to our reviewing guidelines | 15:29 |
| abentley | gary_poster: That sounds more like general-purpose documentation to me. | 15:30 |
| gary_poster | the import fascist is just a tool for us to enforce our policies, and I'd rather we understand/follow/lead from the intent of our policies than the letter of our policies | 15:30 |
| gary_poster | abentley: not sure how we are disagreeing? | 15:30 |
| abentley | reviewing guidelines are for reviewers, not necessarily for developers. | 15:31 |
| gary_poster | abentley: oh I see. yes, agree | 15:31 |
| barry | gary_poster: agreed. i'd like to give francis a chance to weigh in too. gary_poster this sounds like a discussion for the ml. would you like to start that there? i will take an action to document any decisions in the wiki | 15:31 |
| gary_poster | barry: yes, I'll take that. | 15:32 |
| barry | gary_poster: thanks | 15:32 |
| barry | [ACTION] gary_poster to take importfascist discussion to the ml | 15:32 |
| MootBot | ACTION received: gary_poster to take importfascist discussion to the ml | 15:32 |
| barry | [ACTION] barry to document all importfascist decisions in the appropriate wiki page | 15:32 |
| MootBot | ACTION received: barry to document all importfascist decisions in the appropriate wiki page | 15:32 |
| gary_poster | are we cool on the security-proxy-around container bit that we skimmed over? | 15:32 |
| gary_poster | or should we add that to an agenda for a later meeting? | 15:33 |
| barry | gary_poster: do you mean the entire container (dict, set, list) should be security proxied, or just the items it contains? | 15:33 |
| adeuring | me -- sorry for being late... | 15:34 |
| gary_poster | typically you proxy the container for simplicity. If you *really* want to proxy the items only, you could, I guess, but that's not lazy for the programmer or the computer, typically | 15:34 |
| barry | gary_poster: wouldn't in most cases the items in the container already be proxied? | 15:34 |
| barry | gary_poster: talking about how the view sees them, not necessarily what it returns | 15:34 |
| gary_poster | barry: ahhhh...that's too general for me. not sure. when you get a container from a storm result, I would expect the result set to be proxied, so that the items are proxied just by the "viral" story | 15:36 |
| barry | gary_poster: that would be my expectation too | 15:36 |
| gary_poster | barry: but...yeah...maybe :-) as a simple-to-follow rule (for which perhaps there are exceptions) I'd suggest that containers should be proxied | 15:37 |
| abentley | gary_poster: A result set is an object, though, not one of the items Barry mentioned. | 15:37 |
| barry | gary_poster: maybe we should rename removeSecurityProxy() to yesReallyLeakPrivateData() | 15:37 |
| gary_poster | abentley: agreed | 15:37 |
| gary_poster | barry: :-) | 15:37 |
| * bac must duck out early. sorry. | 15:37 | |
| abentley | gary_poster: How would you define the security policy for a dict? | 15:38 |
| gary_poster | abentley: I was just trying to come up with a general case I could think of. I'm not sure what our general cases of returning basic python containers in views really are. I'm just suggesting that proxying them is a nice simple rule. security policy for a dict: I Think this is predefined. It's public for the standard dict API. | 15:38 |
| gary_poster | mapping API I should say | 15:38 |
| abentley | gary_poster: So for dicts, we would have them wrapped with a security proxy that did nothing? | 15:39 |
| barry | gary_poster: but that's just to ensure that any objects returned are themselves proxied right? | 15:39 |
| gary_poster | abentley, barry: right on both counts | 15:39 |
| gary_poster | as barry said, having a dict with the individual items wrapped would probably be fine, especially for our use cases | 15:40 |
| barry | i /think/ that's an unnecessary in our case, as we're guaranteed to have only wrapped objects in result sets, but it's a good thing to bring up in the ml thread | 15:40 |
| gary_poster | My primary interest in this is "easy to remember, easy to follow" | 15:40 |
| gary_poster | maybe you are right that we are automatically protected | 15:41 |
| gary_poster | in which case that is easy to remember and easy to follow | 15:41 |
| abentley | gary_poster: I would want to profile before and after making such a change. | 15:41 |
| barry | gary_poster: ideally, "just happens" and you only have to think about it when you need to violate the rules | 15:41 |
| barry | and even then, it's made plainly obvious that you've thought about it and deliberately broken the rule | 15:42 |
| barry | but of course, it will eventually happen that something will leak anyway ;) | 15:42 |
| gary_poster | abentley: sure. It's all in C. It's very fast. If we get utilities or adapters or other objects and*they* return dicts, then this is already happening. That's probably sufficient, as barry is saying. | 15:42 |
| barry | gary_poster: i'm certain francis could immediately confirm or deny | 15:43 |
| gary_poster | barry: cool. | 15:44 |
| barry | so, we have about 2 minutes left. anything more to say on this topic here? | 15:44 |
| gary_poster | not me. | 15:44 |
| gary_poster | I'll put it in the ml post | 15:44 |
| barry | cool, thanks! this is an important discussion to have. | 15:44 |
| barry | anybody else have anything for today? | 15:44 |
| mars | barry, intellectronica and I had a small debate about JS, but it can wait I guess | 15:45 |
| intellectronica | ? | 15:45 |
| barry | mars: can we put it on the agenda for next week? | 15:45 |
| mars | barry, should we use: if (!some_js_var) | 15:45 |
| mars | barry, we can | 15:45 |
| intellectronica | ah, whether explicit is better than implicit in JS too | 15:45 |
| mars | yep | 15:45 |
| barry | cool, thanks. we're outta time, so let's break here for today | 15:45 |
| barry | #endmeeting | 15:45 |
| MootBot | Meeting finished at 09:45. | 15:45 |
| abentley | barry: Also, ampersands-in-urls. | 15:45 |
| barry | thanks everyone! | 15:46 |
| barry | abentley: agenda for next week, or ml? | 15:46 |
| noodles | thanks barry | 15:46 |
| abentley | barry: for next week | 15:46 |
| barry | thanks. | 15:46 |
| jtv | barry: dankjewel en tot volgende keer :) | 15:46 |
| henninge | barry: Sorry for missing out, thanks for calling me! | 15:46 |
| gary_poster | abentley: if you are curious, this is one of the default checkers in zope/security/checkers.py: | 15:46 |
| gary_poster | dict: NamesChecker(['__getitem__', '__len__', '__iter__', | 15:46 |
| gary_poster | 'get', 'has_key', 'copy', '__str__', 'keys', | 15:46 |
| gary_poster | 'values', 'items', 'iterkeys', 'iteritems', | 15:46 |
| gary_poster | 'itervalues', '__contains__']) | 15:46 |
| barry | jtv: :) | 15:47 |
| gary_poster | _default_checkers has a bunch of them | 15:47 |
| gary_poster | so that lets you get, but not set the dict | 15:48 |
| === salgado is now known as salgado-lunch | ||
| === salgado-lunch is now known as salgado | ||
| === salgado is now known as salgado-afk | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!