When developing system extensions, Apple's
[documentation](https://developer.apple.com/documentation/DriverKit/debugging-and-testing-system-extensions)
instructs developers to disable SIP and turn on system extension
developer mode to disable certain runtime checks that allow the
extension to run.
It turns out this is completely unnecessary - any properly set up Xcode
toolchain can build a functioning macOS debug client.
When updating the provisioning profiles (i.e. when changing anything the
Apple Developer Portal), we needed to manually update these build
scripts to point to the new UUIDs.
This can be made simpler to automatically pull it out of the profiles in
CI.
Updated the swift/apple README with new added tips for making release
builds from your local machine.
refs #7581
---------
Signed-off-by: Jamil <jamilbk@users.noreply.github.com>
Co-authored-by: Thomas Eizinger <thomas@eizinger.io>
Developer ID certificates are precious. Apple only allows a limited
number of them per account, and once generated, they cannot be revoked.
They are also not compatible with automatic signing and provisioning in
Xcode due in part to the above reasons.
---------
Signed-off-by: Jamil <jamilbk@users.noreply.github.com>
Co-authored-by: Thomas Eizinger <thomas@eizinger.io>
Because the macOS standalone app doesn't go through the same vetting
process as the App Store build, it's a good idea to smoke test it
occasionally. This PR adds instructions for doing so.
To allow macOS users to rollback, it would be helpful to distribute a
standalone macOS app, similar to how we distribute the GUI client.
The first step in this process is to refactor the macOS client to use a
System Extension -based Network Extension rather than an App Extension
based one. This offers us the flexibility to distribute the macOS client
outside the Mac App Store in addition to via the store.
For this PR I focused on making the minimal set of changes necessary to
support this change. This PR intentionally doesn't update the CI
pipeline to notarize and attach a standalone bundle that will run ad-hoc
on other Macs. That will come in a subsequent PR.
One thing to note about System Extensions is that they're slightly more
finicky when it comes to getting the signing and packaging right. Thus,
the README.md is updated to account for the gotchas involved in
developing System Extensions locally.
Related: #7071.
Tried to organize this PR into commits so that it's a bit easier to
review.
1. Involves simplifying the logic in Adapter.swift so that us mortals
can maintain it confidently:
- The `.stoppingTunnel`, `.stoppedTunnelTemporarily`, and
`.stoppingTunnelTemporarily` states have been removed.
- I also removed the `self.` prefix from local vars when it's not
necessary to use it, to be more consistent.
- `onTunnelReady` and `getSystemDefaultResolvers` has been removed, and
`onUpdateRoutes` wired up, along with cleanup necessary to support that.
2. Involves adding the `reconnect` and `set_dns` stubs in the FFI and
fixing the log filter so that we can log them (see #4182 )
3. Involves getting the path update handler working well on macOS using
`SystemConfiguration` to read DNS servers.
4. Involves getting the path update handler working well on iOS by
employing careful trickery to prevent path update cycles by detecting if
`path.gateways` has changed, and avoid setting new DNS if it hasn't.
Refs #4028Fixes#4297Fixes#3565Fixes#3429Fixes#4175Fixes#4176Fixes#4309
---------
Signed-off-by: Jamil <jamilbk@users.noreply.github.com>
Co-authored-by: Reactor Scram <ReactorScram@users.noreply.github.com>
## Changelog
- Updates connlib parameter API_URL (formerly known under different
names as `CONTROL_PLANE_URL`, `PORTAL_URL`, `PORTAL_WS_URL`, and
friends) to be configured as an "advanced" or "hidden" feature at
runtime so that we can test production builds on both staging and
production.
- Makes `AUTH_BASE_URL` configurable at runtime too
- Moves `CONNLIB_LOG_FILTER_STRING` to be configured like this as well
and simplifies its naming
- Fixes a timing attack bug on Android when comparing the `csrf` token
- Adds proper account ID validation to Android to prevent invalid URL
parameter strings from being saved and used
- Cleans up a number of UI / view issues on Android regarding typos,
consistency, etc
- Hides vars from from the `relay` CLI we may not want to expose just
yet
- `get_device_id()` is flawed for connlib components -- SMBios is rarely
available. Data plane components now require a `FIREZONE_ID` now instead
to use for upserting.
Fixes#2482Fixes#2471
---------
Signed-off-by: Jamil <jamilbk@users.noreply.github.com>
Co-authored-by: Gabi <gabrielalejandro7@gmail.com>
- Conditionally set Automatic or Manual provisioning from env (Fixes
#2326)
- Refactor xcconfig structure to make configuring the project simpler
across different envs
- Use consistent parentheses in Makefiles and xcconfigs (Refs #2324)
(Fixes#2334)
- Update CI to run on our self-hosted M1 runner as well (macos-14)
- Sanitize build environment in `build-rust.sh` to keep only needed ENV
vars from Xcode
- Build both `x86_64` and `aarch64` targets with a single `cargo build`
instead of a loop
- Store artifacts in ephemeral locations
Fixes#2329
- Update `CODE_SIGN_STYLE=Manual`. You'll need to make sure to click
`Download manual profiles` in `Settings -> Account` in Xcode to have
them show up and be usable for local development. This is required to do
all this stuff from GitHub Actions.
- Sign the Apple app for distribution on each PR
- Publish the Apple app builds to App Store Connect on merges to `main`
Implements the FFI part of the following issues:
Fixesfirezone/product#669
Refs firezone/product#672
Refs firezone/product#673
~~Log wg stats as well by moving into warn category.~~ This contains
information we want to keep out of our logging infrastructure for now.
Auth base URL and Control Plane URL are configurable in a new
Server.xcconfig (so that we can have Server_Dev.xcconfig,
Server_Staging.xcconfig, and Server_Prod.xcconfig and switch between
them by copying / symbolic linking).
App's Settings View takes in Team ID instead of a URL. App forms auth
URL from Auth base URL from Server.xcconfig and the Team ID in settings.
Tunnel passes control plane URL from Server.xcconfig to connlib.
~~Marked as draft because this PR depends on #1881.~~ #1881 has been
merged.
* Remove JWT to be an opaque token and update variable names accordingly
* Use new `actor_name` param from the portal instead of user info from
old JWT
* Log attempted portal URL from connlib
* Remove account slug/id from portal_url before sending to connlib
@roop The token from the portal is a Phoenix.Token, not a valid JWT, so
this was causing a JWTDecodeError. Discussed with @AndrewDryga and
concluded this should be an opaque token. Expiry and other invalid token
scenarios will be bubbled up from connlib via an `onError` callback (or
perhaps a dedicated `onTokenInvalid` callback). For now connlib doesn't
handle this specifically.
This PR adds the remaining bits of the Apple tunnel stack for macOS and
iOS devices.
- [x] Find file descriptor corresponding to NE-managed tunnel interface
- [ ] Testing
---------
Signed-off-by: Jamil <jamilbk@users.noreply.github.com>
Co-authored-by: conectado <gabrielalejandro7@gmail.com>
This PR improves the build process for the macOS / iOS apps by building
connlib as part of the macOS / iOS app build.
Fixesfirezone/product#625.
This is how the build would work after this PR:
- `build-rust.sh` creates `libconnlib.a` for the appropriate target
triples only. lipo is not used. When creating macOS debug builds, it’s
built only for the native architecture.
- The network extension targets in the Xcode project set a library
search path as the cargo target dir, so that the Xcode build for a
target triple can pickup the appropriate `libconnlib.a` at link time.
Swift code reorganizations:
- connlib’s Adapter has moved to the main app
- connlib’s CallbackHandler’s logic has moved to Adapter, which is set
as CallbackHandler’s delegate. The CallbackHandler serves as an
interface to receive callbacks from the FFI. In case we need to change
the FFI, CallbackHandler should change as well, so it remains in the
connlib directory. In case of changes to the Rust FFI, as part of the
Rust FFI change PR, we can modify the CallbackHandler class and leave
the delegate unchanged, so that the app can continue to be built without
errors.
- `Connlib.xcodeproject` and build scripts for building
`Connlib.xcframework` are removed
- Connlib headers and Swift files are copied to
`FirezoneNetworkExtension/Connlib` as part of the build process, and
used from there.
Rust build changes:
- The rust target dir remains the same, but it’s ~~passed explicitly as
`--target-dir`~~ used to set `CARGO_TARGET_DIR`, so that the same target
dir can be used to populate Xcode’s library search paths
- The `build.rs` for connlib-apple had lots of code to build Swift code
as part of the Rust build. This PR reverts it to the previous simple
version. With this PR, building connlib-apple (i.e. running
`build-rust.sh`) only builds the Rust code.
- ~~We set `cargo:rerun-if-env-changed=CONNLIB_MOCK`.~~ We don't set
this because it's not required.
- The Rust CI job for building connlib-apple is removed. It's built when
the macOS / iOS apps are built in swift.yml. This means that with this
PR, connlib-apple is tested only when `rust/connlib/**` changes, not
when `rust/**` changes. Is that ok?
Other changes not directly related to the build process change but part
of this PR:
- There’s a cleanup script: `./cleanup.sh`
- Fixed a typo in `swift-pass-checks.yml`: “paths-ginore”
