Re: %ENV not tainted! (was Re: What tests are failing on VMS?)
At 11:59 AM 9/24/2001 -0400, Dan Sugalski wrote:
At 11:23 PM 9/23/2001 -0500, Craig A. Berry wrote:
Basically we're pre-loading a hash when you use keys or values on
%ENV, and if I understand this right, hash elements are not
full-blown scalars and thus do not have tainting bits. Getting an
individual element from %ENV, on the other hand, never involves a
real hash since we just call getenv() or moral equivalent and return
a single (tainted) scalar value. The code where this is implemented
in vms/vms.c is pretty twisty stuff and I don't quite have a good
enough grasp of it yet to be sure this is right or know what to do
about it.
I think the ultimate issue is that %ENV elements fetched from trusted
sources (Like the SYSTEM or CLUSTER mode logicals) are considered untainted,
while the process-level stuff is tainted. Seemed that way the last time I
dove through the twisty mazes, but I might've misread things.
Well, my previous theory is full of it since there is code in hv.c to taint
keys and values retrieved from the pre-loaded %ENV hash. Here's an example
from hv_fetch():
#ifdef DYNAMIC_ENV_FETCH /* %ENV lookup? If so, try to fetch the value now */
if (SvRMAGICAL((SV*)hv) mg_find((SV*)hv, PERL_MAGIC_env)) {
unsigned long len;
char *env = PerlEnv_ENVgetenv_len(key,len);
if (env) {
sv = newSVpvn(env,len);
SvTAINTED_on(sv);
if (key != keysave)
Safefree(key);
return hv_store(hv,key,klen,sv,hash);
}
}
#endif
I think Dan may be onto something though. It seems that not any arbitrary
element of the keys or values of %ENV is guaranteed to be tainted since some
of them are and some of them aren't, and that's by design. However, this
does not mean all is well. On the same system with the same environment, I
see this with Perl 5.5.3:
$ perl -Twle my $foo = (values %ENV)[-1]; open(FILE, qq{$foo})
Name main::FILE used only once: possible typo at -e line 1.
Insecure dependency in open while running with -T switch at -e line 1.
%SYSTEM-F-ABORT, abort
but with 5.6.1 there is no taint warning running the identical code. Sigh.
More dredging in the code and the archives to figure out how this is
supposed to work and what got broken.
Re: %ENV not tainted! (was Re: What tests are failing on VMS?)
At 2:39 AM -0400 9/23/01, Michael G Schwern wrote:
I just ran the taint tests. It looks like VMS's %ENV is *not* tainted.
$ perl -Twle my $foo = (values %ENV)[0]; open(FILE, qq{$foo})
Name main::FILE used only once: possible typo at -e line 1.
Whereas on Unix that would cause a taint error.
I know environment variables are a bit different on VMS than Unix. Is
there any reason you wouldn't want %ENV to be tainted?
Hmm. Generally the environment does taint. For example:
$ DEFINE FOO BAR
$ perl -Twle my $foo=$ENV{'FOO'}; open(FILE, qq{$foo})
Name main::FILE used only once: possible typo at -e line 1.
Insecure dependency in open while running with -T switch at -e line 1.
%SYSTEM-F-ABORT, abort
I don't quite know how to prove this yet, but I think the reason the
example with values %ENV doesn't work derives from the following
behavior as described in Lperlvms/%ENV:
excerpt
At present, the first time you iterate over %ENV using
Ckeys, or Cvalues, you will incur a time penalty as all
logical names are read, in order to fully populate %ENV.
Subsequent iterations will not reread logical names, so they
won't be as slow, but they also won't reflect any changes
to logical name tables caused by other programs.
/excerpt
Basically we're pre-loading a hash when you use keys or values on
%ENV, and if I understand this right, hash elements are not
full-blown scalars and thus do not have tainting bits. Getting an
individual element from %ENV, on the other hand, never involves a
real hash since we just call getenv() or moral equivalent and return
a single (tainted) scalar value. The code where this is implemented
in vms/vms.c is pretty twisty stuff and I don't quite have a good
enough grasp of it yet to be sure this is right or know what to do
about it.
--
Craig A. Berry
mailto:[EMAIL PROTECTED]
... getting out of a sonnet is much more
difficult than getting in.
Brad Leithauser
%ENV not tainted! (was Re: What tests are failing on VMS?)
On Sat, Sep 22, 2001 at 10:59:34PM -0500, Craig A. Berry wrote:
Ok, taint.t. The problem is either inside tainted() or a problem with
how it's picking it's value. I don't think the problem is that %ENV
is not tainted.
Maybe, maybe not. There is a good deal of special handling of both
%ENV and tainting in vms/vms.c. We could have a genuine bug there,
or it may just be test bugs. I'll post the taint test failures in a
separate message.
I just ran the taint tests. It looks like VMS's %ENV is *not* tainted.
$ perl -Twle my $foo = (values %ENV)[0]; open(FILE, qq{$foo})
Name main::FILE used only once: possible typo at -e line 1.
Whereas on Unix that would cause a taint error.
I know environment variables are a bit different on VMS than Unix. Is
there any reason you wouldn't want %ENV to be tainted?
--
Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/
Perl6 Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One
That which stirs me, stirs everything.
-- Squonk Opera, Spoon
Re: What tests are failing on VMS?
In perl.qa, you wrote: So like I said, either tests are habitually failing on vmsperl, or nobody's compiled Perl on OS/390 in a long time (I wouldn't be surprised if that were true). I assume you mean MVS? K. -- Kirrily 'Skud' Robert - [EMAIL PROTECTED] - http://infotrope.net/ We have only two things to worry about: either that things will never get back to normal, or that they already have.
Re: What tests are failing on VMS?
On Sat, Sep 22, 2001 at 01:17:18PM -0500, Craig A. Berry wrote:
Dunno about OS/390 (try the perl-mvs list), but here's the list I got
with perl@12088, Compaq C V6.4-005 on OpenVMS Alpha V7.3:
[-.ext.list.util.t]tainted..FAILED on test 3
[-.lib.extutils]manifestFAILED on test 5
[-.lib.file.find.t]taintFAILED on test 18
[-.lib.test.simple.t]todo...FAILED on test 1
[.lib]vmsishFAILED on test 13
[.op]chdir..FAILED on test 1
[.run]kill_perl.FAILED on test 2
Failed 7/443 tests, 93.00% okay.
Most of these will be difficult or impossible to debug without
access to a VMS system.
Oh ye of little faith. Give me the verbose output of each, please.
There should be a good deal of diagnostic info in there.
manifest.t and chdir.t assume case-preserving file systems.
assume case-preserving file systems... buh.
Ok, trying to wrap my brane around that... what does that mean? Could
open(FILE, Elite); create file called 'eLiTe'? I presume there's a
method to this madness?
For chdir.t, that might be fixed by #12124.
manifest.t... we can probably fix it if I can see the test output.
kill_perl.t runs fine by itself but not in the test suite.
Run vms/test.com on kill_perl.t with the -v flag set and show me the
verbose output.
Did t/op/misc.t used to fail? If so, then it has something to do with
the test names on the end confusing test.com.
Ok, taint.t. The problem is either inside tainted() or a problem with
how it's picking it's value. I don't think the problem is that %ENV
is not tainted.
So let's poke around. Run your moral equivalent of this, please:
#!./perl -Tw
use Devel::Peek;
my $key = (keys %ENV)[0];
my $var = $ENV{$key};
print $key - $var\n;
print Dump $var;
and this
#!./perl -Tw
use Devel::Peek;
my $var = (values %ENV)[0];
print $var\n;
print Dump $var;
and, finally, this:
#!./perl -Tw
use Scalar::Util qw(tainted);
my $var = (values %ENV)[0];
print ok\n if tainted($var);
lib/Test/Simple/t/todo.t failing is probably just a minor bug in
vms/test.com against inline # TODO's with names. That's easy. Try this:
--- vms/test.com2001/09/22 21:45:52 1.1
+++ vms/test.com2001/09/22 21:46:19
@@ -201,7 +201,7 @@
next if /^\s*$/;
-if (/^(not )?ok (\d+)(\s*#.*)?/
+if (/^(not )?ok (\d+)[^#]*(\s*#.*)?/
$2 == $next)
{
my($not, $num, $extra) = ($1, $2, $3);
PS Could you please, please, please, take a swing at getting Perl
installed on the OpenVMS Compaq testdrive account? This will at least
allow us to run things on VMS without having to bug you.
I'm posting information about it here:
http://www.pobox.com/~schwern/cgi-bin/perl-qa-wiki.cgi?CompaqTestDrive
--
Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/
Perl6 Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One
Home of da bomb
Re: What tests are failing on VMS?
At 1:30 AM -0400 9/22/01, Michael G Schwern wrote: So like I said, either tests are habitually failing on vmsperl, or nobody's compiled Perl on OS/390 in a long time (I wouldn't be surprised if that were true). If there are tests that just fail all the time for you guys, post them up and maybe we can fix them, or at least shut them up. Dunno about OS/390 (try the perl-mvs list), but here's the list I got with perl@12088, Compaq C V6.4-005 on OpenVMS Alpha V7.3: [-.ext.list.util.t]tainted..FAILED on test 3 [-.lib.extutils]manifestFAILED on test 5 [-.lib.file.find.t]taintFAILED on test 18 [-.lib.test.simple.t]todo...FAILED on test 1 [.lib]vmsishFAILED on test 13 [.op]chdir..FAILED on test 1 [.run]kill_perl.FAILED on test 2 Failed 7/443 tests, 93.00% okay. I do frequent builds but don't usually post results unless I have a fix. Most of these will be difficult or impossible to debug without access to a VMS system. manifest.t and chdir.t assume case-preserving file systems. kill_perl.t runs fine by itself but not in the test suite. vmsish.t #13 is a known bug in the vmsish 'hushed' pragma. I haven't gotten too far with the others but can try to post detailed results if anyone is interested. -- Craig A. Berry mailto:[EMAIL PROTECTED] Literary critics usually know what they're talking about. Even if they're wrong. -- Perl creator Larry Wall
Re: What tests are failing on VMS?
On Sat, Sep 22, 2001 at 10:59:34PM -0500, Craig A. Berry wrote:
$ perl -MCwd -e chdir('test'); print Cwd::getcwd();
D0:[CRAIG.TEST]
Cwd is running things through VMS::Filespec. I have no idea which one
is the proper thing to do, but it's already been established that Cwd
is generally inconsistent and will most likely stay that way.
For chdir.t, that might be fixed by #12124.
I'll take a look. In the meantime, here's the verbose output:
Ok, after applying 12124 (so everything's using File::Spec and not
Cwd) I still have problems with case differences.
not ok 2 - abs_path() agrees
# Failed test (t/op/chdir.t at line 26)
# got: 'USER1:[SCHWERN.PERL.T]'
# expected: 'USER1:[SCHWERN.PERL.t]'
What's the proper solution to this?
The rest should clear up after tonite's round of chdir patching on
p5p.
manifest.t... we can probably fix it if I can see the test output.
$ perl [-.lib.extutils]manifest.t
1..31
ok 1 - use ExtUtils::Manifest;
ok 2 - make mantest directory
ok 3 - chdir() to mantest
ok 4 - add a temporary file
not ok 5 - mkmanifest() displayed it's additions
# Failed test ([-.lib.extutils]manifest.t at line 58)
# got: 'Added to MANIFEST: MANIFEST
Added to MANIFEST: foo
Added to MANIFEST: manifest
'
# expected: 'Added to MANIFEST: MANIFEST
Added to MANIFEST: foo
'
Ok, it would appear open() is being a smidge too helpful.
ExtUtils::Manifest::mkmanifest() says
open M, MANIFEST;
and it creates the file 'manifest.' Fscinating. Is this normal?
VMS requires every filename to contain a dot?
So open() seems to be handling the non-case-preserving parts ok.
Should it also handle filehandles with no dot?
ok 13 - disabled warnings
not ok 14 - got skipping warning
# Failed test ([-.lib.extutils]manifest.t at line 91)
# 'Skipping manifest.skip
'
# doesn't match '(?-xism:^Skipping MANIFEST\.SKIP)'
Again, open() being too helpful.
ok 18 - created moretest directory
not ok 19 - manifind found [.moretest]quux
# Failed test ([-.lib.extutils]manifest.t at line 109)
Ok, this is failing because we use File::Spec there. We're asking
for:
[.moretest]quux
but manifind() keeps it's keys as unix file paths. That's a genuine
problem. manifind() documents itself as:
manifind() returns a hash reference. The keys of the hash are the
files found below the current directory.
would it work best for it to store the keys as native file paths?
ok 20 - two files found
not ok 21 - both files found
# Failed test ([-.lib.extutils]manifest.t at line 114)
# got: 'foo manifest'
# expected: 'MANIFEST foo'
Another file casing problem.
not ok 22 - maniread found comment
# Failed test ([-.lib.extutils]manifest.t at line 118)
# got: 'none #none'
# expected: '#none'
This looks like a simple matter of the VMS special-case code falling
out of date. Genuine bug. Ok, a little logic rejiggering, nnd,
this should do it. It should also make sure the special-cases don't
drift away.
--- lib/ExtUtils/Manifest.pm2001/09/23 06:05:03 1.1
+++ lib/ExtUtils/Manifest.pm2001/09/23 06:07:46
@@ -142,15 +142,14 @@
while (M){
chomp;
next if /^#/;
+
+my($file, $comment) = /^(\S+)\s*(.*)/;
+next unless $file;
if ($Is_MacOS) {
- my($item,$text) = /^(\S+)\s*(.*)/;
- $item = _macify($item);
- $item =~ s/\\([0-3][0-7][0-7])/sprintf(%c, oct($1))/ge;
- $read-{$item}=$text;
+ $file = _macify($file);
+ $file =~ s/\\([0-3][0-7][0-7])/sprintf(%c, oct($1))/ge;
}
elsif ($Is_VMS) {
- my($file)= /^(\S+)/;
- next unless $file;
my($base,$dir) = File::Basename::fileparse($file);
# Resolve illegal file specifications in the same way as tar
$dir =~ tr/./_/;
@@ -158,9 +157,10 @@
if (@pieces 2) { $base = shift(@pieces) . '.' . join('_',@pieces); }
my $okfile = $dir$base;
warn Debug: Illegal name $file changed to $okfile\n if $Debug;
- $read-{\L$okfile}=$_;
+ $file = \L$okfile;
}
- else { /^(\S+)\s*(.*)/ and $read-{$1}=$2; }
+
+$read-{$file} = $comment;
}
close M;
$read;
ok 30 - return to parent directory
not ok 31 - remove mantest directory
# Failed test ([-.lib.extutils]manifest.t at line 40)
This is failing because the t/mantest directory is not empty. The
unlink on line 147 fails to nail mainfest. Again, related to the
casing issue.
kill_perl.t runs fine by itself but not in the test suite.
Run vms/test.com on kill_perl.t with the -v flag set and show me the
verbose output.
Runs fine by itself, either directly from perl or from within test.com.
Did t/op/misc.t used to fail? If so, then it has something to do with
the test names on the end confusing test.com.
Don't remember offhand
