Skip Menu |

This queue is for tickets about the version CPAN distribution.

Report information
The Basics
Id: 118087
Status: resolved
Priority: 0/
Queue: version

People
Owner: Nobody in particular
Requestors: ppisar [...] redhat.com
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in: 0.9917
Fixed in: (no value)



Subject: Parsing tainted strings in Perl 5.16.3
May I have a question what's version attitude to parsing tainted strings? This code: #!/usr/bin/perl -Tw use version; $ENV{PATH}='/usr/bin'; $a=`echo 1.2.3`; chomp $a; print version->new($a), qq{\n}; works fine since perl v5.17.1-386-g4bac9ae (i.e. prints "1.2.3"), but with older perls (5.16.x and older) it either returns empty string (since version-0.9908) or croaks about "Invalid version format (non-numeric data)" (up to version-0.9907). (The change in version responsible for not croaking is mercurial commit efb44fbc6bd8 (Deal with certain tiedscalars (e.g. created by Readonly::XS).) Does not make sense for the version module to accept tainted input? If it does, would it be possible to change vutil.c so that it works even with perl 5.16 older? To make things more complicated, only the XS implementation is affected. The pure-perl version accepts tainted strings everywhere.
On Mon Sep 26 11:18:40 2016, ppisar wrote: Show quoted text
> May I have a question what's version attitude to parsing tainted strings?
It wasn't initially written assuming that it was going to be a general-purpose version-parsing module that could cope with external data. I wrote it originally to handle assignments to $VERSION and then tests thereof. Now, 10 years down the road, I can see that was a very silly and short-sighted idea. If it is any good at parsing versions, of course someone would want to use it to read the output of some external script. What would you think if I just added a test and simply refused to touch tainted scalars (both to the XS and PP code)? That would put the onus on the user who chooses to run in taint mode to clean the values, which is my reading of good defensive coding. John
Subject: Re: [rt.cpan.org #118087] Parsing tainted strings in Perl 5.16.3
Date: Tue, 27 Sep 2016 07:32:56 +0200
To: John Peacock via RT <bug-version [...] rt.cpan.org>
From: Petr Pisar <ppisar [...] redhat.com>
On Mon, Sep 26, 2016 at 07:56:29PM -0400, John Peacock via RT wrote: Show quoted text
> What would you think if I just added a test and simply refused to touch > tainted scalars (both to the XS and PP code)? That would put the onus on > the user who chooses to run in taint mode to clean the values, which is my > reading of good defensive coding. >
I think that's sane approach. Considering version stores the unparsed string for later use, one could end with a version object providing sometimes tainted and sometimes untainted values. Refusing tainted input completely makes the things simpler. -- Petr
Download signature.asc
application/pgp-signature 213b

Message body not shown because it is not plain text.

Subject: Re: [rt.cpan.org #118087] Parsing tainted strings in Perl 5.16.3
Date: Tue, 27 Sep 2016 08:51:15 +0200
To: John Peacock via RT <bug-version [...] rt.cpan.org>
From: Petr Pisar <ppisar [...] redhat.com>
On Tue, Sep 27, 2016 at 07:32:56AM +0200, Petr Pisar wrote: Show quoted text
> On Mon, Sep 26, 2016 at 07:56:29PM -0400, John Peacock via RT wrote:
> > What would you think if I just added a test and simply refused to touch > > tainted scalars (both to the XS and PP code)? That would put the onus on > > the user who chooses to run in taint mode to clean the values, which is my > > reading of good defensive coding. > >
> I think that's sane approach.
On the other hand, version bundled with Perl does not contain XS variant, therefore banning tainted input in PP code will constitute a change. I don't know p5p's opinion. -- Petr
Download signature.asc
application/pgp-signature 213b

Message body not shown because it is not plain text.

From: ppisar [...] redhat.com
Dne Po 26.zář.2016 11:18:40, ppisar napsal(a): Show quoted text
> May I have a question what's version attitude to parsing tainted > strings? >
I tried to go the opposite way and to add a support for tainted input on old perls. I did some tests with the tainted input and it actually looks like the version object works correctly on tainted values (comparison operators, etc.). The only issue is with stringification that returns undef. This is because Perl_vstringify2() checks for SvPOK(pv) only while the parsing Perl_upg_version2() function checks first for SvPOK(ver) and than falls back to SvPOKp(ver) on PERL_VERSION_LT(5,17,2). Adding the same fall-back logic into Perl_vstringify2(): --- a/vutil/vutil.c Wed Aug 03 06:36:04 2016 -0400 +++ b/vutil/vutil.c Tue Sep 27 15:26:16 2016 +0200 @@ -968,7 +968,11 @@ if (svp) { SV *pv; pv = *svp; - if ( SvPOK(pv) ) + if ( SvPOK(pv) +#if PERL_VERSION_LT(5,17,2) + || SvPOKp(pv) +#endif + ) return newSVsv(pv); else return &PL_sv_undef; allows to return the original string even if it's tainted. Moreover because newSVsv() is used for returning the duplicate, it preserves the taintness. What do you think?
On Tue Sep 27 02:51:36 2016, ppisar wrote: Show quoted text
> On the other hand, version bundled with Perl does not contain XS variant,
Actually, the version code embedded in Perl itself is 100% equivalent to the XS code, so excluding tainted values in both PP and XS/C code would be consistent, whether you are using native Perl or the CPAN version.pm code. John
Will be resolved in 0.9918 (soonish)