feat: verify script signature for fs loader

[ilteoood]

Summary

Resolves https://github.com/callstack/repack/discussions/1178

Test plan

[changeset-bot[bot]]

🦋 Changeset detected

Latest commit: a1a946d0f3e23f55c8157fbdf7d0282af68d7567

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

This PR includes changesets to release 6 packages

Name	Type
@callstack/repack	Major
@callstack/repack-plugin-expo-modules	Major
@callstack/repack-plugin-nativewind	Major
@callstack/repack-plugin-reanimated	Major
@callstack/repack-dev-server	Major
@callstack/repack-init	Major

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

[vercel[bot]]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
repack-website	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Jun 30, 2025 1:43pm

[ilteoood]

Hey @ilteoood thanks for the PR!

since enabling bundle verification on bundles from filesystem will be a breaking change, we need to add a separate prop to script locator that will enable this verification explicitly (we will target to make this enabled with verifyScriptSignature in the next major version of Re.Pack).

Please add unstable_verifyFilesystemScriptSignature prop along verifyScriptSignature and use it instead for filesystem script verification (the unstable_ prefix is there because we will remove this prop altogether in next major).

Hi @jbroma, I disagree with the fact that is a breaking change.

Looking at the documentation, it doesn't explicitly say that verifySignature is not applied to bundles from filesystem, so just by reading that it should be enabled by default.

The correct behaviour is already documented (it should always verify the signature independently from where it is stored), it's just a matter of feature not implemented so...no breaking change, because is not changing the way in which it behaves now, it's just enriching it.

[jbroma]

Hi @jbroma, I disagree with the fact that is a breaking change.

Looking at the documentation, it doesn't explicitly say that verifySignature is not applied to bundles from filesystem, so just by reading that it should be enabled by default.

The correct behaviour is already documented (it should always verify the signature independently from where it is stored), it's just a matter of feature not implemented so...no breaking change, because is not changing the way in which it behaves now, it's just enriching it.

You are right on both accounts that it is the expected implementation and documentation is actually correct on this and doesn't differentiate between a filesystem and remote bundles.

The problem is that if somebody used code-signing before and also utilised filesystem bundles, with this change they will encounter a runtime. If you manage to show that this won't be an issue it will be ok to ship this without an additional flag.

[ilteoood]

Well, if I got it correctly to apply this new functionality you need to update native dependencies, which means that you must rebuild the whole app instead of just the JavaScript.

Said so, for people that don't rebuild the whole app nothing will change while for the other the functionality will be enabled. At that point, since the code will be signed and verified, no problem should be raised.

Am I missing a critical path?

[jbroma]

Well, if I got it correctly to apply this new functionality you need to update native dependencies, which means that you must rebuild the whole app instead of just the JavaScript.

Said so, for people that don't rebuild the whole app nothing will change while for the other the functionality will be enabled. At that point, since the code will be signed and verified, no problem should be raised.

Am I missing a critical path?

hmm sounds reasonable, havent taken the rebuild into account since the changes lives in native land 👍

I think the only scenario that won't be supported by this will be:

• a case when you ship with bundles produced by other version of Re.Pack - which we can disregard
• code signing plugin had local bundles added to exclude field in it's configuration and project was using a combination of local and remote bundles, which in turn were expected to get verified but the locals were not - with the current change that exclusion will cause an incompatibility - but in the end, I think it's a very exotic combination that might not exist out in the wild

let me know WDYT

[ilteoood]

I think that my project is in this situation: a mix of local and remote bundles and a custom function to handles ota update. But in our scenario everything is working fine 🤔

[jbroma]

I think that my project is in this situation: a mix of local and remote bundles and a custom function to handles ota update. But in our scenario everything is working fine 🤔

perhaps you didn't exclude the bundles and the signature was ignored either way? it's a 1024 byte long comment at the end of the bundle, padded with null characters

[jbroma]

anyways, we've managed to establish that the impact of this is rather non-breaking, worst case scenario we will revert this and hide this behind a flag 👍

I'll proceed to review the code itself and test it 👍

[jbroma]

Thank you for your contribution @ilteoood 🚀

[ilteoood]

@jbroma do you know when the next minor will be released, more or less?

[jbroma]

@jbroma do you know when the next minor will be released, more or less?

The plan is to finalize remaining open PRs + 1 more that is not yet on the GH. The goal is to get this released hopefully next week 👍

EDIT: + RN 0.80 support