perl-devel February 2006

perl-devel@lists.fedoraproject.org

4 participants
60 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 169236] New: New version of SpamAssassin available (3.1.0)
by Red Hat Bugzilla 07 Jun '06

07 Jun '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=169236 Summary: New version of SpamAssassin available (3.1.0) Product: Fedora Core Version: fc4 Platform: All URL: http://svn.apache.org/repos/asf/spamassassin/branches/3. 1/UPGRADE OS/Version: Linux Status: NEW Severity: normal Priority: normal Component: spamassassin AssignedTo: wtogami(a)redhat.com ReportedBy: milan.kerslager(a)pslib.cz CC: fedora-perl-devel- list@redhat.com,felicity@kluge.net,jm@jmason.org,parkerm @pobox.com,reg+redhat@sidney.com,wtogami@redhat.com New SpamAssassin 3.1.0 introduces a lot of changes (mostly move to plugins). Will be there a new fersion for FC4 or 3.1.x is supposed to be in FC5 only? Are there some issues for FC4? -- 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 11

[Bug 178580] New: /etc/sysconfig/spamassasin is always modified
by Red Hat Bugzilla 06 Jun '06

06 Jun '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=178580 Summary: /etc/sysconfig/spamassasin is always modified Product: Fedora Core Version: devel Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: normal Component: spamassassin AssignedTo: wtogami(a)redhat.com ReportedBy: wtogami(a)redhat.com CC: fedora-perl-devel- list@redhat.com,felicity@kluge.net,jm@jmason.org,parkerm @pobox.com,reg+redhat@sidney.com,wtogami@redhat.com QA discovered that /etc/sysconfig/spamassasin is being replaced during every package intallation or upgrade. # -a and --auto-whitelist options were removed from 3.0.0 # prevent service startup failure perl -p -i -e 's/(["\s]-\w+)a/$1/ ; s/(["\s]-)a(\w+)/$1$2/ ; s/(["\s])-a\b/$1/' /etc/sysconfig/spamassassin perl -p -i -e 's/ --auto-whitelist//' /etc/sysconfig/spamassassin Since FC3 spamassassin.spec %post contained this to remove user added options during an upgrade from pre-3.0 SA that caused the new version to fail. QA discovered that this perl syntax actually creates another file and deletes the original file. This means that even if no change happens, the file has a different timestamp and selinux security context. Impact: Not much, but it should be fixed some time in the future. Fix: This probably involves testing before doing the modification in order to avoid an unnecessary replacement. In the replacement case chcon is needed in order to maintain the correct selinux context. -- 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 182023] New: error about missing Mail/SPF/Query.pm on each mail processed.
by Red Hat Bugzilla 19 Apr '06

19 Apr '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=182023 Summary: error about missing Mail/SPF/Query.pm on each mail processed. Product: Fedora Core Version: devel Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: normal Component: spamassassin AssignedTo: wtogami(a)redhat.com ReportedBy: davej(a)redhat.com CC: fedora-perl-devel- list@redhat.com,felicity@kluge.net,jm@jmason.org,parkerm @pobox.com,reg+redhat@sidney.com,wtogami@redhat.com each time spamc is invoked, I get this logged in maillog.. Feb 19 03:44:17 nwo spamd[20918]: Can't locate Mail/SPF/Query.pm in @INC (@INC contains: ../lib /usr/lib/perl5/vendor_perl/5.8.8 /usr/lib64/perl5/site_perl/5.8.8/x86_64-linux-thread-multi /usr/lib64/perl5/site_perl/5.8.7/x86_64-linux-thread-multi /usr/lib64/perl5/site_perl/5.8.6/x86_64-linux-thread-multi /usr/lib64/perl5/site_perl/5.8.5/x86_64-linux-thread-multi /usr/lib64/perl5/site_perl/5.8.4/x86_64-linux-thread-multi /usr/lib64/perl5/site_perl/5.8.3/x86_64-linux-thread-multi /usr/lib/perl5/site_perl/5.8.8 /usr/lib/perl5/site_perl/5.8.7 /usr/lib/perl5/site_perl/5.8.6 /usr/lib/perl5/site_perl/5.8.5 /usr/lib/perl5/site_perl/5.8.4 /usr/lib/perl5/site_perl/5.8.3 /usr/lib/perl5/site_perl /usr/lib64/perl5/vendor_perl/5.8.8/x86_64-linux-thread-multi /usr/lib64/perl5/vendor_perl/5.8.7/x86_64-linux-thread-multi /usr/lib64/perl5/vendor_perl/5.8.6/x86_64-linux-thread-multi /usr/lib64/perl5/vendor_perl/5.8.5/x86_64-linux-thread-multi /usr/lib64/perl5/vendor_perl/5.8.4/x86_64-linux-thread-multi /usr/lib64/perl5/vendor Sure enough, there's no Query.pm in any of those (or anywhere in /usr) -- 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.

2 5

[Bug 174984] New: missing timezone variable for Asia/Yekaterinburg in /usr/lib/perl5/vendor_perl/5.8.6/Date/Manip.pm
by Red Hat Bugzilla 15 Mar '06

15 Mar '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=174984 Summary: missing timezone variable for Asia/Yekaterinburg in /usr/lib/perl5/vendor_perl/5.8.6/Date/Manip.pm Product: Fedora Core Version: fc4 Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: normal Component: perl-DateManip AssignedTo: wtogami(a)redhat.com ReportedBy: slain(a)surw.ru CC: fedora-perl-devel-list(a)redhat.com >From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050922 Fedora/1.0.7-1.1.fc4 Firefox/1.0.7 Description of problem: Programs using Date::Manip doesn't work if timezone is set to Asia/Ekaterinburg(YEKT),cause of missing timezone variable in /usr/lib/perl5/vendor_perl/5.8.6/Date/Manip.pm Version-Release number of selected component (if applicable): perl-DateManip-5.42a-4 How reproducible: Always Steps to Reproduce: 1. sudo logwatch Actual Results: ERROR: Date::Manip unable to determine TimeZone. at /usr/lib/perl5/vendor_perl/5.8.6/Date/Manip.pm line 3495 Date::Manip::Date_TimeZone called at /usr/lib/perl5/vendor_perl/5.8.6/Date/Manip.pm line 661 Date::Manip::Date_Init() called at /usr/lib/perl5/vendor_perl/5.8.6/Date/Manip.pm line 779 Date::Manip::ParseDateString('epoch 1133701851') called at /usr/share/logwatch/lib/Logwatch.pm line 508 Logwatch::TimeBuild() called at /usr/sbin/logwatch line 663 Expected Results: working logwatch Additional info: Here is patch to solve it: --- /usr/lib/perl5/vendor_perl/5.8.6/Date/Manip.pm 2003-07-02 22:42:47.000000000 +0600 +++ Manip.pm 2005-12-05 17:57:34.000000000 +0500 @@ -606,6 +606,7 @@ "zp4 +0400 ". # USSR Zone 3 "msd +0400 ". # Moscow Daylight "zp5 +0500 ". # USSR Zone 4 + "yekt +0500 ". # Asia/Yekaterinburg "ist +0530 ". # Indian Standard "zp6 +0600 ". # USSR Zone 5 "novst +0600 ". # Novosibirsk time zone, Russia -- 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 180591] New: bad URL in perl-Net-Telnet package description
by Red Hat Bugzilla 06 Mar '06

06 Mar '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=180591 Summary: bad URL in perl-Net-Telnet package description Product: Fedora Core Version: devel Platform: i386 URL: http://www.cpan.org/~jrogers/Net-Telnet- 3.03/lib/Net/Telnet.pm OS/Version: Linux Status: NEW Severity: normal Priority: normal Component: perl-Net-Telnet AssignedTo: jbrassow(a)redhat.com ReportedBy: petrosyan(a)gmail.com CC: fedora-perl-devel-list(a)redhat.com >From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.1) Gecko/20060202 Fedora/1.5.0.1-2 Firefox/1.5.0.1 Description of problem: bad URL: http://www.cpan.org/~jrogers/Net-Telnet-3.03/lib/Net/Telnet.pm in perl-Net-Telnet package description the correct URL seems to be http://search.cpan.org/src/JROGERS/Net-Telnet-3.03/lib/Net/ Version-Release number of selected component (if applicable): perl-Net-Telnet-0-3.03-4.2 How reproducible: Always Steps to Reproduce: rpm -qi perl-Net-Telnet Additional info: -- 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 183028] Review Request: perl-Spiffy
by Red Hat Bugzilla 28 Feb '06

28 Feb '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-Spiffy https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=183028 ------- Additional Comments From ville.skytta(a)iki.fi 2006-02-28 16:00 EST ------- That will leave trash behind in sourcedir. And for a number of reasons, all Module::Signature checks should be disabled anyway (the exact way how to do that varies between packages). More info: http://koti.welho.com/vskytta/packagers-handbook/packagers-handbook.html#gu… -- 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 183028] Review Request: perl-Spiffy
by Red Hat Bugzilla 28 Feb '06

28 Feb '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-Spiffy https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=183028 ------- Additional Comments From steve(a)silug.org 2006-02-28 15:53 EST ------- Actually, since anything using Module::Signature doesn't like for anything to be in the build directory that isn't in MANIFEST, I'm going with this (unless there are any objections): cat <<'END' > %{_sourcedir}/%{name}-prov #!/bin/sh %{__perl_provides} "$@" | sed -e '/^perl(DB)$/d' END %define __perl_provides %{_sourcedir}/%{name}-prov chmod +x %{__perl_provides} -- 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 183028] Review Request: perl-Spiffy
by Red Hat Bugzilla 28 Feb '06

28 Feb '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-Spiffy https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=183028 ------- Additional Comments From steve(a)silug.org 2006-02-28 15:42 EST ------- Ah, so to be more obvious to a perl person, would this be acceptable? cat <<'END' > %{name}-prov #!/bin/sh %{__perl_provides} "$@" | sed -e '/^perl(DB)$/d' END %define __perl_provides %{_builddir}/Spiffy-%{version}/%{name}-prov chmod +x %{__perl_provides} -- 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 183028] Review Request: perl-Spiffy
by Red Hat Bugzilla 28 Feb '06

28 Feb '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-Spiffy https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=183028 ------- Additional Comments From ville.skytta(a)iki.fi 2006-02-28 14:49 EST ------- Yes, because the perl.prov and perl.req and friends scriptles don't currently take any arguments but just read the filelist from stdin. Backslash protects the $* so it won't be expanded too early when emitting the script. -- 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

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

perl-devel February 2006