Repository navigation
fix(OMN-14162): drop hardcoded LAN Kafka default from master env template - #2239
Merged
Merged
Conversation
📝 WalkthroughWalkthroughThe Kafka bootstrap servers template setting in docs/env-master-template.env was changed from a hardcoded LAN IP default to an empty required value, with added comments explaining LAN vs. off-network broker address usage. ChangesKafka env template documentation
Estimated code review effort: 1 (Trivial) | ~2 minutes 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Comment |
…S in master env template The master env template hardcoded KAFKA_BOOTSTRAP_SERVERS=192.168.86.201:19092 as the value for omniclaude/omniintelligence/omnidash/omnimemory/omnimarket to copy into a working .env. 192.168.86.201 is a LAN address, unroutable off-network — copying this template while traveling silently points local skill-dispatch at an unreachable broker. Blank the default (fail-fast, matching the existing pattern in omniclaude/.env.example and kafka_publisher_base.get_kafka_bootstrap_servers() per OMN-7227) and document both the on-LAN and Tailscale broker addresses in a comment so operators pick the one that matches their network.
jonahgabriel
force-pushed
the
jonah/omn-14162-kafka-tailscale-bootstrap
branch
from
July 9, 2026 02:28
8318e1d to
c468280
Compare
This was referenced Aug 31, 2026
jonahgabriel
added a commit
that referenced
this pull request
Aug 31, 2026
…lic repo (#3074) OMN-17288 scrubbed a live tenant slug out of five files in this repo (#3062, 3f10ee5) and established a synthetic-identifier convention in its place. Three hours later an unrelated lane reintroduced the same slug in omnimarket (#2239), and the rebase carried it onto omnimarket#2241 -- the PR whose own acceptance criterion was "zero grep hits" -- with every enforced gate green. Nothing in either repo was looking. The convention was documentation, and documentation lost a race in three hours. Operating Rule #5: detection that is not a gate gets ignored. Why digests and not a plaintext pattern list: this repo is PUBLIC. Writing a forbidden customer identifier into a pattern file here would create exactly the fresh, greppable, current-tree occurrence the class exists to prevent, and would force that file to be exempt from its own rule -- a special file holding the forbidden value, that nobody scans and that people copy from. That is the shape of the incident, not a fix for it. Entries are salted SHA-256 plus a class label and owning ticket; the loader refuses to load an entry carrying a value/literal/ plaintext field. The salt is committed, so this is obfuscation and not secrecy, and that is stated in the file rather than implied: the OMN-17288 values are already public in git history and the operator ruled document-and-accept on that history. What the format buys is FORWARD safety -- the next entry may be a live identifier that has NOT leaked, where a plaintext denylist would be an active disclosure. Matching windows inside each identifier token, so a literal is caught bare, embedded (tenant_<slug>_v2), and inside a path or URL segment. Findings print path:line:col plus match length and entry id, never the value. Encoded forms are deliberately NOT decoded -- OMN-17180 owns that class, and claiming coverage here would be a false claim. One escape hatch, per line, ticket + reason required: # onex-allow-exposed-identifier OMN-XXXXX reason="<concrete reason>" A bare annotation is rejected, matching every other onex-allow class. There is deliberately NO file-level waiver and NO self-exempt file: a whole-file waiver is how a forbidden value survives in a corner nobody reads. The gate is subject to its own rule. Wired in this same PR on both surfaces (Rule #5): - pre-commit hook `exposed-identifier-gate` - CI job `Exposed Identifier Gate (OMN-17320)` in ci.yml, registered in scripts/ci/ci_summary_gate.py::STRICT_GATE_JOBS. That registration is half the mechanism: dev requires exactly one context (CI Summary), and while the default-deny sweep already fails on a FAILING job, an unregistered job that is skipped or deleted yields SUCCESS -- so without it, removing this job would silently restore the unenforced state that produced the recurrence. Evidence: - Incident replay (OMN-15547 convention) over the real pre-scrub artifact, captured from git object 6527db3 (= 3f10ee5^). ONE same-length redaction of the slug, recorded in registry.yaml with the pre-redaction sha256 so the git object can be re-fetched and diffed; every other byte of the 8455 is verbatim and offsets are preserved, so the finding is asserted at the slug's real position (line 7, col 379). An accept-control in the same module requires the SHIPPED denylist to PASS those same bytes, so a reject-everything guard cannot satisfy the case. - Non-vacuity of all five real entries proven OUT OF TREE (committed tests cannot carry this without defeating the gate's own rule): pre-scrub content extracted from git objects identifies the slug, slug-body, uuid and uuid-prefix entries by digest, and the uuid-hex entry is confirmed by transforming the recovered UUID. Scanner exit 1 with 15 findings across bare/embedded/path-segment forms. - 29 tests pass; full-tree scan clean. Ticket: OMN-17320
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.
Evidence-Source: OCC#3738
Evidence-Ticket: OMN-14162
Summary
OMN-14162: local skill-dispatch Kafka bootstrap was pointed at a LAN-only default via
omnibase_infra/docs/env-master-template.env, which every consuming repo (omniclaude, omniintelligence, omnidash, omnimemory, omnimarket) is documented to copy for local.envsetup.docs/env-master-template.env:28hardcodedKAFKA_BOOTSTRAP_SERVERS=192.168.86.201:19092.192.168.86.201is a LAN IP, unroutable off-network — copying this template while traveling silently breaks local dispatch with no error until the Kafka client times out.192.168.86.201:19092100.109.203.94:39092(omninode-pc.tail75df5e.ts.net:39092)This matches the repo's existing fail-fast convention — every real (non-doc) call site already reads
KAFKA_BOOTSTRAP_SERVERSfrom the environment with no default (kafka_publisher_base.get_kafka_bootstrap_servers()explicitly removed alocalhostdefault under OMN-7227 "to prevent silent local connections";omniclaude/.env.examplealready ships withKAFKA_BOOTSTRAP_SERVERS=blank). The only actual defect was this doc template presenting a LAN IP as the value to copy in.Scope: this repo's docker-compose files and the
.201-server advertise-listener defaults (docker-compose.generated.yml,catalog/services/redpanda.yaml) legitimately hardcode192.168.86.201for container/advertise addressing and are untouched — they're not part of the local-macOS skill-dispatch bootstrap path this ticket targets.Test plan
bash scripts/validation/check_kafka_no_hardcoded_fallback.sh— passes (this hook only scans.py/.sh/.yaml/.yml; confirms no functional Kafka-fallback gate regresses)pre-commit run --files docs/env-master-template.env— all applicable hooks passscripts/validate_env.pyalready treatsKAFKA_BOOTSTRAP_SERVERSas conditionally-required (not defaulted), so blanking the template value doesn't change validator behaviordocs/env-master-template.envprogrammatically (grep -rl env-master-template) — it's a manual copy-and-edit doc, so CI/docker/.201-server paths are unaffectedSummary by CodeRabbit