Repository navigation
fix(deps): uncap setuptools and lock 84.0.0 to remediate CVE-2026-59890 - #1119
Conversation
Co-Authored-By: bot_apk <apk@cognition.ai>
🤖 Devin AI EngineerI'll be helping with this pull request! Here's what you should know: ✅ I will automatically:
Note: I can only respond to comments from users who have write access to this repository. ⚙️ Control Options:
|
👋 Greetings, Airbyte Team Member!Here are some helpful tips and reminders for your convenience. 💡 Show Tips and TricksTesting This CDK VersionYou can test this version of the CDK using the following: # Run the CLI from this branch:
uvx 'git+https://github.com/airbytehq/airbyte-python-cdk.git@devin/1786897778-setuptools-cve-2026-59890#egg=airbyte-python-cdk[dev]' --help
# Update a connector to use the CDK from this branch ref:
cd airbyte-integrations/connectors/source-example
poe use-cdk-branch devin/1786897778-setuptools-cve-2026-59890PR Slash CommandsAirbyte Maintainers can execute the following slash commands on your PR:
|
There was a problem hiding this comment.
Pull request overview
Updates the Airbyte Python CDK’s dependency constraints to unblock downstream resolvers from selecting a non-vulnerable setuptools version (>= 83.0.0) that remediates CVE-2026-59890, without requiring any CDK code changes.
Changes:
- Raises the
setuptoolsconstraint from^80.9.0to>=83.0.0to ensure vulnerable versions cannot be resolved through the CDK dependency graph. - Refreshes
poetry.lockto reflect resolution tosetuptools84.0.0 and associated metadata updates.
Reviewed changes
Copilot reviewed 1 out of 2 changed files in this pull request and generated no comments.
| File | Description |
|---|---|
| pyproject.toml | Updates setuptools dependency constraint to >=83.0.0 to permit/ensure remediation of CVE-2026-59890 downstream. |
| poetry.lock | Lockfile refresh reflecting setuptools upgrade (to 84.0.0) and updated lock metadata hash. |
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
A >=83.0.0 floor forces setuptools without pkg_resources (removed in 82.0.0) on every consumer and leaves no escape hatch for connectors whose dependencies still import it at module load (e.g. pymilvus<2.5.5 in destination-milvus). Dropping only the upper bound unblocks CVE-2026-59890 remediation downstream, and the CDK lock (which the SDM image installs) moves to the fixed 84.0.0.
Baz (bazarnov)
left a comment
There was a problem hiding this comment.
Approved. I changed the floor from >=83.0.0 to >=80.9.0: setuptools 82 removed pkg_resources, and a >=83 floor would take away the setuptools<82 pin that destination-milvus needs (pymilvus 2.3.0 imports pkg_resources at load time, see airbytehq/airbyte#87038). The lock stays on 84.0.0, so the SDM and manifest-server images ship the fixed version. I merged main, and all required checks are green on this head. Check: destination-motherduck fails the same way on recently merged PRs (#1149, #1152, #1154), and Check: source-shopify is still running and not required.
|
❌ Cannot revive Devin session - the session is too old. Please start a new session instead. |
Summary
The CDK constrains
setuptoolsto^80.9.0(>=80.9.0,<81.0.0), so no lockfile that depends onairbyte-cdkcan resolvesetuptools>=83.0.0, the first release that fixes CVE-2026-59890 / GHSA-h35f-9h28-mq5c. The CDK itself never importssetuptoolsorpkg_resources. The dependency only exists for connectors that usesetuptoolswithout declaring it (source-shopify).Changes:
pyproject.toml:setuptools = "^80.9.0">>setuptools = ">=80.9.0"(upper bound removed, floor unchanged).poetry.lock:setuptools80.9.0 >> 84.0.0. Nothing else in the lock moves apart from the content hash. The SDM and manifest-server images install from this lock, so both images now ship the fixed version.Why
>=80.9.0and not a>=83.0.0floorsetuptools82.0.0 removedpkg_resources. A>=83.0.0floor would force every consumer onto asetuptoolswithoutpkg_resourcesand remove the escape hatch of pinningsetuptools<82. At least one monorepo connector needs that escape hatch:destination-milvuspinspymilvus==2.3.0, whosepymilvus/client/__init__.pyrunsfrom pkg_resources import ...at import time, soimport pymilvusfails onsetuptools>=82. Dropping only the upper bound lets consumers take 83+ (issue #1118), while new locks, including the CDK's own, still resolve the latest fixed version.Verification
setuptools,pkg_resourcesordistutilsimports underairbyte_cdk/,unit_tests/orbin/(only a docstring inairbyte_cdk/sources/utils/transform.py).setuptools83/84 require Python>=3.10, which matches the CDK's>=3.10,<3.14.setuptools84.0.0 installed andpkg_resourcesabsent. Thepkg_resourcesreferences in CDK dependencies (pytz,wrapt,werkzeug,ddtrace,openai,pytest) are all guarded or lazy.Updating setuptools (78.1.1 -> 84.0.0). The wheel metadata carriesRequires-Dist: setuptools (>=80.9.0).source-shopify'sfrom setuptools.command.alias import aliasstill resolves on 84.0.0.Check: destination-motherduckfails the same way on unrelated recently merged PRs.Downstream impact
setuptools84.0.0, which has nopkg_resources. Custom components that importpkg_resourcesmust switch toimportlib.metadata/importlib.resources, or run on a connector image that pinssetuptools<82.setuptools>=82on their next lock refresh. Connectors with a dependency that importspkg_resourcesat load time should pinsetuptools<82first. Known case:destination-milvus(follow-up PR in the monorepo: fix(destination-milvus): pin setuptools below 82 for pymilvus 2.3.0 airbyte#87038).Fixes #1118
Related: https://github.com/airbytehq/oncall/issues/13315
Link to Devin session: https://app.devin.ai/sessions/6a924111e09f48dba70eef51ae481d37