osv-scanner.toml
Rama master · réplica de lectura del repositorio original.
# Configuration for github.com/google/osv-scanner
#
# Documented ignores for advisories where a version bump is not viable today.
# Each entry MUST include a reason and SHOULD include an ignoreUntil date so we
# get reminded to re-evaluate. When the underlying crate gets a fix or a viable
# replacement, drop the corresponding entry.
[[IgnoredVulns]]
id = "RUSTSEC-2024-0436"
ignoreUntil = "2026-12-31T00:00:00Z"
reason = """
paste 1.0.15 is unmaintained but only pulled transitively by
tikv-jemalloc-ctl (jemalloc feature on hook0-api) and pprof_util
(profiling feature, disabled by default). No first-party code uses
paste. Migration to pastey (drop-in fork) depends on tikv-jemallocator
upstream — tracked at https://github.com/tikv/jemallocator/issues
"""
[[IgnoredVulns]]
id = "RUSTSEC-2024-0449"
ignoreUntil = "2026-12-31T00:00:00Z"
reason = """
unsafe-libyaml 0.2.11 is unmaintained (repository archived), with no known
vulnerability attached to the advisory. It reaches Cargo.lock only through
serde_yaml 0.9, which the OpenAPI spec generator used by hook0-api requires
unconditionally, including in its latest release, so no version bump or
feature flag removes it. No first-party code parses YAML: the spec is built
from Rust types and served as JSON at /api/v1/swagger.json, so the c2rust
parser never sees external input. Drop this entry once the generator moves
to a maintained YAML crate or is replaced.
"""
# Two migrations this file was waiting on have landed, and their entries are gone
# with the crates that needed them: `validator` is at 0.21.0, which dropped the
# five `unic-*` crates (RUSTSEC-2025-0075, -0080, -0081, -0098, -0101), and
# `hickory-proto` is at 0.26.1, which is the bump RUSTSEC-2026-0118 and -0119
# were deferred against. `rsa` (RUSTSEC-2023-0071) came in through `sqlx-mysql`
# and is no longer in `Cargo.lock` at all. Each was removed after checking the
# lockfile, which is the authority on whether a vulnerable version has actually
# left the tree — see the note at the bottom of this file.
# The three rustls-webpki 0.101.7 entries (RUSTSEC-2026-0098, -0099, -0104) are gone with the
# legacy TLS stack that carried them. aws-sdk-s3's default `rustls` feature compiled in rustls 0.21
# beside the stack the S3 clients actually use; api/Cargo.toml and output-worker/Cargo.toml now
# declare aws-sdk-s3 with `default-features = false` and keep only `default-https-client`
# (rustls 0.23 over rustls-webpki 0.103). Both members must keep that feature list: a single
# member asking for the default feature set brings rustls 0.21, rustls-webpki 0.101, hyper 0.14
# and hyper-rustls 0.24 back for the whole workspace, along with the rustls advisories that have
# no 0.21.x fix (RUSTSEC-2026-0346, -0349).
[[IgnoredVulns]]
id = "RUSTSEC-2026-0387"
ignoreUntil = "2026-12-31T00:00:00Z"
reason = """
crypto-bigint 0.5.5 (constant-time timing variability, fixed in 0.7.6) is the
copy pinned by elliptic-curve 0.13 / p256 0.13 (biscuit-auth) and by aws-sigv4
(sigv4a). No 0.5.x or 0.7.x release is semver-compatible with those parents, so
the fix is not reachable by a lockfile bump. The 0.7.x copy in Cargo.lock is
already on 0.7.6. Biscuit keys are Ed25519 (api/src/main.rs), so the p256 path is
never exercised for signing; sigv4a only signs outgoing S3 requests with no
attacker-observable timing channel. Drop this entry once biscuit-auth and the
AWS SDK move to elliptic-curve 0.14 / a patched crypto-bigint.
"""
[[IgnoredVulns]]
id = "RUSTSEC-2026-0173"
ignoreUntil = "2026-12-31T00:00:00Z"
reason = """
proc-macro-error2 2.0.1 is an "unmaintained" informational advisory (no code
vulnerability, patched = []). It is a compile-time proc-macro dependency only,
pulled transitively by biscuit-quote (biscuit-auth) and paperclip-macros
(paperclip); no proc-macro-error2 code ships in the running binary. No fix
version exists; removal depends on biscuit-auth and paperclip upstreams
migrating off it. Tracked.
"""
# The two image-size entries that stood here (GHSA-5p2g-fcmc-qvqq,
# GHSA-w3rx-r6r6-pgpr) are gone: image-size was bumped 2.0.2 -> 2.0.4 in
# documentation/package-lock.json, past the 2.0.3 fix line of both advisories, so
# neither matches a package in the tree anymore. The scanner surfaced them as
# unused ignores and the lockfile confirmed the removal — same procedure as the
# RUSTSEC-2026-0253 note below.
# The two npm entries that stood here (GHSA-vfj7-8cjw-p6xm, GHSA-ch52-4w7c-c8xp)
# are gone. The braces advisory was withdrawn upstream on 2026-10-23, so it matches
# nothing even though braces 3.0.3 is still locked in documentation/, frontend/ and
# website/. documentation/package-lock.json now resolves http-cache-semantics 4.3.0,
# past the 4.2.0 last affected version. The scanner listed both as unused ignores.
[[IgnoredVulns]]
id = "RUSTSEC-2026-0258"
ignoreUntil = "2026-11-30T00:00:00Z"
reason = """
h2 0.3.27: empty HTTP/2 DATA frames are queued without limit, so a stream nobody drains grows
memory without bound, or panics if the length overflows. Low severity upstream.
The fix is 0.4.16 and no 0.3 release carries it: 0.3.27 is the last of that line on crates.io. The
0.4 copies the same advisory covers are on the patched 0.4 line in this lockfile and in smoke/languages/rust, so
they are patched rather than ignored, and reqwest, which sends every webhook and every other
outbound call, is on that line.
The 0.3.27 copy is reachable only through actix-http 3, the API server, and is not exposed there.
actix-web 4 negotiates HTTP/2 only over ALPN under bind_rustls / bind_openssl, or in cleartext under
an explicit bind_auto_h2c. None of the three appears anywhere in api/src: the server binds plaintext
TCP with TLS terminated upstream, so the frame reader this advisory is about is compiled in and
never entered. (The S3 client's hyper 0.14 path to this copy left with the legacy TLS stack above.)
It moves when actix-http moves to the 0.4 line, which means actix-web 5, unreleased. If hook0-api
ever starts terminating TLS itself, drop this entry and reassess the exposure first: the reasoning
above rests on the process never speaking HTTP/2.
"""
[[IgnoredVulns]]
id = "GHSA-gcqx-w48m-w2h4"
ignoreUntil = "2026-12-31T00:00:00Z"
reason = """
deepmerge 4.3.1 (CVE-2026-93753): mergeObject() lets a `__proto__` key in a source object set the
prototype of the object merge() returns, when the target is a null-prototype object or holds a null
placeholder. The record covers 4.2.0 through 4.3.1 and lists no fixed version, and none exists:
4.3.1, published 2023-03-16, is the latest release, the maintainer closed the upstream report
(TehShrike/deepmerge#273) on 2026-10-02 with a reply that he would not spend time on it, and the
fix proposed there (PR #274) was closed unmerged. No parent offers a way out either:
@svgr/plugin-svgo 8.1.0 and jest-config 30.5.2 are each the latest release and each asks for
^4.3.1.
Both copies are unreachable:
- documentation/package-lock.json, via @docusaurus/preset-classic -> @docusaurus/plugin-svgr ->
@svgr/webpack -> @svgr/plugin-svgo. That package declares deepmerge in its manifest and never
requires it: its published dist/index.js loads only svgo and cosmiconfig, and no source file in
the installed tree requires deepmerge outside its own directory (only manifests name it). A
`docusaurus build` run with a require hook on the module name loaded it in none of the seven
node processes it started.
- frontend/package-lock.json (dev), via jest -> @jest/core -> jest-config. jest-config requires it
lazily at two call sites: the exported mergeConfig() helper, which nothing in frontend/ calls,
and the preset step, which merges `globals` only when both the project config and the preset set
one. jest.config.cjs sets a preset and no `globals`. The same hook over a whole `npm run test`
run (22 suites, 314 tests, 14 node processes) never loaded the module. The copy is dev-only:
jest-config is its only dependent in the tree, so nothing the vite bundle imports reaches it,
and the image carries only that bundle.
Where deepmerge did run, the trigger would still be missing. The advisory needs an attacker to
supply the JSON that gets merged in, and the only inputs here are configuration files committed to
this repository, read at build or test time in CI, never a request body.
Drop this entry once deepmerge publishes a release past 4.3.1 and both lockfiles resolve it, or once
the advisory is disputed or withdrawn upstream; the scanner then lists it as unused. It matches by
id, so it would also hide a deepmerge copy that a lockfile gains later: documentation/ and
frontend/ hold the only two today (tests-api-integrations/, tests-e2e/ and website/ hold none), so
check that before extending ignoreUntil.
Verified 2026-10-28 against the npm registry, the advisory and both lockfiles.
"""
# Reading the scanner's "unused ignores" list.
#
# osv-scanner v2.6.0 reports that list accurately: an id appears there only when
# no finding matched it on this run. That is the signal an entry has gone dead —
# the vulnerable version has left the tree — and the entry should then be dropped.
# RUSTSEC-2026-0253 was removed for exactly this reason: aws-sdk-s3 1.147.0
# relaxed its `lru` requirement and pulled 0.18.4, past the 0.18.2 fix line, so no
# affected 0.16.x copy remains in Cargo.lock.
#
# Earlier versions of the scanner (through v2.3.0) could not be read this way: a
# MarkAsUsed bug flagged every entry as unused regardless, so the lockfile — not
# the list — had to be the authority. v2.6.0 fixes that, but the lockfile check is
# still worth doing: a live entry prints a `<id> has been filtered out because:`
# line, a dead one has its crate (or the affected version range) absent from
# Cargo.lock. Both were checked before RUSTSEC-2026-0253 was removed.
#
# An unused ignore is a warning only: it does not fail the scan (the run stays
# exit 0). Removing the dead entry just keeps that warning from accumulating.
[[IgnoredVulns]]
id = "GHSA-3g3m-2fjr-6pw4"
ignoreUntil = "2026-12-31T00:00:00Z"
reason = """
glob 10.x/13.x is pulled only by build and lint tooling in the npm
workspaces (documentation, frontend), never shipped in a runtime artefact. The
advisory (an aborted async walk keeps reading directories) is only reachable
by a caller that passes an AbortSignal, and the fix is the 14.x major, which
the parents (eslint, vite and docusaurus toolchains) do not accept yet.
Drop this entry once the toolchains allow glob 14.
"""
[[IgnoredVulns]]
id = "GHSA-g3hv-75wg-m249"
ignoreUntil = "2026-12-31T00:00:00Z"
reason = """
minimatch 3.x, 5.x, 9.x and 10.x are pulled by build and lint tooling in the
npm workspaces (documentation, frontend, website) and are only fed glob
patterns written in this repository, never attacker-controlled input. The fix
is the 11.x major, which no parent in the dependency tree accepts yet. Drop
this entry once the toolchains allow minimatch 11.
"""