🔒 Aisle Security Analysis

We found 2 potential security issue(s) in this PR:

1. 🔵 Xcode build-setting injection via unsanitized TEAM_ID in generated BetaRelease.xcconfig

Description

scripts/ios-beta-prepare.sh generates apps/ios/build/BetaRelease.xcconfig and interpolates TEAM_ID directly into xcconfig assignments without validating/sanitizing it.

• Input: TEAM_ID can come from IOS_DEVELOPMENT_TEAM (environment) or --team-id (CLI) without any normalization.
• Sink: TEAM_ID is written verbatim into an .xcconfig file.
• Impact: If an attacker can influence IOS_DEVELOPMENT_TEAM/--team-id (e.g., on a shared CI runner, compromised environment, or when a higher-privileged build script runs with attacker-controlled env), they can inject newlines to add arbitrary xcconfig keys (e.g., override signing settings, bundle IDs, compiler flags) and change how the app is built/signed.

Vulnerable code (excerpt):

TEAM_ID="${IOS_DEVELOPMENT_TEAM:-}"
...
write_generated_file "${BETA_XCCONFIG}" <<EOF
OPENCLAW_DEVELOPMENT_TEAM = ${TEAM_ID}
OPENCLAW_IOS_SELECTED_TEAM = ${TEAM_ID}
EOF

Recommendation

Validate and normalize TEAM_ID before writing it into an xcconfig.

• Strip CR/LF and surrounding whitespace
• Enforce Apple Team ID format (^[A-Z0-9]{10}$)
• (Optional) Apply the same validation in scripts/ios-team-id.sh for the IOS_DEVELOPMENT_TEAM fast-path

Example fix:

TEAM_ID="$(printf '%s' "${TEAM_ID}" | tr -d '\r\n' | xargs)"
if [[ ! "${TEAM_ID}" =~ ^[A-Z0-9]{10}$ ]]; then
  echo "Invalid Apple Team ID '${TEAM_ID}'. Expected 10 uppercase letters/digits." >&2
  exit 1
fi

This prevents newline-based xcconfig injection and ensures the generated build settings are well-formed.

2. 🔵 Potential build setting injection via optional include of gitignored apps/ios/build/Version.xcconfig

Description

apps/ios/Config/Version.xcconfig unconditionally defines version variables and then optionally includes a generated file from apps/ios/build/Version.xcconfig.

Because xcconfig files can define arbitrary Xcode build settings, a tampered or stale apps/ios/build/Version.xcconfig could:

• Override version identifiers (OPENCLAW_*_VERSION) as intended, but also
• Inject unrelated build settings (e.g., CODE_SIGN_ENTITLEMENTS, PRODUCT_BUNDLE_IDENTIFIER, OTHER_SWIFT_FLAGS, etc.) depending on evaluation order, potentially impacting signing/entitlements and build output integrity.

Mitigations exist (the new generator script overwrites this file and rejects symlinks), but the include still creates an implicit trust boundary around a gitignored, workspace-local artifact that may persist across builds or be influenced by CI cache/workspace reuse.

Vulnerable code:

#include? "../build/Version.xcconfig"

Recommendation

Reduce the implicit trust in workspace-local build artifacts.

Options (choose one):

1. Remove the implicit include and instead pass the generated version settings explicitly via xcodebuild/Fastlane using XCODE_XCCONFIG_FILE pointing to a freshly-generated file in a clean temp directory.

2. If keeping the include, harden the generator and build flow:

   • Ensure scripts/ios-write-version-xcconfig.sh is executed in all build entrypoints (CI/Fastlane/Xcode build phases).
   • Consider deleting/recreating apps/ios/build at the start of the build (after verifying it is not a symlink).
   • Validate generated file contents strictly (whitelist only OPENCLAW_GATEWAY_VERSION, OPENCLAW_MARKETING_VERSION, OPENCLAW_BUILD_VERSION) and fail the build if extra keys are present.

Example approach: generate to a temp file and use XCODE_XCCONFIG_FILE (no repo-local include):

TMP_XCCONFIG="$(mktemp -t OpenClawVersion.XXXXXX.xcconfig)"
./scripts/ios-write-version-xcconfig.sh --build-number "$BUILD_NUMBER" >"$TMP_XCCONFIG"
XCODE_XCCONFIG_FILE="$TMP_XCCONFIG" xcodebuild ...

This prevents unexpected overrides from stale or tampered apps/ios/build/Version.xcconfig.

Analyzed PR: #42991 at commit 82b38fe

_{Last updated on: 2026-03-11T10:48:19Z}

Greptile Summary

This PR introduces a complete local Fastlane-based iOS beta release flow covering prepare, archive, and TestFlight upload stages, along with version stamping, watch app icon fix, and bundle ID corrections. The end-to-end flow has been verified with a successful TestFlight upload.

Key changes:

• New beta_archive and beta Fastlane lanes with shared prepare_beta_context helper; old single-lane implementation replaced
• scripts/ios-beta-prepare.sh stamps project.yml version fields, writes a temporary BetaRelease.xcconfig, and regenerates the Xcode project via xcodegen
• scripts/ios-sync-version.ts patches CFBundleShortVersionString and CFBundleVersion in apps/ios/project.yml in-place
• Bundle IDs corrected from ai.openclaw.ios* to ai.openclaw.client* in Signing.xcconfig
• Watch app target gains ASSETCATALOG_COMPILER_APPICON_NAME: AppIcon to fix beta packaging
• apps/ios/project.yml is permanently modified by the prepare step and left dirty in the working tree; developers should revert it after each release run to avoid accidentally committing release version numbers

Confidence Score: 4/5

• Safe to merge — the flow has been verified end-to-end; remaining issues are design limitations and defensive-coding gaps rather than blocking bugs.
• The PR has a confirmed successful TestFlight upload and the core logic is sound. The main concern is that beta_archive unconditionally requires ASC API credentials even when a build number is explicitly provided, which is surprising for an offline-archive use case. Additionally, project.yml is left dirty after every prepare run, risking accidental version commits. Neither issue breaks the primary workflow, but both could catch contributors off-guard.
• apps/ios/fastlane/Fastfile (ASC credential gating in prepare_beta_context) and scripts/ios-beta-prepare.sh (missing empty TEAM_ID guard).

_{Last reviewed commit: 824d720}

Merged via squash.

• Prepared head SHA: 82b38fe93b71e7a06252fb33b8559cebc6c81548
• Merge commit: 2d91284fdb05eb5d8e6b09e10273d02147657890

Thanks @ngutman!