[Python-Dev] Negative times behaviour in itertools.repeat for Python maintenance releases (2.7, 3.3 and maybe 3.4)

Terry Reedy tjreedy at udel.edu
Mon Jan 27 07:11:16 CET 2014


On 1/26/2014 11:02 PM, Nick Coghlan wrote:
> On 27 January 2014 13:51, Alexander Belopolsky
> <alexander.belopolsky at gmail.com> wrote:
>>
>> On Sun, Jan 26, 2014 at 12:00 PM, Vajrasky Kok <sky.kok at speaklikeaking.com>
>> wrote:
>>>
>>>>>> repeat('a', times=-1)
>>> repeat('a')
>>
>>
>> As I think about it, this may be more than a bug but a door for a denial of
>> service attack.   Imagine an application where times comes from an untrusted
>> source.  Someone relying on documented behavior may decide to sanitize the
>> value by only checking against an upper bound assuming that negative values
>> would just lead to no repetitions.  If an attacker could somehow case times
>> to get the value of -1 this may cause an infinite loop, blow up memory etc.
>>
>> If you think this is far-fetched - consider a web app that uses repeat() as
>> a part of logic to pretty-print user input.  The times value may come from a
>> calculation of a difference between the screen width and the length of some
>> string - both under user control.
>>
>> So maybe the fix should go into security bugs only branches as well.
>
> If we do go this path, then we should backport the full fix (i.e.
> accepting None to indicate repeating forever), rather than just a
> partial fix.
>
> That is, I'm OK with either not backporting anything at all, or
> backporting the full change. The only idea I object to is the one of
> removing the infinite iteration capability without providing a
> replacement spelling for it.

I believe that the replacement spelling would be the existing 'spelling' 
of no spelling at all -- omitting the argument. However, having to 
(temporarily) write

def myfunc(...what, num, ...):
...
   if times is None:
     itertools.repeat(what, num)
   else:
     itertools.repeat(what)

is obnoxious at best.

While I am a strong supported of no new features in bug releases, one of 
my early commits added a new parameter to difflib.SequenceMatcher. This 
was after pydev discussion that included Tim Peters and which concluded 
that there was no other sane way to fix the bug. If merely making both 
ways of passing times have the same effect is rejected, then I vote for 
the complete fix. Fixing the default for an existing parameter is less 
of a new feature than a new parameter.

-- 
Terry Jan Reedy



More information about the Python-Dev mailing list