verify-sanitized.sh: identity denylist does not cover private-network topology (RFC1918) — gate gap surfaced by #1320 #1321

Open
opened 2026-08-19 20:53:52 +00:00 by fargo · 0 comments
Member

From the #1320 review chain (rev-security-01 verdict, comment 23282): the sanitization gate's denylist catches operator identity tokens but not private-network addresses, so the estate RFC1918 endpoints that shipped inside folded skills and tools docs (10.1.1.x Portainer/Docker/Gitea/Coolify values) would regress silently — the gate has no rule that sees them.

Content was cleaned in the #1320 remediation (see that issue and its PR); this issue is the GATE defect on its own, filed separately so it has an owner rather than riding inside a content PR.

Scope for whoever takes it:

  • Detection: RFC1918 ranges (10/8, 172.16/12, 192.168/16) across the same file set the identity scan covers.
  • Carve-outs needed: RFC 5737 documentation ranges (192.0.2.0/24, 198.51.100.0/24, 203.0.113.0/24) so examples can use documentation addresses; consider 127.0.0.1 and link-local 169.254/16; decide whether example.internal / .example hostnames are the blessed DNS placeholder (the #1320 remediation used both *.example.internal and RFC5737).
  • Boundary case to encode: guides/INFRASTRUCTURE.md's cloudflare record-update example previously used 10.0.0.5 as a generic example value (not estate topology) — resolved by moving it to 192.0.2.5. A bare RFC1918 ban would have flagged it; the carve-out design should make the blessed pattern obvious.
  • Self-test additions in the gate's own style (planted-file with an RFC1918 address must fail; planted RFC5737 must pass).

Cross-ref: content issue #1320.

From the #1320 review chain (rev-security-01 verdict, comment 23282): the sanitization gate's denylist catches operator identity tokens but not private-network addresses, so the estate RFC1918 endpoints that shipped inside folded skills and tools docs (`10.1.1.x` Portainer/Docker/Gitea/Coolify values) would regress silently — the gate has no rule that sees them. Content was cleaned in the #1320 remediation (see that issue and its PR); this issue is the GATE defect on its own, filed separately so it has an owner rather than riding inside a content PR. Scope for whoever takes it: - Detection: RFC1918 ranges (10/8, 172.16/12, 192.168/16) across the same file set the identity scan covers. - Carve-outs needed: RFC 5737 documentation ranges (192.0.2.0/24, 198.51.100.0/24, 203.0.113.0/24) so examples can use documentation addresses; consider 127.0.0.1 and link-local 169.254/16; decide whether example.internal / .example hostnames are the blessed DNS placeholder (the #1320 remediation used both `*.example.internal` and RFC5737). - Boundary case to encode: guides/INFRASTRUCTURE.md's cloudflare record-update example previously used `10.0.0.5` as a generic example value (not estate topology) — resolved by moving it to `192.0.2.5`. A bare RFC1918 ban would have flagged it; the carve-out design should make the blessed pattern obvious. - Self-test additions in the gate's own style (planted-file with an RFC1918 address must fail; planted RFC5737 must pass). Cross-ref: content issue #1320.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: mosaicstack/stack#1321