noya-cli 0.0.15

Command-line tools for noyalib (noyafmt, noyavalidate)
Documentation 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35

# osv-scanner configuration.
#
# Consumed by:
#   - OpenSSF Scorecard's `Vulnerabilities` check (via osv-scanner)
#   - a local `osv-scanner --config osv-scanner.toml .` run
#
# When to add an ignore entry here:
#   - the advisory is truly informational for our shipped artefacts
#     (build-time-only dep, opt-in feature, no exposure at runtime);
#   - AND the same advisory is already ignored in `deny.toml` under
#     `[advisories.ignore]` with a matching rationale.
#
# The two configs are kept in sync deliberately so a single grep for
# a RUSTSEC ID surfaces every place we've documented our risk
# acceptance. If you remove an entry from `deny.toml`, remove it
# from here too (or the Scorecard alert will re-open).

[[IgnoredVulns]]
id = "RUSTSEC-2026-0173"
# ignoreUntil = "2027-06-01"  # optional — auto-expire the ignore
reason = """
`proc-macro-error2` is unmaintained (author confirmed at
https://github.com/GnomedDev/proc-macro-error-2/issues/17). It
reaches `noyalib` at build time via `validator_derive → validator`,
which is behind the OPT-IN `validator` cargo feature (not in the
default set). No maintained drop-in exists yet as of 2026-07-01:
`validator` 0.20 (released 2025-01-20) still depends on
proc-macro-error2, and `manyhow` / `proc-macro2-diagnostics` have
not been adopted upstream. The dep never ships in a release
artefact — it exists only in the proc-macro macro-expansion phase
of a downstream user who explicitly enabled the `validator` feature.
Ignored here so Scorecard's Vulnerabilities check does not flag it;
kept in lockstep with `deny.toml`'s `[advisories.ignore]` entry.
Revisit when `validator` cuts a release that drops proc-macro-error2.
"""