feat(updater)!: send update-feed credentials only to the feed's origin

[mmaietta]

Summary

• Feed-origin credentials (electron-updater). The credential headers from requestHeaders / addAuthHeader (headers such as Authorization, the same set that is removed on a cross-origin redirect) and the query string of the feed URL are sent only to download URLs on the feed's origin (scheme, host and port). This is the same rule as for redirects: an http → https upgrade of the same host on the default ports keeps them.
  • It applies to every download, against its actual URL: full downloads, both blockmaps, differential range requests, the AppImage differential download, and the NSIS web package (full and differential, which now use the same per-download headers).
  • The old blockmap from an app-set previousBlockmapBaseUrlOverride keeps the credentials on that origin.
  • New protected AppUpdater.downloadRequestHeaders(url, downloadUpdateOptions, originUrl?).
• Provider.feedBaseUrl (electron-updater, new). The generic (also used for s3, spaces and r2), keygen, bitbucket, github and gitlab providers set it; for GitLab its origin is https://<host>, where electron-builder publishes the release assets. It is null by default: the private GitHub provider and custom providers keep sending the request headers to every download URL. A custom provider opts in by overriding the getter, and one that extends a built-in provider inherits it.
• Feed query (electron-updater). newUrlFromBase adds the feed query only to URLs on the feed's origin. A URL on another origin keeps its own query string, so pre-signed URLs work.
• HttpExecutor.removeCrossOriginSensitiveHeaders(headers, originUrl, targetUrl) (builder-util-runtime, new). It returns the headers without the credential headers when targetUrl is on another origin than originUrl, using the cross-origin redirect rule and header set, and the headers themselves otherwise. It copies the headers with deepAssign, which ignores __proto__, constructor and prototype keys, and does not mutate its input.
• migrate-schema (electron-builder). New advisory (log.warn, config unchanged, linking to its v27 breaking-changes section) for a generic publish url with a query string. The publish of the root and of each top-level section of the migrated config is checked. JS/TS configs get the same rule on the syntax tree, with the propValue, objectLiteral and isLiteral helpers that are already on master. The advisory comes last, after the nsis-web, mac entitlements, per-machine and sign-hook advisories.
• Docs. A note on the auto-update page (with the v27 section: signed update manifests cover files[].url and packages.<arch>.path, so a pre-signed URL has to be in latest*.yml before it is signed), a bullet on the hardening page, v27 breaking changes (the at-a-glance row and the section "Update credentials stay on the feed's origin", the migrate-schema list and a tip), v26-to-v27 checklist items, what's new in v27 and the CLI page.
• Changesets. The repo is in changesets pre mode, so the electron-updater major stays on 7.0.0-alpha.
  • manifest-download-credentials: electron-updater major, builder-util-runtime minor;
  • cross-origin-headers-safe-copy: builder-util-runtime patch;
  • migrate-schema-feed-query-advisory: electron-builder patch.

Breaking changes

• Update files on another origin that need credentials. If latest*.yml points downloads at another origin (another host, or the same host with another port or scheme) that authenticates with your requestHeaders / addAuthHeader credentials, or with a token in the feed URL's query (e.g. url: https://updates.example.com/?key=…), those downloads are now requested without them and can fail (for example with 401 or 403). Serve the update files from the feed origin (relative files[].url, the default) or use pre-signed URLs.
• Custom providers. A custom provider that does not extend a built-in provider keeps sending the request headers to every download URL; override Provider.feedBaseUrl to apply the feed-origin rule.
• No action if your update files are served from the feed origin.
• electron-builder migrate-schema prints an advisory for a generic publish url with a query string.

Tests

Added

• manifestDownloadOriginTest (new): a download on another origin gets no credential headers or feed query; the web package on another origin gets none while the same-origin installer keeps them; blockmaps and range requests on another host or over http; same-origin blockmaps and range requests keep the credentials and the feed query; the old blockmap from previousBlockmapBaseUrlOverride; the NSIS web-package and AppImage differential downloads; providers without feedBaseUrl.
• httpExecutorTest: removeCrossOriginSensitiveHeaders (another origin, the same origin, the input is not mutated, another port, https → http, the http → https upgrade, a __proto__ key).
• urlUtilTest: newUrlFromBase keeps the base query on the base origin (another origin, another port, https → http, a URL with its own query, a blockmap path).
• providerFactoryTest, providerTest and gitlabProviderTest: feedBaseUrl of each provider and the null default.
• migrateSchemaTest and migrateProgrammaticSchemaTest: the feed-query advisory, the order of all five advisories (nsis-web, mac entitlements, per-machine, sign hook, feed query) and feed rows in the parity table.

Changed

• baseUpdaterUnitTest (from feat(updater): add VerifyUpdateFileAuthenticodeSignature functionality to AppUpdater #10239): the download in the verifyUpdateFile tests gets a provider stub without feedBaseUrl instead of null, because executeDownload now reads the provider's feed origin for the download headers.

[changeset-bot]

🦋 Changeset detected

Latest commit: 52c8ce3

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 12 packages

Name	Type
builder-util-runtime	Minor
electron-updater	Major
electron-builder	Patch
app-builder-lib	Patch
builder-util	Patch
dmg-builder	Patch
electron-publish	Patch
electron-builder-squirrel-windows	Patch
electron-forge-maker-appimage	Patch
electron-forge-maker-nsis-web	Patch
electron-forge-maker-nsis	Patch
electron-forge-maker-snap	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[claude]

Nothing blocking. The comments below are optional suggestions. There is no need to push a fix for them before merging.

Beyond the two inline findings, a few other candidate issues were checked and ruled out: GitLab/private-GitHub providers silently drop files[].blockMapUrl in resolveFiles (so differential updates there just fall back to full downloads, unlike GitHub's mishandling); httpExecutor.ts's fixed SENSITIVE_REDIRECT_HEADERS set is deliberately extensible via registerSensitiveHeader() for custom auth header names; and the generic-feed-query build warning firing once per process in the programmatic multi-app case shares the same root cause as the PublishManager.ts:83 finding already flagged inline, rather than being a separate bug.

Extended reasoning...

This PR reworks credential/header propagation across origins in electron-updater (redirect header stripping, feed-origin-scoped request headers, blockmap/differential download URLs) plus adds a build-time advisory in the electron-builder migrate-schema/publish path — both touch security-sensitive surface (which requests carry auth headers/tokens). Two confirmed findings are already filed inline (GitHubProvider mishandling an absolute pre-signed blockMapUrl, and the feed-query advisory only firing once per process). I additionally verified GitLabProvider/PrivateGitHubProvider never populate blockMapUrl in resolveFiles at all, and confirmed httpExecutor.ts exposes a registerSensitiveHeader() escape hatch for non-standard credential headers, so neither is an additional bug worth a new inline comment.

Additional findings (outside the current diff — GitHub can't attach inline comments there):

• 🟡 packages/electron-updater/src/providers/GitHubProvider.ts — For GitHubProvider, an absolute files[].blockMapUrl (a pre-signed URL on another host) gets mangled into a broken github.com URL instead of being downloaded as-is, unlike every other non-excluded provider. resolveFiles (Provider.ts:175) runs pathTransformer(fileInfo.blockMapUrl) before resolving against baseUrl. GitHubProvider's transformer (GitHubProvider.ts:237) prepends ${basePath}/download/${tag}/ to the absolute URL string, so new URL(...) treats it as a relative path on github.com rather than the pre-signed host. Fix: resolveFiles (or GitHubProvider's transformer) must skip pathTransformer when the field is already an absolute URL, so files[].blockMapUrl keeps its own origin as docs promise.

  Why this was flagged

  A GitHub-published app sets a pre-signed files[].blockMapUrl (e.g. https://cdn.example.net/app.blockmap?X-Amz-Signature=...) in latest*.yml, as the new feature in updateInfo.ts:41-46 and the manifest-blockmap-url changeset explicitly support. GitHubProvider.resolveFiles (GitHubProvider.ts:237) passes that absolute URL through pathTransformer = p => getBaseDownloadPath(tag, p.replace(/ /g,'-')) (GitHubProvider.ts:240-246), which returns ${basePath}/download/${tag}/https://cdn.example.net/app.blockmap?X-Amz-Signature=.... resolveFiles (Provider.ts:175) then does new URL(that, baseUrl) where baseUrl is github.com; since the string starts with '/', it is parsed as a relative path on github.com, not redirected to cdn.example.net. The differential download then requests a nonexistent github.com path instead of the pre-signed blockmap, erroring and falling back to a full download on every update check. Only GitLabProvider and PrivateGitHubProvider are documented as ignoring blockMapUrl; GitHubProvider is not.

  Verification: GitHubProvider.resolveFiles (GitHubProvider.ts:237) uses the transformer p => this.getBaseDownloadPath(updateInfo.tag, p.replace(/ /g,"-")); getBaseDownloadPath (GitHubProvider.ts:240-246) unconditionally returns ${this.basePath}/download/${tag}/${fileName} even when fileName is an absolute URL.

[claude]

No new blocking issues. 1 optional suggestion (a nit or a note on pre-existing code) was found and not posted. Nothing in this review needs a push before merging.

1 further finding on code this push did not change was outside the scope of this re-review and not posted.