Skip to content

fix(deps): sqlparse >= 0.6.0 — cztery fixable CVE blokują gate pip-audit - #782

Merged
mpasternak merged 1 commit into
devfrom
fix/sqlparse-cve
Aug 19, 2026
Merged

fix(deps): sqlparse >= 0.6.0 — cztery fixable CVE blokują gate pip-audit#782
mpasternak merged 1 commit into
devfrom
fix/sqlparse-cve

Conversation

@mpasternak

Copy link
Copy Markdown
Member

Problem

pip-audit scan (workflow „Dependency vulnerability scan") pada — na tym PR-ze, na #773 i tak samo padnie na dev przy najbliższym uruchomieniu:

Found 4 known vulnerabilities, ignored 2 in 1 package
Name     Version ID             Fix Versions
-------- ------- -------------- ------------
sqlparse 0.5.5   CVE-2026-71491 0.6.0
sqlparse 0.5.5   CVE-2026-59894 0.6.0
sqlparse 0.5.5   CVE-2026-59893 0.6.0
sqlparse 0.5.5   CVE-2026-54284 0.6.0

Wszystkie cztery są fixable, a gate jest ustawiony właśnie „on fixable" — więc blokuje.

To nie jest regresja z żadnego PR-a

Advisories doszły po ostatnim zielonym przebiegu na dev (run z 2026-08-17). Sprawdziłem lock po obu stronach:

$ git show origin/dev:uv.lock | grep -A1 '^name = "sqlparse"'
name = "sqlparse"
version = "0.5.5"

Identycznie na feature-branchu. Czyli dev jest tak samo czerwony — natknąłem się na to przy #773 i wydzielam osobno, zamiast doklejać cudzy problem do feature-brancha, który tylko na niego trafił.

Zmiana

Pin sqlparse>=0.5.4>=0.6.0. sqlparse jest zależnością przechodnią Django (sqlmigrate, formatowanie SQL na stronach debugowych); pin istnieje w pyproject.toml wyłącznie po to, żeby wymusić wersję z fixem — dokładnie tak, jak poprzedni >=0.5.4 wymuszał fix DoS w format_list_of_tuples. Komentarz przy pinie zaktualizowany o numery CVE, żeby następna osoba nie musiała tego odtwarzać z logów CI.

Lock przebudowany uv 0.11.29 (wersja z CI, patrz setup-uv w workflow), a nie moim lokalnym 0.11.14 — inaczej diff miałby 693 linie przepisanych markerów platform_python_implementation, o czym zresztą ostrzega komentarz przy uv-pre-commit w .pre-commit-config.yaml. Tak wychodzi 4 linie:

 pyproject.toml | 6 +++++-
 uv.lock        | 8 ++++----

Weryfikacja

  • manage.py check — „System check identified no issues (4 silenced)"
  • sqlparse 0.6.0 faktycznie zainstalowany po uv sync
  • Pełną suitę zostawiam shardom CI: lokalny przebieg padł na starcie testcontainera przy równoległym obciążeniu Dockera (kontencja, nie kod), a to bump zależności przechodniej — sharded suite jest tu właściwym gejtem. Dopiszę wynik lokalny, jeśli będzie odbiegał.

Bez newsfragmentu — bump zależności przechodniej, zero zmian widocznych dla użytkownika.

Kolejność

Ten PR wchodzi pierwszy; #773 (sortowanie raportów wg nazwisk autorów) przejmie fix po rebase i dopiero wtedy ma szansę być w pełni zielony.

🤖 Generated with Claude Code

https://claude.ai/code/session_01WSUsgzYoDNnXpXGAn5otJg

…udit

`pip-audit scan` (workflow "Dependency vulnerability scan") pada na kazdym
PR-ze i na dev: sqlparse 0.5.5 ma CVE-2026-71491, CVE-2026-59894,
CVE-2026-59893 i CVE-2026-54284. Wszystkie sa fixable (fix: 0.6.0), a gate
jest wlasnie "on fixable", wiec blokuje.

To nie regresja z zadnego PR-a — advisories doszly po ostatnim zielonym
przebiegu na dev (2026-08-17), wiec dev jest tak samo czerwony przy
najblizszym uruchomieniu. Stad osobna zmiana zamiast doklejania jej do
feature-brancha, ktory tylko na nia trafil.

sqlparse jest zalezoscia przechodnia Django (sqlmigrate, formatowanie SQL
w debugu); pin istnieje wylacznie po to, zeby wymusic wersje z fixem —
tak samo jak poprzedni >=0.5.4 wymuszal fix DoS w format_list_of_tuples.
Lock przebudowany uv 0.11.29 (wersja z CI), zeby diff obejmowal sam
sqlparse zamiast przepisywac plik do innego formatu markerow.

Bez newsfragmentu: bump przechodniej zaleznosci, zero zmian widocznych
dla uzytkownika.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01WSUsgzYoDNnXpXGAn5otJg
@mpasternak
mpasternak merged commit 9315a88 into dev Aug 19, 2026
24 checks passed
@mpasternak
mpasternak deleted the fix/sqlparse-cve branch August 19, 2026 12:34
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.

1 participant