Upgrade Platform Python from 3.6.8 to Python 3.9?

[freephile]

In the current Meza CMTE, Python 3.6.8 is installed. For Rocky Linux 8, the platform version of Python is 3.6.8, and that specific platform version (3.6.x) is supported until May 2029 (10 years from initial release in 2019) which is why we did not propose to change it for the upgrade to MediaWiki 1.39 Milestone.

Meanwhile, the Python project offers a current stable of 3.12.1 (for use in your Python project or user-level account outside the platform version).

Note that Rocky Linux has application streams. See Red Hat Enterprise Linux Application Streams Life Cycle - Red Hat Customer Portal

Although there are other 'Pythons' available for Rocky Linux 8, the only one with a sufficient support lifecycle would be 3.11; but that version is not part of the App Stream for Rocky Linux 9 and support expires in May 2024 (right around the corner). So, we'd only want to upgrade the platform Python to Python 3.9 with two criteria met:

1. Python 3.9 brings improvements or bugfixes we can't live without (today).
2. An upgrade to the Rocky Linux OS from 8 to 9 is planned before May 2024 so we aim to upgrade Python to 3.9 anyway.

App Streams for Rocky Linux 8

Application Stream	Release Date	Retirement Date	Release
Python 3.11	May 2023	May 2026	8.8
Python 3.9	May 2021	May 2024	8.4.0
Python 3.8	May 2020	May 2023	8.2.0
Python 3.6	May 2019	May 2029	8.0.0
Python 2.7	May 2019	Jun 2024	8.0.0

The table above shows that (aside from 3.6) there are currently pythons 2.7, 3.8, 3.9 and 3.11 available. None of these alternatives are supported as long as Python 3.6.

Upgrade USER Python

Strictly, one does not need to install Python 3.6 for user scripts. The platform, e.g. dnf, absolutely requires python 3.6 (and could work with 3.9 as discussed above), but it does not need to be visible to the user. The pip probably resolves via alternatives to some pipX.Y.

With any Python modifications, you will pip install as regular user and/or use a Virtualenv.

Could we and/or should we make Meza use a virtualenv so as to avail ourselves of a modern Python independent of the platform Python? This question arises from the bug witnessed in issue #7

[freephile]

Strictly speaking, when considering what Python you would run now on RL8, anticipating an upgrade to Rocky Linux 9, there is Python 3.11 available as an app stream for RL9.2 supported until May 2026. So, it could be feasible to jump on "the bleeding edge" of 3.11 (but you'd have to anticipate another OS upgrade within 2 years.)

Also note: if someone says "Python 3.6 is flagged as vulnerable" - that is not accurate with respect to Rocky Linux / RHEL because RedHat backports security fixes to the Python that they distribute.

e.g. rpm -q platform-python --changelog | grep -i cve

Details

1. • Security fix for CVE-2023-27043
2. • Security fix for CVE-2022-48564
3. • Security fix for CVE-2022-48560
4. • Security fix for CVE-2023-40217
5. • Fix symlink handling in the fix for CVE-2007-4559
6. • Security fix for CVE-2023-24329
7. • Add filters for tarfile extraction (CVE-2007-4559, PEP-706)
8. • Security fix for CVE-2022-45061
9. • Security fixes for CVE-2020-10735 and CVE-2021-28861
10. • Security fix for CVE-2015-20107
11. • Security fix for CVE-2022-0391: urlparse does not sanitize URLs containing ASCII newline and tabs
12. • Security fix for CVE-2021-4189: ftplib should not use the host from the PASV response
13. • Security fix for CVE-2021-3737
14. • Security fix for CVE-2021-3733: Denial of service when identifying crafted invalid RFCs
15. • Security fix for CVE-2021-3426: information disclosure via pydoc
16. • Fix for CVE-2021-23336
17. • Fix for CVE-2021-3177
18. • Security fix for CVE-2020-27619: eval() call on content received via HTTP in the CJK codec tests
19. • Security fix for CVE-2020-26116: Reject control chars in HTTP method in http.client
20. • Avoid infinite loop when reading specially crafted TAR files (CVE-2019-20907)
21. • Resolve hash collisions for Pv4Interface and IPv6Interface (CVE-2020-14422)
22. • Security fix for CVE-2020-8492
23. • Security fix for CVE-2019-16935
24. • Security fix for CVE-2019-16056
25. • Security fix for CVE-2018-20852
26. • Fix for CVE-2019-10160
27. • Security fix for CVE-2019-9948
28. • Fixes CVE-2019-9740 and CVE-2019-9947
29. • Updated fix for CVE-2019-9636 (rhbz#1689318)
30. • Security fix for CVE-2019-9636 (rhbz#1689318)
31. • Security fix for CVE-2019-5010 (rhbz#1666789)
32. • Security fix for CVE-2018-14647
33. • Fix for CVE-2016-1000110 HTTPoxy attack
34. • Refactor patch for properly fixing CVE-2016-5636
35. • Fix for: CVE-2016-0772 python: smtplib StartTLS stripping attack
36. • Removed: 195 (Werror declaration), 197 (CVE-2014-4650)
37. • Fix CVE-2014-4650 - CGIHTTPServer URL handling
38. • Added fix for CVE-2013-4238 (rhbz#996399)
39. • Add patch for CVE-2013-2099 (rhbz#963261).
40. plus CVE-2010-1634 and CVE-2010-2089), 109 (CVE-2008-5983)
41. • CVE-2010-1634: fix various integer overflow checks in the audioop
42. • CVE-2010-2089: further checks within the audioop module (patch 108)
43. • CVE-2008-5983: the new PySys_SetArgvEx entry point from r81399 (patch 109)

[freephile]

I think this is an excellent topic for planning the forward-looking path of the project. The initial issue that precipitated this discussion (complexities and changes in functionality in string processing across versions of Python) is solved in the immediate case.

While I think that it's a good idea to have a modern stable Python environment, I also think that best practices tell you that you don't need to rely on "platform Python" for your Python tool.

I need to look more into https://www.redhat.com/architect/ansible-execution-environment-tips (I believe Jeff Geerling has done some videos on this.)

[freephile]

The message below is at the top of a deploy log.

We probably need to tell ansible that we're using python 3.6.8 explicitly to stop the deprecation??

ansible --version
ansible 2.9.27
config file = /etc/ansible/ansible.cfg
configured module search path = ['/home/userx/.ansible/plugins/modules', '/usr/share/ansible/plugins/modules']
ansible python module location = /usr/lib/python3.6/site-packages/ansible
executable location = /usr/bin/ansible
python version = 3.6.8 (default, Jan 15 2024, 23:09:02) [GCC 8.5.0 20210514 (Red Hat 8.5.0-20)]

[DEPRECATION WARNING]: Distribution centos 8.9 on host localhost should use /usr/libexec/platform-python, but is using
/usr/bin/python for backward compatibility with prior Ansible releases. A future Ansible release will default to using the
discovered platform python for this host. See
https://docs.ansible.com/ansible/2.9/reference_appendices/interpreter_discovery.html for more information. This feature
will be removed in version 2.12. Deprecation warnings can be disabled by setting deprecation_warnings=False in ansible.cfg.

Or upgrade Ansible

https://docs.ansible.com/ansible/latest/installation_guide/intro_installation.html#selecting-an-ansible-package-and-version-to-install

links to the current Ansible package release table and support matrix

Ansible 2.9 was released 31 Oct 2019 with security updates through 26 Apr 2021

EOL
23 May 2022

[freephile]

With 13820f1 and 1219d72 we are using Python 3.12.5

cd /opt/meza/config
[root@rockylinux-s-4vcpu-8gb-nyc3-01 config]# ansible --version
ansible [core 2.16.3]
  config file = /opt/meza/config/ansible.cfg
  configured module search path = ['/root/.ansible/plugins/modules', '/usr/share/ansible/plugins/modules']
  ansible python module location = /usr/lib/python3.12/site-packages/ansible
  ansible collection location = /opt/meza/collections
  executable location = /usr/bin/ansible
  python version = 3.12.5 (main, Sep 24 2024, 09:41:18) [GCC 8.5.0 20210514 (Red Hat 8.5.0-22)] (/usr/bin/python3.12)
  jinja version = 3.1.2
  libyaml = True