Adom Bridge

The published adom/adom-bridge tarball (also served as adom/adom-desktop, same page pg_0awtv7q479) carries a developer's PRIVATE per-user container hostname. The tarball downloads with NO authentication, so the host is readable by anyone who knows the package name.

Reproduced on the CURRENT version, 2.1.129, today:

curl -sL -A "Mozilla/5.0" \
  https://wiki.adom.inc/api/packages/adom/adom-bridge/2.1.129/tarball -o ab.tgz   # HTTP 200, anonymous
tar xzf ab.tgz -C x
grep -raoE '[a-z]+-[a-z0-9]{10,}\.adom\.cloud' x | wc -l                          # 2

Two occurrences, in two different files, with two different causes:

1. dist/linux/adom-bridge (the compiled binary). A usage example baked into the binary's own strings:

register_container '{"name":"galliaApril","url":"wss://<PRIVATE-CONTAINER-HOST>/proxy/8765/"}'

The host is a named developer's personal container (<handle>-<id>-<id>.adom.cloud), and the example also carries that person's workspace name. This is the one that matters: it is a real private host, it ships inside a compiled artifact, and no package author can see it by reading their source tree.

2. skills/adom-bridge-mesh/SKILL.md. Documents the mesh relay default as https://meshrelay-<id>.adom.cloud/. This one may well be intentional (it reads as a real service-container relay, not a personal box), so treat it as a question rather than a defect: if that relay is meant to be public, it is fine as is; if it is per-deployment, it should be a placeholder or a config value.

Why this is worth fixing rather than ignoring

• It discloses a private per-user container hostname to anonymous downloaders.
• A package author cannot fix it from their side or even notice it: it is inside a compiled binary in a published artifact, not in the repo they review.
• It persists across releases. The same class of leak was reported in July as adom/adom-wiki-cli#17 and is still present two months and many versions later.

Suggested fix

• Replace the example host in register_container's usage text with a placeholder (wss://<your-container-host>/proxy/8765/) and a generic workspace name. An example in help text should never be a real host.
• Add a build-time or publish-time check that fails when a shipped artifact contains a *-<id>.adom.cloud host. That is the backstop that would have caught both this and the July report.

Scope check (so this is not filed wider than it should be)

I swept the current published tarball of every other package I could reach, anonymously, for *.adom.cloud private-shaped hosts and for *.adom.internal: adom/core, adom/adom-cli, adom/adom-lbr, adom/altium-bridge, adom/nameplate-generator, adom/mjpeg-stream-viewer, adom/adom-wiki-skillpack, adom/kicad-bridge, adom/hero-studio. All clean. This package is the only one affected.

Related: adom/adom-wiki-cli#17 (same symptom, different mechanism: that report blamed an injected stale page.json, and no current package I checked ships an injected page.json at all, so that specific path looks resolved). The actual private host in this artifact is compiled into the binary, which is why cleaning the page never cleared it.

The private host is redacted here on purpose, since issues are world-readable. It is a one-line grep to recover locally with the command above.