0.3.2 fails signature verification on pkg install/update: refusing to install (package un-updatable)

Overview Files Skills Discover Packages Releases Dependencies Issues7 Breadcrumbs Pull Requests Activity

Closed bug report

John Lauer · 3mo ago ·closed by barrett-land

During a routine adom-wiki pkg update (2026-08-14, Linux cloud container), this package was refused:

warning [SCRIPT_FAILED]: adom/rustdesk-bridge: install script failed -- skipped
(signature verification FAILED for adom/[email protected]: refusing to install)

The refusal is the gate working as designed, but the effect is that 0.3.2 is un-updatable for every consumer until the artifact is re-signed (or the registry's signature record is repaired). Repro: adom-wiki pkg install adom/rustdesk-bridge from any container.

Environment: adom-wiki 1.6.0, Linux cloud container (Hydrogen Cloud), Adom Bridge 2.0.33 on the connected machines. Reported while updating to ab 2.0.33; the rest of the update succeeded.

2 Replies

barrett-land · 2mo ago

Fixed in 0.3.3, published just now. adom-wiki pkg verify adom/rustdesk-bridge is clean:

v0.3.3 | integrity: ok | signature: ok | verified: true

On the cause: it was not a key rotation. 0.3.2's tarball integrity hash matched fine — only the Ed25519 signature failed, against the same signing_key_id (fa82062fd5524493) that every other package on the registry verifies against today. I checked a spread of packages signed with that same key (adom-bridge, pup-bridge, adom-lbr, kicad, instapcb) and they all verify, so 0.3.2 picked up a bad signature at publish time rather than the pinned key moving. A plain republish re-signs and clears it.

Two rename stragglers fixed in the same publish, since this package had never been swept:

package.json / page.json still declared the retired slug: adom-desktop-rustdesk-bridge and requires: ["adom-desktop"] — now rustdesk-bridge / adom-bridge.
bridge.json updateManifestUrl, metadata.activate.bridgeManifestUrl and the release-manifest url all pointed at retired paths. I measured these rather than assuming: they currently 301 rather than hard-fail, so this was latent, not live breakage — but a client that does not follow redirects would have broken on it. All now point at /rustdesk-bridge/.

Left alone deliberately: metadata.activate.kind is still the literal "adom-desktop-bridge". The current SDK has no metadata.activate concept at all and its kind means something different (python | node | exe | external-http), so I could not confirm what still reads this legacy field and did not want to invent a value for it. Worth deciding whether the whole metadata.activate block should just be dropped, as adom/kicad-bridge has already done.

Unrelated, noticed while publishing: the linter reports HERO_NOT_IN_FILES — hero.png is declared as docs/hero.png but the files[] allowlist does not match it, so the hero never ships in the tarball. That is very likely the root cause of #46 (cropped bridge-card hero): it is not that the hero is the wrong aspect, it is that there is no hero in the package at all, so the card falls back to the OG social card. Noted on that issue.

barrett-land closed this · 2mo ago

John Lauer · 2mo ago

Confirmed from a second container: adom-wiki pkg verify adom/rustdesk-bridge returns verified: true on 0.3.3, and the next pkg update here should no longer skip it. Thanks for the cause writeup; the integrity-ok-but-signature-bad distinction is a useful tell for the next one of these.