Should we start adding '-Utaint_support' to CPANtesters configurations

[James E Keenan]

As of perl-5.35.11, perl offers a configuration option,
'-Utaint_support', which enables a user to build a perl executable
without taint support. Neil Bowers contacted me with a pull request for
a CPAN distribution that I co-maintain, IPC-System-Simple
(https://github.com/pjf/ipc-system-simple/pull/39). The purpose of the
p.r. was to enable certain test files to PASS if the user attempted to
install this distro against a "no-taint perl."

This p.r. exposed some problems with the distribution which I haven't
fully resolved but which are probably not perl-5.35.11's problem.
Nonetheless, the fact that Neil is having to work through the "CPAN
River" to create patches for multiple CPAN distros to accommodate
no-taint support suggests that we may need, starting now, to extensively
test distros against perls built with -Utaint_support.

I myself don't do fully automated CPANtesting of the kind that Andreas,
Slaven, Bingos, Carlos and others so unflaggingly do. So I don't know
how much of a human and electronic work burden this might be. I'm
posting here to initiate a discussion.

Thank you very much.
Jim Keenan

[David Cantrell]

On 21/04/2022 22:00, James E Keenan wrote:
> As of perl-5.35.11, perl offers a configuration option,
> '-Utaint_support', which enables a user to build a perl executable
> without taint support.  Neil Bowers contacted me with a pull request for
> a CPAN distribution that I co-maintain, IPC-System-Simple
> (https://github.com/pjf/ipc-system-simple/pull/39).  The purpose of the
> p.r. was to enable certain test files to PASS if the user attempted to
> install this distro against a "no-taint perl."

Yes. I will do so, as I have a module which relies on taint.

> I myself don't do fully automated CPANtesting of the kind that
> Andreas, Slaven, Bingos, Carlos and others so unflaggingly do. So I
> don't know how much of a human and electronic work burden this might
> be. I'm posting here to initiate a discussion.

I already test against a build of blead which I update from git roughly
weekly. It would be trivial to update the script that rebuilds it to
spit out two slightly different builds, so I'll do that this weekend.

--
David Cantrell

[David Cantrell]

On 22/04/2022 07:30, Neil Bowers wrote:
> I’d hold fire on doing anything for a couple of days – there has been an
> extra-time objection to my taint change, which may result in it being
> reverted.
>
> I’ll update you here once it’s resolved either way.

I thought that objection was just about how the user is asked about it
when configuring interactively. But in any case, I have another
potential minor objection - but whether it's a p5p thing or a
CPAN::Reporter thing I don't know:

$ ./blead Tie::Scalar::Decay
...
CPAN::Reporter: Test result is 'pass', 'make test' no errors.
CPAN::Reporter: preparing a CPAN Testers report for Tie-Scalar-Decay-1.1.1
CPAN::Reporter: sending test report with 'pass' via Metabase
...

$ ./blead-no-taint Tie::Scalar::Decay
...
CPAN::Reporter: Test result is 'pass', 'make test' no errors.
CPAN::Reporter: preparing a CPAN Testers report for Tie-Scalar-Decay-1.1.1
CPAN::Reporter: this appears to be a duplicate report for the test phase:
...

Note that CPAN::Reporter can't tell from what's in its list of
previously sent reports that this is a different perl built with
different options. Building with and without -Utaint_support makes no
difference to `archname`, which is what CPAN::Reporter uses to tell the
difference between eg threaded and non-threaded, or normal float vs
longdouble vs quadmath builds.

I'm not sure whether this difference should show up in archname or not,
but if it shouldn't then CPAN::Reporter will need an update so it can
dig it out of Config.pm. It appears to only exist in config_args.

--
David Cantrell