develooper Front page | perl.perl5.porters | Postings from March 2022

Configure parameter for taint support

Thread Next
Neil Bowers
March 1, 2022 22:50
Configure parameter for taint support
Message ID:
This is a long message about a change I’m working on, which will be landing in a number of pull requests, and will then result in a project to identify CPAN distributions that need updates, and to steadily work on PRs for those too. The purpose of this email is: (a) to let everyone know what I’m doing, (b) get feedback and suggestions, if I should be doing things differently, or appear to be unaware of additional things I should be doing, and (c) solicit help, particularly on the CPAN front.

tl;dr: I’m adding a Configure question that lets you drop taint support in Perl. This also requires some changes to tests and documentation, and then I’ll make a list of CPAN dists that need updating to handle taint-free perls.


Perl’s taint support (see `perldoc perlsec` if you’re not familiar with it) adds an overhead of ~10-15% to all programs, regardless of whether you’re using the taint features. The exact overhead varies depending on what your code is doing. These days most (note: I didn’t say "all") people don’t ever use the taint features, but we’re all taking that performance hit.

In 2012 Steffen Mueller decided he didn’t want to keep taking that hit, and added two compiler flags, -DSILENT_NO_TAINT_SUPPORT and -DNO_TAINT_SUPPORT. With the first one, any use of taint features (e.g. -T or -t) would be silently ignored. The other option made them a fatal error.

The downside was that Perl’s Configure script didn’t tell you about these, so most people weren’t aware they existed. I submitted an RFC[2]  for adding a Configure question asking whether you want to build perl without taint support. This means you’ve got a parameter in %Config, so perl code can find out whether it’s running under a perl that supports taint or not.

The Configure script that comes with Perl is built using metaconfig[3], which is like a lego kit for building Configure scripts, but instead of bricks you have units. Each unit defines one or more configuration variables. To set the variable, the unit either asks the user questions, or checks for things on the local machine. The latter are known as "probes". Each unit declares the variable(s) that it is going to set, and can also reference variables in other units. When you build a Configure script, the dependencies are used to assemble the units in the right order, so that variables are defined before they’re used in other units.

I’m implementing the RFC: working on adding a question to Configure about taint support, and making changes to perl5 so that all tests will pass if you disable taint support.

Metaconfig changes

The first PR will be against metaconfig[3], to add a unit which asks if the user wants to build perl with taint support. It defaults to "yes", and defines a variable "taint_support". You can explicitly ask for taint support like this:

    ./Configure -Dusedevel -des -Dtaint_support

And if you don’t want taint support, you could run this (note the -U instead of -D):

    ./Configure -Dusedevel -des -Utaint_support

This sets -DSILENT_NO_TAINT_SUPPORT, as opposed to -DNO_TAINT_SUPPORT. This is because lots of CPAN distributions have tests that start with `#!perl -T`. If we took "no taint support" as -DNO_TAINT_SUPPORT, then lots of tests would fail. As it is, some tests will fail. More on that later.

I’ve also changed one other unit, which mentions taint in some explanatory text. If you’ve disabled taint support, then taint now won’t be mentioned.

Perl changes

The PR for perl5 will add an updated Configure script, update various system files, and files that are needed when building Perl on esoteric platforms. For example, VMS has a script; I’m not properly updating that, as I can’t test it. So for VMS it will just default to "taint support enabled" (the guide to updating metaconfig suggests this approach).

All good so far. I can build perls with and without taint support, and everything works as hoped for. But if you build a perl with -DSILENT_NO_TAINT_SUPPORT, then currently a bunch of tests fail. So the remaining changes in my PR will be to get the tests to past, so that you can run:

    ./Configure -Dusedevel -des -Utaint_support
    make && make test && make install

There are two main reasons for this change: (1) make it easy for people to opt out of taint support (to get the performance boost), and (2) so that code can tell whether it’s running under a perl that supports taint. If your perl was built with a Configure that has the taint question, then the %Config hash in will have the "taint_support" key. Here’s how you might check if your perl supports taint:

    use Config;
    if (!exists($Config{taint_support}) || $Config{taint_support}) {
        print "we have taint!\n";

I’m updating Perl’s core tests that use taint, so the relevant bits of testsuites are skipped if perl doesn’t support taint.

There are 4 dual life distributions that are affected. I’ll be doing pull requests on those. My PR will also have commits for those changes, but the cover note will say that those commits shouldn’t be merged, because hopefully my PRs on the CPAN upstream dists will be merged and then new releases of those will be merged into blead.

Documentation changes

The main PR for perl will have changes to perlsec.pod, as that’s the main bit of documentation that talks about taint. I’ve identified 14 other pod files that could do with minor changes, typically to note that your perl might have been configured to not support taint checking, and see perlsec for more details. I plan to do those afterwards in a separate PR, as I want to get the metaconfig and perl5 changes in to blead before the March 20th release freeze.


Once I’ve done the above, I’ll build two versions of perl – with and without taint support – and then test the N distributions at the top of the CPAN River, to make a list of distributions which might need changes so they can be installed cleanly under taint-free perls. Volunteers to help with PRs for those will be welcome.


I think that’s everything. Have I missed anything? Does it all make sense?

I’m working through Perl’s tests at the moment, hoping to have "make test" passing by the end of the weekend. I’ll then try a bunch of different build configurations (such as those the release manager’s guide gets you to do), to see if this causes any more unexpected fails, and work through anything I find.

Thanks to those who’ve helped me get this far, in particular Tux.



Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About