Found during the v0.8.8 release review (CTO + Tech Lead, P2 deferred).
install.ps1 performs no SHA256/signature verification of the downloaded release archive before Expand-Archive; integrity relies entirely on HTTPS to github.com. The same gap applies to the Windows self-upgrade path (upgradePowershell does irm | iex of the same unverified script). A compromised release asset, a TLS-defeating MITM, or a release-pipeline mistake would be silently extracted and executed as altimate.exe.
This matches the existing bash-installer posture (the script comment is honest about it), so it is deferred — the real fix is release-side, then verify in both installers:
- Release workflow publishes a
checksums.txt (ideally a cosign/minisign signature) per release asset.
- Both
install.ps1 and the bash install verify the downloaded archive's SHA256 against it before extraction.
Deferred because it requires release-pipeline + signing design work, not an in-repo patch, and does not regress the already-shipping bash posture.
Found during the v0.8.8 release review (CTO + Tech Lead, P2 deferred).
install.ps1performs no SHA256/signature verification of the downloaded release archive beforeExpand-Archive; integrity relies entirely on HTTPS to github.com. The same gap applies to the Windows self-upgrade path (upgradePowershelldoesirm | iexof the same unverified script). A compromised release asset, a TLS-defeating MITM, or a release-pipeline mistake would be silently extracted and executed asaltimate.exe.This matches the existing bash-installer posture (the script comment is honest about it), so it is deferred — the real fix is release-side, then verify in both installers:
checksums.txt(ideally a cosign/minisign signature) per release asset.install.ps1and the bashinstallverify the downloaded archive's SHA256 against it before extraction.Deferred because it requires release-pipeline + signing design work, not an in-repo patch, and does not regress the already-shipping bash posture.