287763 - Receiving Error - Insecure dependency in require...

Status: RESOLVED FIXED

(Bugzilla :: Bugzilla-General, defect, P1)

Description

[Frank Gruman]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6) Gecko/20050317 Firefox/1.0.2
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6) Gecko/20050317 Firefox/1.0.2

Received the following error after upgrading from tip:

Software error:

Insecure dependency in require while running with -T switch at
/usr/lib/perl5/5.8.3/i586-linux-thread-multi/IO/Socket.pm line 22.
Compilation failed in require at /usr/lib/perl5/vendor_perl/5.8.3/Net/LDAP.pm
line 8.
BEGIN failed--compilation aborted at
/usr/lib/perl5/vendor_perl/5.8.3/Net/LDAP.pm line 8.
Compilation failed in require at Bugzilla/Auth/Verify/LDAP.pm line 38.
BEGIN failed--compilation aborted at Bugzilla/Auth/Verify/LDAP.pm line 38.
Compilation failed in require at Bugzilla/Auth.pm line 43.
BEGIN failed--compilation aborted at Bugzilla/Auth.pm line 45.
Compilation failed in require at Bugzilla.pm line 28.
BEGIN failed--compilation aborted at Bugzilla.pm line 28.
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 CGI.pl line 48.
BEGIN failed--compilation aborted at CGI.pl line 48.


Software error:

[Fri Mar 25 19:42:52 2005] index.cgi: Insecure dependency in require while
running with -T switch at
/usr/lib/perl5/5.8.3/i586-linux-thread-multi/IO/Socket.pm line 22.
[Fri Mar 25 19:42:52 2005] index.cgi: Compilation failed in require at
/usr/lib/perl5/vendor_perl/5.8.3/Net/LDAP.pm line 8.
[Fri Mar 25 19:42:52 2005] index.cgi: BEGIN failed--compilation aborted at
/usr/lib/perl5/vendor_perl/5.8.3/Net/LDAP.pm line 8.
[Fri Mar 25 19:42:52 2005] index.cgi: Compilation failed in require at
Bugzilla/Auth/Verify/LDAP.pm line 38.
[Fri Mar 25 19:42:52 2005] index.cgi: BEGIN failed--compilation aborted at
Bugzilla/Auth/Verify/LDAP.pm line 38.
[Fri Mar 25 19:42:52 2005] index.cgi: Compilation failed in require at
Bugzilla/Auth.pm line 43.
[Fri Mar 25 19:42:52 2005] index.cgi: BEGIN failed--compilation aborted at
Bugzilla/Auth.pm line 45.
[Fri Mar 25 19:42:52 2005] index.cgi: Compilation failed in require at
Bugzilla.pm line 28.
[Fri Mar 25 19:42:52 2005] index.cgi: BEGIN failed--compilation aborted at
Bugzilla.pm line 28.
[Fri Mar 25 19:42:52 2005] index.cgi: Compilation failed in require at
Bugzilla/Bug.pm line 38.
[Fri Mar 25 19:42:52 2005] index.cgi: BEGIN failed--compilation aborted at
Bugzilla/Bug.pm line 38.
[Fri Mar 25 19:42:52 2005] index.cgi: Compilation failed in require at CGI.pl
line 48.
[Fri Mar 25 19:42:52 2005] index.cgi: BEGIN failed--compilation aborted at
CGI.pl line 48.
Compilation failed in require at /admin/Bugzilla/index.cgi line 33.


The system was running fine prior to the upgrade from cvs tip.  

Reproducible: Always

Steps to Reproduce:
1.Upgrade test system to latest cvs tip.
2.Run Bugzilla  :-)
3.Lather, rinse, repeat

Comment 1

[Dave Miller [:justdave]]

You have it configured to use LDAP I assume based on the error messages?

Comment 2

[Olav Vitters]

*** Bug 287765 has been marked as a duplicate of this bug. ***

Comment 3

[Olav Vitters]

*** Bug 287764 has been marked as a duplicate of this bug. ***

Comment 4

[Frank Gruman]

Nope....I have the mod_auth_ldap module loaded as I am using it for another
virtual host on the same apache engine.

And I have successfully used the system since I loaded the ldap module.  It
wasn't until I pulled from the current tip that it blew up on me.

Comment 5

[Dave Miller [:justdave]]

OK, so just to get it straight, you DON'T have Bugzilla configured to use LDAP...

which means something is REALLY broken because Bugzilla shouldn't even be
loading the LDAP modules if that's the case.

Comment 6

[Max Kanat-Alexander]

In fact, the stack trace there does indeed prove that you *are* using a Bugzilla
with the "verify method" parameter (or whatever it's called) set to LDAP.

What version of Net::LDAP do you have? Does upgrading it help?

I've also seen that IO::Socket error message before; I think it's from having
too old of a version of IO::Socket (as strange as that may sound). What version
of IO::Socket is on that machine? Does upgrading it help?

Comment 7

[Joel Peshkin]

*** Bug 287926 has been marked as a duplicate of this bug. ***

Comment 8

[Joel Peshkin]

We've been chasing this as a result of a few manifestations...

Without using LDAP, it shows up as soon as you try to use Net::SMTP (or anything
else that involves IO::Socket

See some of the notes on bug 287926

All you have to do is ....

#!/usr/bin/perl -wT
# -*- Mode: perl; indent-tabs-mode: nil -*-
#

use strict;
use lib ".";
require "CGI.pl";
use Bugzilla::Config qw(:locations);


use Net::SMTP;
use IO::Socket;


If you skip the use Bugzilla::Config, the problem goes away
If you hack the IO::Socket file (in perl 5.8.0/5.8.1 at least), to change a line
 from....
require IO::Socket::UNIX if ($^O ne 'epoc');
to....
require IO::Socket::UNIX;

the problem also goes away.

It seems like $^O is tainted in a very strange way.

Comment 9

[:glob ✱]

this looks like an issue with File::Spec

Comment 10

[:glob ✱]

(In reply to comment #9)
> this looks like an issue with File::Spec

i retract this.

it's in find_languages..

if you comment out these lines, the taint error goes away:

    my $deft_path = File::Spec->catdir('template', $lang, 'default');
    my $cust_path = File::Spec->catdir('template', $lang, 'custom');
    push(@languages, $lang) if(-d $deft_path or -d $cust_path);

however replacing them with simplified versions restores the error:

    my $deft_path = "template/$lang/default";
    my $cust_path = "template/$lang/custom";
    push(@languages, $lang) if(-d $deft_path or -d $cust_path);


hrm, $lang is tainted, however grep against the readdir protects us.
trict_taint'ing $lang in the foreach (@langdirs) fixes this.

i'm still trying to figure out why.

Comment 11

[Dave Miller [:justdave]]

(In reply to comment #10)
> hrm, $lang is tainted, however grep against the readdir protects us.
> trict_taint'ing $lang in the foreach (@langdirs) fixes this.
> 
> i'm still trying to figure out why.

It's loaded from a file (well, a directory in this case).  Anything loaded from
a data file is tainted.  Note that loading from a data file is different from
executing a file which sets variables (which is what we do with localconfig and
data/params).

Comment 12

[:glob ✱]

> It's loaded from a file (well, a directory in this case).

sorry, i know why $lang is tainted.  what i don't know is why $^O is getting
tainted as a result of $lang's taintness.

Comment 13

[:glob ✱]

Attachment: v1

Comment 14

[:glob ✱]

Attachment: v2

this is a better way of doing it (thanks joel).

Comment 15

[:glob ✱]

Comment on attachment 179247 [details] [diff] [review]
v2

oops, meant to clear the review, not deny my own patch.

Comment 16

[:glob ✱]

Attachment: v3

v2, while pretty, didn't work.

Comment 17

[Frédéric Buclin]

Checking in defparams.pl;
/cvsroot/mozilla/webtools/bugzilla/defparams.pl,v  <--  defparams.pl
new revision: 1.157; previous revision: 1.156
done