Will sqlite3 be updated in the standard library to address fixed CVSS vulnerabilities?

Python 3.12.2 has SQLite version 3.40.1 in the standard library. sqlite3 3.43.2 fixes CVE-2023-7104 (high) and CVE-2024-0232 (medium). Is there any chance that SQLite version 3.43.2 will be updated in the standard library and made part of an upcoming Python version?

1 Like

Python 3.12.2 used sqlite 3.43.1 on Windows and 3.45.1 on macOS. If you’re on any other platform, sqlite will be provided by your system, not by Python.

Python 3.12.3 will (as of right now) use sqlite 3.45.1 on both Windows and macOS, currently planned for April 9th.

6 Likes

Note that, for macOS, the link above only applies to Python 3.12’s installed from python.org macOS installers. Other distributors of Python for macOS (like Homebrew, MacPorts, Conda, etc) either supply their own version of SQLite or default to using the Apple-supplied version in macOS.

You can check what version is in use with your Python (on any platform) with something like:

python3 -c 'import sqlite3;print(sqlite3.sqlite_version)'

or, more easily, starting with Python 3.12:

python3.12 -m sqlite3 -v

3 Likes

Additional context for my original question is that Python 3.12.2 is running in a Docker container with python:3.12.2-slim-bookworm (Debian) as the base image. Sqlite3 is, apparently, not installed in slim but the command python3.12 -m sqlite3 -v returns ‘SQLite version 3.40.1’. Should I expect sqlite 3.45.1 to be available in python:3.12.3-slim-bookworm when it’s eventually available?

That’s a community maintained docker image: Docker

I don’t think there’s much expertise on this forum about that distribution, you should reach out through their discussion channels.

2 Likes

This says 3.43.1 did.

The sqlite built and shipped with python (on platforms where it is built and bundled) is unaffected by CVE-2023-7104, as it isn’t even built with the affected extension

a way of encountering CVE-2024-0232 exists in theory but requires allowing untrusted user input to be used to craft a query (which is itself problematic without that CVE) or developers having pathological uses of the json extension.

It’s great that both will be fixed, but I wouldn’t worry about using sqlite through python as a result of these.

1 Like

Try explaining that to a security team that’s trying to keep a large collection of deployments of thousands of software products to millions of machines safe. Their attitude is “If the app depends on X and X depends on Y and Y has a CVE against it, delete the app until X and Y have been upgraded to a version of Y that fixes the CVE.”

4 Likes

I guess I can count myself lucky since I was able to do just that with both of these vulnerabilities. One thing that can probably done going forward to make it easier for those with security teams without plans in place for that, now that python intends to have a SBOM is to use VEX to label that python is unaffected by a CVE from a dependency with justification. (VEX are intended to be issuable without new releases, and considered to attach to a SBOM), but that probably needs to go into another thread.

2 Likes