Validate resolved release version in installers#27
Merged
Conversation
The installers derived the version from the /releases/latest redirect without checking the result. GitHub only points /releases/latest at a full release, so a prerelease-only (or release-less) repo redirects to the /releases listing instead of a /tag/ URL. The old parse left that whole URL as the "version", passed the non-empty guard, and built a bogus download URL that 404'd with a confusing error. Both scripts now parse the tag from the redirect, validate it against a semver pattern, fall back to the GitHub API, and abort with a clear message pointing at EMAILABLE_VERSION when no full release is resolvable. The pattern accepts prerelease suffixes, so an explicit EMAILABLE_VERSION can install a prerelease even though auto-detection never selects one.
92bf42e to
f28a7c4
Compare
There was a problem hiding this comment.
Pull request overview
This PR hardens the Bash and PowerShell installers by correctly resolving the “latest full release” version from GitHub and failing early (with a clear error) when the repo has no full releases (e.g., prerelease-only state), preventing confusing 404s from malformed download URLs.
Changes:
- Added a validated “latest version” resolution path that rejects non-tag redirects by enforcing a semver pattern.
- Added a GitHub API fallback when
/releases/latestredirect parsing fails. - Improved failure messaging to point users to
EMAILABLE_VERSION/$env:EMAILABLE_VERSIONfor explicit installs.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.
| File | Description |
|---|---|
| scripts/install.sh | Adds latest_version() with semver validation + API fallback; updates version resolution error handling. |
| scripts/install.ps1 | Adds semver validation + Get-LatestVersion with redirect parsing and API fallback; updates version resolution error handling. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
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
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.
Problem
curl -fsSL https://emailable.com/install-cli | bashfails with a 404. Theinstall-cliURL itself is fine (200, serves the script) — the 404 comes from inside the script when it downloads the release tarball.Both installers derived the version from the
/releases/latestredirect without validating the result. GitHub only points/releases/latestat a full release, so a prerelease-only (or release-less) repo redirects to the/releaseslisting instead of a/tag/URL. The oldsed 's#.*/tag/##'parse then left the entire URL as the "version", which passed the non-empty guard and produced a bogus download URL that 404'd with a confusing error.install.ps1had the identical flaw (($location -split '/tag/')[-1]with no validation).Fix
Both scripts now:
/tag/redirect is rejected here rather than 404ing on a bogus tarball URL later;EMAILABLE_VERSIONwhen no full release is resolvable.The semver pattern accepts prerelease suffixes, so an explicit
EMAILABLE_VERSION=0.3.0-rc.1can install a prerelease, even though auto-detection never selects one (mirrors how GitHub's/releases/latestbehaves).Verification
bash -npasses;latest_version()correctly aborts against the current prerelease-only repo state.0.3.0/1.2.3-rc.1, rejects the barereleasesURL.EMAILABLE_VERSION=0.3.0downloads, verifies the checksum, and installs a working binary.install.ps1could not be execute-linted locally (nopwsh); logic mirrors the bash path and was traced by hand — worth a run on a Windows/pwsh box before merge.This hardens the failure mode but does not by itself make the published install command succeed: that still requires
v0.3.0to be published as a full release rather than a prerelease.