Am 03.06.2013 18:48, schrieb Chris Steipp:
On Mon, Jun 3, 2013 at 6:04 AM, Nikolas Everett neverett@wikimedia.org wrote:
- Build smaller components sensibly and carefully. The goal is to be
able to hold all of the component in your head at once and for the component to present such a clean API that when you mock it out tests are meaningful.
Yep. Very few security issues come up from a developer saying, "I'm going to chose a lower security option", and they attacker plows through it. It's almost always that the attacker is exploiting something that the developer didn't even consider in their design. So the more things that a developer needs to hold in their head from between the request and the response, the more likely vulnerabilities are going to be introduced. So simplifying some of our complex components and clearly documenting their security properties would be very helpful towards a more secure codebase. Adding layers of abstraction, without making the security easy to understand and demonstrate, will hurt us.
I agree with the sentiment, but disagree with the metric used.
Currently, we have relatively few components, which have very complex internal information flows, and quite complex dependency networks (or quite simple: everything depends on everything).
I'm advocating a system of many more components with several dependencies each, but with simple internal information flow and a clear hierarchy of dependency.
So, which one is simpler to hold in your head? Well, it's simpler to remember fewer components. But not fully understanding their internal information flow (EditPage, anyone) or how they interact and depend on each other is what is really hurting security (and overall code quality).
So, I'd argue that even if you have to remember 15 (well named) classes instead of 5, you are still better off if these 15 classes only depend on a total of 5000 lines of code, as opposed to 50k or more with the current system.
tl;dr: number of lines is a better metric for the impact of dependencies than the number of classes is. Big, multi purpose classes and context objects (and global state) keep the number of classes low, but cause dependency on a huge number of LoC.
-- daniel