On 08/23/12 12:05 AM, Robert O'Callahan wrote: > On Thu, Aug 23, 2012 at 8:40 AM, Ben Hearsum <[email protected]> wrote: > >> On 08/22/12 04:38 PM, Gregory Szorc wrote: >>> Let's think of what can be done to secure/limit Python. Disabling import >>> has already been mentioned. That's a start. >> >> I think it's worth noting that even if you *do* limit what you can do >> through some technical means, you still have the option to change that >> later, disable it some places, etc. It's really easy to get into that >> game when you're fixing blockers or working on chemspills, too. >> > > If someone is that desperate, what would you have them do instead of hack > the configuration file? Aren't they likely to respond by doing some even > worse hack that gets the job done?
It's hard to answer this in the abstract. In my experience, sometimes it takes only a little more effort to do things the "right" way (that is, the way you would do them if you weren't under time pressure). These cases are where limiting peoples' ability to things in a bad or difficult to maintain way really pays off. For cases where the "right" fix can only happen through rearchitecting or an otherwise large change I'm not sure how it would play out. > I think it makes a ton of sense to use automation to stop developers > accidentally doing something they shouldn't. But if someone's desperate > enough to disable the automation, and can get a review for it, then I don't > think it makes sense to try to stop them. Yeah, I think I agree. My experience in RelEng has biased me strongly towards not allowing even temporary hacks like that, because it's rare that we ever remove them, and end up with a pile of very difficult to maintain hacks (Tinderbox client, buildbot-configs). This may not be the case for the build system in general, though. _______________________________________________ dev-platform mailing list [email protected] https://lists.mozilla.org/listinfo/dev-platform
