fix(adb-mysql-mcp-server): force cryptography>=50.0.0 to clear the Grype gate

[danbarr]

Problem

build-containers (uvx/adb-mysql-mcp-server/spec.yaml) fails the Grype gate (--fail-on high --only-fixed) on a single finding:

Package	Installed	Fixed in	Advisory	Severity
cryptography	48.0.1	50.0.0	GHSA-g6cj-pr64-35w5	High

PKCS#7 EnvelopedData decryption exposes a Bleichenbacher oracle through distinguishable errors and timing. Affected range is >=44.0.0, <50.0.0.

The image itself builds and runs correctly. This is purely the vulnerability gate.

Why this is only surfacing now

build-containers declares needs: [discover-configs, verify-provenance, mcp-security-scan], so a failing scan prevents the build job from ever running. adb-mysql-mcp-server had been failing mcp-security-scan with ModuleNotFoundError: No module named 'mcp.server.fastmcp' after mcp 2.0.0 dropped that module, so this server never reached Grype. #669 fixes the scan failure, which unmasks this finding.

To be explicit, this is not a regression from the mcp<2 constraint added in #669: cryptography resolves to 48.0.1 identically with and without that constraint (verified in clean virtualenvs both ways).

Root cause

alibabacloud-tea-openapi caps the dependency:

cryptography (<49.0.0,>=3.0.0) ; python_version >= "3.9"

The fix is cryptography 50.0.0, which that cap excludes. This is the exact scenario #668 describes: an upstream cap holding a transitive dependency below the version that fixes a vulnerability.

.grype.yaml states that runtime dependencies under /opt/uv-tools are deliberately not ignorable, and should be "resolved by that package bumping its vulnerable dep, or by per-finding analysis in a follow-up PR." So an ignore rule is not the right instrument here.

Proposed fix

Once #669 merges, add a second constraint to uvx/adb-mysql-mcp-server/spec.yaml:

spec:
  package: "adb-mysql-mcp-server"
  version: "2.0.0"
  constraints:
    - spec: "mcp<2"
      reason: |
        adb-mysql-mcp-server depends on mcp[cli]>=1.8.0 with no upper bound, but
        mcp 2.0.0 removed the mcp.server.fastmcp module the server imports at
        startup.
    - spec: "cryptography>=50.0.0"
      reason: |
        alibabacloud-tea-openapi caps cryptography <49.0.0, but the fix for
        GHSA-g6cj-pr64-35w5 (High) is cryptography 50.0.0.

The longer term alternative is to ask alibabacloud-tea-openapi upstream to raise its cap, which is the more correct fix but much slower and not something we control. Worth doing in parallel if someone wants to open that upstream, but it should not block clearing the gate here.

Verification already performed

Built locally with dockhand and scanned with grype 0.110.0 (the version CI uses), from the repo root so .grype.yaml applies:

Spec	Grype result
mcp<2 only (current)	1 High, cryptography 48.0.1, reproduces the CI failure
+ cryptography>=50.0.0	No vulnerabilities found

Because 50.0.0 is two majors past the declared cap, functional checks were run against the image with cryptography 50.0.0 and mcp 1.29.0:

• Container starts, all 3 tools and 4 resources activate.
• alibabacloud_tea_openapi.client, alibabacloud_credentials.client, alibabacloud_adb20211201.client, and adb_mysql_mcp_server.server all import.
• RSA sign/verify, the primitive the SDK uses for request signing, works.

Residual risk: the above covers imports and the signing primitive, but not live API calls against AnalyticDB, which needs credentials. Worth a functional pass before or shortly after merging.

Why this is a separate PR

Changing only uvx/adb-mysql-mcp-server/spec.yaml matches the workflow path filters for that one config, so it rebuilds just that server. Folding it into #669 would trigger another full catalog rebuild, since that PR touches cmd/dockhand/**.

Blocked on #669, which adds the spec.constraints mechanism this depends on.