perl-devel July 2006

perl-devel@lists.fedoraproject.org

4 participants
47 discussions

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

21 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 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

When to use perl(:WITH_...) requires?
by Chris Weyl 29 Jul '06

29 Jul '06

Hey all -- Perl provides a number of provides flags, e.g.: perl(:WITH_ITHREADS) perl(:WITH_LARGEFILES) perl(:WITH_PERLIO) perl(:WITH_THREADS) Most perl module spec files only deal with perl(:MODULE_COMPAT_5.8.8), etc. But I see a number of them (arch-specific, typically), do use these flags, along the lines of: Requires: %(perl -MConfig -le 'if (defined $Config{useithreads}) { print "perl(:WITH_ITHREADS)" } else { print "perl(:WITHOUT_ITHREADS)" }') etc, etc. So, when should I use these? Should lines along the one above be included for all flags in an arch-specific spec file? What's a good rule of thumb here? -Chris -- Chris Weyl Ex astris, scientia

1 0

[Bug 197460] libgtk-java package errantly provides perl modules
by Red Hat Bugzilla 29 Jul '06

29 Jul '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 cweyl(a)alumni.drew.edu changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |fedora-perl-devel- | |list(a)redhat.com -- 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 199514] New: suidperl segfaults when different version of perl/suidperl is installed.
by Red Hat Bugzilla 25 Jul '06

25 Jul '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=199514 Summary: suidperl segfaults when different version of perl/suidperl is installed. Product: Fedora Core Version: fc5 Platform: All OS/Version: Linux Status: NEW Severity: low Priority: low Component: perl AssignedTo: jvdias(a)redhat.com ReportedBy: imlinux(a)gmail.com QAContact: dkl(a)redhat.com CC: fedora-perl-devel-list(a)redhat.com Description of problem: suidperl segfaults when different version of perl/suidperl is installed. This is kind of a no-duh but I recently installed perl-suidperl without updating perl. I believe I had version 5.8.8-4 of perl and 5.8.8-5 of perl-suidperl. When running suidperl as a non-root user I'd get a segfault. An strace listed some files that could not be found. After updating perl the error went away. Might be a good idea to have suidperl require perl-%{version}-%{release}. Incredibly minor but thought I'd mention it. -- 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 1

[Bug 122066] Unable to establish LDAP over SSL or TLS
by Red Hat Bugzilla 19 Jul '06

19 Jul '06

Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Unable to establish LDAP over SSL or TLS https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=122066 jvdias(a)redhat.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |steve(a)silug.org ------- Additional Comments From jvdias(a)redhat.com 2006-07-19 19:53 EST ------- *** Bug 190887 has been marked as a duplicate of this bug. *** -- 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 190887] New: RFE: move perl-LDAP to Extras
by Red Hat Bugzilla 19 Jul '06

19 Jul '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=190887 Summary: RFE: move perl-LDAP to Extras Product: Fedora Core Version: devel Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: normal Component: perl-LDAP AssignedTo: jvdias(a)redhat.com ReportedBy: steve(a)silug.org CC: fedora-perl-devel-list(a)redhat.com As seen in bug #122066, perl-LDAP should really require several modules that are available in Extras. Since Core packages can't have dependencies on Extras packages, I think perl-LDAP should be moved to Extras where the correct dependencies can be added. It doesn't look like anything in Core requires it in FC5. # repoquery --whatrequires --alldeps perl-LDAP smbldap-tools-0:0.9.2-2.fc5.noarch perl-LDAP-1:0.33-1.2.noarch amavisd-new-0:2.3.3-5.fc5.noarch otrs-0:2.0.4-3.fc5.noarch amavisd-new-0:2.4.0-1.fc5.noarch -- 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 1

[Bug 199287] New: Replace hardcoded .fc6 by %{?dist}
by Red Hat Bugzilla 19 Jul '06

19 Jul '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=199287 Summary: Replace hardcoded .fc6 by %{?dist} Product: Fedora Core Version: devel Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: normal Component: perl-Net-DNS AssignedTo: jvdias(a)redhat.com ReportedBy: redhat-bugzilla(a)linuxnetz.de CC: fedora-perl-devel-list(a)redhat.com Description of problem: Please replace hardcoded .fc6 by %{?dist} in the perl-Net-DNS spec file. Version-Release number of selected component (if applicable): perl-Net-DNS-0.58-1 Expected results: --- perl-Net-DNS.spec 2006-07-17 22:10:44.000000000 +0200 +++ perl-Net-DNS.spec.rsc 2006-07-18 20:10:05.000000000 +0200 @@ -1,6 +1,6 @@ Name: perl-Net-DNS Version: 0.58 -Release: 1.fc6 +Release: 1%{?dist} Summary: DNS resolver modules for Perl License: GPL or Artistic Group: Development/Libraries -- 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 1

[Bug 122066] Unable to establish LDAP over SSL or TLS
by Red Hat Bugzilla 19 Jul '06

19 Jul '06

Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Unable to establish LDAP over SSL or TLS https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=122066 dax(a)gurulabs.com changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|WONTFIX |RAWHIDE -- 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 122066] Unable to establish LDAP over SSL or TLS
by Red Hat Bugzilla 19 Jul '06

19 Jul '06

Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Unable to establish LDAP over SSL or TLS https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=122066 ------- Additional Comments From dax(a)gurulabs.com 2006-07-19 18:53 EST ------- These just got added to rawhide, so they should be part of core and RHEL5. yah. Finally. -- 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 July 2006