November 2006 Archives

The first standalone Perl Hackathon has been a rousing success, and The Perl Foundation is looking forward to sponsoring two or three each year around the country, or around the world.

From Friday November 10th to Sunday November 12th, over thirty Perl hackers converged on the Country Inn & Suites in Crystal Lake, IL, a far northwest suburb of Chicago. For three days, nearly around the clock, we worked, talked, ate, and worked some more on Perl projects of all kinds. There were hackers from around the Chicago area as well as others from Oregon, California, New York, Ontario and England. Some were only around for one day, while others came in Thursday night and left Monday morning. It was a gathering that let everyone do what they wanted, when they wanted, while still getting work done.

The Parrot project had the largest population working on it. Chip Salzenberg and Jerry Gay flew in to drive the development. Friday morning, there were six hackers who were familiar with Parrot, but when it was over, eight new project members had worked on it. Bugs were fixed, design documents were created, and hackers met other hackers for the first time.

Perl::Critic also had a big showing. Chris Dolan and yours truly met with Michael Wolf and James Keenan to create new policies and hash out design decisions as we pushed to the version 1.0 release of this crucial tool.

On Saturday night, Ken Krugler of the code search engine gave a demo of the site, and heard feedback about how can help serve the Perl community better. I'm excited about outside companies working to help Perl while helping themselves. Most important, Krugler sponsored the night's Chicago deep dish pizza to feed the hungry hacking throng.

Smaller projects got attention as well. Pete Krawczyk and I worked on projects like ack, File::Next and HTML::Tree, since most of our time was spent running around getting people to public transportation, getting snacks, ordering Chinese food, and making sure everything ran smoothly. For more details on who was there, and what we worked on, see the Hackathon Chicago wiki at

The one question everyone asked was, "When's the next one?" The Perl Foundation is currently working on ideas, plans, budgets and sponsorship for making more hackathons happens, but we need people to host and organize them. A hackathon is an ideal way for a Perl Mongers group to host an event, but with much easier requirements than hosting YAPC (Yet Another Perl Conference). If you or your Perl Mongers group would be interested in hosting a hackathon, please email me at [email protected]

I read today in the November 15th issue of Software Development Times (an actual paper publication!) that buffer overflows are no longer the most common update security problem reported by CVE (

The three most common types of security vulnerabilities in 2005 were cross-site scripting (16.0%), SQL injection (12.9%) and buffer overflows (9.8%). So far in 2005, buffer overflows has lost the #3 place to PHP remote includes.

The good news is that Perl has long had capabilities in the language and its most common libraries that effectively shut down many of these attacks.

It's not surprising that buffer overflows are on the way out. Perl programmers have long been able to not worry about buffer overflows. Dynamic strings mean no buffer overruns. Fortunately, all the new dynamic languages like Ruby, Python and PHP have dynamic strings as well, leaving only C and C++ programmers having to worry about the size of their malloc buffers.

Where Perl shines in web security is with its built-in "taint mode". When taint mode is enabled, all data from an external source, such as from a web input form, is assumed to be untrusted and tainted. If a user types in her name, the resulting string is marked internally as tainted. Most of the time, this effect is invisible.

print "Hello, $name, glad to see you.\n";
Perl will print out the the user's name, because no matter what $name is, it doesn't present a security risk. However, consider this common rookie programmer mistake.
$dbh = ... code to make a database connection ...;
$dbh->do( "insert into visitors (name) values ('$name')" );
That works fine for values of $name like "Bob Smith", but consider a string like:
'); drop table visitors;
Your SQL expands out into
insert into visitors (name) values (''); drop table visitors;')
That results in three statements, separated by semicolons: One inserts an empty value in the "visitors" table, the second deletes the "visitors" table, and the third a syntax error. The effect is that one well-crafted string from a miscreant means you've lost your data table. The possibilities are endless.

Taint mode to the rescue!

With Perl's taint mode, and DBI's TaintIn attribute enabled, SQL injection attacks can't happen. Perl's DBI module sees the tainted data, since any data created from tainted data is also tainted, and refuses to execute the command. In effect, DBI says "You don't know that the SQL command you're passing me is trustworthy, so I won't run it."

Of course, DBI handles the safe way of doing SQL calls, using placeholders:

$sth = $dbh->prepare( "insert into visitors (name) values (?)" );
$sth->execute( $name );
The data is passed to DBI, but entirely separately from the command. The command is not created using tainted data, so is safe for DBI to execute.

SQL injection prevention is just the beginning of the value of taint mode to Perl programmers. Tainted data also can't be used for executing system commands or reading source code, as in the PHP remote include exploits. For a more thorough discussion of how taint mode works, and why you want it on in every web program you write, see the perlsec documentation for Perl with perldoc perlsec, or online at

I hope that other dynamic languages continue to borrow Perl's features and add explicit taint-mode checking to their bags of tricks. Modern web development demands it.

Perl Foundation board member, conference organizer and Perl oldbie Nat Torkington is interviewed in this article from Linux Format.

Call for Proposals

This call for proposals is delayed because I managed to set up my calendar notification incorrectly. My apologies if this has inconvenienced anyone. Also, after this, I'll be on vacation for a week and a half, so I won't be able to respond right away to grant submissions, but I'll catch up with this when I get back.

If you have an idea for doing some work for the Perl community and you think it's worthy of a grant, please send your grant entry to [email protected]. Submission deadlines is the last day of November, voting starts in December and we will be awarding the grants by the beginning of January. I've fixed my calendar notification and we should be back on schedule after this.

First, please read about how to submit a grant. Read that carefully as grants are often rejected if they don't meet the criteria. For example, if you want to submit improvements to a well-known project but there's no evidence that you have at least tried to work with the maintainers of that project, the grant will likely not be approved. You can also read through our rules of operation for a better idea of thee grant process.

About TPF

The Perl Foundation - supporting the Perl community since 2000. Find out more at

About this Archive

This page is an archive of entries from November 2006 listed from newest to oldest.

October 2006 is the previous archive.

December 2006 is the next archive.

Find recent content on the main index or look in the archives to find all content.


OpenID accepted here Learn more about OpenID
Powered by Movable Type 6.2.2