gh-134873: Fix a DOS issue in idlelib

[johnzhou721]

A DOS by Quadratic complexity issue is fixed in idlelib. Part of (but does not fix) #134873.

• Issue: A Series of Simple DOS Vulnerabilities #134873

[terryjreedy]

I believe that the 6 lines from 1205 to 1210 can be replaced by 2 lines -- an re.match and an f-string. I will submit an alternate proposal later. I believe that the input vevent name should have either no <>s or 2 of each, with maybe the latter for back compatibility (I will test). But I will may stick with the more general code to not break buggy extensions.

[ZeroIntensity]

Assuming this is the fix that we go with, let's add a test case.

[johnzhou721]

@terryjreedy so should I leave the code for now, or should I go ahead and replace with the re.match thing you are going to propose? @ZeroIntensity so do you mean that active voice is preferred in release notes? I can replace this specific case with the change that you are suggesting, but I'm asking for advice in this aspect for future News.

[johnzhou721]

Yes, I think it can be. Will fix.

…

Message ID: ***@***.***>

[kexinoh]

@johnzhou721
I would greatly appreciate it if you could kindly address the issue located at

cpython/Lib/idlelib/editor.py

Lines 1373 to 1378 in 5ab66a8

	while True:
	chars = chars[:-1]
	ncharsdeleted = ncharsdeleted + 1
	have = len(chars.expandtabs(tabwidth))
	if have <= want or chars[-1] not in " \t":
	break

. I sincerely apologize for overlooking this in my previous message.

As an example, I successfully utilized Gemini 2.5 Pro to generate a reasonable fix for this problem. Could you give it a try?

[johnzhou721]

@kexinoh Yes, I would give it a try once I have time; however, I am working on something else right now -- is it acceptable if I delay this by about a day or so?

(if anyone else has a fix ready before I get to this, feel free to make a pr onto the branch of my pr and I'll merge it into my PR)

[johnzhou721]

@kexinoh I have a small amount of time not enough to work on anything else before I end my day so I attempted the issue you pointed out -- but can't test though.

[johnzhou721]

Assuming this is the fix that we go with, let's add a test case.

Where? How? For what? Thanks! @ZeroIntensity

[ZeroIntensity]

Where? How? For what?

We need a test case in test_idlelib that results in DOS/extreme slowness off main. Basically, just do something to prove that this PR fixes it (probably just testing with large amounts of data).

[johnzhou721]

I've added tests but there are still logic errors.

[johnzhou721]

Good. Very good.

I've found that I've been assuming everything has width of tabwidth... I'd need to change my approach significantly.

[johnzhou721]

OK So I've just made the tests run in an more organized way, and I've also asserted an at least 10x speedup (w/ one of the test of 10^4 order of magnitude length) and I've also used the old code to confirm the test data is correct. Looks good to me so far!

[johnzhou721]

Wait... all platforms are failing EXCEPT the one I have access to...

[johnzhou721]

Never mind...

[johnzhou721]

I've fixed the issues -- is macOS 14 not using --slow-ci?

Anyways, I just scrubbed the ncharsdeleted stuff in the function and calculate it manually using length differences.

@bedevere-bot I have made the requested changes, please review again

[johnzhou721]

I have made the requested changes; please review again

[bedevere-app]

Thanks for making the requested changes!

@picnixz: please review the changes made to this pull request.

Changes were made, but I'll review it tomorrow (or later this week, I'll be offline for a few days).

[picnixz]

(I'm removing the request until I have time)

[zware]

Sidenote: I have a very hard time believing that there is any reasonable DOS in this code at all. Can someone please explain how it can be exploited?

[johnzhou721]

@zware Maybe have a huge indentwidth and carefully configured string of whitespaces so that want gets very small?