[Copying Andreas, Jos, Schwern and the Module::Build list]

Well, I'm not sure that escalating to Securiteam at this point was
necessary given the low overall risk of the threat, but let's set that
aside and find some agreement on closing the hole. Here are my
thoughts on some of the problems/options:

Problem 1: race condition between unarchiving and execution if
Makefile.PL or Build.PL is world writable (ditto test files as well)

(a) Have CPAN and CPANPLUS refuse to run 'perl *.PL' if the PL in
question is world writable.

(b) Have CPAN and CPANPLUS not preserve mode permissions even for
root; that's "--no-same-permissions") for tar or $Archive::Tar::CHMOD
= 0 for Archive::Tar. I presume there's a comparable thing for zip
archives. That leaves it up to the users umask setting.

(c) Both

(d) Something else

(e) Ignore it

Personally, I lean towards (b) as that seems relatively sane and
minimally disruptive.

On Thu, Sep 18, 2008 at 3:50 PM, Tina Müller wrote:

I'm moving this over to cpan-workers@perl.org so anyone can read the
thread and it shows up in google, etc.

This is basically what the new -j switch to cpan does, although it
doesn't try to figure out if the configuration you load is valid yet.

On Wed, Sep 17, 2008 at 4:24 PM, brian d foy cpan.org> wrote:

Sort of. In Oslo, various people said we should reactivate
cpan-workers@perl.org for discussions about how to move the CPAN tools
and ecosystem forward. So I and some other have subscribed but
there's been not much traffic. But come join! We can start it up.

I like the idea. My personal wishlist for CPAN.pm is to eventually
eliminate all the globals and global file locking so multiple CPAN's
can run concurrently. Then multiple config files become potentially
even more useful.

-- David

On Thu, Apr 10, 2008 at 08:49:31AM +0200, Andreas J. Koenig wrote:

Hmm, I'll have to take another look at that; it sounds interesting.

hellooooo

hdp.