Firezone

Recent Commits

• Jamil(17 Aug 26)

  refactor(portal): rename Device Trust back to Trust Anchors (#14711) The settings page that holds CA certificates was renamed to "Device Trust" a few weeks ago. That name was too broad. The page only stores trust anchors, which validate an upcoming feature, so the tab is called "Trust Anchors" again. It lives at `/settings/trust_anchors`, and the global flag is `trust_anchors` again. A migration renames the row in the `features` table. Device attestation keeps the "device trust" name. When a client connects and we read its MDM device id, serial, and UUID, that is still device trust and nothing there changed. Related: #14640 Co-authored-by: Claude Opus 5 (1M context) <[email protected]>

• Thomas Eizinger(17 Aug 26)

  ci(fuzz): fix grow task template rendering (#14710) The reworked `grow` task never runs: `mise` renders task scripts as templates, and bash's array length syntax for the failed-steps list reads as an unclosed template comment, so both nightly discover jobs fail before fuzzing starts. Tracking the failed steps in a string avoids the clash. Related: #14543 Co-authored-by: Claude <[email protected]>

• Jamil(17 Aug 26)

  feat(portal): identify attributed website users (#14708) ## Summary - validate website attribution parameters, persist them in the signed portal session, and redirect to a clean URL - send anonymous landing events and non-blocking PostHog $identify events after successful portal sign-in or account creation - carry signup attribution through the signed email verification token - cover email OTP, userpass, already-authenticated, and OIDC portal sign-in flows - load POSTHOG_PROJECT_API_KEY through runtime env_var_to_config and disable PostHog when it is unset or blank ## Testing - mix credo --strict - mix format --check-formatted on changed Elixir files - mix test test/portal/config_test.exs test/portal/analytics/post_hog_test.exs test/portal_web/controllers/home_controller_test.exs test/portal_web/live/sign_up_test.exs test/portal_web/session_redirector_test.exs (63 tests) - git diff --check ## Related - Website attribution handoff: https://github.com/firezone/website/pull/441 - Production infrastructure configuration: https://github.com/firezone/infra/pull/835 ---

• Thomas Eizinger(17 Aug 26)

  test(fuzz): anchor roam reset window at portal reconnect (#14709) After a roam under classic ICE, the reference model recorded the connection reset at the end of the dead-socket window. Reconnecting needs the portal though, which only comes back after the portal window, so the model's loss tolerance expired slightly before the client could have finished reconnecting and fuzzing found sequences where the first packet after the roam fell just outside it. Anchoring the reset at the portal reconnect matches when recovery can actually begin. --------- Co-authored-by: Claude <[email protected]>

• Thomas Eizinger(17 Aug 26)

  ci(fuzz): grind past crashes and commit the failing inputs (#14543) A crash ended the fuzz run at its first find and aborted `grow` on the spot, so most of the half hour of coverage discovery was thrown away along with the input that provoked it: the nightly job pushed nothing and the artifact died with the runner. `-ignore_crashes=1` keeps the run going for its whole budget now, and the inputs that failed are packed into the corpus once the coverage measurement is done. That commit is what reports the bug, so the run itself has no need to fail: replaying the pushed corpus turns CI red on the branch until the crash is fixed, and the input goes on covering that code afterwards. Related: #14494 --------- Co-authored-by: Claude <[email protected]>

• Jamil(17 Aug 26)

  ci: publish the iOS IPA on the apple-client release (#14678) MDMs that manage iOS offer the ability to install / manage the client via an IPA package. For example, here is Intune: <img width="845" height="396" alt="Screenshot 2026-08-15 at 4 00 08 PM" src="https://github.com/user-attachments/assets/d77d34e0-fd5c-486f-a0d9-84c4374c61da" /> To support this we expose the ipa as a downloadable artifact on the `apple-client` release.

• Thomas Eizinger(17 Aug 26)

  test(fuzz): derive TCP give-up behaviour from simulated OS (#14656) The fuzzer's simulated TCP clients used a fixed 30s abort timeout, far more aggressive than any real operating system, so connections died in simulated scenarios that every real stack survives. Clients now sample the operating system they simulate and derive their TCP give-up time from it, matching the retransmission budgets of Linux and Android (~15 minutes), macOS and iOS (~7.5 minutes) and Windows (~90 seconds). Future OS-dependent behaviour can hang off the same `SimulatedOs` enum. `smoltcp`'s abort timer counts from the last packet received from the remote even when nothing is outstanding, which would kill idle connections that real stacks keep forever. The OS timeout is therefore paired with short keep-alives: an idle connection stays alive through keep-alive round-trips and only aborts once its path has actually been dead for the OS' duration. --------- Co-authored-by: Claude <[email protected]>

• Jamil(17 Aug 26)

  fix(portal): serve HTTP behind a TLS-terminating proxy (#14705) Firezone used to run behind a proxy that held the TLS certificate and passed the client details along in `X-Forwarded-*` headers. Phoenix holds the certificate itself now, so the client is simply the other end of the socket. #14671 finished that move, but it also removed the option to put your own proxy in front, which self-hosted installs rely on. With `https://` external URLs nothing listened at all, and with `http://` URLs every link and cookie became plain HTTP. The public endpoint now decides once whether a proxy sits in front of it, and nothing behind it asks again. It redirects to HTTPS only while it holds a certificate itself, and it trusts the forwarded headers only on requests that arrive from an address in `PHOENIX_EXTERNAL_TRUSTED_PROXIES`. Every other request has them removed, including the geolocation headers that policy conditions match on. To run behind a proxy, keep the external URLs on `https://` and set `PHOENIX_HTTP_PUBLIC_PORT` plus `PHOENIX_EXTERNAL_TRUSTED_PROXIES`. Your proxy must append to `X-Forwarded-For` rather than pass on what the client sent, and clients with private addresses need their ranges in `PHOENIX_PRIVATE_CLIENTS`. Related: #14671

• Thomas Eizinger(17 Aug 26)

  test(fuzz): match TCP sockets on remote port in assertions (#14703) The TCP connection assertion looked sockets up by their local endpoint only. A client can hold several connections from the same local port to different remotes, keyed by the full 4-tuple, so the assertion could pick the wrong socket and report a destination port mismatch for a healthy connection. Including the remote port in the lookup checks each expected connection against its own socket. Co-authored-by: Claude <[email protected]>

• Thomas Eizinger(17 Aug 26)

  feat(portal): count policy authorizations by iceless status (#14653) The portal already decides per authorization whether the peers can run ICE-less, but nothing records the outcome, so there is no way to tell how far the rollout has actually got. Emit an OpenTelemetry counter for every policy authorization the portal grants, tagged with the resolved decision and with each of the three inputs it is derived from, so that an authorization which stayed on ICE can be attributed to the account feature flag rather than to a peer that never advertised the capability. Authorizations granted over the deprecated 1.4 paths are counted as well, so the denominator is every authorization the portal grants rather than only those on the current handshake. --------- Co-authored-by: Claude <[email protected]> Co-authored-by: Jamil Bou Kheir <[email protected]>

• Firezone Bot(17 Aug 26)

  chore(fuzz): grow committed corpora (#14665) The nightly fuzz jobs discovered new coverage and refreshed each target's uncovered-region ceiling.

• dependabot[bot](17 Aug 26)

  build(deps-dev): bump sobelow from 0.14.1 to 0.15.0 in /elixir (#14680) Signed-off-by: dependabot[bot] <[email protected]> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>

• Jamil(16 Aug 26)

  fix(portal): keep OTel Bandit handler attached on dead sockets (#14701) After #14676 the only error left on staging from scanners is this one: ``` Handler {OpentelemetryBandit, :otel_bandit} has failed and has been detached. Reason=%Bandit.TransportError{message: "Unable to obtain peer_data", error: :einval} ``` It looks like the same kind of noise, but it is not. When a client hangs up in the middle of a request, the OpenTelemetry handler asks Bandit for the client address, Bandit cannot read a socket that is already gone, and the handler raises. `:telemetry` then removes that handler from the node. From that moment the portal records no HTTP traces at all until it restarts. One scanner can switch off tracing for a whole node, and demoting the message to info would only hide that. So this stops the crash instead of hiding it. The portal now attaches a thin wrapper around the OpenTelemetry handler. When the client socket is already gone the wrapper drops the span and the request carries on. Any other failure still crashes the handler and logs at error, because that would be a real bug worth seeing. Related: #14676

• Jamil(15 Aug 26)

  fix(portal): relevel Bandit socket errors and TLS alerts (#14676) Scanners and probes keep knocking on the staging portal. #14672 moved most of the log events they cause from error down to info, but it missed one. When a client hangs up in the middle of a request, Bandit asks the socket for the peer address, gets `:einval` back, and reports that at error level. Only the Thousand Island copy of that event was covered, not the one Bandit logs itself. Both reporting paths now share one list of client-side failures, so the same underlying problem gets the same level no matter which layer logs it. The list also grew to include the other socket errors that mean the peer went away, and the TLS alerts a client can send after the handshake finishes. That last part matters now that the portal terminates public TLS itself. Server problems still log at error: HTTP 5xx, socket errors we do not expect, TLS handshake failures, and any application crash inside a connection process. Related: #14672 Related: #14667

• Jamil(15 Aug 26)

  fix(portal): relevel expected Bandit client errors (#14672) This relevels known client-originated Bandit and Thousand Island failures from error to info using an OTP primary Logger filter. The events remain available in Azure logs, but no longer trip AppLevel=error monitors or the Sentry warning threshold. The filter covers: - closed conn_data lookups returning einval - econnaborted and econnreset connection terminations - Bandit HTTP 4xx protocol errors, including request timeouts and malformed scanner traffic - TLS user_canceled alerts Server-side Bandit HTTP 5xx errors, other transport and TLS failures, telemetry handler failures, and unrelated application errors remain at error level. The sampled production Azure export contained 62 events. This change relevels 60 of them while leaving the two OpenTelemetry handler failures untouched. ## Testing - mix test test/portal/logger_filters_test.exs test/portal/application_test.exs (12 tests passed) - manually verified the Logger pipeline emits client HTTP 400, econnaborted, and TLS user_canceled events at info while preserving HTTP 500 and TLS handshake_failure events at error ---

• Jamil(15 Aug 26)

  chore(deps): bump portal to elixir 1.20.3-otp-29.0.5 (#14673) Picks up the newest Elixir and OTP patch releases for the portal. Alpine stays on 3.23.5, which is already the newest patch on that line.

• Firezone Bot(15 Aug 26)

  chore: publish apple-client 1.5.19 (#14670) Signed-off-by: Jamil <[email protected]> Co-authored-by: Jamil <[email protected]>

• Jamil(15 Aug 26)

  refactor(portal): clean up unused endpoint logic (#14671) ## Summary - serve HTTPS deployments exclusively through the public TLS/SNI endpoint - retain direct Web and API listeners only for plain-HTTP local environments, deriving their ports from the external URLs - remove the rollout-only legacy listener flag and redundant Web/API port settings - simplify Docker Compose while preserving its existing HTTP endpoints PortalWeb.Endpoint and PortalAPI.Endpoint remain logical Phoenix endpoints for their socket and pipeline responsibilities; they no longer bind production HTTPS listeners. Development continues to serve the Web endpoint at https://localhost:13443. ## Testing - mix test test/portal/config/definition_test.exs test/portal/config_test.exs test/portal/endpoint_test.exs test/portal_api/endpoint_test.exs test/portal_api/redirect_to_rest_api_url_test.exs - MIX_ENV=prod mix compile --warnings-as-errors - mix format --check-formatted - mix credo --strict - parsed docker-compose.yml with Ruby YAML

• Brian Manifold(14 Aug 26)

  feat(portal): update REST API for v1 (#14332) Brings the Portal REST API to /v1: every route now lives under a versioned prefix, with the old unversioned routes kept as a deprecated but fully working shim. Deprecation/Sunset/Link response headers are used for the unversioned routes. Also, adds query-param filtering to Sites, Groups, Actors, Resources, Policies, and Gateways, reusing the existing Portal.Repo.Filter framework already used elsewhere in the app.

• Jamil(14 Aug 26)

  fix(portal): polish device posture upgrade and verification UI (#14669) ## Summary - update the Device Posture upgrade splash to describe MDM and EDR integrations - align the Intune verification form with the established Authentication and Directory Sync verification UI - use the standard Verify Now, Verifying, and checked Verified states, tenant status row, reset action, and error flash - cover the splash copy and verification UI states in the Device Posture LiveView test ## Testing - mix test test/portal_web/live/settings/device_posture_test.exs — 22 passed - mix compile --warnings-as-errors - mix format --check-formatted - mix credo --strict

• Jamil(14 Aug 26)

  feat(portal): terminate public TLS in Phoenix (#14667) Add an opt-in public Phoenix ingress that selects on-disk certificates by SNI, dispatches web and API hosts, and redirects HTTP to HTTPS. The mTLS listener obtains the client certificate directly from Bandit peer data, removing the trusted proxy header. Existing listeners remain enabled by default so this image can deploy before the infrastructure cutover. Rollout order: deploy this PR before applying firezone/infra#831 in each environment. Related: firezone/infra#831

• Jamil(14 Aug 26)

  refactor(portal): consolidate feature flag gates (#14668) ## Summary - rename the device posture settings LiveView, file, routes, DOM IDs, and UI copy consistently - centralize the only global rollout flags, device_trust and device_posture, as database-backed Portal.Features checks - show the Device Trust and Device Posture settings tabs from those global rollout flags; show the posture page only with the account entitlement and otherwise show the upgrade splash - keep plan entitlements account-local, add device_posture with a nil default, keep ICE-less hidden from Account settings, and make log_sinks account-local only - remove the sign_up gate and obsolete FEATURE_* runtime configuration - apply the same database rollout gates to device trust and device posture schedulers/workers ## Feature flag inventory - Global DB rollout: device_trust, device_posture - Account-local entitlements: policy_conditions, idp_sync, rest_api, internet_resource, iceless, log_sinks, device_posture - Env: FEATURE_ICELESS_ENABLED only seeds the CI/development account-local ICE-less value; it is not read as a runtime gate - Always enabled: sign_up ## Testing - mix test — 4,721 passed - mix compile --warnings-as-errors - mix format --check-formatted - mix credo --strict --------- Signed-off-by: Jamil <[email protected]>

• Jamil(14 Aug 26)

  feat(portal): sync devices from intune (#14488) Adds a Device Integrations page in Settings where an admin grants Microsoft admin consent to one Intune tenant. From then on a job pulls that tenant's managed device list every two hours and stores it, so we have a record of company devices whether or not they ever connect to Firezone. The page shows the tenant, how many devices came back, and how many are compliant. Each device gets a row with a column per property. Seven properties are always empty: Graph withholds them from list queries, and `$select` does not bring them back even for a single device. Entra directory sync and Intune both talk to Microsoft Graph, so the two API clients become one. Each keeps its own app registration and consent flow. All of this sits behind a `device_posture` feature flag, both global and per account, and is off for everyone until we turn it on. Nothing reads the synced devices yet. Tying them to the devices table, and using the compliance fields in policies, come in later PRs.

• Jamil(14 Aug 26)

  fix(portal): verify Google directory admins via delegation (#14666) ## Summary - request only `openid email` from the dedicated Google directory authorization client - verify the signed ID token, including audience, issuer, expiry, PKCE-bound nonce, verified email, subject, and hosted-domain claims - impersonate the exact signed-in email through domain-wide delegation with only `admin.directory.customer.readonly` - call `customers/my_customer` to enforce the signed-in user permission and compare the returned customer ID with the configured sync customer - keep customer-read verification tokens isolated from full sync tokens in the cache ## Security properties A non-admin in the configured Workspace cannot pass the Admin SDK probe. An admin from another Workspace receives a different customer ID and cannot bind that Workspace to the Firezone account. Interactive OAuth credentials are never used to access the Admin SDK. ## Deployment The existing `GOOGLE_SYNC_AUTHZ_CLIENT_ID` and `GOOGLE_SYNC_AUTHZ_CLIENT_SECRET` remain in use. Its OAuth consent configuration only needs `openid` and `userinfo.email`. The domain-wide delegation grant for the sync service account must retain `admin.directory.customer.readonly` along with the normal sync scopes. ## Tests - `mix test` — 4,645 passed - `mix test test/portal_web/controllers/oidc_controller_test.exs` — 154 passed after the Dialyzer fix - `mix compile --warnings-as-errors` — passed - `mix dialyzer --format dialyxir` — passed - `mix credo --strict` — passed with existing TODO suggestions

• Jamil(14 Aug 26)

  fix(portal): preserve verification process node (#14664) ## Summary - preserve the originating Erlang node when encoding the LiveView PID into OAuth verification state - encrypt the node-aware PID value so internal node names are not exposed to browsers or identity providers - use the node-aware encoding for Google, Okta, generic OIDC, Entra authentication, Entra directory sync, and Google directory sync verification callbacks - continue accepting legacy local PID strings for callbacks already in flight during deployment - reject malformed and authenticated non-PID values ## Root cause Verification state previously stored a PID as text such as `<0.23297.0>`. That representation identifies the process only on the node where it was created. When a callback was routed to another portal node, `list_to_pid/1` interpreted it as a local PID on the callback node and could not retrieve the pending PKCE verification session. The replacement uses an encrypted Erlang external PID representation. It retains the source node, allowing the callback and result controllers to communicate with the original LiveView across the connected cluster. Okta directory sync is not changed because its verification is synchronous and has no OAuth callback. ## Testing - 396 focused OIDC controller, verification controller, authentication LiveView, directory LiveView, and OIDC helper tests - `mix format --check-formatted` - `mix credo --strict` - manual two-node BEAM test confirming the value decodes to the exact remote PID, supports remote signaling, and does not expose the node name

• Jamil(14 Aug 26)

  fix(portal): open Google directory verification (#14663) ## Summary - keep the `OpenURL` hook mounted while Google directory verification changes the button to its loading state - reserve the authorization window synchronously from the click gesture so the Google API preflight does not trigger popup blocking - navigate the reserved window when the OAuth URL is ready and close it when preflight fails - add regression coverage for Google verification from an existing directory edit form ## Root cause Google directory verification now performs service-account and Admin SDK preflight requests before generating the OAuth URL. The original hook lived on the Verify Now button, but LiveView replaced that button with Verifying... before the delayed `open_url` event arrived. This destroyed the event listener. The delayed `window.open` could also be rejected as an unsolicited popup. ## Testing - `mix format --check-formatted` - 207 focused directory sync and OIDC tests - `mix assets.build` - `mix credo --strict`

• Jamil(14 Aug 26)

  fix(portal): keep revocation list inside the panel (#14662) The revocation list showed the full CRL address in every row. Those addresses are long, so the table grew wider than the panel and pushed the expand arrow past the right edge of the screen, where nobody could click it. Rows now stay inside the panel and cut long names and addresses off with an ellipsis. The arrow is visible again, and expanding a row still shows the full address.

• Jamil(14 Aug 26)

  fix(portal): authorize Google directory setup (#14661) ## Summary - require interactive Google OAuth authorization before verifying a Google Workspace directory - use the dedicated `GOOGLE_SYNC_AUTHZ_CLIENT_ID` and `GOOGLE_SYNC_AUTHZ_CLIENT_SECRET` for directory verification, independently of the `GOOGLE_OIDC_CLIENT_ID` used by the Google authentication provider - request only `https://www.googleapis.com/auth/admin.directory.customer.readonly` with authorization code and PKCE, then call `customers/my_customer` to prove the consenting user has the required Workspace administrator permission - preflight the configured impersonation identity through the service account and compare its immutable Workspace customer ID with the interactive administrator customer ID - keep the customer ID only in ephemeral verification state; persist only the verified domain and existing verification fields - reject Workspace mismatches, replayed callbacks, stale verification sessions, and client-supplied verification fields - preserve existing verified Google directory records so current syncs continue without forced re-verification ## Security impact This prevents a Firezone account administrator from entering an impersonation email from another Workspace that already granted domain-wide delegation to Firezone and attaching that Workspace to their Firezone account. Verification now proves both sides belong to the same Workspace: the configured service-account impersonation identity and the user authorizing directory setup. The interactive Admin SDK request also proves that the authorizing user has permission to read the Workspace customer record. ## Rollout requirements Deployments must provide `GOOGLE_SYNC_AUTHZ_CLIENT_ID` and `GOOGLE_SYNC_AUTHZ_CLIENT_SECRET` for a dedicated Google OAuth web application. This is separate from the Google authentication-provider client configured by `GOOGLE_OIDC_CLIENT_ID`. The dedicated application must allow `https://www.googleapis.com/auth/admin.directory.customer.readonly` and have the Firezone Google directory verification callback registered as an authorized redirect URI. This sensitive scope may require Google verification for production. ## Testing - `mix format --check-formatted` - 230 focused Google directory, callback, LiveView, and OIDC tests - `mix credo --strict` Rebased directly on `main`.

• Jamil(14 Aug 26)

  fix(portal): validate OIDC issuer and nonce (#14659) ## Summary - require and retain the issuer from OIDC discovery, then validate each ID token issuer against it - bind Google, Okta, and generic OIDC authorization requests and callbacks with a nonce derived from the server-held PKCE verifier - preserve the documented Google legacy issuer and Microsoft tenant-independent issuer-template behavior - prevent additional authorization parameters from overriding state, nonce, or PKCE parameters ## Dependency This is intentionally stacked on #14658 because the shared verifier must support the Microsoft Entra tenant-independent discovery issuer introduced and exercised by that PR. It can be retargeted to main after #14658 merges. ## References - https://developers.google.com/identity/openid-connect/openid-connect#validatinganidtoken - https://learn.microsoft.com/en-us/entra/identity-platform/access-tokens#validate-the-issuer ## Testing - mix test - 4,610 tests passed (6 doctests, 4,604 tests)

• Jamil(14 Aug 26)

  fix(portal): authorize Entra tenant setup (#14658) The Microsoft Entra admin-consent callback contains an unsigned tenant query parameter and cannot be used as proof that the current user controls that tenant. This change treats that callback as untrusted and adds a signed, user-bound verification step before associating an Entra tenant with a Firezone account. - Follow Entra admin consent with a tenant-specific OIDC authorization-code and PKCE flow. - Validate the ID-token signature, audience, issuer, tenant, nonce, signing-key issuer, and immutable user object ID. - Require a tenant-wide Global Administrator or Privileged Role Administrator to complete auth-provider setup using the signed wids claim. - For directory sync, bind the verified user object ID to an app-only Graph lookup of effective directory roles, then verify the granted app roles and required Graph endpoints. - Attempt the identity proof silently using the existing Microsoft session, with an interactive fallback only when Entra requires it. - Keep pending verification state bound to a short-lived reference and consume it before code exchange. Rollout requirements: - The Entra authentication app registration must set groupMembershipClaims to DirectoryRole. - The Entra directory-sync app registration must declare the delegated Microsoft Graph openid and profile permissions in addition to its existing application permissions. Re-granting admin consent lets the identity-proof leg complete without a second consent prompt. Testing: - mix format --check-formatted - mix test: 4,600 passed (6 doctests and 4,594 tests) - Manually verified Entra authentication-provider and directory-sync setup in dev. ---