[Bug 172336] New: getgrnam() crashes with "Out of memory" if /etc/group contains long lines
by Red Hat Bugzilla
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(a)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.
17 years, 7 months
[Bug 178580] New: /etc/sysconfig/spamassasin is always modified
by Red Hat Bugzilla
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(a)jmason.org,parkerm
@pobox.com,reg+redhat@sidney.com,wtogami(a)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.
17 years, 10 months
[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
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.
18 years, 1 month
[Bug 174373] New: Perl program crashes on end if prepared statements are used
by Red Hat Bugzilla
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=174373
Summary: Perl program crashes on end if prepared statements are
used
Product: Fedora Core
Version: fc4
Platform: i386
OS/Version: Linux
Status: NEW
Severity: normal
Priority: normal
Component: perl-DBD-Pg
AssignedTo: wtogami(a)redhat.com
ReportedBy: pb(a)bieringer.de
CC: fedora-perl-devel-list(a)redhat.com
>From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; de-DE; rv:1.7.12) Gecko/20050919 Firefox/1.0.7
Description of problem:
A specific (not so big) Perl program crashes crashes on a special scenario
Version-Release number of selected component (if applicable):
perl-DBD-Pg-1.41-2 perl-5.8.6-16.fc4 postgresql-8.0.4-2.FC4.1
How reproducible:
Always
Steps to Reproduce:
1. create a Perl program
2. use DBD::Pg
3. connect to database
4. create some prepare statements like
my $statement = "SELECT * FROM table WHERE number = ?";
my $sth_test_select = $dbh->prepare($statement) || die $DBI::errstr;
5. use statements
6. disconnect from database
7. exit
Actual Results: Crash:
rt_sigprocmask(SIG_BLOCK, [PIPE], [], 8) = 0
send(3, "Q\0\0\0\rrollback\0", 14, 0) = 14
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
poll([{fd=3, events=POLLIN|POLLERR, revents=POLLIN}], 1, -1) = 1
recv(3, "C\0\0\0\rROLLBACK\0Z\0\0\0\5I", 16384, 0) = 20
rt_sigprocmask(SIG_BLOCK, [PIPE], [], 8) = 0
send(3, "X\0\0\0\4", 5, 0) = 5
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
close(3) = 0
stat64("/usr/lib/perl5/vendor_perl/5.8.6/i386-linux-thread-multi/auto/DBI/DESTROY.al", 0x94ce0c8) = -1 ENOENT (No such file or directory)
open("/usr/share/locale/locale.alias", O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=2528, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7d6c000
read(3, "# Locale name alias data base.\n#"..., 4096) = 2528
read(3, "", 4096) = 0
close(3) = 0
munmap(0xb7d6c000, 4096) = 0
open("/usr/share/locale/en_US.UTF-8/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/locale/en_US.utf8/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/locale/en_US/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/locale/en.UTF-8/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/locale/en.utf8/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/locale/en/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/lib/perl5/site_perl/5.8.6/i386-linux-thread-multi/auto/DBI/DESTROY.al", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
open("/usr/lib/perl5/site_perl/5.8.5/i386-linux-thread-multi/auto/DBI/DESTROY.al", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
open("/usr/lib/perl5/site_perl/5.8.4/i386-linux-thread-multi/auto/DBI/DESTROY.al", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
open("/usr/lib/perl5/site_perl/5.8.3/i386-linux-thread-multi/auto/DBI/DESTROY.al", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
open("/usr/lib/perl5/site_perl/5.8.6/auto/DBI/DESTROY.al", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
open("/usr/lib/perl5/site_perl/5.8.5/auto/DBI/DESTROY.al", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
open("/usr/lib/perl5/site_perl/5.8.4/auto/DBI/DESTROY.al", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
open("/usr/lib/perl5/site_perl/5.8.3/auto/DBI/DESTROY.al", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
open("/usr/lib/perl5/site_perl/auto/DBI/DESTROY.al", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
open("/usr/lib/perl5/vendor_perl/5.8.6/i386-linux-thread-multi/auto/DBI/DESTROY.al", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
open("/usr/lib/perl5/vendor_perl/5.8.5/i386-linux-thread-multi/auto/DBI/DESTROY.al", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
open("/usr/lib/perl5/vendor_perl/5.8.4/i386-linux-thread-multi/auto/DBI/DESTROY.al", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
open("/usr/lib/perl5/vendor_perl/5.8.3/i386-linux-thread-multi/auto/DBI/DESTROY.al", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
open("/usr/lib/perl5/vendor_perl/5.8.6/auto/DBI/DESTROY.al", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
open("/usr/lib/perl5/vendor_perl/5.8.5/auto/DBI/DESTROY.al", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
open("/usr/lib/perl5/vendor_perl/5.8.4/auto/DBI/DESTROY.al", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
open("/usr/lib/perl5/vendor_perl/5.8.3/auto/DBI/DESTROY.al", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
open("/usr/lib/perl5/vendor_perl/auto/DBI/DESTROY.al", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
open("/usr/lib/perl5/5.8.6/i386-linux-thread-multi/auto/DBI/DESTROY.al", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
open("/usr/lib/perl5/5.8.6/auto/DBI/DESTROY.al", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
open("./auto/DBI/DESTROY.al", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
exit_group(0) = ?
Expected Results: If prepare variable would be undef'ed before exit (before oder after disconnect), the crash would no longer occur.
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.
18 years, 2 months
[Bug 179271] New: spamd: SPF: lookup failed: Can't locate object method "type" via package "Net::DNS::RR::TXT"
by Red Hat Bugzilla
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=179271
Summary: spamd: SPF: lookup failed: Can't locate object method
"type" via package "Net::DNS::RR::TXT"
Product: Fedora Core
Version: fc4
Platform: x86_64
OS/Version: Linux
Status: NEW
Severity: normal
Priority: normal
Component: perl-Net-DNS
AssignedTo: jvdias(a)redhat.com
ReportedBy: aleksander.adamowski.redhat(a)altkom.pl
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/20050923 Fedora/1.7.12-1.5.1
Description of problem:
On an Opteron (x86_64) server, Spamassassin's spamd logs the following error messages every now and then:
Jan 28 21:13:06 nmail spamd[2082]: SPF: lookup failed: __alarm___BEGIN failed--compilation aborted at /usr/lib64/perl5/vendor_perl/5.8.6/x86_64-linux-thread-multi/Net/DNS/RR/TXT.pm line 5, <GEN21> line 32._Compilation failed in require at (eval 55) line 3, <GEN21> line 32.
Jan 28 21:16:26 nmail spamd[2073]: SPF: lookup failed: __alarm___BEGIN failed--compilation aborted at /usr/lib/perl5/5.8.6/Text/ParseWords.pm line 3, <GEN28> line 32._Compilation failed in require at /usr/lib64/perl5/vendor_perl/5.8.6/x86_64-linux-thread-multi/Net/DNS/RR/TXT.pm line 8, <GEN28> line 32._BEGIN failed--compilation aborted at /usr/lib64/perl5/vendor_perl/5.8.6/x86_64-linux-thread-multi/Net/DNS/RR/TXT.pm line 8, <GEN28> line 32._Compilation failed in require at (eval 56) line 3, <GEN28> line 32.
Jan 28 21:20:33 nmail spamd[2078]: SPF: lookup failed: __alarm___Compilation failed in require at (eval 61) line 3, <GEN39> line 32.
Jan 28 21:21:28 nmail spamd[2071]: SPF: lookup failed: __alarm___Compilation failed in require at (eval 58) line 3, <GEN87> line 33.
Jan 28 21:22:14 nmail spamd[2084]: SPF: lookup failed: __alarm___Compilation failed in require at (eval 58) line 3, <GEN111> line 32.
Jan 28 21:27:00 nmail spamd[2082]: SPF: lookup failed: Can't locate object method "new" via package "Net::DNS::RR::TXT" at /usr/lib64/perl5/vendor_perl/5.8.6/x86_64-linux-thread-multi/Net/DNS/RR.pm line 260, <GEN118> line 53.
Jan 28 21:27:38 nmail spamd[2071]: SPF: lookup failed: Can't locate object method "type" via package "Net::DNS::RR::TXT" at /usr/lib/perl5/vendor_perl/5.8.6/Mail/SPF/Query.pm line 1295, <GEN166> line 79.
Jan 28 21:27:44 nmail spamd[2082]: SPF: lookup failed: Can't locate object method "new" via package "Net::DNS::RR::TXT" at /usr/lib64/perl5/vendor_perl/5.8.6/x86_64-linux-thread-multi/Net/DNS/RR.pm line 260, <GEN136> line 79.
Jan 28 21:35:21 nmail spamd[2072]: SPF: lookup failed: __alarm___BEGIN failed--compilation aborted at /usr/lib64/perl5/vendor_perl/5.8.6/x86_64-linux-thread-multi/Net/DNS/RR/TXT.pm line 8, <GEN228> line 79._Compilation failed in require at (eval 90) line 3, <GEN228> line 79.
Jan 28 21:38:52 nmail spamd[2080]: SPF: lookup failed: __alarm___Compilation failed in require at (eval 99) line 3, <GEN246> line 32.
Jan 28 21:39:00 nmail spamd[2069]: SPF: lookup failed: __alarm___Compilation failed in require at (eval 115) line 3, <GEN255> line 32.
Jan 28 21:39:05 nmail spamd[2072]: SPF: lookup failed: Can't locate object method "new" via package "Net::DNS::RR::TXT" at /usr/lib64/perl5/vendor_perl/5.8.6/x86_64-linux-thread-multi/Net/DNS/RR.pm line 260, <GEN262> line 33.
Jan 28 21:40:02 nmail spamd[2083]: SPF: lookup failed: __alarm___Compilation failed in require at (eval 100) line 3, <GEN274> line 33.
Jan 28 21:42:50 nmail spamd[2070]: SPF: lookup failed: __alarm___Compilation failed in require at (eval 91) line 3, <GEN264> line 303.
Jan 28 21:43:00 nmail spamd[2075]: SPF: lookup failed: __alarm___BEGIN failed--compilation aborted at /usr/lib64/perl5/vendor_perl/5.8.6/x86_64-linux-thread-multi/Net/DNS/RR/TXT.pm line 8, <GEN279> line 303._Compilation failed in require at (eval 117) line 3, <GEN279> line 303.
Jan 28 21:45:54 nmail spamd[2070]: SPF: lookup failed: Can't locate object method "type" via package "Net::DNS::RR::TXT" at /usr/lib/perl5/vendor_perl/5.8.6/Mail/SPF/Query.pm line 1295, <GEN282> line 79.
Jan 28 21:54:57 nmail spamd[2074]: SPF: lookup failed: __alarm___BEGIN failed--compilation aborted at /usr/lib64/perl5/vendor_perl/5.8.6/x86_64-linux-thread-multi/Net/DNS/RR/TXT.pm line 8, <GEN317> line 35._Compilation failed in require at (eval 104) line 3, <GEN317> line 35.
Jan 28 21:55:24 nmail spamd[2082]: SPF: lookup failed: Can't locate object method "new" via package "Net::DNS::RR::TXT" at /usr/lib64/perl5/vendor_perl/5.8.6/x86_64-linux-thread-multi/Net/DNS/RR.pm line 260, <GEN293> line 36.
Version-Release number of selected component (if applicable):
perl-Net-DNS-0.49-2, perl-5.8.6-22, spamassassin-3.0.4-2.fc4
How reproducible:
Sometimes
Steps to Reproduce:
1. Install FC4 and the latest updates on an x86_64 machine
2. Launch SpamAssassin
3. Send some mail from the outside world (untrusted networks) to it
4. Watch the maillog
Actual Results: The above errors are logged.
Expected Results: No errors are logged and SPF rules are run by SpamAssassin.
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.
18 years, 2 months
_h2ph_pre.ph / $Config{cppsymbols} omits gcc-3.4+ cpp "predefined macros"
by Jason Vas Dias
This is a bug report for perl from jvdias(a)redhat.com,
generated with the help of perlbug 1.35 running under perl v5.8.8.
-----------------------------------------------------------------
[Please enter your report here]
The gcc cpp "predefined macros" have no definitions in _h2ph_pre.ph,
causing many includes of .ph files to fail, eg. :
<pre>
$ perl -e 'require "sys/socket.ph";'
Undefined subroutine &main::__LONG_MAX__ called at (eval 259) line 1.
Compilation failed in require at /usr/lib/perl5/5.8.8/i386-linux-thread-multi/sys/socket.ph line 11.
Compilation failed in require at -e line 1
</pre>
__LONG_MAX__, and __INT_MAX__, and many other '#define's, have NO
definition in ANY header file with gcc-3.4+, but are built-in to
cpp, as described in the gcc.info documention on the cpp option '-dM':
<pre>
`-dCHARS' ...
`M'
Instead of the normal output, generate a list of `#define'
directives for all the macros defined during the execution of
the preprocessor, including predefined macros. This gives
you a way of finding out what is predefined in your version
of the preprocessor. Assuming you have no file `foo.h', the
command
touch foo.h; cpp -dM foo.h
will show all the predefined macros.
</pre>
With gcc-4+ on i386 Fedora Core, many '#define's are "predefined" in cpp:
<pre>
$ >foo.h; cpp -dM foo.h | egrep '_MAX__|__VERSION|long '
#define __WCHAR_MAX__ 2147483647
#define __SHRT_MAX__ 32767
#define __LDBL_MAX__ 1.18973149535723176502e+4932L
#define __UINTMAX_TYPE__ long long unsigned int
#define __SCHAR_MAX__ 127
#define __DBL_MAX__ 1.7976931348623157e+308
#define __LONG_LONG_MAX__ 9223372036854775807LL
#define __VERSION__ "4.1.0 20060128 (Red Hat 4.1.0-0.17)"
#define __LONG_MAX__ 2147483647L
#define __WCHAR_TYPE__ long int
#define __INT_MAX__ 2147483647
#define __INTMAX_MAX__ 9223372036854775807LL
#define __FLT_MAX__ 3.40282347e+38F
#define __INTMAX_TYPE__ long long int
</pre>
Also, many of these '#define's will cause the current version of
h2ph to emit bad definitions - ie
__VERSION__="4.1.0\ 20060128\ (Red\ Hat\ 4.1.0-0.17)"
would have become:
<pre>
unless (defined &__VERSION__) { sub __VERSION__() { "\"4\.1\.0\\" } }
</pre>
because h2ph split the $Config{cppsymbols} on /\s/ only.
Also floating point defintions were mangled into strings by h2ph:
<pre>
unless (defined &__LDBL_MAX__) { sub __LDBL_MAX__() { "1\.18973149535723176502e\+4932L" }
</pre>
This problem was originally reported as Red Hat bugzilla #178343:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=178343
and is present in all current perl versions - 5.8.7, 5.8.8-RC1, and 5.9.3+ (bleadperl).
So here's a patch against the 5.8.8-RC1 source to merge in the cpp internal
"predefined macro" definitions into Cppsym.true in Configure, so they appear in
$Config{cppsymbols}, and to fix h2ph's _extract_cc_defines() and
build_preamble_if_necessary() subs to deal with escaped whitespace symbol values,
floating point constants, signed numeric constants, and parethensized values properly:
<pre>
___ BEGIN PATCH: ___
--- perl-5.8.8-RC1/Configure.bz178343 2006-01-08 09:51:03.000000000 -0500
+++ perl-5.8.8-RC1/Configure 2006-01-31 11:50:02.000000000 -0500
@@ -20230,6 +20230,19 @@
chmod +x Cppsym.try
$eunicefix Cppsym.try
./Cppsym < Cppsym.know > Cppsym.true
+: Add in any linux cpp "predefined macros":
+if [[ "$osname" == *linux* ]] && [[ "$ccname" == *gcc* ]]; then
+tHdrH=`mktemp ./XXXXXX`
+rm -f $tHdrH'.h' $tHdrH
+touch $tHdrH'.h'
+if cpp -dM $tHdrH'.h' > $tHdrH'_cppsym.h' && [ -s $tHdrH'_cppsym.h' ] ; then
+ sed 's/#define[\ \ ]*//;s/[\ \ ].*$//' < $tHdrH'_cppsym.h' > $tHdrH'_cppsym.real';
+ if [ -s $tHdrH'_cppsym.real' ]; then
+ cat $tHdrH'_cppsym.real' Cppsym.know | sort | uniq | ./Cppsym | sort | uniq > Cppsym.true;
+ fi;
+fi
+rm -f $tHdrH'.h' $tHdrH'_cppsym.h' $tHdrH'_cppsym.real';
+fi;
: now check the C compiler for additional symbols
postprocess_cc_v=''
case "$osname" in
--- perl-5.8.8-RC1/utils/h2ph.PL.bz178343 2006-01-13 12:56:47.000000000 -0500
+++ perl-5.8.8-RC1/utils/h2ph.PL 2006-01-31 11:53:24.000000000 -0500
@@ -778,8 +778,16 @@
if ($opt_D) {
print PREAMBLE "# $_=$define{$_}\n";
}
-
- if ($define{$_} =~ /^(\d+)U?L{0,2}$/i) {
+ if ($define{$_} =~ /^\((.*)\)$/) {
+ # parenthesized value: d=(v)
+ $define{$_} = $1;
+ };
+ if ($define{$_} =~ /^([+-]?(\d+)?\.\d+([eE][+-]?\d+)?)[FL]?$/ ) {
+ # float:
+ print PREAMBLE
+ "unless (defined &$_) { sub $_() { $1 } }\n\n";
+ } elsif ($define{$_} =~ /^([+-]?\d+)U?L{0,2}$/i) {
+ # integer:
print PREAMBLE
"unless (defined &$_) { sub $_() { $1 } }\n\n";
} elsif ($define{$_} =~ /^\w+$/) {
@@ -805,9 +813,8 @@
@Config{'ccsymbols', 'cppsymbols', 'cppccsymbols'};
# Split compiler pre-definitions into `key=value' pairs:
- foreach (split /\s+/, $allsymbols) {
- /(.+?)=(.+)/ and $define{$1} = $2;
-
+ while( $allsymbols=~/([^\s]+)=((\\\s|[^\s])+)/g ) {
+ $define{$1} = $2;
if ($opt_D) {
print STDERR "$_: $1 -> $2\n";
}
___ END PATCH ___
</pre>
Please consider fixing this issue in the upcoming 5.8.8 / 5.9.3 releases,
as many header files are made unusable by this problem .
Thanks & Regards,
Jason Vas Dias<jvdias(a)redhat.com>
perl package maintainer
Red Hat, Inc.
[Please do not change anything below this line]
-----------------------------------------------------------------
---
Flags:
category=core
severity=medium
---
This perlbug was built using Perl v5.8.8 in the Red Hat build system.
It is being executed now by Perl v5.8.8 - Fri Jan 20 16:43:53 EST 2006.
Site configuration information for perl v5.8.8:
Configured by Red Hat, Inc. at Fri Jan 20 16:43:53 EST 2006.
Summary of my perl5 (revision 5 version 8 subversion 8) configuration:
Platform:
osname=linux, osvers=2.6.15-1.1863_fc5, archname=i386-linux-thread-multi
uname='linux jvdias 2.6.15-1.1863_fc5 #1 thu jan 19 19:17:58 est 2006 i686 i686 i386 gnulinux '
config_args='-des -Doptimize=-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i386 -mtune=pentium4 -fasynchronous-unwind-tables -Dversion=5.8.8 -Dmyhostname=localhost -Dperladmin=root@localhost -Dcc=gcc -Dcf_by=Red Hat, Inc. -Dinstallprefix=/usr -Dprefix=/usr -Darchname=i386-linux -Dvendorprefix=/usr -Dsiteprefix=/usr -Duseshrplib -Dusethreads -Duseithreads -Duselargefiles -Dd_dosuid -Dd_semctl_semun -Di_db -Ui_ndbm -Di_gdbm -Di_shadow -Di_syslog -Dman3ext=3pm -Duseperlio -Dinstallusrbinperl=n -Ubincompat5005 -Uversiononly -Dpager=/usr/bin/less -isr -Dd_gethostent_r_proto -Ud_endhostent_r_proto -Ud_sethostent_r_proto -Ud_endprotoent_r_proto -Ud_setprotoent_r_proto -Ud_endservent_r_proto -Ud_setservent_r_proto -Dinc_version_list=5.8.7 5.8.6 5.8.5 5.8.4 5.8.3 -Dscriptdir=/usr/bin'
hint=recommended, useposix=true, d_sigaction=define
usethreads=define use5005threads=undef useithreads=define usemultiplicity=define
useperlio=define d_sfio=undef uselargefiles=define usesocks=undef
use64bitint=undef use64bitall=undef uselongdouble=undef
usemymalloc=n, bincompat5005=undef
Compiler:
cc='gcc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -DDEBUGGING -fno-strict-aliasing -pipe -Wdeclaration-after-statement -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/usr/include/gdbm',
optimize='-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i386 -mtune=pentium4 -fasynchronous-unwind-tables',
cppflags='-D_REENTRANT -D_GNU_SOURCE -DDEBUGGING -fno-strict-aliasing -pipe -Wdeclaration-after-statement -I/usr/local/include -I/usr/include/gdbm'
ccversion='', gccversion='4.1.0 20060117 (Red Hat 4.1.0-0.15)', gccosandvers=''
intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234
d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12
ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8
alignbytes=4, prototype=define
Linker and Libraries:
ld='gcc', ldflags =' -L/usr/local/lib'
libpth=/usr/local/lib /lib /usr/lib
libs=-lresolv -lnsl -lgdbm -ldb -ldl -lm -lcrypt -lutil -lpthread -lc
perllibs=-lresolv -lnsl -ldl -lm -lcrypt -lutil -lpthread -lc
libc=/lib/libc-2.3.90.so, so=so, useshrplib=true, libperl=libperl.so
gnulibc_version='2.3.90'
Dynamic Linking:
dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E -Wl,-rpath,/usr/lib/perl5/5.8.8/i386-linux-thread-multi/CORE'
cccdlflags='-fPIC', lddlflags='-shared -L/usr/local/lib'
Locally applied patches:
RC1
---
@INC for perl v5.8.8:
/usr/lib/perl5/site_perl/5.8.8/i386-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/lib/perl5/vendor_perl/5.8.8/i386-linux-thread-multi
/usr/lib/perl5/vendor_perl/5.8.8
/usr/lib/perl5/vendor_perl/5.8.7
/usr/lib/perl5/vendor_perl/5.8.6
/usr/lib/perl5/vendor_perl/5.8.5
/usr/lib/perl5/vendor_perl/5.8.4
/usr/lib/perl5/vendor_perl/5.8.3
/usr/lib/perl5/vendor_perl
/usr/lib/perl5/5.8.8/i386-linux-thread-multi
/usr/lib/perl5/5.8.8
.
---
Environment for perl v5.8.8:
HOME=/home/boston/jvdias
LANG=en_US.UTF-8
LANGUAGE (unset)
LD_LIBRARY_PATH (unset)
LOGDIR (unset)
PATH=/usr/kerberos/bin:/usr/bin:/bin:/usr/bin:/usr/games:/usr/X11R6/bin:/home/boston/jvdias/bin
PERL_BADLANG (unset)
SHELL=/bin/bash
18 years, 2 months
[Bug 175953] New: perl5db.pl contains syntax error
by Red Hat Bugzilla
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=175953
Summary: perl5db.pl contains syntax error
Product: Fedora Core
Version: fc3
Platform: All
OS/Version: Linux
Status: NEW
Severity: normal
Priority: normal
Component: perl
AssignedTo: jvdias(a)redhat.com
ReportedBy: jeremy(a)jbrookman.me.uk
QAContact: dkl(a)redhat.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.7.12) Gecko/20050922 Fedora/1.0.7-1.1.fc3 Firefox/1.0.7
Description of problem:
perl5db.pl contains a syntax error on line 5814:
my $rv = $ENV{PERLDB_NOTTY} || ( $ENV{HOME} ? $ENV{HOME} : /tmp ) ."/perldbtty$$";
should read
my $rv = $ENV{PERLDB_NOTTY} || ( $ENV{HOME} ? $ENV{HOME} : "/tmp" ) ."/perldbtty$$";
Version-Release number of selected component (if applicable):
perl-5.8.5-22.FC3
How reproducible:
Always
Steps to Reproduce:
perl -d -e 42
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.
18 years, 3 months
[Bug 167354] Review Request: amavisd-new
by Red Hat Bugzilla
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: amavisd-new
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=167354
------- Additional Comments From paul(a)xtdnet.nl 2006-01-24 22:22 EST -------
I finally found the reason for my failure, which is the following line:
$enable_db = 1
checking the build shipped config file shows:
[root@cdc amavisd]# grep enable_db
/usr/src/redhat/BUILD/amavisd-new-2.3.3/amavisd.conf*
/usr/src/redhat/BUILD/amavisd-new-2.3.3/amavisd.conf:$enable_db = 1;
# enable use of BerkeleyDB/libdb (SNMP and nanny)
/usr/src/redhat/BUILD/amavisd-new-2.3.3/amavisd.conf:$enable_global_cache = 1;
# enable use of libdb-based cache if $enable_db=1
/usr/src/redhat/BUILD/amavisd-new-2.3.3/amavisd.conf-default:# $enable_db = 0;
/usr/src/redhat/BUILD/amavisd-new-2.3.3/amavisd.conf-sample:$enable_db = 1;
# enable use of BerkeleyDB/libdb (SNMP and nanny)
/usr/src/redhat/BUILD/amavisd-new-2.3.3/amavisd.conf-sample:$enable_global_cache
= 1; # enable use of libdb-based cache if $enable_db=1
So I believe it did ship with $enable_db=1
So either this functionality is broken, or more likely, something else needs to
happen that I have not yet done, but which was already dont on the server of the
rpm builder.
--
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.
18 years, 3 months