Perl 5 Porters Weekly: October 1-October 6, 2012
[ cross posted from its original blog ]
Welcome to Perl 5 Porters Weekly, a summary of the email traffic on the perl5-porters email list. I was in San Francisco this past week at RICON 2012, a conference about distributed systems for developers. It was organized by Basho who wrote and support the "NoSQL" Riak data store. I was there mostly in my capacity as an Erlang developer, but kept a finely tuned ear out for Perl. Unfortunately, there wasn't any discussion of Perl (or Python for that matter.) Most of the developers there work on Rails, Scala/Clojure, Erlang or node.js and it was a little disappointing to my inner Perl nerd that there wasn't much consideration of implementations outside of these 5 programming languages.
Topics this week:
- TPF Grants (DAVEM / NWCLARK)
- Security Issues in perl-5.16.x
- Rounding a floating point number
- Taking CPANPLUS out of core
You probably know that The Perl Foundation supports Dave Mitchell and Nicholas Clark to do (more or less) full time support work on Perl 5's core, but something I didn't really appreciate until I started following p5p pretty closely was how much gnarly nasty stuff these guys dive into and address.
I would strongly encourage you to read the monthly summaries from Dave Michell and Nicholas Clark's grant work. There is really a lot of great long running hard to solve bugs that are being ironed out thanks to these two contributors.
Thank you gentlemen. I know you're getting paid, but it's still a dirty job and someone's got to do it. I'm grateful you're there to take it on.
Security Issues in perl-5.16.x
One of the most active threads this week was from a followup by Reini Urban discussing what he considers to be security issues in perl-5.16.x. The main concern seems to be that Perl happily accepts null bytes (\0) in input to various data structures and system calls. Reini sees it as a vector to load (for instance) user supplied shell code into arbitrary memory locations.
There was some genuine concern that one of the areas where Perl will accept a null byte was in a package name (for example, "Foo::Bar\0Evil" is a valid Perl package name, although %INC will have just Foo::Bar in it after execution.)
Dave Mitchell summed up the general list response like this:
5.16.0 allows null chars in module names and stashes. Well, there were some changes in 5.16.0, but null chars in strings, symbol tables, filenames etc has been a feature in perl since 5.000 or earlier. Whether this is a good thing is something the can be discussed, but it's hardly a new issue. [...] tl;dr: Reini to world: "OMG! 5.16.0 is incredibly insecure; no-one must use it. The Perl Porters don't understand security! They're all stupid! Why do they refuse to fix these critical issues?" Us: "No its not; yes we do, no we're not, no we don't".
Later, Chip Salzenberg sarcastically posted a patch to core that detects and warns if there is an embedded NULL byte in a pathname to open or stat.
Ricardo Signes replied:
This was exceptionally rude, passing into realms of sarcasm rarely glimpsed. Those who think that a warning for a nul in a filename is a good idea seem unlikely to be swayed by it. Those who think it's a bad idea, I suppose, might get a chuckle. Mostly, it seems like nastiness for nastieness' sake.
Rounding a floating point number
A user reported that moving from i386 to x64_64 on CentOS 6 made his perl (5.10.1) report a different floating point rounding behavior.
On this platform (x86) the output is like the following: # perl -e 'printf("%.2f", 6.685);' 6.68 But on the other (x64) platform I got this: # perl -e 'printf("%.2f", 6.685);' 6.69
Greg Lindahl posted a note that perl ought to be compiled with the '-fexcess-precision=standard' flag when building on gcc 4.5+ to help eliminate this problem on several platforms.
Taking CPANPLUS out of core
Sawyer X started his "final" thread on the topic of removing CPANPLUS from Perl's core distribution. He said this work should be postponed until there's a viable CPAN client that isn't CPANPLUS on VMS. Craig Berry said that he thinks getting CPAN.pm working is pretty close.
Prompted by a bug report in a2p, there was some consideration of the fate of the a2p and s2p tools. The purpose of these tools is to take an awk or sed script and emit an equivalent perl script. Johan Vromans asks:
I've been wondering for a long time now: Are a2p and s2p actually still used? They made sense 20 years ago, when people were writin awk and sed scripts and perl was a new and upcoming tool. But are these tools still used today, to the extent that they should be part of the perl core, instead of CPAN modules/tools?
Good questions! Do you use these tools?