Embed asInvoker UAC manifest in the Windows launcher stub#29822
Closed
rdesgroppes wants to merge 1 commit into
Closed
Embed asInvoker UAC manifest in the Windows launcher stub#29822rdesgroppes wants to merge 1 commit into
asInvoker UAC manifest in the Windows launcher stub#29822rdesgroppes wants to merge 1 commit into
Conversation
github-actions
Bot
added
the
awaiting-review
rdesgroppes
changed the title
asInvoker UAC manifest in the Windows launcher stub
rdesgroppes
force-pushed
the
windows-launcher-uac-manifest
branch
2 times, most recently
from
49c387f to
d29a672
Compare
rdesgroppes
force-pushed
the
windows-launcher-uac-manifest
branch
2 times, most recently
from
1a0cbc7 to
b129f28
Compare
Contributor
Author
|
@meteorcloudy, may I request your review? |
iancha1992
added
the
team-Core
### Description Add `win_manifest.xml` (`requestedExecutionLevel asInvoker`) and `win_resources.rc` to `src/tools/launcher`, link them via the existing `windows_resources` rule, and add a regression test. ### Motivation On Windows, manifest-less PE executables whose name contains keywords like "install", "setup", "update", or "patch" trigger the UAC installer-detection heuristic and demand elevation (error 740), even when the target does nothing privileged. Declaring `asInvoker` in the launcher stub bypasses the heuristic. Because the manifest lives in the PE resource section, `launcher_maker`'s byte-copy propagates it to every generated binary automatically. Fixes bazelbuild#29819. ### Build API Changes No ### Checklist - [x] I have added tests for the new use cases (if any). - [ ] I have updated the documentation (if applicable). ### Release Notes RELNOTES[NEW]: Windows launcher stubs now embed an `asInvoker` UAC manifest, preventing error 740 for targets whose name matches the installer-detection heuristic.
rdesgroppes
force-pushed
the
windows-launcher-uac-manifest
branch
from
b129f28 to
81025f3
Compare
fmeum
approved these changes
Jun 22, 2026
fmeum
left a comment
fmeum
left a comment
Collaborator
There was a problem hiding this comment.
We could pribanoy also use this to enable UTF-8 awareness for more tools quite easily - thanks for fixing the rc build!
github-actions
Bot
added
the
community-reviewed
Wyverald
added
team-OSS
Contributor
Author
probably 😉, and also declare "long path capability"? |
github-actions
Bot
removed
the
awaiting-PR-merge
Collaborator
|
@bazel-io fork 9.2.0 |
Member
|
This ended up breaking our bootstrap builds on Windows (https://buildkite.com/bazel/bazel-bazel/builds/35912/list?sid=019eff63-e9b9-437e-bd31-1c19bcb531b3&tab=output), and we're reverting this commit. Sorry about the inconvenience; the breakage was not surfaced in the presubmit checks as the bootstrap test takes a long time to run, so we left it running in postsubmit only. Could you make sure |
copybara-service Bot
pushed a commit
that referenced
this pull request
Jun 26, 2026
*** Reason for rollback *** Breaks post-submit: https://buildkite.com/bazel/bazel-bazel/builds/35912 *** Original change description *** Embed `asInvoker` UAC manifest in the Windows launcher stub (#29822) ### Description Add `win_manifest.xml` (`requestedExecutionLevel`: `asInvoker`) and `win_resources.rc` to `src/tools/launcher`, link them via the existing `windows_resources` rule, and add a regression test. ### Motivation On Windows, manifest-less PE executables whose name contains keywords like "install", "setup", "update", or "patch" trigger the "[UAC installer-detection heuristic](h... *** PiperOrigin-RevId: 938607441 Change-Id: Ic272822bac15c4c80d6b6699d2da905b977c85e2
Contributor
Author
Sure thing, please bear with me. |
rdesgroppes
added a commit
to rdesgroppes/bazel
that referenced
this pull request
Jun 27, 2026
This reverts commit bazelbuild@f5aeb71, relanding bazelbuild#29822. Additional fix: the change makes `//src/tools/launcher:launcher` depend on a `windows_resources` target, but an rc toolchain was registered only in the root `MODULE.bazel`. The embedded `@bazel_tools` copy of the launcher requires `@@bazel_tools//src/main/res:toolchain_type`, which nothing provided, so the postsubmit `bazel_bootstrap_distfile_test` (which rebuilds `@bazel_tools` from source, unlike presubmit) could not bootstrap Bazel on Windows. As the toolchain type label resolves relative to the repo that loads `winsdk_toolchain.bzl`, each module must register its own rc toolchain, so this: - registers `@local_config_winsdk//:all` and `empty_rc_toolchain` in `src/MODULE.tools` (as in the root `MODULE.bazel`), - drops the now-redundant `empty_rc_toolchain` registration from `testBuildLaunchersWithClangClOnWindows`. Verified with `bazel_bootstrap_distfile_test` on Windows: ``` bazel.exe test //src/test/shell/bazel:bazel_bootstrap_distfile_test [...] INFO: Build completed successfully, 2 total actions //src/test/shell/bazel:bazel_bootstrap_distfile_test PASSED in 732.8s Executed 1 out of 1 test: 1 test passes. ``` RELNOTES[NEW]: Windows launcher stubs now embed an `asInvoker` UAC manifest, preventing "The requested operation requires elevation. (error: 740)" for targets whose name matches the installer-detection heuristic.
rdesgroppes
added a commit
to rdesgroppes/bazel
that referenced
this pull request
Jun 27, 2026
This reverts commit bazelbuild@f5aeb71, relanding bazelbuild#29822. Additional fix: the change makes `//src/tools/launcher:launcher` depend on a `windows_resources` target, but an rc toolchain was registered only in the root `MODULE.bazel`. The embedded `@bazel_tools` copy of the launcher requires `@@bazel_tools//src/main/res:toolchain_type`, which nothing provided, so the postsubmit `bazel_bootstrap_distfile_test` (which rebuilds `@bazel_tools` from source, unlike presubmit) could not bootstrap Bazel on Windows. As the toolchain type label resolves relative to the repo that loads `winsdk_toolchain.bzl`, each module must register its own rc toolchain, so this: - registers `@local_config_winsdk//:all` and `empty_rc_toolchain` in `src/MODULE.tools` (as in the root `MODULE.bazel`), - drops the now-redundant `empty_rc_toolchain` registration from `testBuildLaunchersWithClangClOnWindows`. Verified with `bazel_bootstrap_distfile_test` on Windows: ``` bazel.exe test //src/test/shell/bazel:bazel_bootstrap_distfile_test [...] INFO: Build completed successfully, 2 total actions //src/test/shell/bazel:bazel_bootstrap_distfile_test PASSED in 732.8s Executed 1 out of 1 test: 1 test passes. ``` RELNOTES[NEW]: Windows launcher stubs now embed an `asInvoker` UAC manifest, preventing "The requested operation requires elevation. (error: 740)" for targets whose name matches the installer-detection heuristic.
2 tasks
Contributor
Author
@Wyverald I reverted f5aeb71 and found what broke: a missing toolchain registration in |
rdesgroppes
added a commit
to rdesgroppes/bazel
that referenced
this pull request
Jun 27, 2026
This reverts commit bazelbuild@f5aeb71, relanding bazelbuild#29822. Additional fix: the change makes `//src/tools/launcher:launcher` depend on a `windows_resources` target, but an rc toolchain was registered only in the root `MODULE.bazel`. The embedded `@bazel_tools` copy of the launcher requires `@@bazel_tools//src/main/res:toolchain_type`, which nothing provided, so the postsubmit `bazel_bootstrap_distfile_test` (which rebuilds `@bazel_tools` from source, unlike presubmit) could not bootstrap Bazel on Windows. As the toolchain type label resolves relative to the repo that loads `winsdk_toolchain.bzl`, each module must register its own rc toolchain, so this: - registers `@local_config_winsdk//:all` and `empty_rc_toolchain` in `src/MODULE.tools` (as in the root `MODULE.bazel`), - drops the now-redundant `empty_rc_toolchain` registration from `testBuildLaunchersWithClangClOnWindows`. Verified with `bazel_bootstrap_distfile_test` on Windows: ``` bazel.exe test //src/test/shell/bazel:bazel_bootstrap_distfile_test [...] INFO: Build completed successfully, 2 total actions //src/test/shell/bazel:bazel_bootstrap_distfile_test PASSED in 732.8s Executed 1 out of 1 test: 1 test passes. ``` RELNOTES[NEW]: Windows launcher stubs now embed an `asInvoker` UAC manifest, preventing "The requested operation requires elevation. (error: 740)" for targets whose name matches the installer-detection heuristic.
rdesgroppes
added a commit
to rdesgroppes/bazel
that referenced
this pull request
Jun 27, 2026
This reverts commit bazelbuild@f5aeb71, relanding bazelbuild#29822. Additional fix: the change makes `//src/tools/launcher:launcher` depend on a `windows_resources` target, but an rc toolchain was registered only in the root `MODULE.bazel`. The embedded `@bazel_tools` copy of the launcher requires `@@bazel_tools//src/main/res:toolchain_type`, which nothing provided, so the postsubmit `bazel_bootstrap_distfile_test` (which rebuilds `@bazel_tools` from source, unlike presubmit) could not bootstrap Bazel on Windows. As the toolchain type label resolves relative to the repo that loads `winsdk_toolchain.bzl`, each module must register its own rc toolchain, so this: - registers `@local_config_winsdk//:all` and `empty_rc_toolchain` in `src/MODULE.tools` (as in the root `MODULE.bazel`), - drops the now-redundant `empty_rc_toolchain` registration from `testBuildLaunchersWithClangClOnWindows`. Verified with `bazel_bootstrap_distfile_test` on Windows: ``` bazel.exe test //src/test/shell/bazel:bazel_bootstrap_distfile_test [...] INFO: Build completed successfully, 2 total actions //src/test/shell/bazel:bazel_bootstrap_distfile_test PASSED in 732.8s Executed 1 out of 1 test: 1 test passes. ``` RELNOTES[NEW]: Windows launcher stubs now embed an `asInvoker` UAC manifest, preventing "The requested operation requires elevation. (error: 740)" for targets whose name matches the installer-detection heuristic.
rdesgroppes
added a commit
to rdesgroppes/bazel
that referenced
this pull request
Jun 27, 2026
This reverts commit bazelbuild@f5aeb71, relanding bazelbuild#29822. Additional fix: the change makes `//src/tools/launcher:launcher` depend on a `windows_resources` target, but an rc toolchain was registered only in the root `MODULE.bazel`. The embedded `@bazel_tools` copy of the launcher requires `@@bazel_tools//src/main/res:toolchain_type`, which nothing provided, so the postsubmit `bazel_bootstrap_distfile_test` (which rebuilds `@bazel_tools` from source, unlike presubmit) could not bootstrap Bazel on Windows. As the toolchain type label resolves relative to the repo that loads `winsdk_toolchain.bzl`, each module must register its own rc toolchain, so this: - registers `@local_config_winsdk//:all` and `empty_rc_toolchain` in `src/MODULE.tools` (as in the root `MODULE.bazel`), - drops the now-redundant `empty_rc_toolchain` registration from `testBuildLaunchersWithClangClOnWindows`. Verified with `bazel_bootstrap_distfile_test` on Windows: ``` bazel.exe test //src/test/shell/bazel:bazel_bootstrap_distfile_test [...] INFO: Build completed successfully, 2 total actions //src/test/shell/bazel:bazel_bootstrap_distfile_test PASSED in 732.8s Executed 1 out of 1 test: 1 test passes. ``` RELNOTES[NEW]: Windows launcher stubs now embed an `asInvoker` UAC manifest, preventing "The requested operation requires elevation. (error: 740)" for targets whose name matches the installer-detection heuristic.
rdesgroppes
added a commit
to rdesgroppes/bazel
that referenced
this pull request
Jun 27, 2026
This reverts commit bazelbuild@f5aeb71, relanding bazelbuild#29822. Additional fix: the change makes `//src/tools/launcher:launcher` depend on a `windows_resources` target, but its embedded `@bazel_tools` copy had no rc toolchain for `toolchain_type`, so the postsubmit `bazel_bootstrap_distfile_test` (which rebuilds `@bazel_tools` from source, unlike presubmit) could not bootstrap Bazel on Windows. The resource-compiler package lived at `src/main/res`, outside `@bazel_tools`, so embedding it there required `@bazel_tools`-qualified labels and hand-staging the package in the lockfile test. Move it to `tools/res` instead, beside the other embedded toolchains, so it is embedded and staged like its siblings and labels resolve relative to the loading repo. Each module must then register its own rc toolchain, so this registers `@local_config_winsdk//:all` and `empty_rc_toolchain` in `src/MODULE.tools` (as in the root `MODULE.bazel`) and drops the now redundant `empty_rc_toolchain` registration from `testBuildLaunchersWithClangClOnWindows`. RELNOTES[NEW]: Windows launcher stubs now embed an `asInvoker` UAC manifest, preventing "The requested operation requires elevation. (error: 740)" for targets whose name matches the installer-detection heuristic.
rdesgroppes
added a commit
to rdesgroppes/bazel
that referenced
this pull request
Jun 27, 2026
This reverts commit bazelbuild@f5aeb71, relanding bazelbuild#29822. Additional fix: the change makes `//src/tools/launcher:launcher` depend on a `windows_resources` target, but its embedded `@bazel_tools` copy had no rc toolchain for `toolchain_type`, so the postsubmit `bazel_bootstrap_distfile_test` (which rebuilds `@bazel_tools` from source, unlike presubmit) could not bootstrap Bazel on Windows. The resource-compiler package lived at `src/main/res`, outside `@bazel_tools`, so embedding it there required `@bazel_tools`-qualified labels and hand-staging the package in the lockfile test. Move it to `tools/res` instead, beside the other embedded toolchains, so it is embedded and staged like its siblings and labels resolve relative to the loading repo. Each module must then register its own rc toolchain, so this registers `@local_config_winsdk//:all` and `empty_rc_toolchain` in `src/MODULE.tools` (as in the root `MODULE.bazel`) and drops the now redundant `empty_rc_toolchain` registration from `testBuildLaunchersWithClangClOnWindows`. RELNOTES[NEW]: Windows launcher stubs now embed an `asInvoker` UAC manifest, preventing "The requested operation requires elevation. (error: 740)" for targets whose name matches the installer-detection heuristic.
rdesgroppes
added a commit
to rdesgroppes/bazel
that referenced
this pull request
Jun 29, 2026
This reverts commit bazelbuild@f5aeb71, relanding bazelbuild#29822. Additional fix: the change makes `//src/tools/launcher:launcher` depend on a `windows_resources` target, but its embedded `@bazel_tools` copy had no rc toolchain for `toolchain_type`, so the postsubmit `bazel_bootstrap_distfile_test` (which rebuilds `@bazel_tools` from source, unlike presubmit) could not bootstrap Bazel on Windows. The resource-compiler package lived at `src/main/res`, outside `@bazel_tools`, so embedding it there required `@bazel_tools`-qualified labels and hand-staging the package in the lockfile test. Move it to `tools/res` instead, beside the other embedded toolchains, so it is embedded and staged like its siblings and labels resolve relative to the loading repo. Each module must then register its own rc toolchain, so this registers `@local_config_winsdk//:all` and `empty_rc_toolchain` in `src/MODULE.tools` (as in the root `MODULE.bazel`) and drops the now redundant `empty_rc_toolchain` registration from `testBuildLaunchersWithClangClOnWindows`. RELNOTES[NEW]: Windows launcher stubs now embed an `asInvoker` UAC manifest, preventing "The requested operation requires elevation. (error: 740)" for targets whose name matches the installer-detection heuristic.
kapunahelewong
pushed a commit
to kapunahelewong/bazel
that referenced
this pull request
Jul 2, 2026
…ld#29822) ### Description Add `win_manifest.xml` (`requestedExecutionLevel`: `asInvoker`) and `win_resources.rc` to `src/tools/launcher`, link them via the existing `windows_resources` rule, and add a regression test. ### Motivation On Windows, manifest-less PE executables whose name contains keywords like "install", "setup", "update", or "patch" trigger the "[UAC installer-detection heuristic](https://www.advancedinstaller.com/user-guide/vista-uac.html)" and demand elevation, even when the target does nothing privileged. When running such executables without admin privileges, one indeed face errors resembling: ``` FATAL: ExecuteProgram(C:\[...]\install.exe) failed: ERROR: src/main/native/windows/process.cc(189): CreateProcessW("C:\[...]\install.exe"): The requested operation requires elevation. (error: 740) ``` Declaring `asInvoker` in the launcher stub bypasses the heuristic, similar to rust-lang/cargo#393 (`cargo update` triggered the same heuristic): cargo now ships a `windows.manifest.xml` embedded via its build script. Because the manifest lives in the PE resource section, `launcher_maker`'s byte-copy propagates it to every generated binary automatically. Fixes bazelbuild#29819. ### Build API Changes No ### Checklist - [x] I have added tests for the new use cases (if any). - [ ] I have updated the documentation (if applicable). ### Release Notes RELNOTES[NEW]: Windows launcher stubs now embed an `asInvoker` UAC manifest, preventing "The requested operation requires elevation. (error: 740)" for targets whose name matches the installer-detection heuristic. Closes bazelbuild#29822. PiperOrigin-RevId: 937996732 Change-Id: I28684baa50ecf5b79c38c22bcc97ecdbc23677af
kapunahelewong
pushed a commit
to kapunahelewong/bazel
that referenced
this pull request
Jul 2, 2026
*** Reason for rollback *** Breaks post-submit: https://buildkite.com/bazel/bazel-bazel/builds/35912 *** Original change description *** Embed `asInvoker` UAC manifest in the Windows launcher stub (bazelbuild#29822) ### Description Add `win_manifest.xml` (`requestedExecutionLevel`: `asInvoker`) and `win_resources.rc` to `src/tools/launcher`, link them via the existing `windows_resources` rule, and add a regression test. ### Motivation On Windows, manifest-less PE executables whose name contains keywords like "install", "setup", "update", or "patch" trigger the "[UAC installer-detection heuristic](h... *** PiperOrigin-RevId: 938607441 Change-Id: Ic272822bac15c4c80d6b6699d2da905b977c85e2
copybara-service Bot
pushed a commit
that referenced
this pull request
Jul 8, 2026
…30043) ### Description This reverts commit f5aeb71, relanding #29822. Additional fix: the change makes `//src/tools/launcher:launcher` depend on a `windows_resources` target, but its embedded `@bazel_tools` copy had no rc toolchain for `toolchain_type`, so the postsubmit `bazel_bootstrap_distfile_test` (which rebuilds `@bazel_tools` from source, unlike presubmit) could not bootstrap Bazel on Windows. The resource-compiler package lived at `src/main/res`, outside `@bazel_tools`, so embedding it there required `@bazel_tools`-qualified labels and hand-staging the package in the lockfile test. Move it to `tools/res` instead, beside the other embedded toolchains, so it is embedded and staged like its siblings and labels resolve relative to the loading repo. Each module must then register its own rc toolchain, so this registers `@local_config_winsdk//:all` and `empty_rc_toolchain` in `src/MODULE.tools` (as in the root `MODULE.bazel`) and drops the now redundant `empty_rc_toolchain` registration from `testBuildLaunchersWithClangClOnWindows`. Verified with `bazel_bootstrap_distfile_test` on Windows: ``` bazel.exe test //src/test/shell/bazel:bazel_bootstrap_distfile_test [...] INFO: Build completed successfully, 2 total actions //src/test/shell/bazel:bazel_bootstrap_distfile_test PASSED in 732.8s Executed 1 out of 1 test: 1 test passes. ``` ### Motivation Same as #29822: > On Windows, manifest-less PE executables whose name contains keywords like "install", "setup", "update", or "patch" trigger the "[UAC installer-detection heuristic](https://www.advancedinstaller.com/user-guide/vista-uac.html)" and demand elevation, even when the target does nothing privileged. > > When running such executables without admin privileges, one indeed face errors resembling: > ``` > FATAL: ExecuteProgram(C:\[...]\install.exe) failed: ERROR: src/main/native/windows/process.cc(189): CreateProcessW("C:\[...]\install.exe"): The requested operation requires elevation. > (error: 740) > ``` > > Declaring `asInvoker` in the launcher stub bypasses the heuristic, similar to rust-lang/cargo#393 (`cargo update` triggered the same heuristic): cargo now ships a `windows.manifest.xml` embedded via its build script. > > Because the manifest lives in the PE resource section, `launcher_maker`'s byte-copy propagates it to every generated binary automatically. Fixes #29819. (for real) ### Build API Changes No ### Checklist - [x] I have added tests for the new use cases (if any). - [ ] I have updated the documentation (if applicable). ### Release Notes RELNOTES[NEW]: Windows launcher stubs now embed an `asInvoker` UAC manifest, preventing "The requested operation requires elevation. (error: 740)" for targets whose name matches the installer-detection heuristic. Closes #30043. PiperOrigin-RevId: 944416012 Change-Id: I37a388ad42ea8192af454a978de39dbe4ff2d100
2 tasks
rdesgroppes
added a commit
to rdesgroppes/bazel
that referenced
this pull request
Jul 8, 2026
…azelbuild#30043) ### Description This reverts commit f5aeb71, relanding bazelbuild#29822. Additional fix: the change makes `//src/tools/launcher:launcher` depend on a `windows_resources` target, but its embedded `@bazel_tools` copy had no rc toolchain for `toolchain_type`, so the postsubmit `bazel_bootstrap_distfile_test` (which rebuilds `@bazel_tools` from source, unlike presubmit) could not bootstrap Bazel on Windows. The resource-compiler package lived at `src/main/res`, outside `@bazel_tools`, so embedding it there required `@bazel_tools`-qualified labels and hand-staging the package in the lockfile test. Move it to `tools/res` instead, beside the other embedded toolchains, so it is embedded and staged like its siblings and labels resolve relative to the loading repo. Each module must then register its own rc toolchain, so this registers `@local_config_winsdk//:all` and `empty_rc_toolchain` in `src/MODULE.tools` (as in the root `MODULE.bazel`) and drops the now redundant `empty_rc_toolchain` registration from `testBuildLaunchersWithClangClOnWindows`. Verified with `bazel_bootstrap_distfile_test` on Windows: ``` bazel.exe test //src/test/shell/bazel:bazel_bootstrap_distfile_test [...] INFO: Build completed successfully, 2 total actions //src/test/shell/bazel:bazel_bootstrap_distfile_test PASSED in 732.8s Executed 1 out of 1 test: 1 test passes. ``` ### Motivation Same as bazelbuild#29822: > On Windows, manifest-less PE executables whose name contains keywords like "install", "setup", "update", or "patch" trigger the "[UAC installer-detection heuristic](https://www.advancedinstaller.com/user-guide/vista-uac.html)" and demand elevation, even when the target does nothing privileged. > > When running such executables without admin privileges, one indeed face errors resembling: > ``` > FATAL: ExecuteProgram(C:\[...]\install.exe) failed: ERROR: src/main/native/windows/process.cc(189): CreateProcessW("C:\[...]\install.exe"): The requested operation requires elevation. > (error: 740) > ``` > > Declaring `asInvoker` in the launcher stub bypasses the heuristic, similar to rust-lang/cargo#393 (`cargo update` triggered the same heuristic): cargo now ships a `windows.manifest.xml` embedded via its build script. > > Because the manifest lives in the PE resource section, `launcher_maker`'s byte-copy propagates it to every generated binary automatically. Fixes bazelbuild#29819. (for real) ### Build API Changes No ### Checklist - [x] I have added tests for the new use cases (if any). - [ ] I have updated the documentation (if applicable). ### Release Notes RELNOTES[NEW]: Windows launcher stubs now embed an `asInvoker` UAC manifest, preventing "The requested operation requires elevation. (error: 740)" for targets whose name matches the installer-detection heuristic. Closes bazelbuild#30043. PiperOrigin-RevId: 944416012 Change-Id: I37a388ad42ea8192af454a978de39dbe4ff2d100
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
5 participants
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.
Description
Add
win_manifest.xml(requestedExecutionLevel:asInvoker) andwin_resources.rctosrc/tools/launcher, link them via the existingwindows_resourcesrule, and add a regression test.Motivation
On Windows, manifest-less PE executables whose name contains keywords like "install", "setup", "update", or "patch" trigger the "UAC installer-detection heuristic" and demand elevation, even when the target does nothing privileged.
When running such executables without admin privileges, one indeed face errors resembling:
Declaring
asInvokerin the launcher stub bypasses the heuristic, similar to rust-lang/cargo#393 (cargo updatetriggered the same heuristic): cargo now ships awindows.manifest.xmlembedded via its build script.Because the manifest lives in the PE resource section,
launcher_maker's byte-copy propagates it to every generated binary automatically.Fixes #29819.
Build API Changes
No
Checklist
Release Notes
RELNOTES[NEW]: Windows launcher stubs now embed an
asInvokerUAC manifest, preventing "The requested operation requires elevation. (error: 740)" for targets whose name matches the installer-detection heuristic.