Craig A. Berry wrote:
At 8:14 AM -0500 8/13/07, John E. Malmberg wrote:
Craig A. Berry wrote:
At 11:39 PM -0500 8/12/07, John E. Malmberg wrote:
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.
I don't see this failure with a default configuration. Do you have
any protected subsystem identifiers on that system? That could is
considered the equivalent of running with setuid and could trigger
tainting.
The utftaint.t test is run with the "-T" flag in the command line,
and that is what is triggering the tainting.
I am not aware of any problems with $ENV{PATH} on specifically not tainted
tests.
Is utftaint.t succeeding with all 88 tests for you?
Yes, it is. It appears to matter what the definition of PATH is in
the environment. Specifically, it has to be defined (if defined at
all) to something that parses as a native directory spec. The three
examples below show a native directory spec that exists (test
succeeds), a meaningless bareword (test fails), and a valid native
directory spec that does not exist (test succeeds). So what is the
actual value of PATH that you have when you get the failures?
Symlinks are the only significant configuration option that is
different between your set-up and mine, so perhaps that is part of
the mix. Totally a WAG at this point, but you may have a symlink
that is being taint checked before being followed and we need to
reverse that order.
It is failing for me for path being undefined, and path being set to the
current working directory, project_root:[perl-blead.t] by Perl.
If I set path to project_root:[perl-blead.t] before running the
utftaint.t, it works.
I do not see what is the difference between these logical names, as both
of them are in super, and both are 27 characters long according to f$length.
My only guess is that there is something different about the logical
names that is only visible to the system call.
$ define path d0:[craig.perl.t]
$ perl -"T" [.op]utftaint.t
1..88
ok 1 - tainted: ascii, before test
...
ok 86 - tainted: latin1, downgrade down
ok 87 - fresh_perl - matching a regexp is taint agnostic
ok 88 - fresh_perl - therefore swash_init should be taint agnostic
This works for me also, even though d0:[craig.perl.t] does not exist on
my system.
$ define path foo
%DCL-I-SUPERSEDE, previous value of PATH has been superseded
$ perl -"T" [.op]utftaint.t
1..88
ok 1 - tainted: ascii, before test
...
ok 86 - tainted: latin1, downgrade down
Insecure directory in $ENV{PATH} while running with -T switch at ./test.pl line
537.
# Looks like you planned 88 tests but ran 86.
%SYSTEM-F-ABORT, abort
This also fails for me in the same way.
$ define path notadisk:[notadir]
%DCL-I-SUPERSEDE, previous value of PATH has been superseded
$ perl -"T" [.op]utftaint.t
1..88
ok 1 - tainted: ascii, before test
...
ok 86 - tainted: latin1, downgrade down
ok 87 - fresh_perl - matching a regexp is taint agnostic
ok 88 - fresh_perl - therefore swash_init should be taint agnostic
This succeeds for me.
In the process where I am running the tests standalone, path is not
explicitly assigned by me.
My guess is that it is failing in the tests run as part of the build
because something is leaving a path value that should not be there.
That may be an artifact of some of the symbolic link tests that you are
not running.
I think that it may be useful to modify test.com to look for left over
things like files named ".;", and changes to logical names like Path,
foo, and sys$login.
It still does not seem to make sense to me that the definition of the
PATH environment variable or logical name before running Perl should
determine to if it were able to be untainted or not.
-John
[EMAIL PROTECTED]
Personal Opinion Only
