This is grossly incorrect. The car is a a much better conductor to ground than a human body. Even leaving the metal portion of a car aside, rubber becomes an rather good conductor at the power levels provided by a lightning strike, certainly a better conductor than your body. Where are you getting your misinformation?
Incorrect. While occupying the interior of a vehicle would afford better protection than you'd get standing alone, you wouldn't have to be fully inside the car for it to afford some protection in the event of a lightning strike. Merely being in contact with the door handle would create a condition whereby the car provides a more conductive path to ground than your body. You appear to have a poor understanding of electricity. Incidentally, rubber becomes more conductive at power levels approaching those supplied by lightning strikes.
If you live in MX, odds are good you aren't trading nearly the amount of currency the GP is yielding on a daily basis for that take friendliness. Therein lies the essence of a first world problem.
What do the Village People have to do with this? Is it fun to work at the old CIA?
First world problems.
You seem confused. Please try reading this thread again, starting with the original post I replied to. Also, the counter-example I provided in my last reply isn't Python. Before opening your mouth to speak, you should probably be reasonably certain you know what you're talking about. Cheers.
You just quoted 106 characters to accomplish the following simple task:
print "Hello, World\n";
That's 23 characters to accomplish the same task, but the core issue isn't even really the character count alone. It's the verbosity combined with the requirement that an object be explicitly constructed to perform something that is a fundamentally procedural task.
As a side note, if our hypothetical programmer merely examines and untaints $ENV{PATH} in the last example, the exploit will succeed, since Perl doesn't do any taint inspection of a string passed to system() unless it interpolates potentially tainted input. Still, a reasonable programmer would hopefully have an "ah ha" moment after being reminded that $ENV{PATH} is tainted and consider the rest of the environment.
I completely agree.
I don't think you're being argumentative at all. Your points are fair and valid, and I'll note that the specific example provided (per the comments embedded in it) is a bit on the contrived side. That said, Perl actually used to just use whatever it found in $ENV{SHELL} for system() calls, which would have removed the necessity of including the explicit
However, the earlier example is still quite useful for demonstrating another Perl best practice: taint mode. I have seen some truly dreadful things done via shell-outs in various languages, because programmers are of course capable of doing all sorts of very silly and dangerous things in their programs (such as including direct shell binary invocations in system calls), frequently without realizing those things are that dangerous in context. This may be due to the dangers being difficult to anticipate, and this could be said of our first example, as it doesn't contain any code that visibly uses external data. Here's what happens when we turn on taint mode in the initially exploitable script: Perl taint mode saves lives.
If I get the time, I'll be setting up various test environments with an assortment of examples written in different languages and frameworks to demonstrate the sorts of differences described herein, and I'll be glad to keep you posted if you like.
I'm perfectly capable of fixing things myself. That's not the issue here. Try enforcing the policy you described across even a moderately sized multi-tenant SMB computing environment running a variety of applications that you're responsible for managing. You'll soon find that your policy results in negative revenue. The end result becomes a case study in "you broke it, they stopped buying it."
I put together a small example for you.
The Zimbra example is only a single case intended to illustrate the mere existence of #!/bin/bash in scripts on commonly deployed systems; there are many, many others to be found, including wrappers for various commonly used utilities than may well wind up being called from a CGI script. As for your last sentence, you're conflating two concepts. I was specifically addressing the following response: "Certainly not in a distribution which does not have bash as the system shell. You can uninstall bash in such a distribution, and the system is expected to continue running." See the difference?
Top Ten Things Overheard At The ANSI C Draft Committee Meetings: (5) All right, who's the wiseguy who stuck this trigraph stuff in here?
