> Martin, what constitutes a security fix for Python?  For example,  
> isn't it conceivable that one could place a long key into some  
> registry setting used by python and thus interfere with its stack?

If it has a CVE identifier, it's a security fix. Otherwise, I'd apply
standard risk assessment procedures, and ask the release manager for
judgement.

> Aren't stack buffer overruns a classic security hole?

My personal risk assessment of this issue is that it has a fairly low
risk, as the likelihood of an attack is low. Just placing a key in the
registry is not sufficient as an attack: one would also need a different
user who has a Python application that enumerates this part of the
registry. In that scenario, the user would have to be unprivileged (*), i.e.
would not have write permissions to either HKLM nor HKCR. Writing to HKCU
does not constitute a threat, since it would only allow to crash your own
Python applications.

There may be opportunities where an administrator has a script that
traverses HKEY_USERS while a different user is logged on. Given that the
threat of being discovered is very high for the attacker, and given that
the typical Windows installation does not use concurrent logins, and
given that traversing HKEY_USERS is uncommon, I think the risk of this
threat is really low.

(*) an administrator user could just as well replace the Python DLL,
causing a threat regardless of the winreg module.