viirya opened a new pull request, #52:
URL: https://github.com/apache/spark-connect-gateway/pull/52
### What changes were proposed in this pull request?
Run `cargo audit` in CI, checking `Cargo.lock` against the RustSec advisory
database.
| File | Purpose |
|---|---|
| `.github/workflows/audit.yml` | The workflow (triggers below) |
| `dev/audit-new-advisories.sh` | Pull-request check: report only advisories
the change introduces |
| `.cargo/audit.toml` | Ignores RUSTSEC-2023-0071 (`rsa`), pointing at
SPARK-60369 |
The workflow keeps two questions apart:
- **Is `main` affected by a known advisory?** A daily schedule (and
`workflow_dispatch`) runs a full `cargo audit` on `main`.
- **Does this change introduce one?** Pull requests that touch `Cargo.lock`,
a
`Cargo.toml`, `.cargo/audit.toml`, or the audit tooling run
`dev/audit-new-advisories.sh`. It audits the base revision's `Cargo.lock`
and
the pull request's against the same snapshot of the database, and fails
only
on advisory/crate pairs that the base does not have. Advisories already on
`main` are listed but not counted against the pull request.
There is **no push trigger**. A merge has already been checked as a pull
request, and a full audit on push would mark every dependency merge red while
`main` carries any unfixed advisory, including merges that fix one.
`dev/audit-new-advisories.sh` exits 0 when nothing is introduced, 1 when
something is, and 2 when `cargo audit` cannot produce a report. `cargo audit`
itself exits 1 on findings, so its status cannot tell a finding from a
failure
(for example, the database could not be fetched); the script requires a JSON
report and treats anything else as an error rather than a pass. Pairs are
compared without versions, so moving a crate from one affected version to
another does not count as new.
`cargo-audit` is installed with `cargo install --version 0.22.1 --locked`
instead of a third-party action, to stay within the Apache GitHub Actions
allowlist. Checkout and toolchain setup are the same pinned steps `ci.yml`
uses.
### Why are the changes needed?
Nothing in CI checked dependencies for known vulnerabilities. Three
advisories
(`h2`, `rustls`, `rsa`) sat on `main` with CI green and were found only by
running `cargo audit` by hand. The `h2` fix from SPARK-60115 is a `--precise`
pin on a transitive dependency, which a later `cargo update` or a `hyper` /
`tonic` bump could silently undo.
The reason for not simply failing on any advisory: the database changes
daily,
so such a check would turn pull requests red for vulnerabilities they did not
introduce -- the failure mode SPARK-59989 fixed for the floating Rust
toolchain.
While this change was being prepared, eleven new advisories affecting the
lockfile were published, so this is not hypothetical.
**The `rsa` ignore.** RUSTSEC-2023-0071 (Marvin Attack) has no fixed release:
0.9.10 is the latest stable and 0.10 exists only as a release candidate. The
attack recovers a private key from the timing of private-key operations. The
gateway only verifies RS256 signatures with public keys through
`jsonwebtoken`;
every `EncodingKey` / `RsaPrivateKey` use is inside `#[cfg(test)]`, and the
direct `rsa` dependency is a dev-dependency. SPARK-60369 tracks removing the
ignore and lists when to revisit it.
**What to expect after merge.** The scheduled run will be red until the
advisories currently on `main` are fixed: #51 (SPARK-60371) addresses nine of
them, and RUSTSEC-2026-0381 / -0382 (`webpki-roots`, `rustls-webpki`) will be
handled separately. That is the intended signal. Pull requests are not
affected by it.
### Does this PR introduce _any_ user-facing change?
No. CI only.
### How was this patch tested?
`dev/audit-new-advisories.sh` was run locally against real lockfiles:
| Base | Head | Result |
|---|---|---|
| `main` | `main` | exit 0; existing advisories listed as already present |
| `main` | #51's lockfile | exit 0; nine advisories listed as resolved |
| `main` | `main` before SPARK-60115 (`h2` 0.4.15) | **exit 1**;
RUSTSEC-2026-0258 reported as introduced |
| -- | no arguments / missing file | exit 2 |
| `main` | unparseable lockfile (also tried as base) | exit 2, not a pass |
RUSTSEC-2023-0071 is absent from every report, confirming `.cargo/audit.toml`
is honoured when a lockfile is given with `--file`.
The base-lockfile step (`git fetch --no-tags --depth=1 origin <base sha>`
with
credentials not persisted, then `git show <sha>:Cargo.lock`) was exercised
in a
fresh shallow clone of this repository that did not contain the commit.
This pull request does not change `Cargo.lock`, so its own pull-request check
should report no introduced advisories.
### Was this patch authored or co-authored using generative AI tooling?
Yes, co-authored with Claude Code.
--
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]
