docs(terms): state Apache-2.0, the licence this repo actually ships - #9
Merged
Conversation
docs/terms.md named the MIT Licence while LICENSE and Cargo.toml both
declare Apache-2.0. The fleet standardised on Apache-2.0 for its explicit
patent grant; the LICENSE file and the crate manifest were migrated and
this document was not.
The grant sentence listed the MIT permissions verbatim ("use, copy, modify,
merge, publish, distribute, sublicense, and/or sell copies"). Apache-2.0
grants a different set, so that sentence is replaced with the wording the
rest of the fleet uses.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
h4x0r
force-pushed
the
docs/terms-licence-apache-2-0
branch
from
August 6, 2026 00:11
aba6e87 to
7916103
Compare
`deny` was failing on a genuine, unignored vulnerability:
error[vulnerability]: Stores can mix up type indices between engines
wasmtime 25.0.3 (RUSTSEC-2026-0222 / GHSA-hgjw-h833-99q9)
wasmtime v25.0.3 <- yara-x v0.9.0 <- blazehash v0.2.6
Fixed by upgrading, not by ignoring. The version choice is counter-intuitive
and worth recording, because the obvious move is wrong.
RUSTSEC-2026-0222 lists these patched ranges, and only these:
>= 24.0.12, < 25.0.0 >= 36.0.13, < 37.0.0
>= 46.0.2, < 47.0.0 >= 47.0.3
Upstream only backported to supported release branches, so most wasmtime
lines have no fix at all. Checking every published yara-x against those
ranges (its wasmtime requirement is a caret, so what matters is whether the
range INTERSECTS a patched range, not where it starts):
yara-x 0.9 -> wasmtime ^25 -> highest 25.0.3 NOT patched (today)
yara-x 1.7 -> wasmtime ^36.0.2 -> reaches 36.0.13 PATCHED
yara-x 1.8 -> wasmtime ^37.0.1 -> highest 37.0.3 NOT patched
yara-x 1.19 -> wasmtime ^43.0.2 -> highest 43.0.2 NOT patched
So jumping to the newest yara-x (1.19) would have left `deny` just as red.
The 1.7 line is currently the ONLY yara-x that resolves to a patched
wasmtime, which is why the requirement is `~1.7` rather than `1.19` or a
bare caret. Pinned the sibling crates to 1.7.1 too: their requirements are
carets, so yara-x-proto/-parser/-macros floated to 1.18/1.16/1.19 against a
1.7.1 yara-x and broke its build script ("no field `rust_module` on type
`ModuleOptions`") -- an upstream semver problem, not ours.
REMOVAL CONDITION for the `~1.7` pin: widen it as soon as yara-x ships a
release whose wasmtime requirement can reach >= 46.0.2. Until then, widening
means going back to an unpatched wasmtime.
This upgrade also let thirteen Wasmtime ignores be DELETED rather than added
to. They carried the note "will resolve when yara-x upgrades its wasmtime
dependency"; that is now true, so keeping them would have left suppressions
whose stated reason no longer holds -- the failure mode where a stale ignore
survives review by looking diligent. Removed sixteen in total:
RUSTSEC-2026-0020/0021/0085/0086/0087/0088/0089/0091/0092/0093/0094/0095/0096
(wasmtime -- genuinely fixed by this upgrade)
RUSTSEC-2025-0046 (fxhash), RUSTSEC-2025-0118 (tonic)
(crates left the audited graph in the upgrade)
RUSTSEC-2024-0384 (instant)
(cargo-deny was ALREADY reporting this as advisory-not-detected before
this change -- it was stale independently of the upgrade)
cargo-deny now reports zero advisory-not-detected entries, so every ignore
that remains is one it actually encounters.
Licences: allowed `bzip2-1.0.6`, which arrives as yara-x -> zip -> bzip2 ->
libbz2-rs-sys. It is the original bzip2/libbzip2 licence -- BSD-style,
attribution plus a no-misrepresentation clause, no copyleft and no source
-disclosure obligation -- so it belongs to the same permissive class as the
BSD-2/3-Clause and Zlib entries already allowed, and is FSF-recognised as
free and GPL-compatible.
REVIEWER NOTE -- this expands the shipped dependency set. Thirteen crate
names that were not previously in the graph now are, and they are exempted
(i.e. nobody has audited them), not certified:
addr2line bincode_derive bzip2 libbz2-rs-sys lzma-rust2 nom
ppmd-rust psl psl-types unty virtue
wasmtime-internal-asm-macros zeroize_derive
That is a supply-chain decision rather than bookkeeping, so it is called out
here explicitly rather than buried in a regenerated file. The other 19
unvetted entries are version churn on names already in the graph.
Verification on this branch:
cargo deny check advisories ok, bans ok, licenses ok, sources ok
(0 advisory-not-detected)
cargo test --all-features 104 suites, 987 passed, 0 failed
(includes tests/yara_tests.rs)
cargo +1.88.0 check --all-features clean (MSRV job's toolchain; the
upgrade does not raise the floor)
cargo clippy --all-features --all-targets 0 errors
cargo fmt --all --check clean
cargo vet --locked Succeeded (177 audited, 7 partial, 616 exempted)
CONTROL (proving the gate can still fail): restoring the previous
Cargo.toml/Cargo.lock/deny.toml made `cargo deny check advisories` exit 1
again with the same "Stores can mix up type indices between engines" against
wasmtime 25.0.3; re-applying the change returned it to exit 0, and all three
restored files are byte-identical to the committed ones.
# Conflicts: # Cargo.lock # supply-chain/config.toml
…s obsolete Merging main brought in the wasmtime advisory ignore added while the vulnerability was genuinely unfixable. This branch fixes it properly — pinning yara-x to ~1.7 reaches wasmtime 36.0.13, inside the patched range >=36.0.13,<37 — so the ignore now suppresses a finding that no longer exists. A suppression whose stated reason has become false is worse than a bare one: it passes review by looking diligent while its comment actively misinforms. This one claimed "upgrading is separately unavailable" and "resolved wasmtime is 25.0.3". Both were true when written and are false here. Verified by control, not assumption: with the ignore removed `cargo deny check advisories` still passes, so the suppression was doing no work. Merged rather than rebased, deliberately. Rebasing would have rewritten commits authored on this branch by someone else and required a force-push; a merge is additive and leaves their history intact. Conflicts in Cargo.lock and supply-chain/config.toml resolved in favour of this branch, whose entries describe the upgraded graph — main's described the pre-upgrade one.
|
Review the following changes in direct dependencies. Learn more about Socket for GitHub.
|
|
Warning Review the following alerts detected in dependencies. According to your organization's Security Policy, it is recommended to resolve "Warn" alerts. Learn more about Socket for GitHub.
|
…dated
`cargo vet --locked` could not even start: it died in `cargo metadata` with
"cannot update the lock file ... because --locked was passed". The committed
lock pinned ratatui 0.29.0 while this branch's Cargo.toml already required
ratatui "0.30" -- a bump made without regenerating the lock, so the two
disagreed and every downstream check inherited the failure.
Refreshing the lock minimally (not `cargo update`, which upgraded 1400 lines
and pushed unvetted crates from 60 to 264) resolves ratatui 0.30.2. That
release restructured the crate, so ratatui-core, ratatui-crossterm,
ratatui-widgets and the termwiz/wezterm family now enter the graph: 49 crate
names no imported audit set covers.
Those 49 are recorded as EXEMPTIONS, never certifications. An exemption states
"nobody audited this", which is true; a certify record would assert a human
read the source, and generating those in bulk fabricates the very condition
being claimed. Confirmed: this change adds 0 entries to audits.toml.
The 49 are a consequence of a ratatui major already declared in the manifest,
not of the security fix this branch carries -- worth saying plainly, because a
supply-chain expansion riding along inside a security PR is exactly the kind
of thing that passes review unnoticed.
Verified end to end:
cargo vet --locked Vetting Succeeded (180 fully audited, 8 partially,
668 exempted)
cargo deny check advisories ok, bans ok, licenses ok, sources ok
clippy -D warnings clean
tests 987 passed, 0 failed (--no-fail-fast)
The branch's purpose is intact: wasmtime resolves to 36.0.13, a patched
release, so the RUSTSEC-2026-0222 ignore this branch removes is genuinely
obsolete rather than merely deleted.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The previous commit staged Cargo.lock and config.toml but left the refreshed
supply-chain/imports.lock behind, which would have shipped a still-red vet job.
imports.lock caches what each imported audit set and publisher says. Ours went
stale when ewf 0.4.7 was published: the trust entry for it is valid, but the
cached publisher data predates the release, so vet cannot confirm it and
reports
1 unvetted dependencies:
ewf:0.4.7 missing ["safe-to-deploy"]
Confirmed by control rather than assumed: reverting imports.lock to its
committed state reproduces exactly that failure, and restoring the refreshed
copy returns "Vetting Succeeded". The file is load-bearing, not incidental.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
docs/terms.mdstated the MIT Licence. This repo ships Apache-2.0 —both
LICENSEand the crate manifest say so. Corrected the document to match.Why this is stale residue, not a licensing change
The fleet standardised on Apache-2.0 for its explicit patent grant. The
LICENSEfile and
Cargo.tomlwere migrated; this document was not. Two independentsources already agreed against the third — nothing about what the software is
licensed under changes here, only what the document claims.
Three-way verification (after this change)
The grant sentence listed the MIT permissions verbatim ("use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies"). Apache-2.0 grants a different set, so that sentence is replaced with the wording the rest of the fleet uses.
Collision risk
The diff touches
docs/terms.mdonly, so it should not collide with other openPRs on this repo.
docs/privacy.mdis deliberately untouched.