peer: refuse to start if launch_cfg lacks abuse-handling rules

[myleshorton]

Summary

Defence-in-depth for Share My Connection abuse handling. Refuses to start the peer sing-box if the server-supplied launch_cfg is missing the expected abuse rule_set / reject rules.

Why this matters: Phase 1 SmC abuse handling lives entirely in the sing-box JSON that lantern-cloud sends back from /v1/peer/register (see pcfg/samizdat.go — abuseRejectRules + abuseRemoteRuleSets + peerEgressBlockRules). The peer client currently hands that JSON straight to libbox after one VPN-bypass tweak. A regression in samizdat.go that ever shipped a launch_cfg without those rules would turn every newly-registered peer into an open residential proxy until someone noticed.

How the check works

sequenceDiagram
    autonumber
    participant LC as lantern-cloud<br/>pcfg/samizdat.go
    participant P  as peer.Client.Start<br/>radiance/peer/peer.go:187
    participant V  as validateAbuseRules<br/>radiance/peer/validate.go ✨
    participant LB as libbox.NewServiceWithContext

    P->>LC: POST /v1/peer/register
    LC-->>P: launch_cfg JSON (with abuse rules)
    P->>V: peer/peer.go:202<br/>validateAbuseRules(regResp.ServerConfig) ✨
    Note over V: parse route.rule_set + route.rules<br/>assert 4× abuse tags present in both<br/>assert RFC1918 + SMTP canary rejects
    rect rgba(180, 230, 200, 0.3)
        alt Happy path — rules intact
            V-->>P: nil
            P->>LB: build + start sing-box
        else Server-side regression — rules missing
            V-->>P: errors.Join(missing tags, missing canaries)
            Note over P: Start returns error,<br/>peer refuses to share
        end
    end

Loading

The check is purely structural and permissive about sing-box's JSON shape (it marshals "default" rules in both inlined and {"type":"default","default":{...}} forms — TestValidateAbuseRules_NestedDefaultForm covers both).

What it asserts

1. Abuse rule_set tags present in route.rule_set: geosite-malware, geoip-malware, geosite-phishing, geosite-cryptominers. The canonical list mirrors abuseTags in lantern-cloud/cmd/api/pcfg/samizdat.go.
2. Matching reject rule for each tag in route.rules. A rule_set without a reject rule is a no-op — sing-box downloads the list and never enforces it.
3. Static reject canaries: one entry from each block in peerEgressBlockRules — 10.0.0.0/8 (RFC1918 canary) and port 25 (SMTP canary). Spot-check rather than full enumeration so legitimate additions in samizdat.go don't break this check.

What it does NOT cover

• The .srs files at the rule_set URLs (could be corrupted/tampered)
• The trustworthiness of the rule_set URLs themselves (currently Chocolate4U on GitHub raw — single point of trust, tracked separately)
• Behaviour while the rule_set is being downloaded for the first time (sing-box fails open during that window — separate concern, see audit notes)
• Volumetric / rate-limit abuse (explicitly deferred to engineering#3443)

These are flagged in the audit notes but are out of scope for a structural-validation PR.

Errors are joined, not first-failure

errors.Join means a thoroughly broken config (e.g. someone accidentally deleted half of samizdat.go's route block) surfaces every missing piece in one error report. Whoever is triaging "why won't my peer start?" doesn't have to fix-one-thing-find-the-next.

launch_cfg failed abuse-rule sanity check:
  route.rule_set is missing abuse tags: [geosite-malware geoip-malware]
  route.rules has no reject action for abuse tags: [geosite-malware geoip-malware]
  route.rules is missing static abuse blocks: [RFC1918 reject (canary 10.0.0.0/8) SMTP-port reject (canary :25)]

Keeping the validator in sync with the server

abuseRuleSetTags in this PR mirrors abuseTags in lantern-cloud/cmd/api/pcfg/samizdat.go. If samizdat.go grows or renames a tag, this list grows with it. A future test that exercises an actual lantern-cloud-generated launch_cfg through validateAbuseRules would close the drift gap entirely — left as follow-up since it spans two modules.

Test plan

• go test ./peer/ -count=1 — full peer test suite green
• go test ./peer/ -run TestValidateAbuseRules -v — 10/10 validator unit tests pass
  • happy path
  • nested-default JSON form
  • missing route block
  • missing abuse rule_set tag
  • missing abuse reject rule
  • missing RFC1918 canary
  • missing SMTP canary
  • non-reject action ignored (e.g. route instead of reject)
  • all errors joined when multiple checks fail
  • malformed JSON
• Existing stubServer fixture updated to minimalValidLaunchCfg — no peer test regressions.
• (Follow-up) Cross-module test: feed an actual pcfg.GenerateSamizdat output through validateAbuseRules to catch drift between the two files.

[Copilot]

Pull request overview

Adds a peer-side safety gate that validates the server-supplied sing-box config before starting Share My Connection, so peers refuse configs missing abuse-blocking structure.

Changes:

• Adds validateAbuseRules and unit tests for required abuse rule sets, reject rules, and static canaries.
• Calls the validator during Client.Start before patching and starting sing-box.
• Updates peer test fixtures to use a config that passes the new validation.

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 10 comments.

File	Description
peer/validate.go	New structural validator for peer launch config abuse-blocking rules.
peer/validate_test.go	Unit tests and shared minimal valid launch config fixture.
peer/peer.go	Invokes abuse-rule validation during peer startup.
peer/peer_test.go	Updates stub registration response to include valid abuse-rule config.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Pull request overview

Copilot reviewed 4 out of 4 changed files in this pull request and generated no new comments.