[Feature Request] - Python 3.9.17

[c200chromebook]

Is your feature request related to a problem? Please describe. Right now, ALinux is on Python 3.9.16, but 3.9.17 is out. We are seeing a twistlock for 3.9.16, which our security guys argue could be fixed by upgrading.

Describe the solution you'd like Is there an easy way to upgrade Python when a new version is released, but before it's deployed?

Describe alternatives you've considered Tried building it from source with RUN curl -O https://www.python.org/ftp/python/3.9.17/Python-3.9.17.tgz && tar -xvzf Python-3.9.17.tgz && cd Python-3.9.17 && ./configure --enable-optimizations && make install && cd .. && rm -rf Python-3.9.17 && rm -rf Python-3.9.17.tgz

[c200chromebook]

Think I'm overwriting the existing python install and the twistlock is spurious.

[stewartsmith]

You likely would be, and thus would be having a likely "interesting" time with having a bunch of OS functionality continuing to work.

Amazon Linux does address security issues in packages we ship, I'll ensure that we're on top of what's in Python 3.9.17.

What is the bug you see with 3.9.16? What is this "twistlock" you speak of, I'm not familiar with any core python functionality that would be called this, so I do want to ensure we're looking at the right thing. What issue are you seeing?

[c200chromebook]

We're seeing CVE-2023-24329 (https://nvd.nist.gov/vuln/detail/CVE-2023-24329) showing up due to 3.9.16. Believe it or not, overwriting the system installed python doesn't seem to break anything (but is probably a bad idea). Talking a bit to the information security guys, the detection of .16 is likely due to the base layer of the docker image.

[stewartsmith]

https://alas.aws.amazon.com/AL2023/ALAS-2023-116.html patched CVE-2023-24329 back prior to AL2023 GA.

So for that CVE, unless you're running a pre-GA container image, you have our update.

There's other reasons to look at the 3.9.17 update of course, but that specific CVE isn't one of them.

It's possible the security scanning tool isn't taking into account our metadata on backported CVE fixes. It will need to be fixed or a lot of false positives will follow.

[c200chromebook]

Yes, we see a lot of false positives, and it's very annoying! I'll talk to our scanning guys.

[stewartsmith]

Yes, we see a lot of false positives, and it's very annoying! I'll talk to our scanning guys.

You're not alone, a lot of scanners have gotten these kinds of things wrong in various ways.

I've been starting to sketch out some documentation for security scanner authors that may help the situation, but it's at the "not yet quite a draft to share with anyone" phase, let alone checked for embarrassing spelling mystakes and tpyos. When I have something to show, I'll try and remember to post a link here.

[daniejstriata]

@stewartsmith Do your team explicitly add the CVEs being fixed in the RPM's SPEC? I find that it makes my task much easier if I can look at the package history and see all the CVEs that was fixed in it.

[stewartsmith]

We ensure that updateinfo.xml (i.e. the repository metadata) is accurate in what CVEs are fixed.

While we would like to be able to say that the RPM SPEC file (and thus RPM changelog) could contain this, various reasons means this is not always the case. For example, sometimes the issue we're working on fixing doesn't have a CVE yet when we're working on the fix.

The best way is to parse the updateinfo metadata for the latest AL2023 release, that will give the best picture of a easily machine readable format with the data needed.

[c200chromebook]

Dumb question - if I do yum updateinfo list installed cves, I don't see CVE-2023-27043, which should be present for Python 3.9.16, showing only as patched for Python 3.11 here: https://alas.aws.amazon.com/cve/html/CVE-2023-27043.html

Has this been patched for 3.9 too?

[c200chromebook]

cc @stewartsmith - anyone I might bug about this one?