"... not correct for their bundled versions ..."

Some core modules are bound to a particular Perl version; for instance, if you look at B or strict (on CPAN) you'll see that their distributions are Perl releases. With these, the Perl version and core module are aligned.

Other core modules have their own distributions on CPAN; for example, File::Temp and File::Spec. With these, assuming there are no backwards incompatibilities, you can install a version later than the core version and use it without any problems. I believe the majority of core modules fall into this category; although, that's just a gut feeling and I'd be happy to be corrected on this.

So, the idea of correctness, in this context, will often have no validity.

"... CPAN modules on the runner had been updated for some reason, even though it is a core module."

There are quite a few scenarios where such updates might occur. A couple off the top of my head:

• I want to use a core module. There's a newer version on CPAN with an optimisation/bug fix/security fix/new feature/whatever that I'd like. I install the newer CPAN version.
• I install some arbitrary module. It has a prerequisite for a core module with a later version than I have. The newer version gets installed as part of the overall installation process. Unless I'm closely monitoring the installation output, I may not even notice that this has occurred.

"To add to the confusion all of the failing reports show File::Spec 3.75 loaded, whatever the perl version is."

The latest "File::Spec CPAN version" is 3.75, and has been since August 2018. The latest "File::Spec 5.36.0 core version" is 3.84, released May 2022. So, the latest CPAN version isn't necessarily more recent than the latest core version.

Overall, I wouldn't get too bogged down with what module versions testers have at the time they test your module. Unless there's some indication that an update occurred to meet one of your prerequisites, it's unlikely their current version has any direct bearing on your module.

Purely out of interest (I don't use Mail::SpamAssassin) I successfully installed your module:

  SIDNEY/Mail-SpamAssassin-4.0.0-rc4a-TRIAL.tar.gz
  /usr/bin/make install  -- OK
[download]

When the CPAN Testers Matrix is next updated, you should see a shiny, new, green swatch against 5.36.0 in the cygwin column. :-)

I'll just note that three of your optional modules failed:

Failed during this command:
 (optional) GRUBER/Net-Patricia-1.22.tar.gz   : make_test NO
 (optional) MAXMIND/MaxMind-DB-Reader-XS-1.000009.tar.gz: writemakefil
+e NO '/home/ken/perl5/perlbrew/perls/perl-5.36.0/bin/perl Build.PL' r
+eturned status 256
 (optional) JMEHNLE/mail-spf/Mail-SPF-v2.9.0.tar.gz: make_test NO
[download]

I sent testers reports for all of those. That may be of interest to you; it isn't to me. :-)

I got the first results back from an rc4b-TRIAL that tries out hy's suggestion

  my $tname = shift;
  $tname = untaint_var($tname);
...
  my $abslogdir = File::Spec->canonpath(Cwd::realpath("log"));
  $abslogdir  = untaint_var($abslogdir);
  $workdir = File::Spec->abs2rel(tempdir("$tname.XXXXXX", DIR => $absl
+ogdir));
[download]

Same failure.

I've also earlier uploaded an rc4c-TRIAL that is the same as rc4b-TRIAL except adding a module dependency on File::Temp so the report will show what version it loads, and should see results from that some hours from now.

I looked at the code in File::Temp and File::Spec, particularly File::Spec->splitpath, File::Spec->splitdir and File::Spec->catdir that hy pointed out, and I don't see anything it does that could taint the $path variable that is eventually passed to that mkdir on line 542 when, as in this case, tempdir is called with just template and DIR arguments that are not tainted.

If there are no other hints, I think I will just have to leave it as something on BINGOS' 64 bit test runners (doesn't happen on their i386 and i686 architecture runners) that I can't reproduce, and ignore it unless some user of our module reports it trying to install it.

Ken, thanks for trying it out. The optional modules are optional for a reason. I know some are not really maintained and either don't load or are finicky to load on Windows, like the three you mentioned. They still work on enough platforms that we make use of them if they are available.

hy

s/hy/hv/g; # :)

Same failure.

Ah well, it was worth a try. (I had not appreciated that the sample fail was on Linux, I had imagined more esoteric systems.)

I've looked at more code, and am not seeing any obvious opportunities to get tainted results.

I could just about imagine getting taint interaction from rand() - at least, I know that some systems provide device sources of randomness, which would involve interacting with the filesystem. I'm not aware of any way to configure perl to use those directly with rand() though, and I don't see anything in perl source that would touch a filesystem or environment variables if the standard pp_rand() gets called. I can't rule out something replacing pp_rand in PL_ppaddr[] though.

All I can really suggest is to get more instrumentation by shipping a copy of (some version of) File::Temp::tempdir() (and/or a monkey-patched File::Temp::_gettemp()) with checks at various points that $path is touched.

I see that Scalar::Util provides tainted() at least as far back as the version shipped with perl-5.8, so that's probably a reasonable way to check.

The other option would be to contact BINGOS and ask if he could investigate, or give you access to one of the affected systems. And - long shot - it would also be interesting to check if there are any other modules that both use <c>tempdir() and test its behaviour under tainting that have also been tested by the same smokers.