perl-devel June 2006

perl-devel@lists.fedoraproject.org

9 participants
43 discussions

[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 191387] New: RFE: support for perl-Spreadsheet-ParseExcel
by Red Hat Bugzilla 31 Aug '06

31 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 190887] New: RFE: move perl-LDAP to Extras
by Red Hat Bugzilla 20 Jul '06

20 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 191653] New: RFE: DBD::MySQL has been updated to 3.0003
by Red Hat Bugzilla 18 Jul '06

18 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=191653 Summary: RFE: DBD::MySQL has been updated to 3.0003 Product: Fedora Core Version: devel Platform: All URL: http://search.cpan.org/src/CAPTTOFU/DBD-mysql- 3.0003/ChangeLog OS/Version: Linux Status: NEW Severity: normal Priority: normal Component: perl-DBD-MySQL AssignedTo: jvdias(a)redhat.com ReportedBy: rmo(a)sunnmore.net CC: fedora-perl-devel-list(a)redhat.com Description of problem: DBD::Mysql has been updated Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: 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 4

[Bug 194521] New: Update to version 0.7009?
by Red Hat Bugzilla 29 Jun '06

29 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=194521 Summary: Update to version 0.7009? Product: Fedora Extras Version: fc5 Platform: All URL: http://search.cpan.org/dist/Gtk-Perl/ OS/Version: Linux Status: NEW Severity: normal Priority: normal Component: Gtk-Perl AssignedTo: matthias(a)rpmforge.net ReportedBy: cweyl(a)alumni.drew.edu QAContact: extras-qa(a)fedoraproject.org CC: extras-qa(a)fedoraproject.org,fedora-perl-devel- list(a)redhat.com 0.7009 is available... And needed for a module I'm packaging. Would an update be possible? -- 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 184319] New: Spamassassin and SELinux
by Red Hat Bugzilla 28 Jun '06

28 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=184319 Summary: Spamassassin and SELinux Product: Fedora Core Version: fc4 Platform: i386 OS/Version: Linux Status: NEW Severity: normal Priority: normal Component: spamassassin AssignedTo: wtogami(a)redhat.com ReportedBy: rsandu(a)softhome.net 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: As described in SpamAssassin's man page, the program must create user_prefs in $HOME/.spamassassin, where $HOME is the homedirectory of the user spamassassin is run under. When spamc is invoked from Postfix's master.cf file (as described at http://wiki.apache.org/spamassassin/IntegratedSpamdInPostfix) and SELinux is enabled, Spamassassin can't create user_prefs file in /home/someuser, even if "someuser" was created on purpose. Version-Release number of selected component (if applicable): spamassassin-3.0.4-2.fc4 selinux-policy-targeted-1.27.1-2.22 postfix-2.2.2-2 (stock Fedora Core 4 + updates March 06, 2006) How reproducible: Always. Steps to Reproduce: 1. Invoke Spamassassin as a filter, from Postfix, as described in http://wiki.apache.org/spamassassin/IntegratedSpamdInPostfix, with SELinux enabled. Postfix users should be virtual users. Actual results: The process can't write user_prefs under /home/someuser. Expected results: A predefined system user should be created when installing Spamassassin (by the rpm), with an appropiate, FHS-compliant homedirectory, in order to provide a place to create user_prefs, when Postfix users are virtual users and SELinux is enabled. Spamassassin docs should indicate the correct way to proceed/configure in such cases. 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 2

[Bug 195473] New: invalid use of âregisterâ in linkage specification
by Red Hat Bugzilla 27 Jun '06

27 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=195473 Summary: invalid use of ‘register’ in linkage specification Product: Fedora Core Version: devel Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: normal Component: perl AssignedTo: jvdias(a)redhat.com ReportedBy: ellson(a)research.att.com QAContact: dkl(a)redhat.com CC: fedora-perl-devel-list(a)redhat.com Description of problem: I think the right explanation of this problem is that gcc-4.1.1-3 is a little more pedantic than earlier versions and has exposed a bug in the perl headers. On this basis I'm reporting the bug against perl. Attempting to build a swig-generated perl extension, like the attached example, produces many errors like: /usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/perlvars.h:35: error: invalid use of ‘register’ in linkage specification A workaround is to "#define register" (i.e. null out the register keywork completely) Version-Release number of selected component (if applicable): perl-5.8.8-6 gcc-4.1.1-3 swig-1.3.29-0.1 How reproducible: 100% problem verified on x86_64 and i386 platforms Steps to Reproduce: 1. zcat bug.tgz | tar xf - 2. cd bug 3. make Actual results: swig -c++ -perl5 -o example_wrap.cpp example.i /usr/bin/g++ -I`perl -e 'use Config; print $Config{archlib};'`/CORE -fPIC -DPIC -c -o example_wrap.o example_wrap.cpp /usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/thrdvar.h:34: error: invalid use of ‘register’ in linkage specification /usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/thrdvar.h:38: error: invalid use of ‘register’ in linkage specification /usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/thrdvar.h:40: error: invalid use of ‘register’ in linkage specification ... /usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/perlvars.h:66: error: invalid use of ‘register’ in linkage specification /usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/perlvars.h:69: error: invalid use of ‘register’ in linkage specification /usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/perlvars.h:73: error: invalid use of ‘register’ in linkage specification example_wrap.cpp:1421: error: invalid use of ‘register’ in linkage specification example_wrap.cpp:1871: error: invalid use of ‘register’ in linkage specification make: *** [example_wrap.o] Error 1 Expected results: (uncomment the hack that adds "#define register" in Makefile) $ make clean rm -f *.o example_wrap.cpp example.pm libexample* $ make swig -c++ -perl5 -o example_wrap.cpp example.i (echo "#define register"; cat example_wrap.cpp) >example_wrap.cpp.tmp mv -f example_wrap.cpp.tmp example_wrap.cpp /usr/bin/g++ -I`perl -e 'use Config; print $Config{archlib};'`/CORE -fPIC -DPIC -c -o example_wrap.o example_wrap.cpp /usr/bin/g++ -I`perl -e 'use Config; print $Config{archlib};'`/CORE -fPIC -DPIC -c -o example.o example.cpp g++ -shared example_wrap.o example.o -o libexample.so $ ./example.pl 24 Additional info: ------- Additional Comments From ellson(a)research.att.com 2006-06-15 09:19 EST ------- Created an attachment (id=130972) --> (https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=130972&action=view) small test case -- 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 163219] perldl is unable to load the documentaion and demo files
by Red Hat Bugzilla 24 Jun '06

24 Jun '06

Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: perldl is unable to load the documentaion and demo files https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=163219 p.van.egdom(a)gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|MODIFIED |CLOSED Resolution| |CURRENTRELEASE Fixed In Version| |perl-PDL-2.4.2-4.fc5 ------- Additional Comments From p.van.egdom(a)gmail.com 2006-06-23 16:46 EST ------- This seems fixed in "perl-PDL-2.4.2-4.fc5". Below a piece of the changelog : * ma sep 26 2005 Warren Togami <wtogami(a)redhat.com> - 2.4.2-2 - Ship pdldoc.db, tune build dependencies and file permissions (#163219 scop) Below is some output of "perldl" : perlDL shell v1.33 PDL comes with ABSOLUTELY NO WARRANTY. For details, see the file 'COPYING' in the PDL distribution. This is free software and you are welcome to redistribute it under certain conditions, see the same file for details. ReadLines, NiceSlice, MultiLines enabled Reading PDL/default.perldlrc... Found docs database /usr/lib/perl5/vendor_perl/5.8.8/i386-linux-thread-multi/PDL/pdldoc.db Type 'help' for online help Type 'demo' for online demos Loaded PDL v2.4.2 Note: AutoLoader not enabled ('use PDL::AutoLoader' recommended) perldl> -- 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

RE: cpan Module::Build install problem - Argument list too long
by Philippe Lang 22 Jun '06

22 Jun '06

fedora-perl-devel-list-bounces(a)redhat.com wrote: > Philippe Lang wrote: >> Hi, >> >> I'm facing a bug when trying to install a perl module from CPAN, >> which requires the installation of Module::Build first. >> >> This bug is apparently not new: >> http://rt.cpan.org/Public/Bug/Display.html?id=19406. And until now, I >> was not able to find a workaround. Setting the environment variables >> LANG or LC_ALL to C (tips I could find on internet) did not correct >> anything. >> >> >> The problem is the following: if you type >> >>> cpan Module::Build >> >> ... After a while, you get: >> >> Running make test >> /usr/bin/perl Build --makefile_env_macros 1 test t/basic...........ok >> >> t/compat..........ok 2/60Couldn't run Build.PL: Argument list too >> long at >> > /root/.cpan/build/Module-Build-0.2801/blib/lib/Module/Build/Compat.pm >> line 200. >> # Failed test (t/compat.t at line 180) >> t/compat..........NOK 3# Failed test (t/compat.t at line 181) >> >> t/compat..........NOK 4make[1]: *** No targets specified and no >> makefile found. Stop. # Failed test (t/compat.t at line 56) >> t/compat..........NOK 5make[1]: *** No rule to make target `test'. >> Stop. # Failed test (t/compat.t at line 63) >> t/compat..........NOK 6# Failed test (t/compat.t at line 64) >> >> t/compat..........NOK 7# 'MAKE TEST >> >> # MAKE[1]: ENTERING DIRECTORY >> `/ROOT/.CPAN/BUILD/MODULE-BUILD-0.2801/T/_TMP/SIMPLE' # MAKE[1]: >> LEAVING DIRECTORY >> `/ROOT/.CPAN/BUILD/MODULE-BUILD-0.2801/T/_TMP/SIMPLE' # ' # >> doesn't match '(?-xism:DONE\.|SUCCESS)' >> make[1]: *** No rule to make target `realclean'. Stop. >> # Failed test (t/compat.t at line 66) >> t/compat..........NOK 8make: *** [test] Interrupt >> >> >> >> ... And at the end, the module cannot be installed: >> >> >> >> Failed Test Stat Wstat Total Fail List of Failed >> > ---------------------------------------------------------------------- >> -- >> ------- >> t/compat.t 30 7680 60 30 3-10 13-20 38 41 43 45-46 48-55 59 >> 3 tests and 31 subtests skipped. >> Failed 1/21 test scripts. 30/670 subtests failed. >> Files=21, Tests=670, 47 wallclock secs (30.05 cusr + 16.79 csys = >> 46.84 >> CPU) Failed 1/21 test programs. 30/670 subtests failed. >> make: *** [test] Error 255 >> /usr/bin/make test -- NOT OK >> Running make install >> make test had returned bad status, won't install without force >> >> >> >> >> >> This problem is specific to Redhat. I did the same job under FreeBSD >> 6.1 just before, without any problem. >> >> >> Does anyone have an idea how I can install this Module? Is there >> maybe an RPM package in order to install Module::Build? > > This problem affects RHL9, FC1-FC3, and RHEL3-4. > > It may also affect older RHL and RHEL releases; I haven't tried them. > > It can be worked around for RHL9, FC1, FC2, RHEL3 by setting > LANG=C before running the test suite. > > For FC3 and RHEL4 you'll need to use an older version of > Module::Build, such 0.2612. I have packages here: > > http://www.city-fan.org/ftp/contrib/perl-modules/ > > Paul. Thanks a lot Paul, it works just great. Regards, --------------- Philippe Lang Attik System

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

perl-devel June 2006