fix(ingest/deps): sqlparse 0.6.0, pyOpenSSL>=26.4.0, cryptography>=50.0.0 by rob-1019 · Pull Request #19385 · datahub-project/datahub

rob-1019 · 2026-08-21T20:20:37Z

Summary

Two dependency-range fixes in metadata-ingestion/setup.py:

sqlparse: the <0.6.0 cap excluded the release that fixes CVE-2026-54284, CVE-2026-59893, and CVE-2026-71491 (all HIGH). datahub only uses the stable public API (sqlparse.format wrapped in try/except in sql_formatter.py, and token walking in the PowerBI native SQL parser), so 0.6.x is admitted with a <1.0.0 ceiling.
pyOpenSSL: 26.0–26.3 crash on import against cryptography>=49 (AttributeError: module 'lib' has no attribute 'GEN_EMAIL') — a resolution the existing cryptography>=49.0.0,<51.0.0 range permits. The floor moves to 26.4.0, the first release compatible with cryptography 49/50.
cryptography (second commit): floor raised to 50.0.0 — >=49.0.0 still admitted 49.x, which carries CVE-2026-69247 (fixed only in 50.0.0). Updated in both setup.py and the shared ingestion constraints snippet.

Why floors instead of just lifting caps

The sqlparse change is deliberately >=0.6.0 rather than only removing the <0.6.0 ceiling: a lifted cap merely permits the fixed release, and any environment with an existing resolution (or a committed lockfile) keeps installing the vulnerable 0.5.x forever. A floor makes the CVE fix self-enforcing — acryl-datahub itself refuses to resolve against the vulnerable versions, so every consumer picks up the fix on its next dependency resolution with no per-consumer action.

Downstream note: distributions that maintain generated lockfiles pinning sqlparse==0.5.x or cryptography==49.x/48.x will see those pins become invalid against this release — that's intended; lockfile regeneration resolves to the fixed versions. Same for pyOpenSSL 26.0–26.3 pins.

Test plan

Verified both usage sites (sql_formatter.py, native_sql_parser.py) touch only stable sqlparse public API
Reproduced the pyOpenSSL 26.0.0 + cryptography 50 import crash; confirmed 26.4.0 imports cleanly
CI

Checklist

The PR conforms to DataHub's Contributing Guideline
Links to related issues (if applicable)
Tests for the changes have been added/updated

🤖 Generated with Claude Code

Summary by cubic

Admits sqlparse 0.6.x, requires pyOpenSSL>=26.4.0, and raises the cryptography floor to 50.0.0 to address CVEs and prevent import crashes. Previously sqlparse<0.6.0, pyOpenSSL>=26.0.0, and cryptography>=49.0.0; now sqlparse>=0.6.0,<1.0.0, pyOpenSSL>=26.4.0,<27.0.0, and cryptography>=50.0.0,<51.0.0. No functional changes; only dependency resolution.

Propagates these ranges across setup.py, pyproject.toml extras, docker/snippets/ingestion/constraints.txt, metadata-ingestion/constraints.txt (re-exported), and uv.lock.
Aligns powerbi and sigma extras with sqlparse>=0.6.0,<1.0.0.
Updates redash extra to sql-metadata>=3.0.1,<4.0.0 (older versions hard‑pin sqlparse<0.6.0).
Migration: regenerate lockfiles; ensure MSSQL extras install pyOpenSSL>=26.4.0. Update any pins to sqlparse==0.5.x, cryptography==49.x, or pyOpenSSL==26.0–26.3.

^{Written for commit bbfb2f9. Summary will update on new commits.}

- sqlparse<0.6.0 excluded the release that fixes CVE-2026-54284, CVE-2026-59893, and CVE-2026-71491 (all HIGH). datahub's usage is the stable public API (sqlparse.format in a try/except, token walking in the powerbi native SQL parser), so admit 0.6.x with a <1.0.0 ceiling. - pyOpenSSL 26.0-26.3 crash on import against cryptography>=49 (AttributeError: module 'lib' has no attribute 'GEN_EMAIL') — a resolution the existing cryptography>=49.0.0,<51.0.0 range permits. Raise the floor to 26.4.0, the first release compatible with cryptography 49/50. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

cursor · 2026-08-21T20:20:50Z

PR Summary

Overview
Raises ingestion dependency floors so CVE-fixed versions are required, not merely allowed: sqlparse>=0.6.0,<1.0.0, pyOpenSSL>=26.4.0, and cryptography>=50.0.0,<51.0.0.

sqlparse 0.6.x addresses HIGH CVEs that the old <0.6.0 cap blocked. sql-metadata moves to >=3.0.1 because older releases pin sqlparse<0.6.0. pyOpenSSL 26.4.0 is the first release that imports cleanly against cryptography 49/50. Cryptography 50.0.0 is required for CVE-2026-69247.

Ranges are updated in setup.py, extras, Docker constraints, and lockfiles. Downstream lockfiles pinning sqlparse==0.5.x, cryptography==49.x, or pyOpenSSL 26.0–26.3 will need regeneration.

^{Reviewed by Cursor Bugbot for commit bbfb2f9. Bugbot is set up for automated code reviews on this repo. Configure here.}

codecov · 2026-08-21T20:23:06Z

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ All tests successful. No failed tests found.

📢 Thoughts on this report? Let us know!

cursor

Cursor Bugbot has reviewed your changes using high effort and found 3 potential issues.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit a37bbcd. Configure here.}

The >=49.0.0 floor still admits 49.x, which carries CVE-2026-69247 (fixed only in 50.0.0). Raised in both setup.py and the shared ingestion constraints snippet; the <51.0.0 ceiling and pyOpenSSL>=26.4.0 pairing are unchanged. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

rob-1019 · 2026-08-21T20:28:54Z

Added a second commit raising the cryptography floor to 50.0.0: the >=49.0.0 floor still admitted 49.x, which carries CVE-2026-69247 (fixed only in 50.0.0). Updated in both setup.py and the shared ingestion constraints snippet.

cubic-dev-ai

1 issue found and verified against the latest diff

Prompt for AI agents (unresolved issues)


Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="metadata-ingestion/setup.py">

<violation number="1" location="metadata-ingestion/setup.py:156">
P1: Generated packaging metadata was not regenerated, so PEP 621 builds still request the vulnerable sqlparse range and old pyOpenSSL floor. Regenerate `pyproject.toml` and `uv.lock` before merging.</violation>
</file>

_{Reply with feedback, questions, or to request a fix.

Re-trigger cubic}

cubic-dev-ai · 2026-08-21T20:29:37Z

 usage_common = {
-    "sqlparse<0.6.0",
+    # >=0.6.0 for CVE-2026-54284 / CVE-2026-59893 / CVE-2026-71491.
+    "sqlparse>=0.6.0,<1.0.0",


P1: Generated packaging metadata was not regenerated, so PEP 621 builds still request the vulnerable sqlparse range and old pyOpenSSL floor. Regenerate pyproject.toml and uv.lock before merging.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At metadata-ingestion/setup.py, line 156: <comment>Generated packaging metadata was not regenerated, so PEP 621 builds still request the vulnerable sqlparse range and old pyOpenSSL floor. Regenerate `pyproject.toml` and `uv.lock` before merging.</comment> <file context> @@ -152,7 +152,8 @@ usage_common = { - "sqlparse<0.6.0", + # >=0.6.0 for CVE-2026-54284 / CVE-2026-59893 / CVE-2026-71491. + "sqlparse>=0.6.0,<1.0.0", } </file context>

cubic-dev-ai

1 existing issue remains and no new issues found across 2 files (changes from recent commits).

_{Requires human review: Auto-approval blocked because this review re-detected 1 unresolved issue already reported by Cubic.

Re-trigger cubic}

…they're declared CI's checkLockFile plus review-bot findings caught the incomplete first pass: - Regenerate pyproject.toml (generate_pyproject_deps.py; equivalence 152/152) and uv.lock (sqlparse 0.6.0, cryptography 50.0.0, pyOpenSSL 26.4.0). - powerbi and sigma extras: align their own sqlparse pins with the >=0.6.0,<1.0.0 floor (sigma's <0.6.0 pin would have been unsatisfiable). - redash extra: sql-metadata>=3.0.1 — every earlier release hard-pins sqlparse<0.6.0; datahub code never imports it (comment reference only). - constraints snippet: pyopenssl floor raised to 26.4.0 to match setup.py. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

…he updated lock The generated constraints file (uv export from uv.lock) still pinned sqlparse==0.5.5, failing installDev with an internal conflict against the new >=0.6.0 floor. Re-exported: sqlparse 0.6.0, cryptography 50.0.0, pyOpenSSL 26.4.0, sql-metadata 3.0.1. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

cubic-dev-ai

1 issue found across 4 files (changes from recent commits).

Prompt for AI agents (unresolved issues)


Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="metadata-ingestion/setup.py">

<violation number="1" location="metadata-ingestion/setup.py:751">
P1: When `installAll` or `checkLockFile` uses the checked-in constraints, this new extra is unsatisfiable because `constraints.txt` still forces `sql-metadata==2.20.0` (and `sqlparse==0.5.5`). Regenerate and commit `metadata-ingestion/constraints.txt` after these dependency changes.</violation>
</file>

_{Tip: Review your code locally with the cubic CLI to iterate faster.

Re-trigger cubic}

cubic-dev-ai · 2026-08-21T21:24:53Z

-    "redash": {"redash-toolbelt<0.2.0", "sql-metadata<3.0.0"} | sqlglot_lib,
+    # sql-metadata>=3.0.1: every earlier release hard-pins sqlparse<0.6.0, conflicting with
+    # the CVE floor above. Not imported by datahub code (comment reference only).
+    "redash": {"redash-toolbelt<0.2.0", "sql-metadata>=3.0.1,<4.0.0"} | sqlglot_lib,


P1: When installAll or checkLockFile uses the checked-in constraints, this new extra is unsatisfiable because constraints.txt still forces sql-metadata==2.20.0 (and sqlparse==0.5.5). Regenerate and commit metadata-ingestion/constraints.txt after these dependency changes.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At metadata-ingestion/setup.py, line 751: <comment>When `installAll` or `checkLockFile` uses the checked-in constraints, this new extra is unsatisfiable because `constraints.txt` still forces `sql-metadata==2.20.0` (and `sqlparse==0.5.5`). Regenerate and commit `metadata-ingestion/constraints.txt` after these dependency changes.</comment> <file context> @@ -746,7 +746,9 @@ - "redash": {"redash-toolbelt<0.2.0", "sql-metadata<3.0.0"} | sqlglot_lib, + # sql-metadata>=3.0.1: every earlier release hard-pins sqlparse<0.6.0, conflicting with + # the CVE floor above. Not imported by datahub code (comment reference only). + "redash": {"redash-toolbelt<0.2.0", "sql-metadata>=3.0.1,<4.0.0"} | sqlglot_lib, "rdf": {"rdflib==6.3.2", "requests==2.32.5", "requests_file==3.0.1"}, "redshift": sql_common </file context>

datahub-connector-tests · 2026-08-21T22:01:45Z

Connector Tests Results

All connector tests passed for commit bbfb2f9

View full test logs →

To skip connector tests, add the skip-connector-tests label (org members only).

Autogenerated by the connector-tests CI pipeline.

github-actions Bot added the ingestion PR or Issue related to the ingestion of metadata label Aug 21, 2026

cursor Bot reviewed Aug 21, 2026

View reviewed changes

Comment thread metadata-ingestion/setup.py

Comment thread metadata-ingestion/setup.py

Comment thread metadata-ingestion/setup.py

rob-1019 changed the title ~~fix(ingest/deps): admit sqlparse 0.6.0 and require pyOpenSSL>=26.4.0~~ fix(ingest/deps): sqlparse 0.6.0, pyOpenSSL>=26.4.0, cryptography>=50.0.0 Aug 21, 2026

cubic-dev-ai Bot reviewed Aug 21, 2026

View reviewed changes

Comment thread docker/snippets/ingestion/constraints.txt

vercel Bot deployed to Preview August 21, 2026 20:43 View deployment

vercel Bot had a problem deploying to Preview August 21, 2026 21:22 Failure

cubic-dev-ai Bot reviewed Aug 21, 2026

View reviewed changes

github-actions Bot deployed to datahub-wheels (Preview) August 21, 2026 21:26 View deployment

vercel Bot deployed to Preview August 21, 2026 21:39 View deployment

maggiehays added the needs-review Label for PRs that need review from a maintainer. label Aug 22, 2026

Navigation Menu

Uh oh!

fix(ingest/deps): sqlparse 0.6.0, pyOpenSSL>=26.4.0, cryptography>=50.0.0 - #19385

fix(ingest/deps): sqlparse 0.6.0, pyOpenSSL>=26.4.0, cryptography>=50.0.0#19385
rob-1019 wants to merge 4 commits into
masterfrom
fix/ingest-sqlparse-pyopenssl-deps

rob-1019 commented Aug 21, 2026 •

edited by cubic-dev-ai Bot

Loading

Uh oh!

cursor Bot commented Aug 21, 2026 •

edited

Loading

Uh oh!

codecov Bot commented Aug 21, 2026 •

edited

Loading

Uh oh!

cursor Bot left a comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

rob-1019 commented Aug 21, 2026

Uh oh!

cubic-dev-ai Bot left a comment •

edited

Loading

Uh oh!

Uh oh!

cubic-dev-ai Bot Aug 21, 2026

Uh oh!

Uh oh!

cubic-dev-ai Bot left a comment •

edited

Loading

Uh oh!

Uh oh!

cubic-dev-ai Bot left a comment

Uh oh!

cubic-dev-ai Bot Aug 21, 2026

Uh oh!

datahub-connector-tests Bot commented Aug 21, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Conversation

rob-1019 commented Aug 21, 2026 • edited by cubic-dev-ai Bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Why floors instead of just lifting caps

Test plan

Checklist

Summary by cubic

Uh oh!

cursor Bot commented Aug 21, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

PR Summary

Uh oh!

codecov Bot commented Aug 21, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Codecov Report

Uh oh!

cursor Bot left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

rob-1019 commented Aug 21, 2026

Uh oh!

cubic-dev-ai Bot left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

cubic-dev-ai Bot Aug 21, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

cubic-dev-ai Bot left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

cubic-dev-ai Bot left a comment

Choose a reason for hiding this comment

Uh oh!

cubic-dev-ai Bot Aug 21, 2026

Choose a reason for hiding this comment

Uh oh!

datahub-connector-tests Bot commented Aug 21, 2026

Connector Tests Results

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

rob-1019 commented Aug 21, 2026 •

edited by cubic-dev-ai Bot

Loading

cursor Bot commented Aug 21, 2026 •

edited

Loading

codecov Bot commented Aug 21, 2026 •

edited

Loading

cubic-dev-ai Bot left a comment •

edited

Loading

cubic-dev-ai Bot left a comment •

edited

Loading