Re: Python Tooling

On Mon Aug 31, 2026 at 8:38 PM UTC, Magnus Hagander wrote:
> On Mon, 31 Aug 2026 at 22:32, Tristan Partin <tristan(at)partin(dot)io> wrote:
>
>> On Mon Aug 31, 2026 at 8:26 PM UTC, Jonathan S. Katz wrote:
>> > On 8/31/26 4:23 PM, Tristan Partin wrote:
>> >
>> >>> The basic answer is, "use whatever is in debian" because that's what
>> it's
>> >>> deployed on, and at this point that's trixie.
>> >>>
>> >>> That also means we do *not* want to change the dependencies to anything
>> >>> other than whatr's there.
>> >>
>> >> Does this mean that we rely on the versions of Python packages within
>> >> Trixie and the requirements.txt is basically ignored?
>> >
>> > FWIW I will use requirements.txt in my local environment, but that only
>> > happens when it gets nuked, so it's a once-every-few-years ordeal.
>> >
>> > (I could probably get the pgweb env to load from a container; perhaps
>> > this is a suggestion towards a Dockerfile?)
>>
>> Are you referring to deploying as a container or a devcontainer? To
>> expand on what I am thinking that we should use native Python tooling to
>> manage dependencies. For instance, we would encode all our dependencies
>> in the pyproject.toml, and then actually run the server with `uv run
>> ...`.
>>
>> Python tooling moves so much faster than Debian that I don't think it
>> makes sense to depend on Debian for anything other than the base OS and
>> maybe the Python interpreter.
>>
>
> I think you're going to have a very steep uphill battle to fight to get
> that done. Mainly because the vast majority of dependencies we have lack
> the basic idea of a stable release/branch, LTS or whatever you want to call
> it. Django itself does, which makes it work. But we don't have the
> resources to go around and manually figure out which changes are needed to
> which of our many apps whenever we're forced to upgrade something because
> of a security update. For very little actual gain, since just sticking to
> the supported versions has served us very well for many years.

I hear your concerns. Two thoughts:

1) The fact that Debian is an LTS distro does not necessarily mean that
security updates will get backported. For instance, if software xyz has
a vulnerability in version 1.X that isn't fixed until version 2.3, it is
seriously unlikely that Debian has the resources to maintain a forked
version of 1.X with the security fix. As you said, most software doesn't
maintain an LTS branch. Debian tracks CVEs affecting its current package
set[0]. I counted 48 CVEs affecting Python and other Python packages.
I decided to look at one of these for an example: CVE-2026-47180[1]. It
affects the python3-zeroconf package[2]. Trixie has version 0.147.0
packaged, which was released just about a year ago. GitHub reports[3]
that the CVE was fixed in 0.149.5, and affected versions are everything
less than that. This CVE was published on 2026-05-21, so Debian has been
knowingly vulnerable for over 3 months. If we managed our own
dependencies, we could have updated the day of the disclosure to 0.149.5
which was released 4 days before the CVE was published. I understand
being able to do this requires resources and time...

2. But I think that this problem can largely be automated away. On other
software forges (GitHub, etc.), you can have automations for bumping
dependencies upon new releases, and the forges can notify you of
security vulnerabilities in your dependencies. If we didn't want to move
Git hosting to other forges, we could also do our own automations using
systemd timers that automagically sends patches to the list when a new
release of one of our dependencies is published.

Out of curiosity, how often is the Debian server restarted to pull in
new updates?

[0]: https://security-tracker.debian.org/tracker/status/release/stable
[1]: https://security-tracker.debian.org/tracker/CVE-2026-47180
[2]: https://packages.debian.org/trixie/python3-zeroconf
[3]: https://github.com/python-zeroconf/python-zeroconf/security/advisories/GHSA-9pgc-3ccv-5297

--
Tristan Partin
PostgreSQL Contributors Team
AWS (https://aws.amazon.com)