Ken, that makes a whole lot of sense. I was off by one commit when looking at what I thought was version 0.23 in the github history and missed that old version also having mkdir at line 542. Probably just a weird coincidence that the only other versions with mkdir at that line are the two most recent, leading me to assume that the CPAN modules on the runner had been updated for some reason, even though it is a core module.

It is still confusing in that besides the various 5.18.x perls on some failing reports, other have perl versions 5.14.x and a 5.20.0 but still say line 542, which is not correct for their bundled versions of File::Temp.

I just noticed that because my module lists File::Spec as a dependency, the CPAN test report includes it in a list with the version that is actually loaded. So I should be able to upload another TRIAL version and in about 24 hours see what these test runners with the failures say the actual versions are they are using. To add to the confusion all of the failing reports show File::Spec 3.75 loaded, whatever the perl version is.

"... 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. :-)

— Ken

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.