On Mon 22 Sep 2008, Ken Williams wrote:
> >> Override create_readme() I think.
> >
> > That was actually do_create_readme. However, in my case it was
> > easier to override _main_docfile.
>
> But _main_docfile() is a private undocumented method, which can (and
> very very likely will) change or dis
On Mon, Sep 22, 2008 at 5:09 AM, Torsten Foertsch
<[EMAIL PROTECTED]> wrote:
> By the way, you haven't answered my initial question. What is
> the "right" way to do that in M::B?
This is Perl, so TIMTOWTDI.
Personally, I generally only override ACTION_ subroutines. If I need
code from a private
Torsten Foertsch wrote:
> I understand the argument why MakeMaker is bad. But it has worked for
> many years now. How do you expect to build a greater user base if it's
> so complicated to do simple things in M::B?
Now, before we drift off into "MakeMaker did it better" land, let me remind
you t
[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/opti
On Mon, Sep 22, 2008 at 3:00 PM, David Golden <[EMAIL PROTECTED]> wrote:
> 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
> On Mon, 22 Sep 2008 16:00:41 -0400, "David Golden" <[EMAIL PROTECTED]>
> said:
> 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
Here are the results. Of the 2700+ dists in Eric's list, about 20 had
different results. Unfortunately, I didn't think to stop my mirror from
replicating and some of these are from a new version of Moose with
incompatible changes. In any case, nothing went from "pass" to "unknown"
which would be
# from Ken Williams
# on Monday 22 September 2008 13:45:
>> (a) Have CPAN and CPANPLUS refuse to run 'perl *.PL' if the PL in
>> question is world writable.
>
>That wouldn't completely solve the problem, since someone could
>quickly rewrite *.PL and change it to non-writable status. Note that
>a
On Mon, Sep 22, 2008 at 5:23 PM, Eric Wilhelm
<[EMAIL PROTECTED]> wrote:
>
> Would that "tracks-covering chmod" not require *ownership* of the file?
According to the man page for chmod(1), yes, but on Win32 doesn't a
world-writable file mean it's world-replaceable too?
In any case, I was also try
On Mon, Sep 22, 2008 at 6:23 PM, Eric Wilhelm
<[EMAIL PROTECTED]> wrote:
> Yes. Would someone please explain to me how this issue is not already
> made a mostly non-issue by having a proper umask and running CPAN as
> non-root?
Someone in the thread (sorry, forget who and I'm not going to search
> On Mon, 22 Sep 2008 22:37:55 +0200, [EMAIL PROTECTED] (Andreas J. Koenig)
> said:
>> (d) Something else
> I lean toward PAUSE not indexing them thus pulling the plug as early
> as possible.
And so I have implemented it now. If it breaks too much in too short
time, we could probab
11 matches
Mail list logo
