fix(deps): clear the remaining uv.lock highs — cryptography override, seed resolution (#2120) - #2121
Conversation
|
Important Review skippedAuto reviews are disabled on base/target branches other than the default branch. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
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 |
|
a2d75d1 to
1f11a51
Compare
…2120) airbyte-cdk 6.60.x resolves cryptography 44.0.3, which carries a Bleichenbacher timing oracle in PKCS#1 v1.5 decryption (CVE-2026-26007, fixed in 46.0.5) and GHSA-537c-gmf6-5ccf (fixed in 48.0.1). The override resolves 49.0.0. Regenerating the lock from a clean checkout, as trivy.yml does, and rescanning: both findings clear. Harness suites with the override applied: 42 passed, 1 skipped -- identical to baseline. Signed-off-by: Gregory Gogin <grigoriy.gogin@constructor.tech>
2cfe977 to
50ac046
Compare
| # pathspec>=0.9,<0.13. Pin mypy above that line and the resolver satisfies | ||
| # it by walking dbt-core back to 1.2.6, locking a 2022 dependency set that | ||
| # nothing installs -- the image runs `pip install .` without this extra. | ||
| "mypy>=1.10", |
There was a problem hiding this comment.
I do not understand why newer dbt-core requires so old version of pathspec.
Also pathspec>=0.9 and pathspec>=1.0.0 can work with latelst pathspec, isn't it? I.e. pathspec==1.1.1 satisfies both.
mypy 1.10 is very old.
There was a problem hiding this comment.
Claude proposed a more optimal solution, which should fix it, because in the current state there were some complex dependencies like:
the maximal dbt-core we can resolve, 1.11.12, requires pathspec < 0.13
mypy >= 1.20 requires pathspec >= 1.0.0.
(dbt-core 1.12.0 raised its cap to < 1.1, but it needs dbt-adapters >= 1.24.5 and dbt-clickhouse 1.10.1 needs dbt-adapters < 1.23.0.)
So proposed solution was to remove mypy и ruff from dependencies (seems they are not needed), which led to removing one branch of constraints ("mypy → pathspec" from → dbt-core → dbt-adapters → dbt-clickhouse), so mypy goes to 2.3.0 and pathspec depends only from dbt-core
There was a problem hiding this comment.
Hm, mypy and ruff required for pre commit checks. So they must be installed somehow. It may not be related to things baked in connector images.
There was a problem hiding this comment.
It seems you need to bump dbt-core.
50ac046 to
d829c73
Compare
…rrent (#2120) The scan reports eight highs on deploy/seed for jinja2 2.11.3, werkzeug 2.1.2 and sqlparse 0.4.3 -- a 2022 dependency set nothing installs. uv resolves the base dependencies and the dev extra together, and mypy==2.1.0 needs pathspec>=1.0.0 while dbt-core on the 1.11 line caps pathspec below 0.13. The pin could not move, so dbt-core gave: the resolver walked it back to 1.2.6, before that constraint existed. dbt-core 1.12 raised its own cap to pathspec<1.1 (dbt-labs/dbt-core#12385), so a current mypy resolves against a current dbt-core. The extra now asks for mypy>=2,<3 and the graph comes out at dbt-core 1.12.0, dbt-adapters 1.24.5, pathspec 1.0.4, mypy 2.3.0. dbt-clickhouse settles on 1.9.3 rather than 1.10.1: the 1.10 line caps dbt-adapters below 1.23.0, under dbt-core 1.12.0's 1.24.5 floor, and 1.9.3 carries no adapter bound at all. ruff moves 0.15.16 -> 0.15.21 to match the ruff-pre-commit hook, which was already on v0.15.21. Two different pins meant a local run and the commit hook could reach different verdicts. Locking from clean: dbt-clickhouse 1.9.3, dbt-core 1.12.0, jinja2 3.1.6, sqlparse 0.5.5, no werkzeug -- 0 CRITICAL and 0 HIGH repo-wide. The documented recipe still works end to end: `pip install -e '.[dev]'` then `ruff check .` (All checks passed) and `mypy .` (14 files, no issues). Signed-off-by: Gregory Gogin <grigoriy.gogin@constructor.tech>
d829c73 to
48f4d64
Compare
Closes #2120. Clears the last ten
uv.lockfindings the scan reports at GitHub-high severity —the remainder after #2083 covered
nltkandlangchain-core.How this is measured
uv.lockis not tracked (.gitignore:24)..github/workflows/trivy.ymlregenerates every lockwith
uv lockbefore scanning, so the findings describe uv's resolution of the committedpyproject.tomlfiles. Every number here comes from running that same step locally — same pinneduvandtrivyimages, same flags.One caveat worth stating:
uv lockis incremental and keeps whatever an existing lock alreadypins. CI locks a clean checkout; locally the lock must be deleted first or the result is fiction.
1.
cryptographyin the connector harness — 2 highairbyte-cdk 6.60.xresolvescryptography 44.0.3: a Bleichenbacher timing oracle in PKCS#1 v1.5decryption (
CVE-2026-26007, fixed in 46.0.5) andGHSA-537c-gmf6-5ccf(fixed in 48.0.1). Onemore entry in the existing override list; resolves 49.0.0.
2.
deploy/seed— mypy and dbt-core could not share apathspec, 8 highThe eight findings name
jinja2 2.11.3,werkzeug 2.1.2andsqlparse 0.4.3— a 2022 dependencyset nothing installs.
uvresolves the base dependencies and the dev extra together, andmypy==2.1.0needspathspec>=1.0.0whiledbt-coreon the 1.11 line capspathspecbelow 0.13.The pin could not move, so
dbt-coregave: the resolver walked it back to 1.2.6, before thatconstraint existed, and locked its dependency tree.
dbt-core1.12 raised its own cap topathspec<1.1(dbt-labs/dbt-core#12385), so a currentmypyresolves against a currentdbt-core. The extra now asks formypy>=2,<3:dbt-clickhousesettles on 1.9.3 rather than 1.10.1: the 1.10 line capsdbt-adaptersbelow1.23.0, under
dbt-core1.12.0's 1.24.5 floor, and 1.9.3 carries no adapter bound at all.Requesting
dbt-clickhouse>=1.10together withmypy>=2givesNo solution found, so theadapter version is not a free choice here.
ruffmoves 0.15.16 → 0.15.21 to match theruff-pre-commithook, which was already onv0.15.21. Two different pins meant a local run and the commit hook could reach differentverdicts.
Unchanged:
[project.dependencies], the[tool.ruff]and[tool.mypy]config, the Dockerfile(
pip install .does not install the extra), the composeseed-sampleservice, the developerrecipe in the README, and CI — no workflow references
deploy/seed.Test plan
(
trivy fs --scanners vuln --include-dev-deps,aquasec/trivy:0.72.0). By GitHub'sCVSS-derived severity: 10 high → 0
deploy/seedlocks to dbt-clickhouse 1.9.3, dbt-core 1.12.0, dbt-adapters 1.24.5,pathspec 1.0.4, mypy 2.3.0, ruff 0.15.21, jinja2 3.1.6, sqlparse 0.5.5, no werkzeug
pip install -e '.[dev]'succeeds,ruff check .→ All checks passed (so 0.15.21 introduces no new failures),mypy .→ Success, no issues found in 14 source filespip install ., the Dockerfile path — succeeds;seed,silver,identity,profiles,generatorsall importpytest --suites-onlywith the cryptography override — 42 passed, 1 skipped,identical to baseline
git diff --checkcleantrivy.ymltriggers onmainplus the nightlyschedule, so nothing runs against
security-hardening— they will not move until thisreaches
main, or the workflow is fired viaworkflow_dispatch