** Description changed: [ Impact ] This bug was found when trying to use Trac 1.6. The trac.web.modpython_frontend handler supplied by Trac indirectly ends up in platform._sys_version which requires sys.version to be of a specific format: "X.Y.Z (buildno, builddate, buildtime) [compiler]", and raises ValueError if it cannot be parsed. The error that appears in the Apache log is: ... File "/usr/lib/python3.12/platform.py", line 1108, in _sys_version ... ValueError: failed to parse CPython sys.version: '3.12.3' Troubleshooting indicated that this is a problem with mod_python. An upstream issue was filed[1], and quickly fixed[2]. A reproducer for this bug that does not involve trac was kindly provided by @mdsquire and is being used in the test plan, instead of installing and configuring trac. - 1. https://github.com/grisha/mod_python/issues/138 2. https://github.com/grisha/mod_python/commit/51f359d1252865181247e5182294ae5a28e3116d - [ Test Plan ] # Create an ubuntu noble container or VM, and perform these steps in it: sudo apt install apache2 libapache2-mod-python lynx -y wget https://bugs.launchpad.net/ubuntu/+source/libapache2-mod- python/+bug/2078527/+attachment/5813129/+files/python_bug_2078527.tar.gz sudo mkdir -p /opt/local/tmp sudo tar -C /opt/local/tmp/ -xf python_bug_2078527.tar.gz echo "Include /opt/local/tmp/python_bug_2078527/apache2.conf" | sudo tee -a /etc/apache2/apache2.conf sudo a2enmod python sudo systemctl restart apache2 lynx -dump http://127.0.0.1/mod-python-bug-2078527 # When reproducing the error, the output will contain a ValueError: Python sys.version 3.12.3 platform.python_version() ValueError: failed to parse CPython sys.version: '3.12.3' # With the fix, the output is: Python sys.version 3.12.3 (main, Jun 18 2025, 17:59:45) [GCC 13.3.0] platform.python_version() 3.12.3 [ Where problems could occur ] + strtok() modifies the first argument, and that is explicitly forbidden in the Py_GetVersion() documentation[3] - * Think about what the upload changes in the software. Imagine the - change is wrong or breaks something else: how would this show up? + The returned string points into static storage; the caller should not modify + its value. - * It is assumed that any SRU candidate patch is well-tested before - upload and has a low overall risk of regression, but it's important - to make the effort to think about what ''could'' happen in the event - of a regression. + The fix acts on a copy of the string now, allocated in the apr pool. + This is not a normal malloc like strdup, as it's using this apr pool + mechanism. I presume this new string allocation doesn't have to be freed + specifically, and is being handled by the pool mechanism. The + documentation[4] doesn't mention such freeing requirements. I'm afraid + I'm not familiar with apr pools. - * This must never be "None" or "Low", or entirely an argument as to why - your upload is low risk. + I also checked the upstream git repository for follow-up fixes after + this change, and there are none. - * This both shows the SRU team that the risks have been considered, - and provides guidance to testers in regression-testing the SRU. + If something bad were to happen, it could be a memory leak, or further + crashes inside this function, or in the worst case, elsewhere in + mod_python. - [ Other Info ] - * Anything else you think is useful to include + 3. https://docs.python.org/3/c-api/init.html#c.Py_GetVersion + 4. https://apr.apache.org/docs/apr/trunk/group__apr__strings.html#gabc79e99ff19abbd7cfd18308c5f85d47 - * Make sure to explain any deviation from the norm, to save the SRU - reviewer from having to infer your reasoning, possibly incorrectly. - This should also help reduce review iterations, particularly when the - reason for the deviation is not obvious. - - * Anticipate questions from users, SRU, +1 maintenance, security teams - and the Technical Board and address these questions in advance [ Original Description ] Ubuntu version: 24.04.1 Package version: 3.5.0.1-3build1 Python version: 3.12.3 I encountered this problem after upgrading from jammy -> nobel and installing Trac 1.6. I do not believe this is a problem with Trac however. The trac.web.modpython_frontend handler supplied by Trac indirectly ends up in platform._sys_version which requires sys.version to be of a specific format: "X.Y.Z (buildno, builddate, buildtime) [compiler]", and raises ValueError if it cannot be parsed. However, setting the handler to mod_python.testhandler reveals that sys.version is just "X.Y.X". So the sys.version that is being set by mod_python is not compatible with the standard python platform module. The error that appears in the Apache log is: ... File "/usr/lib/python3.12/platform.py", line 1108, in _sys_version ... ValueError: failed to parse CPython sys.version: '3.12.3' Adding this hack to the trac.web.modpython_frontend module resolves the problem: try: sys.version.index(" ") except ValueError: sys.version += ' (dummy, dummy, dummy) [dummy]'
-- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2078527 Title: sys.version from mod_python cannot be parsed by the python platform module To manage notifications about this bug go to: https://bugs.launchpad.net/mod-python/+bug/2078527/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
