perl-devel August 2006

perl-devel@lists.fedoraproject.org

3 participants
50 discussions

[Bug 199372] New: PATCH: sparc64 use CFLAGS
by Red Hat Bugzilla 02 Oct '06

02 Oct '06

Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=199372 Summary: PATCH: sparc64 use CFLAGS Product: Fedora Core Version: devel Platform: sparc64 OS/Version: Linux Status: NEW Severity: normal Priority: normal Component: perl AssignedTo: jvdias(a)redhat.com ReportedBy: dennis(a)ausil.us QAContact: dkl(a)redhat.com CC: fedora-perl-devel-list@redhat.com,tcallawa@redhat.com Description of problem: sparc64 needs to use CFLAGS with CC to link properly using gcc the attached patch fixes this issue Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info: ------- Additional Comments From dennis(a)ausil.us 2006-07-18 23:33 EST ------- Created an attachment (id=132651) --> (https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=132651&action=view) use cflags -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.

1 3

[Bug 194077] New: upstream perl bugs fixed since 5.8.8 was released
by Red Hat Bugzilla 02 Oct '06

02 Oct '06

Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=194077 Summary: upstream perl bugs fixed since 5.8.8 was released Product: Fedora Core Version: devel Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: normal Component: perl AssignedTo: jvdias(a)redhat.com ReportedBy: jvdias(a)redhat.com QAContact: dkl(a)redhat.com CC: fedora-perl-devel-list(a)redhat.com Description of problem: These upstream perl bugs / issue have beed fixed in the upstream 5.8.x maintenance release of perl since perl-5.8.8 was released: o 38454 - 'rindex corrects for $[ on bytes rather than UTF-8' http://rt.perl.org/rt3/index.html?q=38454 apply upstream patch #27116 o 24816 - 'Magic vars seem unsure if they are purely numeric' http://rt.perl.org/rt3/index.html?q=24816 ( perl -wle 'print $? = $? ^ "3"' -> 'Argument "^C" isn't numeric' ) apply upstream patch #27391 o Avoid writing over the input string in the case 'F' in moreswitches. apply upstream patch #27426 o 34925 - 'overload and rebless' http://rt.perl.org/rt3/index.html?q=34925 apply upstream patches #27509, #27512 o 3038 - '$qr = qr/^a$/m; $x =~ $qr; fails' http://rt.perl.org/rt3/index.html?q=3038 apply upstream patch #27604 o apply upstream patch #27605 - 'Fix off-by-one in $0 set magic.' o 23141 - '($_) = () fails to set $_ to undef' http://rt.perl.org/rt3/index.html?q=23141 apply upstream patch #27914 o 38619 - 'Bug in lc and uc (interaction between UTF-8, substr, and lc/uc)' http://rt.perl.org/rt3/index.html?q=38619 apply upstream patch #27329 Version-Release number of selected component (if applicable): perl-5.8.8-4 How reproducible: 100% Steps to Reproduce: See upstream bug reports and the new RHTS test cases in CVS perl/perl-tests/FC6 . -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.

1 5

[Bug 185242] New: ioctl default minimum argument length of 256 should be restored
by Red Hat Bugzilla 22 Sep '06

22 Sep '06

Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=185242 Summary: ioctl default minimum argument length of 256 should be restored Product: Fedora Core Version: fc4 Platform: All URL: http://rt.perl.org/rt3/Ticket/Display.html?id=38223 OS/Version: Linux Status: NEW Severity: normal Priority: normal Component: perl AssignedTo: jvdias(a)redhat.com ReportedBy: jvdias(a)redhat.com QAContact: dkl(a)redhat.com CC: fedora-perl-devel-list@redhat.com,prockai@redhat.com +++ This bug was initially created as a clone of Bug #185240 +++ Description of problem: This is perl bug request ticket 38223 . Owing to the fix for bug 171111, where the length bitfield of the ioctl number argument, which specifies the length of the optional RD ioctl output third argument, was not being extracted correctly, and perl used 256 as the minimum length of the third argument in all cases, perl now does not ascribe any minimum length to the third argument unless the length bitfield is specified. This has the result that unless the length bitfield of the ioctl number is specified, a third argument of a buffer with insufficient length for the ioctl output will be overflowed, and perl will suffer a buffer overflow and a potential memory access violation or memory corruption, as generated by the following code (from perlbug RT# 38223): #!/usr/bin/perl require 'sys/ioctl.ph'; die "no TIOCGWINSZ " unless defined &TIOCGWINSZ; open(TTY, "+</dev/tty") or die "No tty: $!"; unless (ioctl(TTY, &TIOCGWINSZ, $winsize='')) { die sprintf "$0: ioctl TIOCGWINSZ (%08x: $!)\n", &TIOCGWINSZ; } ($row, $col, $xpixel, $ypixel) = unpack('S4', $winsize); print "(row,col) = ($row,$col)"; print " (xpixel,ypixel) = ($xpixel,$ypixel)" if $xpixel || $ypixel; print "\n"; Perl now correctly detects the buffer overflow: Possible memory corruption: ioctl overflowed 3rd argument at ./bug38223.pl line 5. This would not have occurred with perl versions before perl-5.8.6-18, because the length of all the ioctl third output arguments was made a minimum of 256 bytes. The overflow would not have occurred if the ioctl call had been : ioctl(TTY, &TIOCGWINSZ, $winsize='x'x16) or ioctl(TTY, &TIOCGWINSZ | (16 << &_IOC_SIZESHIFT), $winsize='') The default size of 256 has been restored in the latest upstream patch for this issue: ==== //depot/perl/perl.h#657 (text) ==== Index: perl/perl.h --- perl/perl.h.~1~ Fri Jan 13 04:10:49 2006 +++ perl/perl.h Fri Jan 13 04:10:49 2006 @@ -2977,8 +2977,8 @@ # define IOCPARM_LEN(x) (((x) >> 16) & \ # IOCPARM_MASK) # else # if defined(_IOC_SIZE) && defined(__GLIBC__) - /* on Linux systems we're safe */ -# define IOCPARM_LEN(x) _IOC_SIZE(x) + /* on Linux systems we're safe; except when we're not [perl #38223] */ +# define IOCPARM_LEN(x) (_IOC_SIZE(x) < 256 ? 256 : \ _IOC_SIZE(x)) # else /* otherwise guess at what's safe */ # define IOCPARM_LEN(x) 256 End of Patch. Version-Release number of selected component (if applicable): perl-5.8.6-22 How reproducible: 100% Steps to Reproduce: Invoke a READ ioctl with a 0 length bitfield and and output buffer third argument of insufficient length to hold the potential ioctl output. Actual results: Perl exits with error: Possible memory corruption: ioctl overflowed 3rd argument Expected results: Perl should enforce a minimum length of 256 bytes for the ioctl output buffer. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.

1 6

[Bug 174684] New: Perl integer overflow issue
by Red Hat Bugzilla 22 Sep '06

22 Sep '06

Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=174684 Summary: Perl integer overflow issue Product: Fedora Core Version: fc4 Platform: All OS/Version: Linux Status: NEW Severity: security Priority: normal Component: perl AssignedTo: jvdias(a)redhat.com ReportedBy: bressers(a)redhat.com QAContact: dkl(a)redhat.com CC: fedora-perl-devel-list(a)redhat.com Perl integer overflow issue There exists an integer overflow problem in Perl which can lead to a string format issue. If a large enough integer is supplied to a printf statement which uses the %n conversion, it may be possible to execute arbitrary code. This problem will not be easy to remotely exploit as a very poorly written script will first be needed. http://marc.theaimsgroup.com/?l=full-disclosure&m=113342788118630&w=2 Doesn't Affec: RHEL2.1 This issue also affects FC3 -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.

1 15

[Bug 172336] New: getgrnam() crashes with "Out of memory" if /etc/group contains long lines
by Red Hat Bugzilla 22 Sep '06

22 Sep '06

Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=172336 Summary: getgrnam() crashes with "Out of memory" if /etc/group contains long lines Product: Fedora Core Version: fc4 Platform: i386 URL: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=227621 OS/Version: Linux Status: NEW Severity: security Priority: normal Component: perl AssignedTo: jvdias(a)redhat.com ReportedBy: jvdias(a)redhat.com QAContact: dkl(a)redhat.com CC: fedora-perl-devel-list@redhat.com,prockai@redhat.com +++ This bug was initially created as a clone of Bug #163958 +++ >From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.10) Gecko/20050720 Firefox/1.0.6 Description of problem: This bug has been fixed in Debian and in newest Perl. I'm just wondering does this concern RHEL 3 too, because we are rather close having "too much" users in one group and I would rather see this bug fixed before that we are going to have problems. * Fix test of reenterant function return values which was causing perl to malloc itself to death if ERANGE was encountered before ENOENT (such as a long line in /etc/group; closes: #227621). Version-Release number of selected component (if applicable): How reproducible: Didn't try Additional info: -- Additional comment from jvdias(a)redhat.com on 2005-11-02 16:23 EST -- This is PERL bug 37056, fixed with patch 25084 in bleadperl (5.9.x): ( http://rt.perl.org/rt3/Ticket/Display.html?id=37056 ) Subject: getgrent fails if a line in /etc/groups gets too long Date: Fri, 02 Sep 2005 15:53:08 +0200 To: perlbug(a)perl.org From: Michiel Blotwijk <michiel(a)blotwijk.com> This is a bug report for perl from michiel(a)altiplano.be, generated with the help of perlbug 1.35 running under perl v5.8.5. ----------------------------------------------------------------- [Please enter your report here] The function getgrent throws an error if a line in /etc/groups gets too long (> 3000 characters). This error can be reproduced as follows: 1/ Manually add a large number of users to a group in /etc/group. It doesn't really matter if these are real users or not, as long as the line exceeds 3000 characters. 2/ perl -e 'use User::grent; while (my $gr = getgrent() ) { print $gr->name."\n"; }' This will return an "Out of memory!" message. This thread seems to be related: http://lists.debian.org/debian-security/2005/06/msg00041.html Originally reported at Debian: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=227621 As said in the Debian bug report: From: "Steinar H. Gunderson" <sgunderson(a)bigfoot.com> To: Peter Palúch <peterp(a)frix.fri.utc.sk> Cc: control(a)bugs.debian.org, 227621(a)bugs.debian.org, debian-security(a)lists.debian.org Subject: Re: perl: getgrnam() crashes with "Out of memory" if /etc/group contains long lines Date: Fri, 10 Jun 2005 15:03:02 +0200 It's about the same bug in perl as it was in glibc. reentr.pl line 698 reads: $call = qq[((PL_REENTRANT_RETINT = $call)$test ? $true : (((PL_REENTRANT_RETINT == ERANGE) || (errno == ERANGE)) ? ($seenm{$func}{$seenr{$func}})Perl_reentrant_retry("$func"$rv) : 0))]; The problem here is "errno == ERANGE". If, at any time, there's a line longer than the initial buffer, getgrent() (or any in the same family) will get ERANGE back (and errno will be set to ERANGE). However, this is never reset. Thus, when getgrent_r() hits EOF, it returns ENOENT, _but errno is still ERANGE_. Perl figures the buffer was too small, doubles it and tries again, but still gets ENOENT, of course (and errno is still ERANGE). This goes on forever and ever until you run out of memory (which happens quite fast). The solution is simply to remove "errno == ERANGE" AFAICS; getgrent_r() does not define what happens to errno, and the return message will always be ERANGE if the buffer is too small. I'm a bit tempted to tag this "security"; if a user can (say) change his or her own GECOS field to make it long enough, Perl programs using getpwent() will crash, for instance. I can't find any direct way to exploit it (chfn limits the length of the fields, for instance), but I'm still slightly concerned over the possibilities of a DoS; Cc-ing debian-security. /* Steinar */ I agree this bug has security implications . This problem affects all {get,set}* nss perl wrapper functions, not only getgrent . This problem affects all previous releases of PERL in all current Red Hat releases. The patch is very straightforward - replace all occurences of ((PL_REENTRANT_RETINT == ERANGE) || (errno == ERANGE)) with (PL_REENTRANT_RETINT == ERANGE) in reentr.inc and reentr.pl. This bug is now being fixed in these perl versions: Rawhide / FC-5 : perl-5.8.7-0.7.fc5 FC-4 : perl-5.8.6-16 RHEL-4 : perl-5.8.5-17.RHEL4 RHEL-3 : perl-5.8.0-90.2 -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.

1 3

[Bug 202310] New: perl-DBI: update request to version 1.52 (FC-5 and rawhide)
by Red Hat Bugzilla 15 Sep '06

15 Sep '06

Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=202310 Summary: perl-DBI: update request to version 1.52 (FC-5 and rawhide) Product: Fedora Core Version: devel Platform: All OS/Version: Linux Status: NEW Severity: high Priority: high Component: perl-DBI AssignedTo: jvdias(a)redhat.com ReportedBy: jpo(a)di.uminho.pt CC: fedora-perl-devel-list(a)redhat.com Description of problem: Version 1.52 fixes two memory leaks. Version-Release number of selected component (if applicable): Rawhide: perl-DBI-1.51-1.src.rpm FC-5 : perl-DBI-1.50-2.2.src.rpm Additional info: Version 1.52 changelog ---------------------- +=head2 Changes in DBI 1.52 (svn rev 6734), 30h July 2006 + + Fixed memory leak (per handle) thanks to Nicholas Clark and Ephraim Dan. + Fixed memory leak (16 bytes per sth) thanks to Doru Theodor Petrescu. + Fixed execute_for_fetch/execute_array to RaiseError thanks to Martin J. Evans. + Fixed for perl 5.9.4. Users of Perl >= 5.9.4 will require DBI >= 1.52. + + Updated DBD::File to 0.35 to match the latest release on CPAN. + + Added $dbh->statistics_info specification thanks to Brandon Black. + + Many changes and additions to profiling: + Profile Path can now uses sane strings instead of obscure numbers, + can refer to attributes, assorted magical values, and even code refs! + Parsing of non-numeric DBI_PROFILE env var values has changed. + Changed DBI::Profile docs extensively - many new features. + See DBI::Profile docs for more information. Diff from DBI-1.51 to DBI-1.52 ------------------------------ http://search.cpan.org/diff?from=DBI-1.51&to=DBI-1.52 -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.

1 4

[Bug 191350] Review Request: perl-Spreadsheet-ParseExcel
by Red Hat Bugzilla 30 Aug '06

30 Aug '06

Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: perl-Spreadsheet-ParseExcel https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=191350 Bug 191350 depends on bug 191387, which changed state. Bug 191387 Summary: RFE: support for perl-Spreadsheet-ParseExcel https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=191387 What |Old Value |New Value ---------------------------------------------------------------------------- Resolution| |NEXTRELEASE Status|NEW |CLOSED -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.

1 0

[Bug 191387] New: RFE: support for perl-Spreadsheet-ParseExcel
by Red Hat Bugzilla 30 Aug '06

30 Aug '06

Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=191387 Summary: RFE: support for perl-Spreadsheet-ParseExcel Product: Fedora Extras Version: fc5 Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: normal Component: perl-Unicode-Map AssignedTo: gauret(a)free.fr ReportedBy: mpeters(a)mac.com QAContact: extras-qa(a)fedoraproject.org CC: extras-qa(a)fedoraproject.org,fedora-perl-devel- list(a)redhat.com RFE - support for perl-Spreadsheet-ParseExcel Spreadsheet::ParseExcel is a perl module that requires modification to Unicode::Map in order to fully function. At a minimum, the following lines need to be added to Unicode/Map/REGISTRY: name: CP932Excel srcURL: $SrcUnicode/VENDORS/MICSFT/WINDOWS/CP932.TXT src: $DestUnicode/VENDORS/MICSFT/WINDOWS/CP932.TXT map: (which you copied directry)/CP932Excel.map # Don't remove this line It would not be appropriate for perl-Spreadsheet-ParseExcel to modify that file itself, since it does not own it. -=- Additionally, there is the issue of the CP932Excel.map file perl-Spreadsheet-ParseExcel is a noarch package, but the correct place for the map file is in an arch dependent directory (ie i386-linux-thread-multi/Unicode/Map/MS/WIN/ ) There are two options - I can install the file as part of perl-Spreadsheet-ParseExcel and make the package arch dependent, or the file can be added to the Unicode::Map package. I would prefer the latter, but would be willing to do the former. -=- The README file describing this can be viewed at http://search.cpan.org/src/KWITKNR/Spreadsheet-ParseExcel-0.2603/README The needed map file is at http://search.cpan.org/src/KWITKNR/Spreadsheet-ParseExcel-0.2603/CP932Excel… -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.

1 2

[Bug 204174] New: SpamAssassin with URIDNSBL tries DNS lookups for *.so in body text
by Red Hat Bugzilla 26 Aug '06

26 Aug '06

Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=204174 Summary: SpamAssassin with URIDNSBL tries DNS lookups for *.so in body text Product: Fedora Core Version: fc5 Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: normal Component: spamassassin AssignedTo: wtogami(a)redhat.com ReportedBy: amessina(a)messinet.com CC: fedora-perl-devel- list@redhat.com,felicity@kluge.net,jm@jmason.org,parkerm @pobox.com,reg+redhat@sidney.com,wtogami@redhat.com Description of problem: SpamAssassin, when using the URIDNSBL plugin (the default) attempts DNS queries on body text containing words such as libplain.so, or anything ending in ".so". The DNS queries fail of course. I noticed this problem as I am subscribed to info-cyrus and postfix-users mailing lists where these libraries are often discussed. Version-Release number of selected component (if applicable): spamassassin-3.1.3-1.fc5 How reproducible: Every time. Steps to Reproduce: 1. Ensure that the SpamAssassin URIDNSBL plugin is loaded in /etc/mail/spamassassin/init.pre 2. Send a message with "<whatever word you want>.so" in the body of the message (I tried "marcinator.so") 3. Check your /var/log/messages and see Aug 26 06:51:47 home named[5631]: lame server resolving 'marcinator.so' (in 'so'?): 205.166.226.38#53 Aug 26 06:51:49 home named[5631]: unexpected RCODE (REFUSED) resolving 'marcinator.so/NS/IN': 209.68.0.85#53 Actual results: SpamAssassin looks up *.so from body text Expected results: SpamAssassin would not look up *.so as it causes unnecessary DNS lookups that will fail Additional info: When I comment out the URIDNSBL plugin entry in /etc/mail/spamassassin/init.pre and try again, the symptoms do not occur. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.

1 2

[Bug 197460] libgtk-java package errantly "provides" perl modules
by Red Hat Bugzilla 13 Aug '06

13 Aug '06

Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: libgtk-java package errantly "provides" perl modules https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=197460 skasal(a)redhat.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |CLOSED Resolution| |RAWHIDE ------- Additional Comments From skasal(a)redhat.com 2006-08-13 15:56 EST ------- (In reply to comment #3) > Don't install the examples as +x, They are not installed with +x. (In reply to comment #2) > %define __perl_provides %{nil} Indeed, I'm using this workaround until bug #202210 is fixed. Thank you for the advice. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

perl-devel August 2006