Perl 5 Development Archives

May 02, 2007

May 2, 2007 - Help Wanted: SOAP::Lite

Here's my first Help Wanted entry. SOAP::Lite needs your help. Byrne Reese has posted a good assessment of the state of the SOAP::Lite. Read on for details.

To start, SOAP::Lite works. That is, it works well for easy things (it's actually the easiest out there in any language) and you can get it to work for complicated things. But it needs help and it's going to need more help in the near future. SOAP is becoming more and more important to interface between major software products. Perl excels as a glue language, but it won't be able to continue to do this if it can't talk SOAP easily. For example, one of the biggest problems right now is it can't easily generate WSDL.

In addition to solving its problems right now, it will need to be ported to Perl 6. It will be much nicer to do that if we can get a decent re-write now.

How do you help?

  • Byrne mentioned a few ways in his summary. He needs some dedicated coders.
  • Do you use SOAP and perl at work? Get your boss to let you spend time improving it.
  • I think this work would be appropriate for grant requests, either normal TPF grants or the new micro-grants. Let's break down the tasks into something manageable.

This is a big project to tackle, but one that will surely have thousands of people running your code. And if you like coding in Perl, it will increase the chance that you'll be able to keep doing so in your day job.

May 02, 2007

May 2, 2007 - Help Wanted: Perl Coding Needed

I often hear this:

"I'd get involved in Perl, but all the cool stuff is done and there's no room to make a name for myself. No one needs another DBI module..."

or even:

"All the cool kids are using (Ruby/Python/TI-994A Extended Basic) because they don't have CPAN yet and they can become the uber-programmer for the cool modules."

Well, to these I say, "Nonsense!" There is a ton of work to be done for Perl today, right now. And it's crucially important work. So whenever I come across something that I think is really important, I'm going to post it with the heading 'Help Wanted.'

Criteria: This isn't going to be stuff like, "We need someone to fix this RT ticket for this module." I'm going to try to post stuff that I feel is truly important to Perl and would be useful to many people. I'll also try to post any progress if I hear about it.

Interested? Go check out the first posting for SOAP::Lite.

December 03, 2006

December 3, 2006 - A trio of Perl calendars

December brings three different online calendars for the Perl community.

First, the traditional Perl Advent Calendar informs you about a snazzy module every day until the 25th, with requisite RSS feed for those of you practicing one of the three virtues this holiday season.

Next, for Catalyst users, or those who'd like to start, the Catalyst Advent Calendar brings a daily tip for those interested in this increasingly popular framework.

Finally, brian d foy has created a Perl Community calendar on Google Calendar. Follow it via XML, iCal, and HTML.


You can find this calendar also here: http://www.markthisdate.com/calendar/details.html?calendar=917 and it is downloadable to Outlook, Pdf and all other majar callendar apps.

Cheers,

Rutger

contributed by Rutger on December 4, 2006 11:06 AM

November 17, 2006

November 17, 2006 - Perl's taint checking to the rescue

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 (cve.mitre.org).

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 http://perldoc.perl.org/perlsec.html

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.


"With Perl's taint mode, and DBI's TaintIn attribute enabled, SQL injection attacks can't happen."

This isn't true. Taint checking does not prevent this. It simply doesn't allow it with tainted data. The user can still untaint data incorrectly, and SQL injection attacks can still happen.

contributed by Anonymous on February 18, 2007 6:54 PM

September 27, 2006

September 27, 2006 - Thanks Nick

This week the Perl community lost one of its long time contributors, Nick Ing-Simmons, who died of a heart attack on Monday September 25th 2006.

Nick joined the Perl community in the early days of Perl 5. He consistently contributed to the perl5-porters mailing list and later became pumpkin for 5.003_02 where he added the initial implementation of the PerlIO layer.

Nick is probably best known for his work on the Tk and Encode modules. Tk was initially born out of frustration that perl didn't have a native GUI at the time. Nick tirelessly developed Tk for over a decade. Tk often influenced the development of the perl internals through its aggressive use of XS.

Nick was an intelligent person with a willingness to share his knowledge to help others and one who had a great passion about everything he did.

Our deepest condolences go out to his long time partner, Medi, and all those close to him.

The Perl community owes a lot to Nick so I am sure many will join us in saying

"Thanks Nick"


This is indeed a great loss for the community. Nick was a really classy guy who always turned whatever he was working on into something positive for others. He leaves a lot of goodwill in his wake.

-Ken

contributed by Ken Williams on September 28, 2006 4:29 AM


Too many good people are dying these days. God bless you Nick, may you rest in peace and eternal happiness. :(

contributed by Ollie on September 29, 2006 6:27 PM


When I was working with Perl/Tk, I came across Nick's comments on mailing lists frequently. His death is a loss for our community, a real tragedy. May Nick rest in peace.

contributed by Colin on September 30, 2006 6:00 AM


Dear citizens of the "programming republic of Perl",
it is with deep shock and dismayal that I just read about the death of the father of Perl::Tk. It was his Tk that saved my day(s) in that it gave me an employment just when I direly was in need of one...
I'm too sad to find anything more to say...
Steffen Beyer (Mr. Date::Calc, Bit::Vector, Data::Locations etc.)

contributed by Steffen Beyer on October 7, 2006 7:19 AM


I am a happy user of Nick's software, which makes my everyday working life easier - and no doubt Nick's work had the same effect for countless other programmers around the world. To my dismay, I learned about his death today over a bug report that he will never receive. Which just goes to demonstrate that we best understand the value of people and the contribution they bring to the world once it is too late to express gratitude. Shame on me, I make a living on free software as if it was a commodity, yet people like Nick are not usually part of my prayers. Now they will, at chapter "thanksgiving".

I am a non-native english speaker and I may not be able to express my mood as poetically as the previous poster, but this does not make my condolences to Medi and relatives any less sincere.

contributed by Dominique Quatravaux on October 26, 2006 10:56 AM


Mr Simmons contribution to the perl community was incredible.

Tk is an incredible Perl Module...It's one of the best modules that I have ever seen in the Perl community.

How fantastic applications with incredible GUIs can be developed using Tk....and thanks to Mr Simmons.

I hope that someone else continues keeping, maintaning and updating his great baby...Tk

My condolences to his family and our great perl community

contributed by daniel mazzini on November 16, 2006 5:35 PM

September 18, 2006

September 18, 2006 - Take back your modules

Mark Stosberg wrote a great article on perlmonks called ""Take Back Your Modules about the responsibilities module users have for the modules they use.

September 05, 2006

September 5, 2006 - Perl 5 powering Web 2.0

John Wang has a great blog entry titled Perl 5 Powering Web 2.0 that points at all the web apps out there that are done in good ol' Perl 5.

You don't have to have Rails to do amazing things with the web. You want frameworks, we got frameworks!

December 15, 2005

December 15, 2005 - Patches fix sprintf buffer overflow

The Perl community has released a fix to the sprintf function that was recently discovered to have a buffer overflow in very specific cases. All Perl users should consider updating immediately.

Dyad Security recently released a security advisory explaining how in certain cases, a carefully crafted format string passed to sprintf can cause a buffer overflow. This buffer overflow can then be used by an attacker to execute code on the machine. This was discovered in the context of a design problem with the Webmin administration package that allowed a malicious user to pass unchecked data into sprintf. A related fix for Sys::Syslog has already been released.

The Perl 5 Porters team have solved this sprintf overflow problem, and have released a set of patches, specific to four different versions of Perl.

  • For Perl 5.8.0

ftp://ftp.cpan.org/pub/CPAN/authors/id/N/NW/NWCLARK/sprintf-5.8.0.patch

  • For Perl 5.8.1 and 5.8.2

ftp://ftp.cpan.org/pub/CPAN/authors/id/N/NW/NWCLARK/sprintf-5.8.2.patch

  • For Perl 5.8.3

ftp://ftp.cpan.org/pub/CPAN/authors/id/N/NW/NWCLARK/sprintf-5.8.3.patch

  • For Perl 5.8.4 through 5.8.7

ftp://ftp.cpan.org/pub/CPAN/authors/id/N/NW/NWCLARK/sprintf-5.8.7.patch

While this specific patch fixes a buffer overflow, and thus prevents malicious code execution, programmers must still be careful. Patched or not, sprintf can still be used as the basis of a denial-of-service attack. It will create huge, memory-eating blocks of data if passed malicious format strings from an attacker. It's best if no unchecked data from outside sources get passed to sprintf, either directly or through a function such as syslog.

For further information, or information about The Perl Foundation, please email pr at perlfoundation.org.


When can we expect a patch for windows 2003?

contributed by Nitin on April 21, 2006 2:40 PM


The patches are already available on the CPAN if you build from source. If you're using ActiveState's builds, that's something to direct to ActiveState.

contributed by Andy Lester on April 21, 2006 7:58 PM

December 13, 2005

December 13, 2005 - Updated Perl modules alleviate Webmin security flaw

The Perl community has updated the core module Sys::Syslog to help alleviate a security hole in the Webmin web administration package. All Webmin users should update immediately to the updated version of Sys::Syslog.

Dyad Security released a security advisory explaining how arbitrary, untrusted data can get passed by Webmin into Perl's Sys::Syslog module as a sprintf format string. This allows an attack to create arbitrarily large strings, overwhelming server resources and causing a denial of service.

However, Dyad Security's other security advisory, detailing an integer overflow bug in Perl's sprintf, meant that the Webmin bug could potentially mean arbitrary code execution with the permissions of the web server process, not just a denial of service.

The release of the updated Sys::Syslog handles the specific coding problem presented by Webmin, and perhaps other packages, of passing format strings to the syslog() function when the programer does not realize that syslog() acts as a proxy for sprintf. The new syslog() function now notes the special case of only passing one message parameter, and does what the programmer intended: treats the parameter as a single message string and does not call sprintf.

The other issue, with the sprintf integer overflow, is still being worked on. Fixes have been made, and patches for older versions of Perl are being created. The Perl 5 Porters are taking the time to make sure that the patches work for as many existing Perl 5 installations as possible. Watch news.perlfoundation.org for information on the patches as they become available.

Further queries may be sent to pr at perlfoundation.org.

Perl 5 Development Category

This page contains an archive of all entries posted to The Perl Foundation in the Perl 5 Development category. They are listed from newest to oldest.

Many more entries can be found on the main index page or by looking through the archives.

Powered by
Socialtext