perl-modperl mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Warnier ...@ice-sa.com>
Subject Re: [OT] AW: Unsuccessful stat on filename containing newline in RegistryCooker.pm
Date Fri, 01 Mar 2013 10:43:17 GMT
demerphq wrote:
> On 28 February 2013 21:12, André Warnier <aw@ice-sa.com> wrote:
>> I am ranting, and I know it.  But the basic fact is that " ", in 99% of
>> programming languages
> 
> I doubt it, considering all the major languages I know of use a "," to
> separate arguments.
> 
> And if you are in a programming language then the filename will be
> stored in a variable, so you generally wont care if it contains
> spaces, or whatever.
> 
>> and OS shells
> 
> Here it is maybe true.
> 
>> is a meta-character that normally acts
>> as a separator between arguments, keywords, parameters, whatever.  So
>> electing to allow it in paths and filenames was a bad decision, which has
>> cost so far millions of unproductive hours to be spent, and will cost many
>> more millions before a reasonable parade is found.
> 
> If you accept arbitrary sets of filenames and expect to feed them as
> arguments to something like a shell without managing issues like them
> having spaces in them then you are opening yourself up to way worse
> issues than them having spaces in them.
> 
> Whats to stop them giving you a filename that is actually a command,
> or a redirect, or whatever?
> 

You do not have to convince us, I think that we all know this already. You may want to 
read http://perldoc.perl.org/perlsec.html#SECURITY-MECHANISMS-AND-CONCERNS if you haven't

yet done so.  It may give you some additional ideas about things to watch for.
Or take your latest perl program, and remove all spaces from it, just for a laugh.

But I believe that you are missing the point of this whole disgression entirely, and you 
may want to re-read it from the beginning, and take it for what it is. LOL.

Mime
View raw message