Configure option for not including taint support

Preamble

Author:  Neil Bowers <neilb@cpan.org>
Sponsor:
ID:      0012
Status:  Accepted

Abstract

Add a Configure option for deciding whether to include taint support in this build of Perl. This is essentially a Configure wrapper around the existing -DSILENT_NO_TAINT_SUPPORT compile flag. The question would be worded as

“Do you want to build Perl with taint support? [y]”,

so the default of “Yes” means that Perl will build as previously.

Motivation

Rationale

Specification

What do we mean by “no Taint support”?

There are currently two compilation options:

  1. SILENT_NO_TAINT_SUPPORT: no taint support, but you can still call -T, it just won’t do anything.
  2. NO_TAINT_SUPPORT: no taint support, trying to call -T is fatal.

Following discussion on the initial proposal, we now propose that the Configure option sets -DSILENT_NO_TAINT_SUPPORT. There are thousands of distributions on CPAN with tests that start with

#!perl -T

Almost all of these don’t require the -T option, but if we make it fatal, then people won’t be able to install a large chunk of CPAN.

Once this is implemented, we’ll be able to identify which CPAN distributions fail to install with taint not enabled, and then decide whether they need updating.

Configure preamble

Before the specific question is asked, Configure should present an explanation.

Perl can provide a set of special security checks, which are known as taint mode. The most well-known of these is that data derived from outside your program should not be trusted (“is tainted”) until you have checked it.

These days there are many more security considerations, and as a result taint mode isn’t widely used. But support for it adds a runtime overhead, whether or not you use it. As a result, you can choose to build Perl without taint support.

Configure prompt

“Do you want to build Perl with taint support? [y]”,

Configure variable

The name proposed for the Configure variable is taint_supported. Because it won’t exist in older versions of Perl, you’d have to check this with logic like this:

use Config;
if (!exists($Config{taint_supported}) || $Config{taint_supported}) {
    # This perl supports taint
}
else {
    # This perl does NOT support taint
}

Documentation changes

perlsec will need to be updated, to explain that the availability of these features depends on how Perl was configured at build time.

Should the documentation be modified at Configure time, to reflect the builder’s decision? I don’t know what precedents there are for this?

perlrun will have to be updated, for example to say that -T relies on Perl having been compiled with taint support.

All other documentation that references taint mode will need to be reviewed to decide whether they should be updated.

Backwards Compatibility

There have been compile flags, -DNO_TAINT_SUPPORT and -DSILENT_NO_TAINT_SUPPORT, for some years, so we’re not really changing much here, but adding this to Configure makes people aware that this option exists.

If you Configure Perl with -d, you’ll still get taint support.

Security Implications

Not applicable, since we’re just putting a thin layer on top of an existing capability.

Famous last words.

Examples

None.

Prototype Implementation

None.

Future Scope

We might consider switching the default to be “don’t include taint support” at some point in the future, but before we consider this, we need a lot more testing without taint support, for example to see what the result is on CPAN.

Rejected Ideas

  1. Do Nothing. Many people on p5p weren’t aware of the existing capability (the compile flag), but on learning of its existence were keen to use it. Extrapolating, the author of this PPC believes that a significant percentage of Perl developers / users would happily make the trade-off (of no taint support, for improved performance), if they had the option.
  2. Default to non-taint support. I think people would rightly be surprised if the new Configure option defaulted to “no taint support”. Anyone currently using taint support would be surprised if they ran Configure -des and then found that their taint-using code stopped working.
  3. Initially I thought this should set -DNO_TAINT_SUPPORT, so use of -T would be fatal. So if someone built Perl without taint support, they’d want to know if something wasn’t working because of that change. But it would also mean they couldn’t install many CPAN distributions, and it’s not realistic to expect them to work around that.
  4. Initially I suggested the question should be “Do you want to drop support for taint? [n]”, so that the new option could default to “No”. But on discussing it with Tux, he felt that people would be confused by the double negative, so we agreed to switch the sense of the question.

Open Issues

I think these question have been resolved far enough here to make a decision on the PPC, and the final details of prompting etc can be left to the implementation.

Copyright (C) 2022, Neil Bowers.

This document and code and documentation within it may be used, redistributed and/or modified under the same terms as Perl itself.