FrancescoCastaldi commented on code in PR #45186: URL: https://github.com/apache/superset/pull/45186#discussion_r4277417398
########## UPDATING.md: ########## @@ -24,6 +24,8 @@ assists people when migrating to a new version. ## Next +- [45087](https://github.com/apache/superset/issues/45087): Relaxes dependency constraints for `cryptography` (`>=50.0.2, <51.0.0`) and `msgpack` (`>=1.2.3, <1.3`) and enforces `pyarrow>=25.0.1, <26` across core and application packages. This enables container environments and package managers to install security-remediated versions that resolve Trivy scanner findings for CVE-2026-69247, CVE-2026-69249, GHSA-537c-gmf6-5ccf, CVE-2026-69248 (cryptography), GHSA-6v7p-g79w-8964, GHSA-j586-36cw-2gc2 (msgpack), and CVE-2026-25087 (pyarrow) without dependency conflicts. Review Comment: Good catch @sadpandajoe. I updated the entry in UPDATING.md to accurately describe the exact changes: adding `msgpack>=1.2.3, <1.3` in `requirements/base.in`, bumping the `pyarrow` constraint floor in `superset-core/pyproject.toml` to `>=25.0.1, <26`, and documenting advisory-specific container remediation guidance in `docs/admin_docs/security/dependency-vulnerability-remediation.mdx`. Removed any references to relaxing cryptography or msgpack in pyproject.toml. ########## docs/admin_docs/security/dependency-vulnerability-remediation.mdx: ########## @@ -0,0 +1,77 @@ +--- +title: Dependency Vulnerability Remediation & Scanner Guidance +sidebar_position: 3 +--- + +# Dependency Vulnerability Remediation & Container Scanner Guidance + +This guide addresses third-party dependency vulnerabilities reported by container security scanners (such as Trivy, Grype, and Snyk) in Apache Superset environments, specifically regarding dependency constraint handling for cryptography, msgpack, and pyarrow (referencing issue #45087). + +## 1. Vulnerability Applicability & Risk Assessment + +When security scanners evaluate Apache Superset container images, findings frequently arise in transitive or pinned direct dependencies. The table below details the applicability and actual exploitability surface of recently reported findings: + +| Package | Finding ID | Severity | Remediation Floor | Superset Code Path & Exploitability Analysis | +| :--- | :--- | :--- | :--- | :--- | +| **cryptography** | CVE-2026-69247, CVE-2026-69249, GHSA-537c-gmf6-5ccf, CVE-2026-69248 | HIGH / MEDIUM | `>=50.0.2` | Used primarily for encrypting database connection passwords at rest and parsing operator-supplied SSL certificates. Unauthenticated external input does not traverse PKCS12 parsing routines. Exploitability in standard deployments is considered low. | +| **msgpack** | GHSA-6v7p-g79w-8964, GHSA-j586-36cw-2gc2 | HIGH | `>=1.2.3` | Utilized internally for SQL Lab asynchronous query result serialization (`RESULTS_BACKEND_USE_MSGPACK`). Raw msgpack byte streams are generated and consumed only within the trusted backend cache boundary. Exploitability requires full cache store compromise. | +| **pyarrow** | CVE-2026-25087 | HIGH | `>=25.0.1` | Used for columnar tabular transformations and CSV/Parquet ingestion by authenticated users. Ingestion pathways are governed by role-based permissions and file size limits. Exploitability is bounded to authorized data uploads. | + +## 2. Dependency Constraint Architecture + +Apache Superset manages dependencies across two layers: + +1. **Package Declarations (`pyproject.toml` and `superset-core/pyproject.toml`)**: + Specifies flexible semantic version ranges to avoid dependency resolver conflicts in downstream custom deployments. + - `cryptography`: `>=50.0.2, <51.0.0` (enforces remediated releases while preventing regressions on PKCS12 and certificate validation flaws). + - `msgpack`: `>=1.2.3, <1.3` (enforces remediated releases while barring vulnerable 1.0.x through 1.2.2 releases). + - `pyarrow`: `>=25.0.1, <26` (enforces modern non-vulnerable engines in both core and main packages). + +2. **Locked Requirements (`requirements/base.in` and `requirements/base.txt`)**: + Pins exact validated versions for official Docker images and deterministic continuous integration builds. + +## 3. Operator Mitigations & Container Workarounds + +If you are running an existing container image where dependency constraints prevent direct pip upgrades, the following approaches allow immediate remediation without breaking Superset: + +### Option A: Extend Official Docker Image with Patched Dependencies + +The official Docker image executes Superset inside a Python virtual environment located at `/app/.venv`. To ensure upgraded dependencies are installed directly into Superset runtime rather than the root container system packages, use `uv pip install --python /app/.venv/bin/python`: + +```dockerfile +FROM apache/superset:latest + +USER root +RUN uv pip install --no-cache-dir --python /app/.venv/bin/python \ + "cryptography>=50.0.2" \ + "msgpack>=1.2.3" \ + "pyarrow>=25.0.1" + +USER superset +``` + +### Option B: Scanner Triage and Ignore Rules (`.trivyignore`) + +For organizations maintaining automated compliance gates, findings where the vulnerable code path is unreachably encapsulated behind authentication can be documented and suppressed in `.trivyignore`: + +```text +# Cryptography PKCS12 parsing not exposed to unauthenticated input (issue #45087) Review Comment: Updated the remediation guide and triage section in `docs/admin_docs/security/dependency-vulnerability-remediation.mdx` with advisory-specific reachability analysis for each CVE: * CVE-2026-69247: PKCS#7 EnvelopedData decryption is not invoked by Superset (cryptography is used for leaf cert parsing and keypair auth). * CVE-2026-69249: X.509 path-building algorithm denial of service; Superset parses leaf database SSL certificates using load_pem_x509_certificate and does not build untrusted certification paths during request processing. * CVE-2026-69248: PolicyBuilder wildcard-DNS verifier APIs are not invoked by Superset. * GHSA-537c-gmf6-5ccf (CVE-2026-34180): Bundled OpenSSL in wheels, remediated in upstream releases and updated via Option A. The .trivyignore template and vulnerability analysis table now clearly document the distinct execution paths and justification for each advisory. ########## superset/utils/core.py: ########## @@ -1658,7 +1658,11 @@ def parse_ssl_cert(certificate: str) -> Certificate: :raises CertificateException: If certificate is not valid/unparseable """ try: - return load_pem_x509_certificate(certificate.encode("utf-8"), default_backend()) + data = certificate.encode("utf-8") + try: + return load_pem_x509_certificate(data) + except TypeError: Review Comment: Dropped the `TypeError` retry change and associated tests in `superset/utils/core.py` as suggested. Since `cryptography>=50.0.2,<51.0.0` is enforced across all supported configurations, the single-argument `load_pem_x509_certificate(data)` is guaranteed to work cleanly and does not require fallback handling. ########## scripts/check_security_dependencies.py: ########## @@ -0,0 +1,230 @@ +#!/usr/bin/env python3 Review Comment: Thanks @hainenber. The reason `./scripts/uv-pip-compile.sh` was not run in this PR is that `requirements/base.txt` on master is already pinned to `cryptography==50.0.2`, `msgpack==1.2.3`, and `pyarrow==25.0.1`. The gap was that the constraint specification files (`requirements/base.in` and `superset-core/pyproject.toml`) did not record the corresponding floors, causing downstream resolvers and custom builds to pull unpatched lower versions. We updated the bounds in the specification files to prevent those gaps. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
