Adam Kennedy wrote:
> 2009/1/28 Michael G Schwern <[email protected]>:
>> A while ago, Audrey suggested inverting the process. Rather than having a
>> program that spits out meta-data, have meta-data which might contain
>> programs.
>>
>> Why is this useful? If you have a program it can do anything, this is the
>> basic Makefile.PL/Build.PL/configure security hole.
>
> If you have data that contains a program, this is no different. The
> only difference now is that the installer will be doing a Windows
> Vista style popup thing, "Can I run this?", "Can I run that?" over and
> over and over.
That's a bad solution. We all know it's a bad solution. We will not use the
known bad solution.
A good solution is to have a single policy of what to do
(execute/ask/disallow) and the meta-file contain defaults if their executables
are not run. This is analogous to how prompt() works.
It is also critical to realize that custom code parts would be considered
*exceptional* rather than normal and the drive would be to eliminate them.
See below.
> I note that we ALREADY have a mechanism for the META.yml to flag that
> you don't need to run the Makefile.PL, so that in the simple cases you
> avoid the need for execution.
The key difference here is that's all or nothing. And it only works for
simple cases, which are not really the problem.
The advantage of the meta-file is it can absorb more and more use cases things
need less and less custom code. This is critical: it improves over time!
>> If you have meta-data that might run programs, you can be alerted before it
>> does so. You can have policies about whether you want that code run. You
>> can
>> have defaults in case the code isn't run. You can absorb common bits of code
>> into the meta-language so people don't need to write custom code for it any
>> more. And the code snippets will be shorter and easier to eyeball for both
>> security audits and debugging.
>>
>> For example...
>>
>> name: Foo-Bar
>> version: from('lib/Foo/Bar.pm')
>> abstract: from('lib/Foo/Bar.pm')
>> authors:
>> - Michael G Schwern <[email protected]>
>> license: perl
>> requires:
>> everywhere:
>> File::Spec: 0.8
>> perl: 5.6.1
>> os_is('Win32'):
>> Win32::Thing: 1.23
>> sub { -x "/usr/bin/mysql" }:
>> DBD::mysql: 0
>>
>> And then we might absorb checks for binary programs into a which("mysql")
>> meta-language function going forward. Or even something that probes the
>> native package manager.
>>
>> Because this is still dynamic, it may spit out a METALocal.yml to record its
>> decisions.
>
> M:I already provides this kind of meta-language (and did so even
> before the DSL stuff). Here's the equivalent in the ordinary M:I
> "meta-language". It's smaller and simpler than your data meta-language
> already.
>
> use inc::Module::Install 0.77;
>
> all_from 'lib/Foo/Bar.pm';
> requires 'File::Spec' => '0.8';
> requires 'Win32::Thing' if win32;
> requires 'DBD::mysql' if -x "/usr/bin/mysql";
>
> WriteAll;
Yes, it is not a coincidence that what I wrote looks an awful lot like
Module::Install.
However, we can't just use a Perl program because it's Perl and can do
anything at all. This blows the whole point of a meta-file out of the water,
that it can be trusted. That it can be read without executing arbitrary code.
--
39. Not allowed to ask for the day off due to religious purposes, on the
basis that the world is going to end, more than once.
-- The 213 Things Skippy Is No Longer Allowed To Do In The U.S. Army
http://skippyslist.com/list/
