Using IO::All reopens all the security holes that the three argument form of open fixes. Of course, in the sense of universality, IO::All is just like PHP, which also has these problems of being able to launch a process or access a foreign website via an open with an unguarded filename, so there is no loss by using IO::All, but especially when writing applications that are publicly accessible, it's better to have less magic.

Interesting. It does highlight a bit of a problem with CPAN though. i.e. If the module authors decline to put such information into the docs, how does a casual Perl programmer know about the risks?

I guess there's little replacement for thinking for yourself.

Also, I'm unaware that Ingy has declined to put such information into the module documentation. It's obvious that IO::All allows you to do that, and I guess most users of IO::All want this cute flexibility.

If the module authors decline to put such information into the docs, how does a casual Perl programmer know about the risks?

I believe this was the reason for annocpan. Look at the upper right hand corner of IO::All. You should see a link to annocpan for IO::All. Unfortunately, no one has annotated IO::All.

-derby

Thanks Corion - skim-reading the docs was clearly insufficient.