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 every R-series regex rule: 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 (36 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 (97 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-C009) | 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, and their score hard-stops at 100, so a weight override has no effect. Code-emitted rules have their own configuration paths where provided, such as [experimental_rules]; [rules.R###] does not control them. Always re-run benchmarks after changing an effective weight.
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-P008 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:
- Run
trustsight reviewagainst your full package set. - Review the new score distribution.
- If the new baseline is acceptable, persist it with the re-baselining workflow.
Warnings¶
Changing weights changes scores. A small adjustment to
MEDIUMfrom 10 to 12 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¶
- Config reference: full schema for both files.
- Rules reference: per-rule defaults across the complete R/H/C/D/S/X catalog.
- Tuning false positives: how to fix rules that over-fire on your packages.