>> it prevents using 3.8 because of this open vulnerability

>What do you mean by this?

>Our understanding is that this is a low-severity CVE because in order for this to be a vulnerability, you'd have to have both:

>1. user access to IP address input; and
>2. control over two addresses sharing numerical representation with leading zeroes: the first resolving when leading zeroes are treated as octal numbers; the second resolving when leading zeroes are treated as decimal numbers.

>Access to both then allows you at best to circumvent IP address-based access control or denial of service. However, access to just 1. allows you to input any IP address to achieve the same goals.

>Hence low-severity.

Even though I agree with you assessment on the root cause of the issue itself, it is listed as critical in https://nvd.nist.gov/vuln/detail/CVE-2021-29921, which means most commercial scan tools will also flag python 3.8 as critical, and this could prevent users from going with python 3.8 on production. (our case too)

>> it does not seem to be a breaking change

>It is a bona fide breaking change. Any IP address configuration saved in files or databases which might have used leading zeroes would be rejected by 3.8.12. The same was true for 3.9.5 but since this release series has much higher exposure (still receiving binary installers and regular-cadence bugfixes), it was less controversial to include it.


>If you still feel this ought to be fixed in 3.8, please elaborate.

IMHO I still think this should be solved in 3.8, otherwise there is really no other alternative but to upgrade to python 3.9 which is a hassle, since all 3.8.x are "critically vulnerable", had the CVE in https://nvd.nist.gov/vuln/detail/CVE-2021-29921 not been marked as critical, then we could have used python 3.8 knowing the two conditions you mentioned earlier.