Nicholas Clark (n...@ccl4.org)

User Information

Display Name:

Nicholas Clark

Partial Email Address:

n...@ccl4.org

Posts:

3778	total
31	in PAR
3748	in Perl 5 Porters

5 Most Recent

All Posts

1) Nicholas Clark Re: File::Path regression in 5.8.9

+1 vote

I believe we're back to code with CVE-2002-0435 But we re-add a CVE, so going backwards is not a...

Perl 5 Porters

[ Profile | Reply to group ]

[ Flat Thread Threaded ]

On Fri, Nov 14, 2008 at 11:59:22AM +0100, Gisle Aas wrote:
> On Nov 14, 2008, at 11:15 , Nicholas Clark wrote:
> >True. I considered this, but then we get back to a version with a CVE,
> >don't we?
> 
> No.  perl-5.8.8 shipped with File-Path-1.08 and the CVE-2008-2827 was  
> introduced in the 2.xx series.

I believe we're back to code with CVE-2002-0435

> >I think I like the idea of reverting the detection code for now, and  
> >then
> >repenting in leisure. Er, well, writing it properly in leisure.
> >
> >Am I right in thinking that if the detection code is reverted, the  
> >behaviour
> >is no different (and hence no worse) than the behaviour of 5.8.8 ?
> 
> Yes, it should be with that regard.

But we re-add a CVE, so going backwards is not a good option either.

I would be most happy if File::Path 2.08 removed the check code, and
2.09 re-added it, patched and fixed, and 5.8.9 shipped with 2.08

That way, if there are still lingering bugs in the check code, they don't
afflict everyone who is forced to use core releases only, and banned from
upgrading from CPAN.

Nicholas Clark

2) Nicholas Clark Re: t/op/regexp_unicode_prop_thr.t marked as binary in APC

+1 vote

In this case, I believe that I already fixed the metadata within perforce. I'm not convinced that...

Perl 5 Porters

[ Profile | Reply to group ]

[ Flat Thread Threaded ]

On Wed, Nov 19, 2008 at 10:29:32AM +0100, Rafael Garcia-Suarez wrote:
> 2008/11/19 Andreas J. Koenig <andreas.koenig.7os6VVqR@franz.ak.mind.de>:

> > Rafael, do you still know how such a file can be decontaminated once
> > it has been added to Perforce?
> 
> I think that the trick was to add a packed version of the
> "contaminated" file in the source code of the APC tools.

In this case, I believe that I already fixed the metadata within perforce.

> Well, with the forthcoming git move, that kind of problem should
> disappear. We should probably get rid of all .packed files and add a
> .gitattributes files at the root to record which files are binary.
> (Versioned metadata. Yay)

I'm not convinced that that's reason alone.

Perforce, also, is quite capable of holding binary files, yet we've chosen
deliberately not to have any. I'm not sure of *all* of the reasons why, but
one of them is it useful having the mailed diffs being canonical, rather than 
partial, because one can verify all the commits.

Nicholas Clark

3) Nicholas Clark Re: This Week on perl5-porters - 3-9 November 2008

+1 vote

I never used the word likely, and it wasn't the meaning I intended: Hence this will be the last...

Perl 5 Porters

[ Profile | Reply to group ]

[ Flat Thread Threaded ]

On Wed, Nov 19, 2008 at 12:14:44AM +0100, David Landgren wrote:

> Future maintenance plans for 5.8.x
> 
>   Nicholas Clark added a paragraph to perl589delta explaining that this
>   release (perl 5.8.9) was likely to be the last of the 5.8 series.

I never used the word likely, and it wasn't the meaning I intended:

    Hence this will be the last significant release of the 5.8.x series.

Nicholas Clark

4) Nicholas Clark Re: 5.8.9 RC1 patches for AIX

+1 vote

Ah. Thanks. Yes. rsync://ftp.linux.activestate.com/perl-5.8.x/ Nicholas Clark...

Perl 5 Porters

[ Profile | Reply to group ]

[ Flat Thread Threaded ]

On Tue, Nov 18, 2008 at 04:37:55PM +0100, Rainer Tammer wrote:

> the change 34861 + 34852 do work together, in fact they _only_ work
> together.
> 
> 34861 ensures that the Perl_signbit is not in the export file (which is
> always correct as Perl_signbit is only a #define if the OS has signbit())
> 34852 uses the export file with nativdlopen on AIX

Ah. Thanks.

> Will there a RC2 ?

Yes.

> What is the correct rsync source for the updated RC1 branch ?

rsync://ftp.linux.activestate.com/perl-5.8.x/

Nicholas Clark

5) Nicholas Clark Re: Change 34882 (was Change 34822)

+1 vote

Probably. But I think it is fixed now, because if I edit the file now with perforce, I get a text...

Perl 5 Porters

[ Profile | Reply to group ]

[ Flat Thread Threaded ]

On Tue, Nov 18, 2008 at 10:29:50AM -0500, Jerry D. Hedden wrote:

> Nicholas Clark wrote:
> > No, you managed to add an ASCII NUL byte at the end:
> >
> > Hopefully fixed with 34883. Appended. Not that there's much diff :-)
> 
> Nope.  That didn't fix it.  At least the contents for the missing file
> are not in the change file:
> 
>     ==== //depot/perl/t/op/regexp_unicode_prop_thr.t#2 (text) ====
>     Index: perl/t/op/regexp_unicode_prop_thr.t
>     Binary files perl/t/op/regexp_unicode_prop_thr.t#1~34882~ and
> perl/t/op/regexp_unicode_prop_thr.t differ
>     End of Patch.
> 
> Do I have to manually add this file to my system based on a snapshot archive?

Probably.

But I think it is fixed now, because if I edit the file now with perforce, I
get a text diff. I didn't before I submitted that change.

Note, I *didn't* get a text diff while my metadata change was unsubmitted.
Mmmm. I'd be curious why they don't consider that a bug. Then again, perforce
fails to version control metadata (certainly about permissions) when one
syncs forwards and backwards in history. *That* I feel is a bigger bug to fix.

But we won't be around to see it fixed.

Nicholas Clark

Highlight

Profile | Posts (3778)

Home > People > Nicholas Clark