[PR #5180] fix(apktool): treat an EPERM launcher spawn as not executable #6804

Open
opened 2026-11-01 21:43:08 +00:00 by bsakaguchi · 0 comments
Owner

📋 Pull Request Information

Original PR: https://github.com/morluto/rea/pull/5180
Author: @Yi-111-a
Created: 10/19/2026
Status: 🔄 Open

Base: main ← Head: fix/apktool-executable-permission


📝 Commits (6)

  • 9fa29de fix(apktool): keep a refused launcher's permission failure distinct
  • 796a731 Merge branch 'main' into fix/apktool-executable-permission
  • 6d2f3af fix(apktool): treat an EPERM launcher spawn as not executable
  • 8dcaee2 docs(apktool): drop the noexec example from the EPERM note
  • db9b6da fix(apktool): fold EPERM into main's launcher-execution-denied branch
  • edb61d6 style(apktool): wrap the launcher errno condition for oxfmt

📊 Changes

2 files changed (+13 additions, -5 deletions)

View changed files

📝 src/apktool/ApktoolConfiguration.ts (+12 -5)
📝 src/apktool/ApktoolVersionProbe.test.ts (+1 -0)

📄 Description

Fixes #5177.

Problem

versionProbeFailure collapsed ENOENT and EACCES into one
command_missing failure. A launcher that exists but is not executable for
the current user therefore reported "was not found" with remediation telling
the caller to point REA_APKTOOL_COMMAND at a different launcher. After the
EACCES handling landed in main, EPERM — the other errno a refused exec can
surface (for example a launcher blocked by an operating-system security
policy) — still had no dedicated outcome.

Approach

The branch is narrowed to exactly that remaining permission outcome, per the
2026-10-26 review. It now merges current main and keeps main's EACCES
branch structure, message wording and APKTOOL_NOT_EXECUTABLE_REMEDIATION /
APKTOOL_MISSING_REMEDIATION constants byte-for-byte; the only source change
is that the launcher-spawn failure matcher accepts EPERM alongside
ENOENT/EACCES, with EPERM taking the same command_not_executable,
"Execution of the selected apktool launcher was denied" path as EACCES. A
short comment records why EPERM is a permission failure rather than a
missing launcher, as in the report.

ProviderRejectionCode is unchanged; no public tool schema or catalog
contract is widened. Refusal behavior is unchanged — only the diagnosis and
recovery advice differ.

Validation

npx vitest run src/apktool/ApktoolVersionProbe.test.ts src/apktool/ApktoolConfiguration.test.ts
 Test Files  2 passed (2)
      Tests  77 passed (77)

New regression: one added row in the existing distinguishes launcher spawn it.each (["EPERM", "command_not_executable"]), asserting EPERM maps to
the same denial outcome as EACCES and never to command_missing. The
EACCES/ENOENT rows are main's, unchanged. Ran on Linux (Node v20.19.2;
the pinned .nvmrc 24.22.1 toolchain is not installed in this sandbox, tests
are unaffected).

Coverage limits: the head was exercised on Linux; macOS arm64 and Windows
were not re-run. EPERM is covered by the shared branch rather than a
separate fixture. Real Apktool/JVM decoding is not involved — the launcher is
an inert stub, as in the report. The earlier EACCES report is recorded in
#5177; no native EPERM reproduction is available locally.

Author readiness

Unchecked for the human owner to complete.


🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.

## 📋 Pull Request Information **Original PR:** https://github.com/morluto/rea/pull/5180 **Author:** [@Yi-111-a](https://github.com/Yi-111-a) **Created:** 10/19/2026 **Status:** 🔄 Open **Base:** `main` ← **Head:** `fix/apktool-executable-permission` --- ### 📝 Commits (6) - [`9fa29de`](https://github.com/morluto/rea/commit/9fa29de2eb5c7ea6f297ebbf6f19b9f6a4288500) fix(apktool): keep a refused launcher's permission failure distinct - [`796a731`](https://github.com/morluto/rea/commit/796a731fed4c6621eb2b63c2eac8587ef0d5b8a7) Merge branch 'main' into fix/apktool-executable-permission - [`6d2f3af`](https://github.com/morluto/rea/commit/6d2f3af858ca0ea7d64f7e45c4c58c54375fc660) fix(apktool): treat an EPERM launcher spawn as not executable - [`8dcaee2`](https://github.com/morluto/rea/commit/8dcaee20b6485117fd363ce4e9899e8c4bec443e) docs(apktool): drop the noexec example from the EPERM note - [`db9b6da`](https://github.com/morluto/rea/commit/db9b6dac9790c58c6633cdb2a68293fe591d0b14) fix(apktool): fold EPERM into main's launcher-execution-denied branch - [`edb61d6`](https://github.com/morluto/rea/commit/edb61d6763fd3bf699debac9e318494130108c1f) style(apktool): wrap the launcher errno condition for oxfmt ### 📊 Changes **2 files changed** (+13 additions, -5 deletions) <details> <summary>View changed files</summary> 📝 `src/apktool/ApktoolConfiguration.ts` (+12 -5) 📝 `src/apktool/ApktoolVersionProbe.test.ts` (+1 -0) </details> ### 📄 Description Fixes #5177. ## Problem `versionProbeFailure` collapsed `ENOENT` and `EACCES` into one `command_missing` failure. A launcher that exists but is not executable for the current user therefore reported "was not found" with remediation telling the caller to point `REA_APKTOOL_COMMAND` at a different launcher. After the `EACCES` handling landed in main, `EPERM` — the other errno a refused exec can surface (for example a launcher blocked by an operating-system security policy) — still had no dedicated outcome. ## Approach The branch is narrowed to exactly that remaining permission outcome, per the 2026-10-26 review. It now merges current main and keeps main's `EACCES` branch structure, message wording and `APKTOOL_NOT_EXECUTABLE_REMEDIATION` / `APKTOOL_MISSING_REMEDIATION` constants byte-for-byte; the only source change is that the launcher-spawn failure matcher accepts `EPERM` alongside `ENOENT`/`EACCES`, with `EPERM` taking the same `command_not_executable`, "Execution of the selected apktool launcher was denied" path as `EACCES`. A short comment records why `EPERM` is a permission failure rather than a missing launcher, as in the report. `ProviderRejectionCode` is unchanged; no public tool schema or catalog contract is widened. Refusal behavior is unchanged — only the diagnosis and recovery advice differ. ## Validation ``` npx vitest run src/apktool/ApktoolVersionProbe.test.ts src/apktool/ApktoolConfiguration.test.ts Test Files 2 passed (2) Tests 77 passed (77) ``` New regression: one added row in the existing `distinguishes launcher spawn it.each` (`["EPERM", "command_not_executable"]`), asserting `EPERM` maps to the same denial outcome as `EACCES` and never to `command_missing`. The `EACCES`/`ENOENT` rows are main's, unchanged. Ran on Linux (Node v20.19.2; the pinned `.nvmrc` 24.22.1 toolchain is not installed in this sandbox, tests are unaffected). Coverage limits: the head was exercised on Linux; macOS arm64 and Windows were not re-run. `EPERM` is covered by the shared branch rather than a separate fixture. Real Apktool/JVM decoding is not involved — the launcher is an inert stub, as in the report. The earlier `EACCES` report is recorded in #5177; no native `EPERM` reproduction is available locally. ## Author readiness Unchecked for the human owner to complete. --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
morluto/rea#6804
No description provided.