I'm going to be posting a series of entries in response to Netanel Rubin's Presentation: The Perl Jam 2, and this is the first of such entries.

As a whole, I felt he grossly miss-characterised Perl and its community, and made a few glaring errors in his presentation and a few leaps of logic.

Amongst his talk, he covered a handful of Real Bugs, but his presentation made it difficult to realise what they were objectively, and his hyperbolic and rhetoric technique served not to educate, not to correct, but to mock.

I feel many of his criticisms would have been better addressed as actual bug reports, not a presentation conveying how software has bugs, and that with better clarity and less rhetorical devices, the important parts of his presentation could have been covered in 5 minutes.

So this is an attempt at clarifying the mistakes in the presentation, and serve as a more objective response where we can unpack the relevant parts, fix the actual problems, and educate our way past the cultural issues that lead people to make bad choices.

I will of course go into far more detail than is strictly necessary.

And its Documented that Nobody should use it

Netanel did not identify this quirk as such, but it underlies a significant chunk of his presentation.

Both CGI.pm and the CGI protocol imply serious limitations on the security and performance of your Web Application, and has been recommended against by everyone worth listening to, and is even documented as such IN CGI.pm itself

CGI.pm is no longer considered good practice for developing web applications, including quick prototyping and small web scripts. There are far better, cleaner, quicker, easier, safer, more scalable, more extensible, more modern alternatives available at this point in time.

The CGI protocol significantly blurs the lines between the Command Line interface, and the Web, in ways that prove to be detrimental, and can serve as an amplifier for bugs and security risks.

One of the attacks he demonstrates relies heavily on a behaviour in Perl that is deemed useful for command line programs: The ability for the caller ( that is, the user of the command line program ), to specify, by way of arguments, names of arbitrary programs to execute to retrieve their output.

This turns out to be a grave trap in a Web context, as HTTP GET Request parameters are passed to the CGI application as parameters to @ARGV , much like parameters on the command line.

And that means any code that happens to utilize that "execute arbitrary programs based on arguments in @ARGV " path ( either by intent, or by way of exploiting a bug ) is simply waiting for the day when some user on the internet can forge a request such as:

http://example.org/fake.cgi?rm -rf /|

And maybe find enough magic spice to trigger the "be a command line and execute that" condition.

And this would clearly be bad.

But this risk exists because of the Command-Line-as-a-Web-Protocol design flaw.