ports/57302: A serious FreeBSD-local patch lacks in ports/japanese/perl5

[IIJIMA Hiromitsu]

>Number:         57302
>Category:       ports
>Synopsis:       A serious FreeBSD-local patch lacks in ports/japanese/perl5
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    freebsd-ports-bugs
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:
>Class:          change-request
>Submitter-Id:   current-users
>Arrival-Date:   Sun Sep 28 02:20:23 PDT 2003
>Closed-Date:
>Last-Modified:
>Originator:     IIJIMA Hiromitsu
>Release:        FreeBSD 4.7-RELEASE-p3 i386
>Organization:
DENNOU GEDOU GAKKAI, N. D. D. http://www.dennougedougakkai-ndd.org
>Environment:
System: FreeBSD sodans.usata.org 4.7-RELEASE-p3 FreeBSD 4.7-RELEASE-p3 #0: Wed Jan 22 14:50:19 JST 2003 root at www.my.domain:/usr/src/sys/compile/RENTALv6 i386

The userland is upgraded to -p16, but the kernel is still -p3.
 
>Description:
When perl looks for the modules requested from the script, ports/japanese/perl5
looks standard modules and then site_perl folders, while other perl packages
such as the base system's one (4.7 or later), ports/lang/perl5 (perl 5.6),
ports/lang/perl5.8 looks site_perl first and then standard modules.

This causes a problem on a 4.x system with ports/japanese/perl5 installed.
If you have installed an update of a standard module from either CPAN or
Ports, then /usr/bin/perl [see NOTE] uses the updated module, whereas
/usr/local/bin/perl [see NOTE] still uses an old one from Ports.

[NOTE]
/usr/bin/perl derives from the FreeBSD base system and its version is 5.005_03.

/usr/local/bin/perl is a symlink to a 5.005_03 with Japanese patch, but when
invoked as 'perl' (not 'jperl') it behaves like no-patch standard perl
as far as possible.

Although ports/japanese/perl5's behaviour is the standard implementation of
original perl (and on other systems, such as Linux or MS Windows, perl behaves
just the same), all other three of the above has FreeBSD-local patches to make
them look for site_perl first.

The patch is at, for example, ports/lang/perl5/files/patch-perl.c.

More information (in Japanese) and the patch for perl 5.005_03
(used for the base system's one) is also avalable at:
http://home.jp.FreeBSD.ORG/cgi-bin/showmail/FreeBSD-users-jp/73502

>How-To-Repeat:
First of all, we can check the difference by the following commands:

*** INVOKING STANDARD PERL ***
% /usr/bin/perl -MNoSuchModule
Can't locate NoSuchModule.pm in @INC (@INC contains: /usr/local/lib/perl5/site_perl/5.005/i386-freebsd /usr/local/lib/perl5/site_perl/5.005 . /usr/libdata/perl/5.00503/mach /usr/libdata/perl/5.00503).
BEGIN failed--compilation aborted.

*** INVOKING ports/japanese/perl5 ONE ***
% /usr/local/bin/perl -MNoSuchModule
Can't locate NoSuchModule.pm in @INC (@INC contains: /usr/local/lib/perl5/5.00503/i386-freebsd /usr/local/lib/perl5/5.00503 /usr/local/lib/perl5/site_perl/5.005/i386-freebsd /usr/local/lib/perl5/site_perl/5.005 .).
BEGIN failed--compilation aborted.

Then, install an update of a standard module, such as CGI.pm, from CPAN
or Ports, then try to use it.
/usr/bin/perl successfully uses the updated module, but /usr/local/bin/perl
will use the old one in perl distribution.

>Fix:

Apply the same patch as used to base system's one:
http://home.jp.FreeBSD.ORG/cgi-bin/showmail/FreeBSD-users-jp/73502

[NOTE] I will send another PR for CGI.pm security problems affecting all
       perl distributions.
>Release-Note:
>Audit-Trail:
>Unformatted: