Closed Bug 353520 Opened 19 years ago Closed 18 years ago

Insecure dependency in piped open while running with -T switch at Bugzilla/BugMail.pm line 653.

Categories

(Bugzilla :: Email Notifications, defect)

Product:
Bugzilla
Component:
Email Notifications
Version:
2.22
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: tncm300, Unassigned)

Details

User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322) Build Identifier: Bugzilla 2.22 I upgraded bugzilla from 2.20 to 2.22. When I open a bug, update bug and leave the bug there for a long time. I commit bug and I got this error "Insecure dependency in piped open while running with -T switch at Bugzilla/BugMail.pm line 653". Could you help? Reproducible: Always Steps to Reproduce: 1. Open a bug 2. Input the comment 3. Leave a bug there for a long time. I dont know exactly how long. 4 Commit Actual Results: I got the software error: Insecure dependency in piped open while running with -T switch at Bugzilla/BugMail.pm line 653. Expected Results: No error
dupe of bug 340538?
I don't think it's a dup of bug 340538. This bug is occured when saving a bug, not changing a password. The error is related to BugMail.pm, not sendmail.pm.
why does time play a role here? Don't you get an error when doing changes "quickly"?
No. I don't get an error when doing changes quickly. Couple our users reported the same error and they said they left the bug untouched more than an hour before they commit to update the bug.
Version: unspecified → 2.22
Could you show us the current output of your ./checksetup.pl?
D:\bugzilla-2.22>checksetup.pl Checking perl modules ... Checking for AppConfig (v1.52) ok: found v1.55 Checking for CGI (v2.93) ok: found v3.04 Checking for Data::Dumper (any) ok: found v2.121 Checking for Date::Format (v2.21) ok: found v2.22 Checking for DBI (v1.38) ok: found v1.48 Checking for File::Spec (v0.84) ok: found v0.87 Checking for File::Temp (any) ok: found v0.14 Checking for Template (v2.08) ok: found v2.13 Checking for Text::Wrap (v2001.0131) ok: found v2001.09291 Checking for Mail::Mailer (v1.67) ok: found v1.67 Checking for MIME::Base64 (v3.01) ok: found v3.01 Checking for MIME::Tools (v5.406) ok: found v5.411 Checking for Storable (any) ok: found v2.12 The following Perl modules are optional: Checking for GD (v1.20) ok: found v2.16 Checking for Chart::Base (v1.0) ok: found v2.3 Checking for XML::Twig (any) not found Checking for GD::Graph (any) ok: found v1.43 Checking for GD::Text::Align (any) ok: found v1.18 Checking for PatchReader (v0.9.4) ok: found v0.9.5 Checking for Image::Magick (any) not found All the required modules are available at: http://landfill.bugzilla.org/ppm/ You can add the repository with the following command: ppm rep add bugzilla http://landfill.bugzilla.org/ppm/ If you want to use the bug import/export feature to move bugs to or from other bugzilla installations, you will need to install the XML::Twig module by running (as Administrator): ppm install XML::Twig If you want to convert BMP image attachments to PNG to conserve disk space, you will need to install the ImageMagick application Available from http://www.imagemagick.org, and the Image::Magick Perl module by running (as Administrator): ppm install Image::Magick Checking user setup ... Removing existing compiled templates ... Precompiling templates ... Checking for DBD::mysql (v2.9003) ok: found v2.9006 Checking for MySQL (v4.0.14) ok: found v4.1.11-nt
Do we perhaps need to untaint $from (after my $from = $headers->get('from');)? Is $headers potentially tainted because its source may include a param, and thus having been read from a file? But if so, why doesn't this bug happen all the time?
Perhaps this problem is unique to Windows?
(In reply to comment #8) > Perhaps this problem is unique to Windows? Line 653 of BugMail.pm is in a if($^O =~ /MSWin32/i) block, so yes.
http://groups.google.com.au/group/perl.perl5.porters/browse_thread/thread/714f78a2dd778799/3b2af50714bf644d "Tainting is able to contaminate special variable $^O that is only read, when a tainted value and $^O are both evaluated as conditions of the same "if" construct." the bug is still open: http://rt.perl.org/rt3/Public/Bug/Display.html?id=24674 the fix appears to use osname from Config instead of $^O. that doesn't explain the timings, but it would be interesting to see if it makes a difference.
glob, this bug is still unconfirmed. Does it mean it's specific to some very special conditions? Decreasing severity as nobody else seems to complain about this bug.
Severity: critical → normal
Actually, I'm fairly certain that this dup is the special Windows case of bug 340538. The only reason the error message is in a different place is because Windows has special code for using sendmail.exe. *** This bug has been marked as a duplicate of 340538 ***
Status: UNCONFIRMED → RESOLVED
Closed: 19 years ago
Resolution: --- → DUPLICATE
I upgraded Bugzilla from 2.22 to 2.22.1. The problem is still occured. Could you please help me how to fix this? Thanks.
tran: Do you have any custom templates or any customizations to your Bugzilla? Are you using a language pack?
(In reply to comment #14) > tran: Do you have any custom templates or any customizations to your Bugzilla? Yes. But I only changed UI related files. Here are files I changed: enter_bug.cgi enter_bug.cgi banner.html.tmpl variables.none.tmpl global.css Usefull-links.html.tmpl > Are you using a language pack? No. I removed code (&& $^O =~ /MSWin32/i) in BugMail.pm and our users haven't got this error so far. I'm not sure it will fix the problem or not. Our Bugzilla worked on 2.18 and 2.20. The problem occured only when I updated from 2.20 to 2.22.
I still got this error in Bugzilla 2.22.1 The error occurs occasionally when updating the flag. Please help.
Status: RESOLVED → UNCONFIRMED
Resolution: DUPLICATE → ---
(In reply to comment #10) > http://groups.google.com.au/group/perl.perl5.porters/browse_thread/thread/714f78a2dd778799/3b2af50714bf644d > "Tainting is able to contaminate special variable $^O that is only > read, when a tainted value and $^O are both evaluated as conditions of > the same "if" construct." > the bug is still open: > http://rt.perl.org/rt3/Public/Bug/Display.html?id=24674 > the fix appears to use osname from Config instead of $^O. Please tell me more. How can I get the osname from Congig file? > that doesn't explain the timings, but it would be interesting to see if it > makes a difference.
> > the fix appears to use osname from Config instead of $^O. > Please tell me more. How can I get the osname from Config file? add "use Config;" to the file(s) that use $^O replace $^O with $Config{'osname'} eg. change if($^O =~ /MSWin32/i) to if($Config{'osname'} =~ /MSWin32/i)
(In reply to comment #18) > > > the fix appears to use osname from Config instead of $^O. > > Please tell me more. How can I get the osname from Config file? > add "use Config;" to the file(s) that use $^O > replace $^O with $Config{'osname'} > eg. > change > if($^O =~ /MSWin32/i) > to > if($Config{'osname'} =~ /MSWin32/i) I got this error error after I changed it: Software error: Global symbol "%Config" requires explicit package name at Bugzilla/BugMail.pm line 648. Compilation failed in require at Bugzilla/Flag.pm line 73. BEGIN failed--compilation aborted at Bugzilla/Flag.pm line 73. Compilation failed in require at Bugzilla/Attachment.pm line 52. BEGIN failed--compilation aborted at Bugzilla/Attachment.pm line 52. Compilation failed in require at Bugzilla/Bug.pm line 38. BEGIN failed--compilation aborted at Bugzilla/Bug.pm line 38. Compilation failed in require at D:/bugzilla-2.22.1/buglist.cgi line 42. BEGIN failed--compilation aborted at D:/bugzilla-2.22.1/buglist.cgi line 42.
> > add "use Config;" to the file(s) that use $^O > Global symbol "%Config" requires explicit package name at Bugzilla/BugMail.pm > line 648. you forgot "use Config;"
After changing the config to include the OS name, the error is still happening. Some our users reported that they still got the error. This error is happening more often when the user sets a flag and includes a comment and hits submit. I think it's related to timing issue too. Could you please help to fix this problem? Thanks.
In Bugzilla in the same version installation that Tran mentioned I would like to add another scenario. Set a user defined flag to ? Added a comment Submit the form And you get this error intermittently.
After upgrading from Bugzilla 2.20 in place, this bug is happening on a weekly basis at random intervals. Updating flags and comments do produce this error randomly.
(In reply to comment #23) > After upgrading from Bugzilla 2.20 in place, From 2.20 to what version?
From 2.20 to 2.22.2.
Unless anybody has an idea how to proceed here, I'm inclined to mark this WONTFIX seeing that 3.0's mailing has been completely overhauled. (I'd say it WORKSFORME on 3.0, but 2.22 is a supported branch...)
(In reply to comment #26) > WORKSFORME on 3.0, but 2.22 is a supported branch...) Yeah, but we only take security fixes on 2.22. So WFM. Reopen if someone can reproduce the bug on 3.0.x or 3.1.x.
Status: UNCONFIRMED → RESOLVED
Closed: 19 years ago → 18 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.