Skip to content

Configuring Rules and Weights

TrustSight exposes two configuration files. Together they control which rules fire, how much each signal contributes to the score, and how evidence tiers are weighted.

Configuration files

File Purpose
rules.toml Definitions for the R-series regex rules and the [[structural]] recipe rules: pattern, severity, target, and scope
config.toml Global scoring parameters: severity_weights, source_bucket_weights, novelty_weights

Both files live in the TrustSight config directory and are read automatically on every run.

Rule namespaces

TrustSight has several rule families. Only the non-FATAL rules defined in rules.toml accept the per-rule controls described below.

Namespace Location Editable Description
R-series (37 rules) rules.toml Non-FATAL rules only Regex detection rules for PKGBUILD pattern matching. [rules.R###] controls in config.toml set enabled and weight_override. Every R rule has a TOML definition, so every R rule reads these controls.
H-series (103 rules) Code only No Heuristics needing diff context a single regex cannot see. They have no rules.toml entry and do not read [rules.H###] controls.
C-series (C001-C032) Code only No Structural invariants : checksum/source coherence and related diff anomalies. These cannot be disabled through rules.toml.

The C-series enforce invariants that the detection rules depend on. They fire automatically and their contribution is built into the scoring model. If you need to adjust their impact, modify the evidence tier weights in config.toml rather than trying to suppress them.

Per-rule controls in config.toml

[rules.R007]
enabled = true
weight_override = 15     # default severity weight

[rules.R010]
enabled = false

enabled and weight_override are read from config.toml; they do not change a rule's TOML definition. FATAL rules cannot be disabled; a weight override on one still has no visible effect because the shipped FATAL weight is 0 and the FATAL signal rides the verdict label and the unsuppressible entry in score_breakdown instead of the number. Code-emitted rules have their own configuration paths where provided, such as [code_rules]; [rules.R###] does not control them. Always re-run benchmarks after changing an effective weight.

Structural rules

rules.toml also accepts a [[structural]] array: rules that ask the typed recipe instead of matching a diff line. They use the same [rules.R###] enabled and weight_override controls, and their findings score like any other rule, capped at HIGH.

[[structural]]
id = "R900"
field = "source"
match = "host_added"
pattern = "^(.*\\.)?example\\.com$"
severity = "MEDIUM"

The primitive list, what a partial diff means, and the cap rationale are in Recipe-Targeted User Rules.

Adjusting scoring parameters in config.toml

[severity_weights]
FATAL = 0
CRITICAL = 40
HIGH = 25
MEDIUM = 15
LOW = 5
INFO = 0

[source_bucket_weights]
trusted_forge = 0
official = 0
raw_hosting = 15
unknown = 20
homograph_attack = 30

There is no block for verification or pinning. Declared checksums, PGP keys, GPG sources and source pins are reported as weight-0 P001-P009 (P004 skipped) findings and cannot be given a weight: a signal an attacker can assert for free must not be able to move a score. See B10.

Re-baselining after changes

Any change to weights or rules invalidates the current baseline. Scores will shift; packages that were Low may become High and vice versa.

After editing rules.toml or config.toml:

  1. Run trustsight review --record against your full package set. The --record flag matters: without it the run is read-only and writes no analysis history, so there is nothing to compare later runs against.
  2. Review the new score distribution.
  3. If the new baseline is acceptable, persist it with the re-baselining workflow.

Warnings

Changing weights changes scores. A small adjustment to MEDIUM from 15 to 17 shifts every package that fires a MEDIUM rule. Always validate against your package set before committing config changes.

Only TOML-defined non-FATAL rules accept [rules.R###] controls. C-series and code-emitted rules cannot be disabled or reweighted that way. Their logic is structural or programmatic and requires the documented dedicated setting, if one exists, or a code change.

See also