Security: Update dependencies to fix CVE vulnerabilities#554
Conversation
- Update fastapi[standard] to >=0.116.0 - Update sentry-sdk[fastapi] to >=2.20.0 (major version upgrade) - Migrate dev-dependencies from deprecated [tool.uv] to [dependency-groups] CVEs addressed: - CVE-2025-66418, CVE-2025-66471, CVE-2026-21441 (urllib3) - CVE-2025-69223 to CVE-2025-69230 (aiohttp) - CVE-2025-54121, CVE-2025-62727 (starlette) - CVE-2025-66221, CVE-2026-21860 (werkzeug) - CVE-2025-68146, CVE-2026-22701 (filelock) Verified with pip-audit: 0 vulnerabilities found.
📝 WalkthroughWalkthroughThe PR updates Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes Poem
🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Fix all issues with AI agents
In `@backend/pyproject.toml`:
- Line 22: The dependency bump to "sentry-sdk[fastapi]>=2.20.0" introduces
breaking changes — search for usages of the removed config keys and deprecated
Hub/scope APIs and update them: replace any client init options using
with_locals with include_local_variables and request_bodies with
max_request_body_size; replace calls to configure_scope() / push_scope() with
the new get_isolation_scope(), get_current_scope(), or new_scope() helpers where
appropriate; if FastAPI middleware spans are required, instantiate
FastApiIntegration(middleware_spans=True) when creating the Sentry integration;
and verify any self-hosted Sentry endpoint expectations (envelope endpoint
/envelope) and minimum server version. After making these changes (look for
symbols like Sentry.init, configure_scope, push_scope, FastApiIntegration), run
a FastAPI startup smoke test to confirm request/error reporting works.
- Around line 41-42: CI is pinning the 'uv' tool to 0.4.15 while the project now
uses [dependency-groups] in pyproject.toml, which requires uv >= 0.4.27 for PEP
735 support; update the uv version constraint in the CI workflow
(continuous_integration.yml) to at least 0.4.27 (preferably a newer stable
release) so dev dependencies (pytest, mypy, ruff, coverage) are installed
correctly when the [dependency-groups] section is used.
| "bcrypt==4.0.1", | ||
| "pydantic-settings<3.0.0,>=2.2.1", | ||
| "sentry-sdk[fastapi]<2.0.0,>=1.40.6", | ||
| "sentry-sdk[fastapi]>=2.20.0", |
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
Sentry SDK Python 2.x migration guide breaking changes
💡 Result:
Key breaking changes when migrating Sentry’s Python SDK from 1.x → 2.x (the official migration guide is here) [1]:
- Python 2 is not supported anymore:
sentry-sdk2.x requires Python ≥ 3.6 (so Python 2.7 must stay onsentry-sdk1.x). [1], [2] - Config option removals/renames:
with_localsremoved → useinclude_local_variablesrequest_bodiesremoved → usemax_request_body_size[1], [2]
- Profiling options are no longer “experimental”:
- Stop setting
profiles_sample_rate/profiler_modevia_experiments; set them as top-level init options. [1]
- Stop setting
- Scopes/Hub API direction changed:
- Hub-based APIs and some scope-manager patterns (e.g.,
configure_scope(),push_scope()) are deprecated in favor of global / isolation / current scopes and helpers likenew_scope()/isolation_scope()/get_current_scope()/get_isolation_scope(). [1], [2]
- Hub-based APIs and some scope-manager patterns (e.g.,
- Transport / ingestion changes:
- Events are sent via the
/envelopeendpoint; self-hosted Sentry must be ≥ 20.6.0. [1], [2] - Custom transports:
Transport.capture_eventis deprecated → useTransport.capture_envelope(and transports should beTransportsubclasses). [1]
- Events are sent via the
- API changes:
before_emit_metriccallback signature changed to include(key, value, unit, tags). [1]last_event_id()was removed in 2.0.0 (and later brought back in 2.2.0). [1], [2]
Sources: official Sentry docs migration guide [1] and the 2.0.0 release notes summary [2].
🌐 Web query:
Sentry SDK FastAPI integration 2.x compatibility changes
💡 Result:
Key 2.x changes that can affect FastAPI / Starlette users of sentry-sdk:
-
Runtime / backend compatibility
- Python support:
sentry-sdk2.0 requires Python ≥ 3.6 (older Python must stay on 1.x). [1] - Self-hosted Sentry:
sentry-sdk2.0 requires Sentry ≥ v20.6.0 (SDK switched to sending via the/envelopeendpoint). [1]
- Python support:
-
Scope / context propagation changes (important for request-scoped data)
- Hub-based APIs and some scope helpers (e.g.,
configure_scope(),push_scope()) are deprecated in 2.x in favor of global / isolation / current scopes (useget_isolation_scope(),get_current_scope(),new_scope(),isolation_scope(), etc.). This can matter if you were manually managing per-request tags/user/context in FastAPI middleware or dependencies. [1]
- Hub-based APIs and some scope helpers (e.g.,
-
FastAPI/Starlette integration behavior changes
- (2.48.0) Middleware spans disabled by default for Django, Starlette, and FastAPI integrations. If you relied on per-middleware spans for performance analysis, you must re-enable them:
FastApiIntegration(middleware_spans=True)/StarletteIntegration(middleware_spans=True). [2] - (2.5.0) New integration option
failed_request_status_codeslets you control which HTTP response codes generate Sentry events (default is 5xx). Example:from sentry_sdk.integrations.starlette import StarletteIntegration from sentry_sdk.integrations.fastapi import FastApiIntegration sentry_sdk.init( integrations=[ StarletteIntegration(failed_request_status_codes=[403, range(500, 599)]), FastApiIntegration(failed_request_status_codes=[403, range(500, 599)]), ] ) ``` [3]
- (2.48.0) Middleware spans disabled by default for Django, Starlette, and FastAPI integrations. If you relied on per-middleware spans for performance analysis, you must re-enable them:
Address Sentry SDK 2.x breaking changes before merging.
This major version bump introduces several breaking changes confirmed by the official migration guide:
- Config options removed:
with_locals→include_local_variables,request_bodies→max_request_body_size - Deprecated APIs: Hub-based patterns (
configure_scope(),push_scope()) replaced withget_isolation_scope(),get_current_scope(),new_scope() - FastAPI-specific: Middleware spans disabled by default in 2.48.0+; re-enable with
FastApiIntegration(middleware_spans=True)if needed - Infrastructure requirement: Self-hosted Sentry must be ≥ v20.6.0 (SDK now sends via
/envelopeendpoint)
Audit the codebase for removed config options and deprecated scope/Hub APIs, then run a startup smoke test with FastAPI to confirm request handling and error reporting work as expected.
🤖 Prompt for AI Agents
In `@backend/pyproject.toml` at line 22, The dependency bump to
"sentry-sdk[fastapi]>=2.20.0" introduces breaking changes — search for usages of
the removed config keys and deprecated Hub/scope APIs and update them: replace
any client init options using with_locals with include_local_variables and
request_bodies with max_request_body_size; replace calls to configure_scope() /
push_scope() with the new get_isolation_scope(), get_current_scope(), or
new_scope() helpers where appropriate; if FastAPI middleware spans are required,
instantiate FastApiIntegration(middleware_spans=True) when creating the Sentry
integration; and verify any self-hosted Sentry endpoint expectations (envelope
endpoint /envelope) and minimum server version. After making these changes (look
for symbols like Sentry.init, configure_scope, push_scope, FastApiIntegration),
run a FastAPI startup smoke test to confirm request/error reporting works.
backend/pyproject.toml
Outdated
| [dependency-groups] | ||
| dev = [ |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
cat backend/pyproject.tomlRepository: ProjectTech4DevAI/kaapi-backend
Length of output: 2270
🏁 Script executed:
# Search for CI and build configuration files
find . -type f \( -name ".github" -o -name ".gitlab-ci.yml" -o -name "*.yml" -o -name "*.yaml" \) | head -20
git ls-files | grep -E "(\.github|\.gitlab-ci|\.circleci|tox\.ini|Makefile|scripts)" | head -20Repository: ProjectTech4DevAI/kaapi-backend
Length of output: 993
🏁 Script executed:
# Search for dependency installation commands
rg -i "pip\s+install|uv\s+(?:pip|sync|install)|hatch|dependency-groups" --type-list | head -5
rg -i "pip\s+install|uv\s+(?:pip|sync|install)" -A 2 -B 2Repository: ProjectTech4DevAI/kaapi-backend
Length of output: 830
🏁 Script executed:
# Check for uv.lock and tool configuration
fd -e "uv.lock" -o -e "pyproject.toml" -o -e "requirements*.txt" | head -20
rg -n "tool\.uv|tool\.hatch|tool\.pip" backend/pyproject.toml -A 5Repository: ProjectTech4DevAI/kaapi-backend
Length of output: 191
🌐 Web query:
PEP 735 dependency groups support: which versions of pip, uv, hatch, poetry support [dependency-groups]?
💡 Result:
PEP 735 ([dependency-groups]) support by tool/version:
- pip: pip 25.1+ (released 2025-04-26) adds
pip install --group …support for PEP 735 dependency groups. [1][2] - uv: uv supports PEP 735
[dependency-groups]for development dependencies / groups; this support exists at least as far back as uv 0.4.27. [3][4] - Hatch: Hatch 1.16+ supports consuming
[dependency-groups]via environmentdependency-groups = [...]. [5] - Poetry: Poetry 2.2.0+ supports defining dependency groups using PEP 735
[dependency-groups]. [6]
Sources:
[1] https://discuss.python.org/t/announcement-pip-25-1-release/89702
[2] https://ichard26.github.io/blog/2025/04/whats-new-in-pip-25.1/
[3] https://docs.astral.sh/uv/concepts/projects/dependencies/
[4] dependabot/dependabot-core#10847
[5] https://hatch.pypa.io/1.16/config/environment/advanced/
[6] https://python-poetry.org/blog/announcing-poetry-2.2.0/
🏁 Script executed:
# Check for uv version constraints
fd -e "uv.lock" -o -e ".python-version" | xargs cat 2>/dev/null || echo "Files not found"
rg "uv" backend/pyproject.toml -iRepository: ProjectTech4DevAI/kaapi-backend
Length of output: 191
🏁 Script executed:
# Check CI workflows for dev dependency handling
cat .github/workflows/continuous_integration.ymlRepository: ProjectTech4DevAI/kaapi-backend
Length of output: 2032
🏁 Script executed:
# Check the other CD workflows
cat .github/workflows/cd-staging.yml | head -50Repository: ProjectTech4DevAI/kaapi-backend
Length of output: 1354
🌐 Web query:
Does uv sync automatically include [dependency-groups] dev dependencies or does it require --group flag?
💡 Result:
uv sync includes the [dependency-groups].dev group automatically by default—you do not need --group dev. (docs.astral.sh)
If you want other dependency groups (e.g. lint, docs, typing), you must either:
- add them explicitly:
uv sync --group lint(repeatable), or - install all groups:
uv sync --all-groups, or - configure defaults in
pyproject.tomlviatool.uv.default-groups(default is["dev"]). (docs.astral.sh)
Citations:
- 1: https://docs.astral.sh/uv/concepts/projects/sync/?utm_source=openai
- 2: https://docs.astral.sh/uv/concepts/projects/sync/?utm_source=openai
Upgrade uv to 0.4.27+ in CI to ensure [dependency-groups] support.
Line 41–42 switches dev deps to [dependency-groups], but CI pins uv 0.4.15 (continuous_integration.yml). PEP 735 dependency-groups support in uv is confirmed from 0.4.27 onwards, so your current version may not properly install dev dependencies like pytest, mypy, ruff, and coverage. Update the uv version constraint in CI workflows to at least 0.4.27 (or a newer stable release).
🤖 Prompt for AI Agents
In `@backend/pyproject.toml` around lines 41 - 42, CI is pinning the 'uv' tool to
0.4.15 while the project now uses [dependency-groups] in pyproject.toml, which
requires uv >= 0.4.27 for PEP 735 support; update the uv version constraint in
the CI workflow (continuous_integration.yml) to at least 0.4.27 (preferably a
newer stable release) so dev dependencies (pytest, mypy, ruff, coverage) are
installed correctly when the [dependency-groups] section is used.
…versal vulnerability in file uploads. Also reverted to tool.uv.dev-dependencies format to fix CI test execution issues.
Codecov Report✅ All modified and coverable lines are covered by tests. 📢 Thoughts on this report? Let us know! |
vprashrex
added
ready-for-review
security
vprashrex
removed
the
security
3 participants
Target Issue: #560
CVEs addressed:
Verified with pip-audit: 0 vulnerabilities found.
Summary
Target issue is #PLEASE_TYPE_ISSUE_NUMBER
Explain the motivation for making this change. What existing problem does the pull request solve?
Checklist
Before submitting a pull request, please ensure that you mark these task.
fastapi run --reload app/main.pyordocker compose upin the repository root and test.Notes
Please add here if any other information is required for the reviewer.
Summary by CodeRabbit
✏️ Tip: You can customize this high-level summary in your review settings.