mux: tarball install removes the working npm layout before the download is verified
- Dominant language
- HCL
- Stars
- 79
- Forks
- 161
- Avg merge
- 1d 10h
- Merged PRs (30d)
- 38
Description
Follow-up from https://github.com/coder/registry/pull/1095 (review thread https://github.com/coder/registry/pull/1095#discussion_r3928942904).
In `scripts/install.sh.tftpl`, the tarball branch runs `rm -rf "$NPM_WORKDIR"` (the `npm/` layout) before it fetches the registry metadata or downloads the replacement archive. #1095 introduced this so only one layout exists at a time and the installed version is always read from the active one. The order is wrong for the failure case: if a cached package-manager install has to be replaced through the tarball path (for example the workspace image lost its package manager) and the registry is unavailable, the script exits after deleting the working install and leaves `$MUX_BINARY` dangling.
Proposed change: download and extract the tarball into a temporary directory first, verify the binary, then switch the layout (move `.mux-package` into place, repoint the `mux` symlink) and remove `npm/` last. The package-manager branch has the mirror-image ordering (`rm -rf .mux-package` before `npm install`) and should get the same treatment, although there the tarball layout is far less likely to be the one that is lost.
> Xum acted on behalf of @ibetitsmike when filing this issue.
Contributor guide
Assessment
This issue has not been assessed yet.