[FR] Support for python 3.8.x

[prrvchr]

What's the problem this feature will solve?

It seems that the latest version of SetupTool has dropped support for Python 3.8.

What a shame, especially since version 75.3.2, which supports 3.8, is vulnerable if you use GitHub Dependabot or FuildAttack.

Describe the solution you'd like

Wouldn't it be possible to keep it working under Python 3.8?

Alternative Solutions

No response

Additional context

No response

Code of Conduct

• I agree to follow the PSF Code of Conduct

[Avasam]

(Please note I am not a maintainer nor do I speak for them)
Python 3.8 codepaths have already been removed from setuptools a while ago (for example: #4718 (comment) )
Python 3.8 is EOL. Meaning it won't receive security fixes either. If you're concerned about vulnerabilities, you should really update to 3.9+

[prrvchr]

Python 3.8 is EOL. Meaning it won't receive security fixes either.

I understand that Python 3.8, which was released at the end of 2019, is at the end of its life.

But it is still present in LibreOffice 25.2 which is not very old and I have to use the python that LibreOffice provides me in my LO extensions.

I don't think that wanting to go so fast brings much except difficulties.

[jaraco]

What a shame, especially since version 75.3.2, which supports 3.8, is vulnerable if you use GitHub Dependabot or FuildAttack.

For security vulnerabilities, we might consider a patch to 75.3.2 to address vulnerabilities. Can you point to where these vulnerabilities were fixed in later versions of Setuptools? Honestly, though, I'm pretty skeptical. If upstream CPython, with dozens of maintainers, can't be bothered to apply security updates for a version of Python, why should a project like Setuptools, with two primary maintainers and a handful of volunteers be expected to invest in those older versions? We'd need a really compelling case (like a known vulnerability with realistic exploits in the wild) to consider retaining support (for Python 3.8 today and 3.9 later in the year, etc).

Edit: I've closed this issue as not planned, but feel free to provide justification to re-open.

[prrvchr]

For security vulnerabilities, we might consider a patch to 75.3.2 to address vulnerabilities. Can you point to where these vulnerabilities were fixed in later versions of Setuptools?

Here is the Dependabot alert I get with Setuptools 75.3.2.
I don't know if there is really a proven risk, but this seems to have been fixed starting with version 78.1.1.

I am willing to submit a PR to backport the code from 78.1.1 to 75.3.2 if necessary?

[abravalheri]

I don't know if there is really a proven risk

How do you use setuptools?

If you are only using the recommended workflow, e.g. by specifying a pyproject.toml and building your package using python -m build, it is unlikely you are affected.

Moreover you can still create pure-python packages with setuptools on Python 3.9 that will work on Python 3.8 (the system that you package your not necessarily have to be the same where it is going to be installed).

[jaraco]

I see that release links back to #4946, where I can see someone else has requested a backport.

I now regret accepting that security vulnerability. I was on the fence as to whether it was a meaningful exploit, and I've already wasted a lot of my life dealing with a code path that's deprecated and unlikely to be reached.

If you want to create the commits backporting the fix to 78.1.1, I'll create a maintenance branch that you can target in a PR. Look for maint/78.1 .

[prrvchr]

How do you use setuptools?

I think that for the use I have of setuptools I have no risk, but it is rather in the aim of providing users of my extensions with a security report without possible flaws...

Look for maint/78.1 .

Thank you, I'll take care of that as soon as possible...

If you want to create the commits backporting the fix to 78.1.1

It seems silly, but I prefer to specify that it is necessary to maintain compatibility with Python 3.8, because for me this support was removed after 75.3.2, but maybe I'm wrong?

[jaraco]

If you want to create the commits backporting the fix to 78.1.1

It seems silly, but I prefer to specify that it is necessary to maintain compatibility with Python 3.8, because for me this support was removed after 75.3.2, but maybe I'm wrong?

Yes, I made a mistake. 75.4.0 was where Python 3.8 support was dropped, so 75.3.x is where the changes need to go. I've created the maint/75.3 branch and removed the maint/78.1 branch.

[prrvchr]

so 75.3.x is where the changes need to go

That's exactly what I wanted to hear... Thanks, I'll be back soon.

[prrvchr]

I just pushed PR#5027.
I've taken the code from 78.1.1 and back ported it to 75.3. However, no tests could be conducted because I don't know where this code is called.