Trust but verify. Enough eyes make all bugs shallow. ... and other proverbs.
I just finished the not-very-interesting book "A Genius for Deception", about successful British efforts to fool the Germans during World Wars 1 and 2. The message is that deception, making something appear different than it is, is much stronger than making something hard to see. An example was "dazzle paint" for ships. Instead of camo, (attempting to make a ship blend into the seascape), paint it with swirling black and white stripes that make the ship appear to move in a different direction. A submarine commander aiming a torpedo from a distance will miss more often. The British employed abstract paint artists to design the patterns on model ships; cubism wins wars. ---- This is germane to open source; variable names and subroutine titles do not specify what those objects do. Hiding exploits in machine code is difficult, hiding them in the source and the comments is easier. Scepticism improves security. Sometimes you must decompile the binaries (yours or others) without knowledge of design intent, and see what they actually do. Decades ago, in the dark days of closed source, I often decompiled/disassembled binaries, and often found flaws in the software design, or opportunities for improvement. A lot easier when the object code was 20 kilobytes rather than 200 megabytes, but the analysis tools are now more larger and more powerful as well. So those become targets, too. The Unix/Linux philosophy of "little tools piped together" and the ease of "do-it-yourself" suggests that we can still combine little tools to make big powerful tools, one time ad hoc, and watch the text fly between them. But we don't, and rely on huge development environments, which reduces effort, but concentrates vulnerabilities into a few large targets that can be attacked as groups with automation. The volunteer philosophy of "we should all contribute a little to our community" suggests that those of us who can should read little bits of code, so that all of us together read all of it in differently overlapping multiple passes. Those who can't read code anymore (like me) can write the documentation and draw the pretty pictures. The quality of our shared output cannot exceed the quality of what we contribute as a cooperative volunteer community. Keith -- Keith Lofstrom [email protected] _______________________________________________ PLUG mailing list [email protected] http://lists.pdxlinux.org/mailman/listinfo/plug
