Yet Another Command Line Parser

[Alex Martelli]

Andrew Dalke <adalke at mindspring.com> wrote:
   ...
> > Not to defend exec (ugly thing it is), but in this case I'm not sure
> > what the security hole would be.
> 
> In some sense we're both right, or wrong.  Security depends on

Yeah, I see your POV.

> > but how are commandline arguments 'untrusted'...?
> 
> I had to think about that for a bit.  Much of the work I do
> (for money or otherwise) ends up being called by some sort
> of web interface or is the interface to such code.  Much of
> the data I use can come from untrusted sources.  So I've
> developed a programming habit of being distrustful of any
> data I get, even if it's from me.
> 
> As a consequence that also means I don't need to think about
> the multiple levels in the system.

Yes: never trusting any data anywhere is a safer habit to acquire, and
if you do get into that mindset your code will have fewer risks of
vulnerabilities.  An "Only the paranoids survive" kind of stance.

However, it's an interesting characteristic of security that it is _not_
free: each security measure, precaution and stance carries a cost in
terms of convenience and productivity.  In any given situation, there
_are_ upper limits to the total amount of such costs that can and will
be born in the name of security.  Thus, I believe it's _good_ for
security to be aware exactly of how much security you're buying, what
threat you are warding off and to what extent, with each security
measure you are taking -- a cost/benefit analysis.

Many practices that weaken security _also_ damage code quality in other
ways, for example by being prone to hard-to-reproduce,
hard-to-track-down bugs.  The 'exec' statement that you criticized
surely falls into that category.  For _those_ practices, I believe that
cost/benefit analysis may well be nearly superfluous: the old slogan
"quality is free" has some truth to it, in as much as the costs of
making good quality code today tend to be repaid with interest in
lowering maintenance costs in the future, enhancing reusability, etc.

So I think a "knee-jerk reaction" against some kinds of 'code smells' is
quite OK.  More generally, I'm not sure "knee-jerk security" is a net
win, though.  The classic example is forcing people to use
12-characters-long, randomly assigned passwords that they can't change:
inevitably they _will_ write those passwords down somewhere, creating
far worse security risks than if some cost-benefit analysis had been
done to find a reasonable compromise between security and practicality.

These are rather general considerations, musings if you will, about
security and development practices, and in no way meant to defend the
'exec' statement you were criticizing.


Alex