On Tuesday, August 27, 2002, at 09:42 PM, [EMAIL PROTECTED] wrote:
> This test script:
> #!/usr/bin/perl -w
> use strict;
> use Inline C => q{
> int tainting() {
> return PL_tainting;
> }
> };
> print tainting();
> ... works fine when invoked normally, but gives an error when invoked
> with tainting:
> crypt% perl -T ~/t0
> Insecure dependency in require while running with -T switch
> at blib/lib/Inline.pm (autosplit into
> blib/lib/auto/Inline/find_temp_dir.al) line 1157.
> BEGIN failed--compilation aborted at /home/hv/t0 line 7.
> crypt%
>
> This appears to be down to the C< elsif (require FindBin and ...) >
> block in find_temp_dir() - I didn't probe further, but maybe something
> put a tainted path into @INC.
I'm guessing that it's because FindBin.pm uses Cwd.pm, and some
(probably should be *all*?) of the ways Cwd.pm determines the
CWD produce it as a tainted value.
I'm not quite sure why /usr/bin/.Inline/ would be considered a
valid tempdir in the first place, though, which seems to be the
point of that block.
> Independently of that, I note that if I have run ~/t0 once under
> perl-5.8.0, Inline fails to predict an incompatibility if I then
> run it again under 5.6.1 - it tries to dynaload without rebuilding,
> and gets a relocation error. ISTR this is a known problem.
Ooh, that's not so good. Inline has a long list of things that
go into the MD5 hash of source dependencies, I guess perl
version (or even something more specific) should be included.
> Also, I (inadvertently) initially tried to run the test script in
> a perl source directory. It fell over quite readily, because perl
> hadn't been built there, but I'd suggest Inline should not spot
> and take advantage of the source directory unless PERL_CORE is set -
> in this case, the perl I was running with was built from different
> sources, so I suspect it would have gone horribly wrong.
What is PERL_CORE?
-Ken
