develooper Front page | perl.module-authors | Postings from November 2003

Re: [Module::Build] Re: How to indicate a dependency in my module

Thread Previous | Thread Next
November 12, 2003 07:25
Re: [Module::Build] Re: How to indicate a dependency in my module
Message ID:

OK, maybe I'm missing a LOT of context here, 'cause I haven't been
agressively keeping up with this mailing list, but the security hole
argument seems a bit odd.

These META.yml files we're refering to -- these are meta data for
managing the build process, files that will be distributed along with
the tarballs we upload to CPAN, right?  

So, if I understand this correctly, you're worried about the build
process eval'ing the contents of a file I sent you.  Hmm.

OK, why is that anymore of a concern for eval'ing the perl module I
also distributed, too?  Isn't that just as big a security hole?  

Or how about the test suites?  If I want to deploy malicious code in
my CPAN upload, I can just drop the evil code into my test suite, and
when you type make tes, I take over your world.

Am I missing something?  Because I also am loath to accept yet another
file format, personally, and I would also prefer to keep my
configuration data written in perl as well.

And if we're talking about the perl build process, what's wrong with a
perl-specific configuration mechanism?

>>>>> "Michael" == Michael G Schwern <Michael> writes:

Michael> In a nutshell: eval()ing the Perl structure back in is a major security hole.
Michael> Part of the point of META.yml is to avoid having to run any foreign code to
Michael> figure out module meta information.

Michael> To review (maybe this should be in a FAQ somewhere).

Michael> Data::Dumper/Perl code - Insecure (you have to eval it).  Perl specific.
Michael> Storable     - Not human readable.  Format changes slightly from version to
Michael> version.  Perl specific.
Michael> XML          - Overkill.  Ugly.  Requires translation between Perl data
Michael> model (hashes, lists, scalars) and XML's (trees).
Michael> Difficult to read and write by humans.

Michael> YAML was chosen because its human readable and writable, its data 
Michael> structures closely match those of Perl (ie. scalars, hashes and arrays),
Michael> it can be read without being eval'd, executable code cannot be hidden in
Michael> it and, as a bonus, its not Perl specific.

Michael> YAML's basic formatting is a structure we're already familiar with and tend
Michael> to use when writing ad-hoc data structures (ie. key: value).
Michael> Indentation as structure we're already more than comfortable with (ie. 
Michael> indented source code) so readers of YAML should have no problem. 
Michael> The less obvious features of YAML shouldn't be necessary for most META.yml
Michael> files.

Michael> Because YAML's data model closely matches that of Perl, writers of META.yml 
Michael> simply need to construct a mirroring Perl structure and let YAML dump it
Michael> out.  Its the closest thing to "Data::Dumper evaling" available.

Michael> -- 
Michael> Michael G Schwern
Michael> I'll tell you what beats voodoo every time, a big ass knife.
Michael> -- "Overkill" Battlebot driver

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About