feat(e2e-latest): enable New Architecture (RN 0.84)#1249
Conversation
…ure support Add mobile-devtools plugin to all examples for reproducible builds via Nix. Upgrade E2E-latest to RN 0.84 with New Architecture enabled, including Gradle 9, cmake 4.1.2, react-native-screens 4.25.2, and native-stack navigation. Add E2E mobile CI workflow. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
abueide
force-pushed
the
feat/e2e-latest-new-arch
branch
from
37aa4da to
158781a
Compare
![semgrep-code-segmentio-2[bot]](https://avatars.githubusercontent.com/u/819518?s=60&v=4){kind=small}
| ${{ runner.os }}-pods-latest- | ||
|
|
||
| - name: Install Devbox | ||
| uses: jetify-com/devbox-install-action@v0.14.0 |
There was a problem hiding this comment.
Semgrep identified an issue in your code:
GitHub Action jetify-com/devbox-install-action@v0.14.0 uses a mutable version tag instead of a pinned commit SHA, allowing attackers who compromise the action's repository to inject malicious code into your workflow.
More details about this
The GitHub Action jetify-com/devbox-install-action is referenced using a semantic version tag v0.14.0 instead of being pinned to a specific commit SHA.
Exploit scenario:
- An attacker gains write access to the
jetify-com/devbox-install-actionrepository (either by compromising maintainer credentials or via a social engineering attack) - The attacker pushes malicious code to the repository and re-tags the
v0.14.0release or creates a newv0.14.0tag pointing to their backdoored commit - When this workflow runs, GitHub resolves
@v0.14.0to the attacker's new commit - The
devbox-install-actionstep executes the attacker's malicious code with access to your repository's source code, secrets, and CI environment - The attacker could exfiltrate credentials, inject code into your build, or compromise downstream dependencies
Because you're using a mutable version tag rather than an immutable commit SHA, you have no way to verify that the code running today is the same code that ran yesterday.
To resolve this comment:
✨ Commit fix suggestion
| uses: jetify-com/devbox-install-action@v0.14.0 | |
| uses: jetify-com/devbox-install-action@<full-40-character-commit-sha> # v0.14.0 | |
| # TODO: Replace <full-40-character-commit-sha> with the commit SHA for the trusted v0.14.0 tag from jetify-com/devbox-install-action. |
View step-by-step instructions
- Replace the third-party action reference
jetify-com/devbox-install-action@v0.14.0with the full 40-character commit SHA for the exact action revision you want to trust, for examplejetify-com/devbox-install-action@<full-commit-sha>. - Keep the same action name and only change the version part after
@so the workflow still usesjetify-com/devbox-install-action, but as an immutable revision. - Get the SHA from the action's repository release or tag that matches
v0.14.0, and use the commit object behind that tag rather than the tag name itself. - Add a comment next to the pinned reference with the original tag for readability, for example
uses: jetify-com/devbox-install-action@<full-commit-sha> # v0.14.0. Pinning to a commit SHA prevents the action code from changing without updating this workflow.
Alternatively, if you cannot verify which commit matches v0.14.0, update to a newer trusted release and pin that release's full commit SHA instead.
💬 Ignore this finding
Reply with Semgrep commands to ignore this finding.
/fp <comment>for false positive/ar <comment>for acceptable risk/other <comment>for all other reasons
Alternatively, triage in Semgrep AppSec Platform to ignore the finding created by third-party-action-not-pinned-to-commit-sha.
Need help with this issue? Consult our Semgrep Findings Documentation or ask in #help-appsec on Slack.
You can view more details about this finding in the Semgrep AppSec Platform.
| ${{ runner.os }}-pods-compat- | ||
|
|
||
| - name: Install Devbox | ||
| uses: jetify-com/devbox-install-action@v0.14.0 |
There was a problem hiding this comment.
Semgrep identified an issue in your code:
GitHub Action pinned to version tag instead of commit SHA allows attacker to inject malicious code that runs in your CI/CD pipeline.
More details about this
The GitHub Action jetify-com/devbox-install-action is pinned to the version tag v0.14.0 rather than a full commit SHA. This means the action's code can be updated at any time by the repository maintainers without your workflow noticing the change.
An attacker who compromises the jetify-com/devbox-install-action repository could inject malicious code into the v0.14.0 tag. When your workflow runs, it would execute this compromised action and the attacker could:
- Execute arbitrary commands in your CI/CD environment
- Steal secrets or environment variables like
IOS_DEVICES,IOS_DEFAULT_DEVICE, or any credentials passed to subsequent steps - Modify your build artifacts or inject code into your application
- Access your repository or deploy credentials
Since you're using this action in a CI/CD pipeline that builds iOS dependencies and runs tests, a compromised action would have full access to your build environment, source code, and any credentials available during the workflow execution.
To resolve this comment:
✨ Commit fix suggestion
| uses: jetify-com/devbox-install-action@v0.14.0 | |
| # TODO: Replace the placeholder below with the verified full 40-character commit SHA for the trusted | |
| # `v0.14.0` release of `jetify-com/devbox-install-action`. A full SHA is required to make this action | |
| # reference immutable and satisfy the Semgrep finding. | |
| uses: jetify-com/devbox-install-action@<full-commit-sha-for-v0.14.0> |
View step-by-step instructions
-
Replace the third-party action tag with a full 40-character commit SHA in the
usesline forjetify-com/devbox-install-action.
Changejetify-com/devbox-install-action@v0.14.0tojetify-com/devbox-install-action@<full-commit-sha-for-v0.14.0>. -
Get the SHA from the action's repository release or tag that you intend to trust, and pin exactly that commit.
For example, use the commit behind thev0.14.0tag, not the tag name itself. -
Keep the rest of the step unchanged, including the existing
with:values such asenable-cache: trueandproject-path: examples/E2E-compat.
Pinning to a commit SHA makes the action reference immutable, so the workflow does not silently pick up different code later. -
Alternatively, if you cannot verify that
v0.14.0points to a trusted commit, update to a newer trusted release first, then pin that release's full commit SHA instead of using a version tag.
💬 Ignore this finding
Reply with Semgrep commands to ignore this finding.
/fp <comment>for false positive/ar <comment>for acceptable risk/other <comment>for all other reasons
Alternatively, triage in Semgrep AppSec Platform to ignore the finding created by third-party-action-not-pinned-to-commit-sha.
Need help with this issue? Consult our Semgrep Findings Documentation or ask in #help-appsec on Slack.
You can view more details about this finding in the Semgrep AppSec Platform.
| ${{ runner.os }}-gradle-latest- | ||
|
|
||
| - name: Install Devbox | ||
| uses: jetify-com/devbox-install-action@v0.14.0 |
There was a problem hiding this comment.
Semgrep identified an issue in your code:
The devbox-install-action is pinned to a version tag instead of a commit SHA, allowing attackers who compromise the repository to inject malicious code into your workflow.
More details about this
The jetify-com/devbox-install-action is pinned to a version tag (v0.14.0) rather than a full commit SHA. An attacker who controls the jetify-com/devbox-install-action repository could push malicious code to that tag or force-push the tag to point to a different commit, and your workflow would execute the attacker's code without detection.
Here's how an attacker could exploit this:
- The attacker gains control of the
jetify-com/devbox-install-actionrepository (by compromising the maintainer's account, for example). - They force-push the
v0.14.0tag to point to a new commit containing malicious code—for example, code that exfiltrates repository secrets or injects a backdoor into your build artifacts. - On the next workflow run, this step executes the malicious code because
@v0.14.0now resolves to the attacker's commit. - The malicious code runs with access to your repository secrets (visible in
${{ secrets.* }}) and can modify your build output, exposing your application to your users.
Using a full commit SHA (like @a1b2c3d4e5f6...) would prevent this because tags can be moved, but commit SHAs are immutable.
To resolve this comment:
✨ Commit fix suggestion
| uses: jetify-com/devbox-install-action@v0.14.0 | |
| # TODO: Replace with the full 40-character commit SHA for jetify-com/devbox-install-action v0.14.0. | |
| uses: jetify-com/devbox-install-action@<full-commit-sha-for-v0.14.0> # v0.14.0 |
View step-by-step instructions
-
Replace the third-party action reference with a full 40-character commit SHA instead of the version tag.
Changeuses: jetify-com/devbox-install-action@v0.14.0touses: jetify-com/devbox-install-action@<full-commit-sha-for-v0.14.0>. -
Resolve the SHA from the action repository by opening the
v0.14.0release or tag injetify-com/devbox-install-actionand copying the exact commit ID for that revision.
Use the full SHA, not a short SHA and not the tag name. -
Keep the rest of the step unchanged, including the existing
with:values such asenable-cache: trueandproject-path: examples/E2E-latest.
Pinning to a commit makes the action version immutable, so the workflow cannot silently pick up different code later.
Alternatively, if you need an easier update process, add a comment next to the pinned SHA with the original version, for example # v0.14.0, while still keeping uses: pinned to the full commit SHA.
💬 Ignore this finding
Reply with Semgrep commands to ignore this finding.
/fp <comment>for false positive/ar <comment>for acceptable risk/other <comment>for all other reasons
Alternatively, triage in Semgrep AppSec Platform to ignore the finding created by third-party-action-not-pinned-to-commit-sha.
Need help with this issue? Consult our Semgrep Findings Documentation or ask in #help-appsec on Slack.
You can view more details about this finding in the Semgrep AppSec Platform.
| ${{ runner.os }}-gradle-compat- | ||
|
|
||
| - name: Install Devbox | ||
| uses: jetify-com/devbox-install-action@v0.14.0 |
There was a problem hiding this comment.
Semgrep identified an issue in your code:
GitHub action jetify-com/devbox-install-action@v0.14.0 is not pinned to a commit SHA, allowing an attacker who gains repository access to inject malicious code into your CI/CD pipeline.
More details about this
The jetify-com/devbox-install-action action is pinned to a version tag (v0.14.0) instead of a full commit SHA, making it vulnerable to malicious modifications.
How an attacker could exploit this:
- An attacker gains write access to the
jetify-com/devbox-install-actionrepository (e.g., through compromised credentials or social engineering). - The attacker adds malicious code to the repository and tags it as
v0.14.0(overwriting the existing tag or creating the tag if it doesn't yet exist). - When your workflow runs and executes
uses: jetify-com/devbox-install-action@v0.14.0, GitHub resolves this tag to whatever commit the attacker pushed. - The attacker's malicious code runs in your CI/CD environment with access to your repository secrets, environment variables, and build artifacts—potentially stealing credentials, injecting backdoors into your build, or exfiltrating sensitive data.
By pinning to a full commit SHA (e.g., uses: jetify-com/devbox-install-action@abc123def456...), the action reference becomes immutable. The attacker would need to forge a SHA-1 collision to substitute malicious code, which is cryptographically infeasible.
To resolve this comment:
✨ Commit fix suggestion
| uses: jetify-com/devbox-install-action@v0.14.0 | |
| # TODO: Replace with the exact 40-character commit SHA for jetify-com/devbox-install-action v0.14.0. | |
| uses: jetify-com/devbox-install-action@<full-commit-sha> # v0.14.0 |
View step-by-step instructions
-
Replace the version tag in the
usesvalue with the full 40-character commit SHA for the exactjetify-com/devbox-install-actionrelease you want to keep using.
Changejetify-com/devbox-install-action@v0.14.0tojetify-com/devbox-install-action@<full-commit-sha>. -
Look up the commit SHA that backs the
v0.14.0tag in the action's repository, and pin to that exact commit instead of the mutable tag.
Use the action's releases or tag page to find the commit, then update the workflow line to something likeuses: jetify-com/devbox-install-action@<40-char-sha>. -
Keep the existing
with:settings unchanged after pinning.
Pinning by SHA makes the action reference immutable, so a tag move or repository compromise cannot silently change what runs in CI.
Alternatively, if you need easier version updates, add the original version as a comment next to the pinned SHA, for example uses: jetify-com/devbox-install-action@<40-char-sha> # v0.14.0.
💬 Ignore this finding
Reply with Semgrep commands to ignore this finding.
/fp <comment>for false positive/ar <comment>for acceptable risk/other <comment>for all other reasons
Alternatively, triage in Semgrep AppSec Platform to ignore the finding created by third-party-action-not-pinned-to-commit-sha.
Need help with this issue? Consult our Semgrep Findings Documentation or ask in #help-appsec on Slack.
You can view more details about this finding in the Semgrep AppSec Platform.
|
Semgrep found 16
GitHub Actions step uses a mutable tag or branch reference. Tags and branch names can be silently repointed by the action owner, enabling supply-chain attacks — as seen in the trivy-action and kics-github-action compromises. Pin the reference to a full 40-character commit SHA instead, e.g. Need help with this issue? Consult our Semgrep Findings Documentation or ask in #help-appsec on Slack. |
1 participant
Summary
Enables New Architecture on the E2E-latest example app (RN 0.84.1) to catch interop issues like the trackDeepLinks crash (#1147) in CI.
Changes
newArchEnabled=trueon Androidsettings.gradlefor RN 0.84 autolinking (replaces oldnative_modules.gradle)kotlin-androidplugin, bump Kotlin to 2.1.20Podfile(remove deprecatedflags,M1_workaround, deployment target override)minSdkVersionto 24 (New Arch requirement)Stack
Why
RN 0.84 defaults to New Architecture. Testing with it enabled will expose bridging/interop issues before they reach users.
🤖 Generated with Claude Code