The last 2 tests in utftaint.t are failing on VMS.
Insecure $ENV{PATH} while running with -T switch at ./test.pl line 547.
I am a bit stumped on how to fix this.
Traditionally on VMS, PATH does not exist.
The C library on VMS helps out and creates a PATH environment variable
when it is referenced. And this appears to be considered tainted by Perl.
Apparently when Perl runs anything in a subprocess, it references this
$ENV{PATH}, as when I run the test program from the CLI, it runs just fine.
Attempting to untaint this $ENV{PATH} causes a LOGICAL NAME PATH to
exist and it still appears to be tainted, and I am not sure how to fix
this if this is the problem.
Changing ENV{PATH} results in a logical name PATH existing after perl
exits which may affect other programs. Even setting the logical name
PERL_ENV_TABLES to CRTL_ENV does not fix this issue.
Interestingly enough, it does not appear easy for Perl on VMS to detect
if a PATH logical name existed before it was run and modified, so Perl
can not clean up.
setting $ENV{PATH} = "" results in a logical name PATH created with a
single character value that is persistent when Perl exits.
It also seems to be one of the ways to untaint PATH.
using delete $ENV{PATH} also results in PATH being untainted, and does
not leave a logical name behind.
This only works if a PATH logical name did not exist before delete
$ENV{PATH} was called. Because then delete $ENV{PATH} just removes the
logical name PATH and that leaves C library generated PATH existing.
In that case two delete $ENV{PATH} calls are needed.
Now if there was a DCL symbol path, then it is probable that it will be
tainted also, so to be sure three delete $ENV{PATH} calls would be needed.
This is an artifact of the way environment variables are implemented in
Perl and the C library.
In the C library, if the environment variable does not exist, then it
looks in the DCL symbol table, and finally all the logical name tables
in the project path, and if it is still not resolved and it is one of a
few special ones, including PATH, the C library generates it. Modified
environment variables are put in the C library environment table.
In Perl on VMS by default, it follows close to the above, except that
modified $ENV{} are put in the process logical name table.
So should test.pl on VMS be doing a delete $ENV{PATH} three times to
make sure it untainted as a fix?
Or should something be done inside of VMS perl to figure out how to
untaint an $ENV{} value.
-John
[EMAIL PROTECTED]
Personal Opinion Only