On iOS, it's possible for the notification granting process to throw
errors, though not very likely. This PR updates updates the plumbing for
how we request user notifications on iOS and respond to the result,
allowing for errors to be propagated back to the user in case something
goes wrong.
Note that unlike installing system extensions and VPN configurations,
disallowing notifications _does not_ result in an error being thrown.
Instead, we receive `false`, and we now track this Bool instead of the
entire `UNAuthorizationStatus` for updating the UI with.
By keeping that Bool `nil` until we load the authorization status, we
fix#7617 as a bonus.
Related: #7714Fixes: #7617
When installing the System Extension or VPN configuration, certain
errors can occur.
Some of these are due to user error and we should further advise the
user how to remedy.
For others, they aren't really actionable, and we silently ignore or
quietly log them.
Resolves: #7714
`fetchResources` is an IPC call. As such, it could potentially take a
long time to execute since the system may need to launch the XPC process
to handle the call.
Since this is called within a 1-second Timer whenever the user has the
MenuBar open (macOS) or is viewing the ResourcesList (iOS), we need to
run these IPC calls in a `Task.detached`.
The resources themselves must be updated on the main thread because
they're an `ObservableObject`, so a bit of refactoring is added to clean
this up a bit.
These can fail sporadically and we don't need to capture them. However,
for users who may be experiencing consistent failures or otherwise
wondering why their client isn't able to check for updates, we leave
them as `warning`.
On Apple, we will silently fail if the tunnel fails to start. This adds
a simple `NSAlert` modal (macOS) or `Alert` popup (iOS) that must be
dismissed before continuing if the tunnel fails to come up, so that the
user has a chance of understanding why.
The vast majority of the time this fails due to DNS lookup errors while
starting connlib.
Related: #7004
Supersedes: #7814
If the user again clicks `Enable System Extension` without having
actually enabled it in system settings, this error will be reported. We
don't necessarily need to act on it.
If the system extension has not been enabled by the user, opening the
`Settings -> Diagnostic Logs` pane will trigger this error. There's
nothing we can do until they enable the system extension, so don't
capture this particular case in Sentry.
When the app starts, we perform various checks in the
`AppViewModel.init` which read and write to disk, which can potentially
be slow (a few seconds), especially for busy rotational hard drives.
These were performed inside a regular `Task` closure, but since
AppViewModel is annotated `@MainActor`, that meant this Task blocked the
main UI thread until the operations completed.
In practice this wasn't an issue because it simply manifested as the app
taking a couple seconds to launch under these conditions.
We fix this by simply using a `Task.detached` which will run the
operations on another thread. Now, the first window will pop up sooner
and immediately show the `ProgressView()` (i.e. a loading spinner icon)
until these operations complete.
A few minor reorganizing of the `os()` macro was also performed because
some of the variables now need to be `await`ed because they live on the
main thread.
refs #7798
Opening URLs using `NSWorkspace.shared.open(url)` (which potentially
launches the browser) is a blocking operation on Apple platforms. This
will cause the UI to hang if called from a UI thread, so we need to
avoid that with a Task.
When starting a Task, by default it's launched with the same priority as
the calling code.
In the UI these are run on the `MainActor` with highest priority by
default. If the worker thread running the Task closure gets blocked, it
will cause the UI to hang.
To fix this, we use `Task.detached` which runs the closure without a
specific priority, which is lower than the UI thread.
Furthermore, `weak self` is used to prevent retain cycles if the parent
thread `deinit`s.
This was causing an issue primarily when making IPC calls because those
will sometimes hang until the XPC service is launched for the first
time.
---------
Signed-off-by: Jamil <jamilbk@users.noreply.github.com>
After reading through this [Apple technical
note](https://developer.apple.com/documentation/technotes/tn3137-on-mac-keychains),
it's clear that we want to actually omit this key from our keychain
queries.
The reason is because:
- on iOS, this will be already set (there is no other option)
- on macOS, the data protection keychain is *unavailable* from system
extensions
After testing, it appears that the original issue that PR sought to fix
was actually fixed by always installing the correct system extension
version: #7759.
Reverts firezone/firezone#7756
When building / testing the Apple clients locally, OS code signing and
security requirements can cause certain types of errors to throw.
We still want to see these in the console, but not necessary capture
them to Sentry.
When a user launches the macOS app, we check if the system extension is
installed. If it was, we assumed it would function properly.
However, an older version of the extension can be installed from our
current app version, so we would erroneously consider the extension as
"installed" even though it needed to be updated.
To fix this, we introduced an enum for tracking the system extension
state with `installed`, `needsReplacement`, and `needsInstall` states.
These track whether the extension is up-to-date, needs upgrade (or
downgrade), or needs to be approved and enabled by the user altogether
respectively.
Importantly, this also gracefully handles downgrades, not just upgrades
since we already return a `.replace` action in our request callback that
the system calls when installing an extension with the same bundle ID as
one that exists.
This will force the macOS Keychain to behave like the iOS Keychain. To
be honest, Apple's documentation is very much lacking in this regard,
but some research suggests this is both heavily recommended by Apple and
that it enables the Keychain operation to benefit from Apple's security
hardware in their Macs.
In my local testing, it also seems to make keychain operations more
reliable when SIP is disabled, but that could be a fluke given the
number of variables at play.
https://developer.apple.com/documentation/security/ksecusedataprotectionkeychain
Draft because stacked.
The Keychain on Apple platforms, while secure, is not always available.
It can be unavailable if the user has changed its permissions
accidentally, the keychain database is corrupt, there is an issue with
the secure enclave, or any number of other system-related or Apple
account-related reasons.
There are only two things we use the Keychain for:
- Storing the `firezone-id`. This is actually not a secret.
- Persisting the `token` upon sign in so that:
- the iOS system can keep the tunnel alive without the GUI running
- the macOS app can relaunch after `Disconnect & Quit` without having to
sign in again
For the first case, we move back to persisting this to a file (see
#7464).
For the second case, we simply don't care too much if the Keychain can't
be saved to. We simply move on with activating the tunnel and logging
the error so we know how often these edge cases occur.
In #7680, I stated that a VPN profile's status goes to `.invalid` when
its associated system extension is yanked. That's not always true. I
observed cases where the profile was still in the `.disconnected` state
with the system extension disabled or removed.
So, now we explicitly check on startup for two distinct states:
- whether the system extension is installed
- whether the VPN profile is valid
Based on this, we show an improved GrantVPNView for macOS only with
clear steps the user must perform to get set up.
If the user accidentally closes this window, they can open the Menubar
and click "Allow VPN permission to sign in" which will both (re)install
the extension and allow the profile.
<img width="1012" alt="Screenshot 2025-01-07 at 5 23 19 PM"
src="https://github.com/user-attachments/assets/c36b078e-835b-4c6e-a186-bc2e5fef7799"
/>
<img width="1012" alt="Screenshot 2025-01-07 at 5 24 06 PM"
src="https://github.com/user-attachments/assets/23d84af4-4fdb-4f03-b8f9-07a1e09da891"
/>
<img width="1012" alt="Screenshot 2025-01-07 at 5 31 41 PM"
src="https://github.com/user-attachments/assets/5b88dfa4-1725-45f2-bd6e-1939b5639cf4"
/>
On macOS, there are two steps the user needs to allow for the VPN
profile to be active: enable the system extension and allow the VPN
profile.
The system extension must be installed before the VPN profile can be
allowed. This PR updates the flow so that the user is prompted to handle
both of those serially. Before, we tried to install the system extension
on launch and prompt the user to allow the profile at the same time.
This PR includes fixes to handle the edge cases where the user removes
the profile and/or extension while the tunnel is connected. When that
happens, the `NEVPNStatus` becomes `.invalid` and we replace the `Sign
In` link in the Menubar with a prompt to restart the grant permissions
flow. On iOS, the behavior is similar -- we move the view back to the
GrantPermissionsView.
Lastly, some refactoring is included to use consistent naming for
`VPNProfile` instead of `TunnelManager` to more closely match what Apple
calls these things.
This is a very minor regression caused by #7555. We didn't bind the
status update observer until after the VPN profile was created. In
practice this didn't cause an issue because the status never changes
until a VPN profile is created, but still thought it's good to fix.
The JSON encoder is now configured in the `init()` as well like any
other instance variable should be.
Although interacting with the Keychain typically involves I/O, there
wasn't a good reason to make all of its functions `async` as this
infects the caller hierarchy. Instead, the calling code should decide
how to wrap the synchronous calls directly with their own preferred
mechanism for dealing with blocking operations.
In practice, it turns out that nearly all of the places we were
interacting with the Keychain was _already_ within some sort of
non-critical Task or equivalent, especially the important parts like the
UI thread. So this complexity is not required.
The Keychain was moved from an `actor` class to a regular enum because
we don't need the serialization guarantees here -- since the calls are
blocking, there is no risk of Keychain operations happening out of
order.
Tested on macOS 15.
If we pass a `completionHandler` to `sendProviderMessage`, the Network
Extension framework will expect that completion handler to be called.
Probably doesn't cause any issue as-is, but it would be better to be
correct here.
- Updates the Sentry release name to follow `component@version` format
- Uses the Sentry `dist` field to set the distribution type,
`appstore|standalone`
- Updates Apple download URL to point to app store or website depending
on package type
- Refactors `AppInfoPlistConstants` to `BundleHelper` to better name
what it does
- Refactor Telemetry module to expose firezoneId and accountSlug for
easier access in the Adapter module
- Set accountSlug to WrappedSession.connect for hydrating the Rust
sentry context
In several places we were unnecessarily wrapping code in either a `Task`
or `DispatchQueue.main.async` block.
The former is only needed if the API we're calling itself exposes an
`async` function or we're running some long-running task.
The latter is typically used for UI updates.
At all other times it is preferable to simply use blocking functions and
let the caller of these best determine how to execute them.
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
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.
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.
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>
