-
Notifications
You must be signed in to change notification settings - Fork 1.4k
Reinstate manifest sandboxing #2848
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Reinstate manifest sandboxing #2848
Conversation
Manifest loading has been sandboxed on macOS for a while, but the change in swiftlang#2518 broke it for 5.3. https://bugs.swift.org/browse/SR-13346 rdar://problem/66586184
This adds tests for manifest sandboxing. Since we made the sandbox more restrictive in 5.3, there are two tests: - in 5.2 we check if we can make a network request - in 5.3 we check if we can launch a process
@swift-ci please smoke test |
Looks like the 5.3 profile is actually too restrictive. |
We need to allow process launches, so that we can even launch the compiled manifest. We also need to allow reads, because otherwise we can't load the PD dylibs. |
@swift-ci please smoke test |
Hm, looks like we were able to leave the sandbox on CI 🤔 |
Failure happens on both macOS CI hosts, so looks like it is consistent. Locally, the test works as expected, the network call is denied. Maybe the failure happens in constructing the URL vs. the actual network call? |
maybe use a different action that does not require network access? |
It doesn't actually matter whether or not the request would succeed since the test assumes it will always be blocked.
I was intentionally using a network request since it seems important to test that this is still blocked. |
@swift-ci please smoke test |
Looks like using an IP address instead of a domain works. |
Manifest loading has been sandboxed on macOS for a while, but the change in #2518 broke it for 5.3.
https://bugs.swift.org/browse/SR-13346
rdar://problem/66586184