Skip to content

Bump certifi to 2026.10.23 for emSign CA compromise - #213

Open
gilesknap wants to merge 1 commit into
masterfrom
fix/emsign-ca
Open

gilesknap wants to merge 1 commit into
masterfrom
fix/emsign-ca

Conversation

@gilesknap

Copy link
Copy Markdown

What and why

certifi before 2026.10.18 still trusts the eMudhra emSign ECC Root CA - G3, whose intermediate keys were compromised (GHSA-6q48-6c7w-9gw2). 2026.10.18 also dropped some unaffected roots, so this goes to the latest release. It bumps the dev certifi entry in Pipfile.lock from 2026.1.4 to 2026.10.23. Only that entry changes. The Pipfile does not pin certifi, so _meta.hash stays the same. The related uv advisory (GHSA-hq85-5cpj-mr62) does not apply because this repo does not use uv.

Closes Dependabot alert 45.

How it was tested

pipenv is not available in the sandbox, so the lock entry was edited by hand. The version and both sha256 hashes (sdist and wheel) were checked against https://pypi.org/pypi/certifi/2026.10.23/json. CI on this PR runs the full build and tests.

Found in local review

Nothing. The reviewer confirmed that the diff touches only the certifi entry and that the hashes match PyPI.

Not in this PR

The other open Dependabot alerts in this repo (urllib3, requests, idna, pytest, Pygments, zipp in Pipfile.lock). A separate sweep will follow.

Merge

Merge commit, after CI is green.

🤖 Generated with Claude Code

https://claude.ai/code/session_01Uybqz7SRaVuiGbQ8Kv6ZHL

Fixes GHSA-6q48-6c7w-9gw2 (eMudhra emSign ECC Root CA - G3 compromised
intermediate keys). Only the certifi entry in Pipfile.lock is changed;
version and sha256 hashes taken from PyPI. GHSA-hq85-5cpj-mr62 (uv) does
not apply: this repo does not use uv.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Uybqz86W312JcHngTnM126
@gilesknap

Copy link
Copy Markdown
Author

Worth knowing: the tests install with pip install -e .[dev], and only the docs job uses Pipfile.lock, so this fix reaches docs CI only. Picking one route (testing from the lock, or dropping Pipfile.lock) would make lock updates meaningful.

This branch has not been deployed

No deployments
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