Update dependency sqlparse to v0.5.5#49
Conversation
📝 WalkthroughWalkthroughThe pull request updates the Changessqlparse Dependency Update
🎯 1 (Trivial) | ⏱️ ~2 minutes
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
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: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@api/tacticalrmm/requirements.txt`:
- Line 32: Update the dependency line to ensure sqlparse==0.5.5 is pinned (it
already is) and then search the codebase for any direct or indirect uses of the
sqlparse package (search for the token "sqlparse" and for likely SQL-parsing
callsites like functions named parse_*, format_*, or any migration/SQL rendering
helpers) and add exception handling for sqlparse.exceptions.SQLParseError around
those callsites; run smoke tests for any SQL parsing flows to confirm behavior.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro Plus
Run ID: 6e9f291c-3200-43a9-8b84-26405f12d329
📒 Files selected for processing (1)
api/tacticalrmm/requirements.txt
| requests==2.32.3 | ||
| six==1.16.0 | ||
| sqlparse==0.5.1 | ||
| sqlparse==0.5.5 |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Description: Verify sqlparse 0.5.5 exists and check for security advisories
# Check PyPI for the specific version
curl -s https://pypi.org/pypi/sqlparse/0.5.5/json | jq -r '.info.version // "Version not found"'
# Check for security advisories
gh api graphql -f query='
{
securityVulnerabilities(first: 10, ecosystem: PIP, package: "sqlparse") {
nodes {
advisory {
summary
severity
publishedAt
}
vulnerableVersionRange
firstPatchedVersion {
identifier
}
}
}
}'Repository: flamingo-stack/tacticalrmm
Length of output: 1391
🏁 Script executed:
#!/bin/bash
# Description: Find sqlparse usage to verify exception handling
# Search for sqlparse imports and usage
rg -n --type=py 'import sqlparse|from sqlparse' -A 5
# Search for parse/format calls that might be affected
rg -n --type=py 'sqlparse\.(parse|format|split)' -C 5Repository: flamingo-stack/tacticalrmm
Length of output: 52
🏁 Script executed:
#!/bin/bash
set -euo pipefail
# Find any mention/usages of sqlparse anywhere in the repo
rg -n "sqlparse" . || trueRepository: flamingo-stack/tacticalrmm
Length of output: 125
🌐 Web query:
sqlparse 0.5.5 DoS protection raises SQLParseError instead of returning None
💡 Result:
In sqlparse version 0.5.5, a change was implemented to address issue #827, ensuring that the library raises a SQLParseError instead of silently returning None when its Denial of Service (DoS) protection limits are exceeded [1][2]. Background and Reason for Change: Earlier versions (introduced in 0.5.4) added security guards—MAX_GROUPING_DEPTH and MAX_GROUPING_TOKENS—to prevent algorithmic complexity attacks during SQL parsing [1][3]. When these limits were initially hit, the parser would silently return None, which effectively suppressed error reporting and made it difficult for users to diagnose why certain large or complex SQL statements were failing to parse [2][4]. Version 0.5.5 corrected this behavior by explicitly raising a SQLParseError, providing clear feedback such as "Maximum grouping depth exceeded" or "Maximum number of tokens exceeded" [5][2]. Managing Limits: If you encounter these errors while processing legitimate, large SQL statements, you can adjust or disable the protections by modifying the constants in sqlparse.engine.grouping [3][4]. To increase or disable these limits, use: import sqlparse.engine.grouping # Increase limits (use with caution) sqlparse.engine.grouping.MAX_GROUPING_DEPTH = 200 sqlparse.engine.grouping.MAX_GROUPING_TOKENS = 50000 # Disable limits completely (use with extreme caution as this restores DoS vulnerability) sqlparse.engine.grouping.MAX_GROUPING_DEPTH = None sqlparse.engine.grouping.MAX_GROUPING_TOKENS = None It is highly recommended to keep these protections enabled if you are processing untrusted SQL input, as they are designed to prevent resource exhaustion attacks [3][4].
Citations:
- 1: https://github.com/andialbrecht/sqlparse/blob/0.5.5/CHANGELOG
- 2: Fix DoS protection to raise SQLParseError instead of silently returning None andialbrecht/sqlparse#827
- 3: andialbrecht/sqlparse@40ed3aa
- 4: 0.5.5 causing Maximum number of tokens exceeded in DBT queries andialbrecht/sqlparse#829
- 5: andialbrecht/sqlparse@da67ac1
Update sqlparse to 0.5.5: DoS handling now raises SQLParseError (check any indirect SQL parsing paths)
sqlparse==0.5.5exists on PyPI; the known security advisories shown for sqlparse are patched by 0.5.5 (e.g., DoS limit issue patched in 0.5.4).- In
sqlparse0.5.5, when grouping limits are exceeded, DoS protection now raisesSQLParseErrorinstead of returningNone. - This repo has no direct
sqlparseusage (only the dependency entry), so breakage risk is mainly if SQL parsing is done indirectly via other dependencies—exercise a smoke test around any SQL-parsing flows.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@api/tacticalrmm/requirements.txt` at line 32, Update the dependency line to
ensure sqlparse==0.5.5 is pinned (it already is) and then search the codebase
for any direct or indirect uses of the sqlparse package (search for the token
"sqlparse" and for likely SQL-parsing callsites like functions named parse_*,
format_*, or any migration/SQL rendering helpers) and add exception handling for
sqlparse.exceptions.SQLParseError around those callsites; run smoke tests for
any SQL parsing flows to confirm behavior.
2 participants
This PR contains the following updates:
==0.5.1→==0.5.5Release Notes
andialbrecht/sqlparse (sqlparse)
v0.5.5Compare Source
Bug Fixes
when grouping limits are exceeded (issue827).
v0.5.4Compare Source
Enhancements
for PEP 561 compliance, enabling type checking with mypy and other tools
(issue756).
to automatically format SQL files. The CLI now supports multiple files and
an
--in-placeflag for in-place editing (issue537).ATTACHandDETACHto PostgreSQL keywords (pr808).INTERSECTto close keywords in WHERE clause (pr820).REGEXP BINARYcomparison operator (pr817).Bug Fixes
very large lists of tuples. This enhances the existing recursion protections
with configurable limits for token processing to prevent DoS through
algorithmic complexity attacks. The new limits (MAX_GROUPING_DEPTH=100,
MAX_GROUPING_TOKENS=10000) can be adjusted or disabled (by setting to None)
if needed for legitimate large SQL statements.
comments (issue801, pr803 by stropysh).
blocks (issue812).
v0.5.3Compare Source
Bug Fixes
service attack (DOS) due to recursion errors for deeply nested statements.
Brought up and fixed by @living180. Thanks a lot!
v0.5.2Compare Source
Bug Fixes
Configuration
📅 Schedule: (UTC)
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ Rebasing: Whenever PR is behind base branch, or you tick the rebase/retry checkbox.
🔕 Ignore: Close this PR and you won't be reminded about this update again.
This PR has been generated by Mend Renovate.