Skip to content

build(deps): fix Dependabot alerts in uv.lock - #512

Merged
james-d-mitchell merged 2 commits into
mainfrom
codex/fix-dependabot-alerts
Oct 27, 2026
Merged

james-d-mitchell merged 2 commits into
mainfrom
codex/fix-dependabot-alerts

Conversation

@james-d-mitchell

@james-d-mitchell james-d-mitchell commented Oct 26, 2026 •

Copy link
Copy Markdown
Member

The documentation and development dependencies in uv.lock still used vulnerable versions, despite the corresponding fixes already present in requirements.txt. Update the lockfile to patched releases covering all 28 open Dependabot alerts.

Package Previous Updated Alerts
certifi 2025.10.5 2026.10.23 1
filelock 3.32.4 4.2.4 3
soupsieve 2.8.4 2.9 2
urllib3 2.7.0 2.8.0 3
virtualenv 21.7.5 21.14.13 19

Also update python-discovery to 1.6.4 and resolve packaging 26.3 for the development group, as required by the newer virtualenv. Keep Soup Sieve at the patched version already used in requirements.txt.

The lockfile was generated by uv 0.12.10 on macOS arm64, starting from this PR's base commit ac998d3758f9d614b1c9affa6144041714f35e23, using:

uv lock \
  --upgrade-package "certifi==2026.10.23" \
  --upgrade-package "urllib3==2.8.0" \
  --upgrade-package "soupsieve==2.9" \
  --upgrade-package "filelock==4.2.4" \
  --upgrade-package "virtualenv==21.14.13"

The target versions were selected after reviewing the security alerts. uv resolved the dependencies and wrote the complete lockfile, including dependency markers, download URLs, and hashes. pyproject.toml was unchanged; the exact version selections above were command-line inputs to uv.

Reproduction was checked in a clean temporary checkout of the base commit. The reproduction check on 27 October 2026 additionally used --upgrade-package "python-discovery==1.6.4": version 1.6.5 was published that morning, so the original command selected that newer transitive release when rerun. With the extra selection, the regenerated file matches the committed SHA-256 09350056cffd42042169709c6b4e5dee84b3757c16491df3ded177f9353a11f0.

Also configure weekly Dependabot updates for the root uv project, using the documented uv ecosystem, so Dependabot can update uv.lock directly.

Validation on macOS with Python 3.14 and the existing compiled extension:

  • Compared every affected lockfile version against all 28 alerts' vulnerable ranges and patched versions; all passed.
  • uv lock --check and the locked environment synchronization check passed.
  • python -m pytest -m quick: 867 passed, 679 deselected.
  • make doc SPHINXOPTS="-W": passed after retrying a local Inkscape converter crash.
  • make doctest: 1,535 passed.
  • Both pre-commit hook stages for uv.lock passed; source-code hooks had no applicable files.
  • The Dependabot configuration parses as YAML, preserves the existing GitHub Actions entry, and adds the documented root uv entry; both hook stages for .github/dependabot.yml passed.
  • All CI checks passed for the original lockfile commit 0921038a; the configuration follow-up is in 297cf90d.
  • Smoke checks for virtualenv creation and pip seeding, file locking, BeautifulSoup/Soup Sieve parsing, and CA bundle availability passed.

AI assistance: OpenAI Codex investigated the Dependabot alerts, updated dependencies, configured weekly uv updates, ran validation, and prepared the commits, pull request, and review response.

Update certifi, filelock, soupsieve, urllib3, and virtualenv to patched
versions covering all 28 open Dependabot alerts. Include the packaging
and python-discovery updates required by virtualenv.

AI assistance: OpenAI Codex investigated the alerts, updated the lockfile,
ran validation, and prepared this commit.

Co-authored-by: OpenAI Codex <codex@openai.com>
@Joseph-Edwards

Copy link
Copy Markdown
Collaborator

I'm reluctant to merge this without knowing what generated the changes in the uv.lock file. I assume that was something like uv lock --upgrade, and if that's the case then all is good. I suppose the tests have passed, which would suggest that the changes are somewhat reasonable. In any case, I think we can enable dependabot to directly update the uv files, so perhaps we should try and do that.

I would prefer to discuss this further before we merge.

Configure Dependabot to update the root uv project each week, following
review feedback on the dependency security fixes.

AI assistance: OpenAI Codex checked the supported ecosystem, updated the
configuration, verified lockfile reproduction, and ran validation.

Co-authored-by: OpenAI Codex <codex@openai.com>

Copy link
Copy Markdown
Member Author

@Joseph-Edwards The lockfile was generated by uv 0.12.10, using targeted --upgrade-package options. The target versions were selected after reviewing the alerts; uv resolved the dependencies and wrote the lockfile, including the markers, download URLs, and hashes. There were no hand-written lockfile entries, and pyproject.toml was unchanged.

The final generation command, starting from the PR base ac998d37, was:

uv lock \
  --upgrade-package "certifi==2026.10.23" \
  --upgrade-package "urllib3==2.8.0" \
  --upgrade-package "soupsieve==2.9" \
  --upgrade-package "filelock==4.2.4" \
  --upgrade-package "virtualenv==21.14.13"

Soup Sieve was kept at 2.9 to match the patched version already in requirements.txt. The packaging and python-discovery updates were required by the newer virtualenv.

The generation was verified again today in a clean temporary checkout. python-discovery 1.6.5 was released this morning, so the replay additionally specified --upgrade-package "python-discovery==1.6.4" to reproduce yesterday's selected version. That produced a byte-for-byte match of the committed uv.lock. The command and reproduction details are now in the PR description.

Following your suggestion, commit 297cf90d also adds weekly Dependabot updates for package-ecosystem: "uv" at the repository root, using the documented configuration. The YAML validation and both hook stages passed; all CI checks passed on the original lockfile commit 0921038a. The PR remains open for discussion.

AI assistance: OpenAI Codex verified the generation process, added the Dependabot configuration, and prepared this response.

@Joseph-Edwards

Copy link
Copy Markdown
Collaborator

Thank you for the extra information. I think the dependabot related things will fail for the dynamic version related reasons we discussed earlier, but otherwise I am happy with these changes.

@james-d-mitchell
james-d-mitchell merged commit 898beda into main Oct 27, 2026
29 checks passed
@james-d-mitchell
james-d-mitchell deleted the codex/fix-dependabot-alerts branch October 27, 2026 17:02
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants