This simplifies the logging API and prevents accidentally writing to the
app or tunnel log file from the wrong process.
Tested on macOS and iOS
Fixes#7616
Draft because stacked
In certain weird edge cases such as:
- The user removes the VPN profile while Firezone is signed in, causing
the `NETunnelProviderSession` to go invalid immediately
- The user approves the system extension to load before the VPN profile
access is granted
then the TunnelManager will not be able to obtain a valid reference to a
NETunnelProviderSession object.
In these cases, for now, it makes more sense to fail silently than to
crash, effectively making these operations a no-op until the user
remedies the VPN profile. Currently the user is prompted to re-grant VPN
profile whenever its status goes to `invalid`, so these cases don't
technically fail without prompting the user.
Draft because it's stacked on #7593Fixes#7579Fixes#7591
---------
Signed-off-by: Jamil <jamilbk@users.noreply.github.com>
Co-authored-by: Thomas Eizinger <thomas@eizinger.io>
When launching Firezone for the first time, the VPN profile doesn't
exist. We prompt the user to create it with "Grant VPN Permission", but
then we fail to reload it, which initializes the tunnelManager instance
variables properly and binds observers.
The result of this was that we failed to react to VPN status changes on
the first launch of Firezone.
This can (and should be) refactored to be cleaner, but that is out of
scope for this PR and will be saved for #6554.
Refs #7579
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>
The CI swift workflow needs to be updated to accommodate the macOS
standalone build. This required a decent amount of refactoring to make
the Apple build process more maintainable.
Unfortunately this PR ended up being a giant ball of yarn where pulling
on one thread tended to unravel things elsewhere, since building the
Apple artifacts involve multiple interconnected systems. Combined with
the slow iteration of running in CI, I wasn't able to split this PR into
easier to digest commits, so I've annotated the PR as much as I can to
explain what's changed.
The good news is that Apple release artifacts can now be easily built
from a developer's machine with simply
`scripts/build/macos-standalone.sh`. The only thing needed is the proper
provisioning profiles and signing certs installed.
Since this PR is so big already, I'll save the swift/apple/README.md
updates for another PR.
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.
Standalone distribution requires using a different signing identity
(certificate), set of provisioning profiles, and (annoyingly) requires
the `-systemextension` suffix for our network extension capabilities.
This PR prepares the Xcode environment for building a Standalone app in
CI that will be notarized by matching certificates and provisioning
profiles in our Apple Developer account.
Since we no longer have access to the tunnel's group container from the
app process, we need to move reading the last VPN stop reason to an IPC
call. This call is used to show an alert to the user when their connlib
session has been disconnected due to 401: Unauthorized.
Fixes#7468
Exporting logs on macOS in >= 1.4.0 presents a challenge because the app
process and tunnel process now write to different directories. They do
this because the network extension is now packaged as a system
extension, which means it runs as root.
Since the Apple App Store requires apps to be sandboxed, and we don't
wish to break App Store compatibility just yet, the tunnel process and
app process can't read or write to a common shared directory anymore.
This leaves IPC as the only reliable means for app <-> tunnel
communication. We already use the provided `sendProviderMessage`
function exposed by Network Extension for other operations, so we add
another message type to handle log export.
The log archive from the tunnel needs to be sent in chunks to reduce the
amount of total memory the export process consumes. To facilitate this,
a custom TunnelLogArchive class is used which handles the business logic
of keeping a pointer into the file we're chunking over.
As each chunk is read from the tunnel log archive, we send it using the
`sendProviderMessage`'s completionHandler callback. If the number of
sent bytes is less than our maximum chunk size, we know we're done.
On the app side, we read each chunk of data from the tunnel process
until a `done` boolean is signaled, at which point we close the archive
file we're writing to and complete the export.
Lastly, we need to compress the app and tunnel archives separately, then
compress the final result into a final archive path set by the user.
This is because it's impossible to compress two decoupled directories at
once.
Very little to any noticeable delay is added when performing this over
the previous approach. Exporting multiple GB of log data from the tunnel
took only a second or two on my M1. Presumably, having to read
uncompressed chunks and doing the compression on the app-side would
result in a couple orders of magnitude more IPC calls.
Refs #7071
Since we need to react to state on this instance changing, we need an
instance of TunnelManager to last the lifetime of the app process.
Thus, it makes more sense to use the `.shared` public static pattern to
maintain an instance of it we can use from anywhere instead of having to
store it in various other classes.
The macOS client starting in 1.4.0 uses a system extension for its
network extension package type. This process runs as root and does not
have access to the app's Group Container folder for reading / writing
log files directly, and vice-versa. This means the tunnel now writes its
logs to a separate directory as the GUI app process.
Since the logging functions of clearing logs, calculating their size,
and exporting them assume all the logs are in the same directory, we
need to introduce IPC handlers to ensure the GUI app can conveniently
still perform these functions when initiated by the user.
We already use the Network Extension API `sendProviderMessage` as our
IPC mechanism for adhoc, bi-directional communication through the
tunnel, so we add more handlers to this mechanism to support the logging
functions summarized above.
In this PR we only fix the log size calculation and clear log
functionality. Exporting logs is more involved and will be implemented
in another dedicated PR.
Xcode has decent support for skipping certain build phases when input
files haven't changed. This only happens for build phases within a
single target, and not for entire Target dependencies.
Before, we defined `Connlib` as its own bonafide build target, and then
added it as a target dependency for the network extension targets. This
causes Xcode to always run our `build-rust.sh` script, which takes
around 30s on my M1 even when `rust/` hasn't changed.
Instead, we can remove the `Connlib` target, and add a "Run script"
phase to the network extension targets themselves. By configuring the
input file list, Xcode will skip this phase if `rust/**/*.rs`,
`rust/**/*.toml` and `rust/Cargo.lock` haven't changed.
This makes it **much** faster to iterate on Swift code -- Xcode is
_very_ fast when building pure Swift (sometimes under < 1s).
<img width="1016" alt="Screenshot 2024-12-11 at 6 10 45 PM"
src="https://github.com/user-attachments/assets/29b5f073-3d58-4c07-9592-f9209033c966"
/>
Unlike the App extension which runs as the user, the system extension
introduced in macOS client 1.4.0 runs as `root` and thus cannot read the
App Group container directory for the GUI process. However, both
processes can read and write to the shared Keychain, which is how we
pass the token between the two processes already.
This PR does two things:
1. Tries to read an existing `firezone-id` from the pre-1.4.0 App Group
container upon app launch. This needs to be done from the GUI process.
If found, it stores it in the Keychain.
1. Refactors the `firezone-id` to be stored in the Keychain instead of a
plaintext file going forward.
The Keychain API is also cleaned up and abstracted to be more ergonomic
to use for both Token and Firezone ID storage purposes.
- Installs the system extension on app launch instead of each time we
start the tunnel, as [recommended by
Apple](https://developer.apple.com/documentation/systemextensions/installing-system-extensions-and-drivers).
This will typically happen when the app is installed for the first time,
or upgraded / downgraded.
- Changes the completion handler functionality for observing the system
extension status to an observed property on the class. This allows us to
update the MenuBar based on the status of the installation, preventing
the user from attempting to sign in unless the system extension has been
installed.
~~This PR exposes a new, subtle issue - since we don't reinstall the
system extension on each startTunnel, the process stays running. This is
expected. However, now the logging handle needs to be maintained across
connlib sessions, similar to the Android tunnel lifetime.~~ Fixed in
#7460
Expect one or two more PRs to handle further edge cases with improved UX
as more testing with the release build and upgrade/downgrade workflows
are attempted.
In order to release the new control protocol to users, we need to bump
the versions of the clients to 1.4.0. The portal has a version gate to
only select gateways with version >= 1.4.0 for clients >= 1.4.0. Thus,
bumping these versions can only happen once testing has completed and
the gateway has actually been released as 1.4.0.
Co-authored-by: Jamil Bou Kheir <jamilbk@users.noreply.github.com>
Apple
[requires](https://github.com/firezone/firezone/actions/runs/12161693820/job/33916881718)
network extensions on macOS to be sandboxed. Given this requirement, we
must explicitly allow both the `com.apple.security.network.client` and
`com.apple.security.network.security` entitlements for making outbound
network requests and for opening sockets respectively.
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.
We want to associate additional device information for the device
verification, these are all parameters that tries to uniquely identify
the hardware.
For that reason we read system information and send it as part of the
query params to the portal, that way the portal can store this when
device is verified and match against that later on.
These are the parameters according to each platform:
|Platform|Query Field|Field Meaning|
|-----|----|-----|
|MacOS|`device_serial`|Hardware's Serial|
|MacOS| `device_uuid`|Hardware's UUID|
|iOS|`identifier_for_vendor`| Identifier for vendor, resets only on
uninstall/install|
|Android|`firebase_installation_id`| Firebase installation ID, resets
only on uninstall/install|
|Windows|`device_serial`|Motherboard's Serial|
|Linux|`device_serial`|Motherboard's Serial|
Fixes#6837
This patch adds a notification for updates for macos clients when they
are on an old version.
This is how it looks:
<img width="497" alt="image"
src="https://github.com/user-attachments/assets/829044fd-e8bc-4b47-b64d-67b8ef72adb0">
The orange dot is shown regardless of the notification being dismissed.
If the notification is dismissed by the "Dismiss this version" button,
until there's no new version there won't be notifications.
Updates are check at the start of firezone and every 6 hours after. This
is saved in `UserDefaults`.
Permissions for notifications needs to be allowed so that it's show,
this should be done by the `requestAuthorization`
Also, when an update is available a new `Update available...` option
appears in the menu
<img width="230" alt="image"
src="https://github.com/user-attachments/assets/16d7fea8-3cf5-4711-9d42-5c49faffe6c8">
This option, same as the notification takes you to the appstore.
---------
Signed-off-by: Jamil <jamilbk@users.noreply.github.com>
Co-authored-by: Jamil <jamilbk@users.noreply.github.com>
When the addressDescription looks like a URI, we highlight it with
markdown and set its click handler to open the URL when clicked. We were
also making it bold, which seems to break macOS's menubar width
calculation, causing the field to truncate (typically after `https://`)
instead of expanding the container to contain it.
By removing the bold formatting, the container is properly sized, fixing
the display issue.
# Before
<img width="553" alt="Screenshot 2024-09-07 at 10 44 37 AM"
src="https://github.com/user-attachments/assets/4596bf54-918d-4a59-81d6-a18e436da5ad">
# After
<img width="569" alt="Screenshot 2024-09-07 at 10 45 38 AM"
src="https://github.com/user-attachments/assets/0400731f-e189-4416-a670-d5c3b314d71b">
With this PR we made internet resource disabled by default.
Since no other resource is disalable and internet resource behavior is
particular we remove all client code to make non internet resource
disalable.
Also, since the portal never makes the internet resource that can't be
disabled we remove the whole code path to handle that.
Additionally, some other smaller refactors across the UI wrt internet
resource
Fix#6509
---------
Signed-off-by: conectado <gabrielalejandro7@gmail.com>
Co-authored-by: conectado <conectado@conectados-MacBook-Air.local>
Co-authored-by: Thomas Eizinger <thomas@eizinger.io>
On Apple, we try to be smart about triggering connlib's `reset()` in
order to keep from triggering endless update loops. This can happen
because connlib itself triggers path monitoring updates through
onUpdateRoutes and such.
Before, we only kept track of whether our primary interface changed in
order to consider the path updated. Now, we also track IPv4/IPv6
connectivity and the network's available gateways (read: routers) to
trigger changes. This fixes the case where our interface loses or gains
IPv4 / IPv6 connectivity, or the router address changes.
Fixes#6515
---------
Signed-off-by: Jamil <jamilbk@users.noreply.github.com>
Co-authored-by: Thomas Eizinger <thomas@eizinger.io>
This publishes the 1.3.0 clients and gateways so that Internet Resources
will work.
The feature is still disabled for the Stripe plans until we publish the
launch post. Select customers have the feature enabled.
Closes#2667
[Refs](https://github.com/firezone/firezone/pull/6299#discussion_r1724108733)
The problem right now, after #6325 we send the internet resource up to
the clients. The clients expect a certain format for the resources and
panic if it isn't followed.
Particularly, in the case of no `address` or no `name`.
To fix this, we add a name and an address for the internet resource when
it is converted to the callback type.
Setting the `name` at that point actually makes a lot of sense since it
homogenizes the name across all platforms. But the internet resource
having an address makes no sense.
So in a next PR, when I do the last UI changes I plan to make `address`
optional for all resources on the clients and specialize the display of
the internet resource.
For now I wanted to get this in so that we don't ever panic on the
internet resource existing. (This was tested on all platforms and it
works)
