CI: installs whichever uv is newest and never audits the locked dependencies, here and in the other five Python plugin repositories #13

New issue

Closed

opened 2026-10-01 10:48:16 +00:00 by tiagoagueda · 0 comments

tiagoagueda commented

2026-10-01 10:48:16 +00:00

Owner

Found on 2026-09-29 in a read-only review of postulo-apprise at 7637d899d, comparing its workflows with the core's (postulo 95348908d) after postulo/postulo#233.

The core pinned uv and audits its lock on every push and weekly. The plugin workflows were not brought along: each installs whatever uv the installer serves that day, and none audits anything. It is filed here because this plugin brings the largest tree of its own into an instance.

Where:
- .forgejo/workflows/ci.yml:45-48 and .forgejo/workflows/release.yml:38-41: curl -LsSf https://astral.sh/uv/install.sh | sh.
- .forgejo/workflows/ci.yml:50-53: uv sync --locked --python 3.14, the only Python tested, against requires-python = ">=3.12" in pyproject.toml:6.
- No pip-audit step and no schedule: trigger in either file.
- The same installer line is in postulo-paperless (.forgejo/workflows/ci.yml:47, release.yml:39), postulo-helloworld (ci.yml:46), postulo-imap (ci.yml:47, release.yml:40), postulo-dav (ci.yml:47, release.yml:39) and postulo-mcp (ci.yml:22); none of them has an audit step either.
- For comparison, the core's .forgejo/workflows/ci.yml:31-36 sets UV_VERSION: "0.12.17" with the reason, "a lock file read by an unpinned tool is pinned only in name (#233)", and its security job (ci.yml:264-299) exports the lock without the project and runs pip-audit==2.10.1 --strict over it, on push and on the weekly cron.
What happens:
1. A uv release that reads or resolves the lock differently turns this CI red, or changes what it installs, on a commit that changed nothing. The core, its pre-commit hook and its Dockerfile move together on one named version; the plugins move with the installer.
2. pyproject.toml:20 declares apprise>=1.9, and uv.lock holds Apprise 1.13.1 with requests, requests-oauthlib, PyYAML, Markdown, certifi and click. When an advisory is published against one of them, the core's audit says nothing, because the core does not depend on Apprise, and no job here looks. The lock is what the tests run against, not what an instance receives (the installer resolves a plugin's requirements from PyPI at install time, plugins/installing.py:26-27), so the audit's use is to tell the maintainer when the floor in dependencies has to rise; today nothing tells them.
3. The suite runs on Python 3.14 only. The core tests 3.12, 3.13 and 3.14, and a plugin is installed into whichever of those the instance runs.
Why it matters: the plugin's destination policy depends on how the locked Apprise behaves, and a vulnerable or changed release of it, or of the tool that reads the lock, reaches a release with nothing having reported it.
Fix: in each workflow, install uv from the versioned installer (https://astral.sh/uv/${UV_VERSION}/install.sh) with the UV_VERSION the core names. Add a job that runs uv export --no-emit-project --all-groups --format requirements-txt --no-hashes and a pinned pip-audit --strict over the result, on push and on a weekly schedule. Either add 3.12 and 3.13 to the test job or raise requires-python to what is tested. The same change applies to the five repositories listed above.

Related to postulo/postulo#233 (closed), which fixed the core only.

Done when

No workflow in this repository contains astral.sh/uv/install.sh without a version, and UV_VERSION equals the core's.
A scheduled job audits the exported lock with a pinned pip-audit, and fails when run against a lock holding a dependency with a known advisory.
A test in tests/ (for example tests/test_workflows.py) reads .forgejo/workflows/*.yml and fails on an unversioned uv installer line; it fails today.

Found on 2026-09-29 in a read-only review of postulo-apprise at 7637d899d, comparing its workflows with the core's (postulo 95348908d) after postulo/postulo#233. The core pinned uv and audits its lock on every push and weekly. The plugin workflows were not brought along: each installs whatever uv the installer serves that day, and none audits anything. It is filed here because this plugin brings the largest tree of its own into an instance. - **Where:** - `.forgejo/workflows/ci.yml:45-48` and `.forgejo/workflows/release.yml:38-41`: `curl -LsSf https://astral.sh/uv/install.sh | sh`. - `.forgejo/workflows/ci.yml:50-53`: `uv sync --locked --python 3.14`, the only Python tested, against `requires-python = ">=3.12"` in `pyproject.toml:6`. - No `pip-audit` step and no `schedule:` trigger in either file. - The same installer line is in postulo-paperless (`.forgejo/workflows/ci.yml:47`, `release.yml:39`), postulo-helloworld (`ci.yml:46`), postulo-imap (`ci.yml:47`, `release.yml:40`), postulo-dav (`ci.yml:47`, `release.yml:39`) and postulo-mcp (`ci.yml:22`); none of them has an audit step either. - For comparison, the core's `.forgejo/workflows/ci.yml:31-36` sets `UV_VERSION: "0.12.17"` with the reason, "a lock file read by an unpinned tool is pinned only in name (#233)", and its `security` job (`ci.yml:264-299`) exports the lock without the project and runs `pip-audit==2.10.1 --strict` over it, on push and on the weekly `cron`. - **What happens:** 1. A uv release that reads or resolves the lock differently turns this CI red, or changes what it installs, on a commit that changed nothing. The core, its pre-commit hook and its Dockerfile move together on one named version; the plugins move with the installer. 2. `pyproject.toml:20` declares `apprise>=1.9`, and `uv.lock` holds Apprise 1.13.1 with `requests`, `requests-oauthlib`, `PyYAML`, `Markdown`, `certifi` and `click`. When an advisory is published against one of them, the core's audit says nothing, because the core does not depend on Apprise, and no job here looks. The lock is what the tests run against, not what an instance receives (the installer resolves a plugin's requirements from PyPI at install time, `plugins/installing.py:26-27`), so the audit's use is to tell the maintainer when the floor in `dependencies` has to rise; today nothing tells them. 3. The suite runs on Python 3.14 only. The core tests 3.12, 3.13 and 3.14, and a plugin is installed into whichever of those the instance runs. - **Why it matters:** the plugin's destination policy depends on how the locked Apprise behaves, and a vulnerable or changed release of it, or of the tool that reads the lock, reaches a release with nothing having reported it. - **Fix:** in each workflow, install uv from the versioned installer (`https://astral.sh/uv/${UV_VERSION}/install.sh`) with the `UV_VERSION` the core names. Add a job that runs `uv export --no-emit-project --all-groups --format requirements-txt --no-hashes` and a pinned `pip-audit --strict` over the result, on push and on a weekly schedule. Either add 3.12 and 3.13 to the test job or raise `requires-python` to what is tested. The same change applies to the five repositories listed above. Related to postulo/postulo#233 (closed), which fixed the core only. ## Done when - No workflow in this repository contains `astral.sh/uv/install.sh` without a version, and `UV_VERSION` equals the core's. - A scheduled job audits the exported lock with a pinned `pip-audit`, and fails when run against a lock holding a dependency with a known advisory. - A test in `tests/` (for example `tests/test_workflows.py`) reads `.forgejo/workflows/*.yml` and fails on an unversioned uv installer line; it fails today.

tiagoagueda added this to the 0.6.0 milestone

2026-10-01 10:48:16 +00:00

tiagoagueda added the

enhancement

label

2026-10-01 10:48:16 +00:00

tiagoagueda referenced this issue from Postulo/postulo-dav

2026-10-17 10:39:29 +00:00

SEC2-048: postulo-dav locks pyjwt 2.13.0, urllib3 2.7.0 and django 6.1.1, carrying 22 published advisories, and CI never audits the lock #31

tiagoagueda referenced this issue from Postulo/postulo-imap

2026-10-17 10:39:30 +00:00

SEC2-049: postulo-imap locks pyjwt 2.13.0, urllib3 2.7.0 and django 6.1.1, carrying 22 published advisories, and CI never audits the lock #24