feat: allow optionally disabling Swift sandbox

[carlocab]

If cargo is invoked inside a sandbox on Darwin, the build will fail when it invokes swift. This is because swift builds within its own sandbox by default, but nested sandboxes are not allowed on Darwin.

This is the case, for example, when building sentry-cli inside Homebrew.

For builds that already happen inside a sandbox, allow setting an environment variable SWIFT_DISABLE_SANDBOX which then results in swift being invoked with --disable-sandbox to enable the build to succeed.

[szokeasaurusrex]

@carlocab, how are you building Sentry CLI when encountering this error? We only should be calling swift when building the apple-catalog-parsing optional dependency, which should only happen when building Sentry CLI with the optional unstable-mobile-app feature.

If you have any logs, that would be helpful to share, thanks!

[carlocab]

We just use cargo install, as shown here: https://github.com/Homebrew/homebrew-core/blob/11a4618b28d5cb2dc5cd258be0995df8441846e6/Formula/s/sentry-cli.rb#L39

In practice, that expands to something like

cargo install --jobs 4 --locked --root=/opt/homebrew/Cellar/sentry-cli/2.47.0 --path=.

in the source directory.

We're not enabling/disabling any features, so it looks like swift is being invoked even when the unstable-mobile-app feature is not being explicitly enabled.

[carlocab]

Based on this

sentry-cli/Cargo.toml

Lines 113 to 115 in 270c6e3

	[target."cfg(target_os = \"macos\")".dependencies]
	mac-process-info = "0.2.0"
	apple-catalog-parsing = { path = "apple-catalog-parsing" }

It looks to me that apple-catalog-parsing is built as soon as you are targeting macOS, regardless of the configuration of unstable-mobile-app.

[szokeasaurusrex]

It looks to me that apple-catalog-parsing is built as soon as you are targeting macOS, regardless of the configuration of unstable-mobile-app.

Ah indeed, nice catch! I'll do a quick update to remove this, as at least for now, we should only compile apple-catalog-parsing when the feature is enabled.

[szokeasaurusrex]

Hey @carlocab, can you try building with Sentry CLI 2.47.1? This release removes the apple-catalog-parsing dependency from macOS.

We still will need to fix this problem once we add the functionality currently hidden under -Funstable-mobile-app into the main binary, but this gives us more time.

Also, could you perhaps provide some references to explain why this change is needed/why we need to resolve it in Sentry CLI? I am not very familiar with Homebrew's build process.

I am also a bit confused about why Homebrew even needs to build Sentry CLI. The Sentry CLI we release in the getsentry/tools tap simply pulls the prebuilt binaries. Why not just do this for the Homebrew-Core version of Sentry CLI?

[carlocab]

Also, could you perhaps provide some references to explain why this change is needed/why we need to resolve it in Sentry CLI? I am not very familiar with Homebrew's build process.

Which part would you like me to explain further? The important thing to consider is that:

• swift invokes a sandbox whenever you do swift build, unless you pass --disable-sandbox
• on macOS, sandboxes cannot be nested
• trying to do swift build without --disable-sandbox will result in an error if you're already in a sandbox (because sandboxes cannot be nested)

Homebrew's build process was just an example of a build that happens inside a sandbox. This can affect any other user that tries to build sentry-cli in a sandbox. Given that, it seems to me that it makes the most sense to fix here, rather than to have various downstream users try to patch your source on their own.

I am also a bit confused about why Homebrew even needs to build Sentry CLI. The Sentry CLI we release in the getsentry/tools tap simply pulls the prebuilt binaries. Why not just do this for the Homebrew-Core version of Sentry CLI?

Probably for the same reasons why nearly every package manger here (except perhaps Scoop and winget) builds Sentry CLI from source instead of fetching a prebuilt binary: https://repology.org/project/sentry-cli/versions

In homebrew-core, we build all packages from source. This allows us to make better guarantees about the provenance of binaries, and gives us more control over the packaging process (which in turn helps us better provide binaries that work well on our user's systems).

[szokeasaurusrex]

Okay, thanks for explaining @carlocab, seems reasonable

[noahsmartin]

Looks good to me thanks @carlocab !

[carlocab]

Thanks both!