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.

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

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

@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)

@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.

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

Where? How? For what? Thanks! @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).

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

Never mind...

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

I have made the requested changes; please review again

Thanks for making the requested changes!

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

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

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?

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

Did you test it with real file in IDLE, not just by calling delete_trail_char_and_space()? I afraid that you will get hard time just displaying a long line containing 10000 tabulations and 10000 spaces.

@serhiy will do. Yes the dos is very non exploitable and not sure if idle is used in production anyways but since it’s reported let sfix

I disagree. If it is non-exploitable, it's not a DOS. Fixing it only encourages further reports of invulnerable vulnerabilities and a waste of volunteer time.

That said, there does appear to be some opportunity for cleanup here. My objection is to classifying the change as "fixing a DOS" rather than to using cleaner code, at the maintainer (@terryjreedy and/or @serhiy-storchaka)'s discretion.

@zware Good point! If so, we'll remove the fix for the have and want thing and only focus on the .lstrip and .rstrip part for <<<<...>>>>> since that makes the code cleaner. The have and want trimming space thing only reduces the time by a factor of the indent width at best which wouldn't be very high