Am 03.06.2013 18:48, schrieb Chris Steipp:
On Mon, Jun 3, 2013 at 6:04 AM, Nikolas Everett
<neverett(a)wikimedia.org> wrote:
2. 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