SupiVPN v0.10.0

SupiVPN v0.10.0

Changes since v0.9.1.
Release commit: 7369ca98d3f74caa50fd1a96ded4408fb25c009a.

Changes

• Add essential Prometheus-format metrics without new dependencies. Metrics are
  disabled by default and enabled explicitly in configuration. VM components
  use a separate TLS listener; public Lambda requires a dedicated Bearer token
  loaded from Secrets Manager. Collection has bounded work, timeouts and caching.
  See metrics configuration.
• Finish the profile migration announced in v0.8.0: remove unbound admission,
  the legacy agent/metadata mode and controller node allowlist. Both VM and
  Lambda enforce active profile proof and verified SAML ownership. Historical
  unbound logins cannot complete authorization, deliver a grant or acknowledge
  it after the upgrade.
• Remove offline unbound issuance through supivpn-profile -out/-template.
  Wrapping-key initialization with -init remains supported; obtain client
  profiles through SAML-authorized download or OpenVPN Connect import.
• Update the pinned Pages upload/deploy actions to native Node.js 24 versions,
  keeping the signing, artifact checks and publication gates unchanged.

Compatibility

Breaking for unbound users: v0.8.x and v0.9.x were the migration window;
v0.9.x, starting with v0.9.1, is the last compatible series with the explicit legacy listener.
Complete migration there before installing v0.10.0. Download bound replacements
through SAML, verify them, drain/stop legacy agents and OpenVPN listeners, and
close their old ports/routes. Remove legacy_profile_nodes from every combined,
public and agent controller configuration, even if empty or null. Old legacy
configuration now fails validation instead of silently enabling weaker access.
See upgrade and rollback.

Schema remains 12 with the same runtime grants. No database migration or
reissue of existing bound profiles is needed. Preserve wrapping keys, TLS trust
and existing bound endpoint/ports. Bound UDP-only and UDP/TCP profiles remain
supported; TCP and metrics are disabled by default. OpenVPN is unmodified.

Upgrade controller/Lambda and node binaries together in a maintenance window;
mixed v0.9/v0.10 server components are not a supported rolling-upgrade matrix.
A Lambda update alone does not stop an existing unbound tunnel. Preserve
revocations, replay history and node generations; do not delete live login rows
or down-migrate the database. Rollback requires a tested, matching schema-12
server pair and saved configuration. Re-enabling v0.9.x legacy mode restores
its old profile-sharing/relay risk.

VM metrics intentionally have TLS without application authentication in the
minimal deployment; restrict reachability to monitoring hosts. Lambda metrics
require separate route, IAM/KMS and token configuration. Native Connect,
live AWS metrics deployment and a full Debian VM metrics acceptance run remain
deployment acceptance checks; do not infer them from unit or container tests.

Validation

Main Checks, CodeQL, automatic Real Okta and pre-release Real Okta passed on 7369ca98d3f74caa50fd1a96ded4408fb25c009a. Each Okta run passed all 23 expected checks and six profile downloads, including plaintext/encrypted policies, incorrect-key refusal, group denial, cookie/replay checks and cleanup. Tag-specific checks and artifact provenance remain required before publication.

Local unit/race, PostgreSQL integration with combined VM and isolated Lambda roles, vet, repository audit, native OpenVPN and OpenVPN 3 Linux checks passed. Historical unbound login completion, fetch and new applied ACK are refused; bound UDP-only and UDP/TCP profiles remain covered. Debian package lifecycle checks and Linux/Lambda builds passed for ARM64 and AMD64. Package checks do not establish running-systemd or reboot acceptance.

A bounded Codex Security review of the unbound removal examined all 27 changed source files, including deleted files, and reported no findings. The metrics change had a separate completed review with no findings. These scoped reviews do not prove the absence of all vulnerabilities; no Deep Scan was used.

Packages

Commit: 7369ca98d3f74caa50fd1a96ded4408fb25c009a. License: AGPL-3.0-only.

Verified native ARM64 and AMD64 builds from Checks for this signed tag. Both bundles use format 3.

Debian 13 packages for ARM64 and AMD64, a shared metapackage and native Debian source are included. Install verified matching packages with apt install ./supivpn*.deb; see DEPLOYMENT.md.

GitHub build provenance was verified for all binary archives, Debian assets and Corresponding Source, including the tag commit and Checks run attempt 1.

Database schema: 12; compatible VM schemas: 7, 8, 9, 10, 11, 12.
Isolated Lambda required schema: 12.

Corresponding Source accompanies the binaries. Verify SHA256SUMS.asc with the pinned SupiVPN release key, then verify the downloaded files against SHA256SUMS before use.

SupiVPN v0.9.1

SupiVPN v0.9.1

Changes

• Restore explicit acceptance of existing unbound profiles for the rest of v0.9.x, correcting their premature removal in v0.9.0. The original transition introduced in v0.8.0 is restored; final removal is v0.10.0.
• Require a separate legacy UDP listener, profile_binding: "legacy" on its agent, the authenticated legacy metadata gate, and an exact legacy_profile_nodes allowlist on the controller. Isolated public and agent Lambdas must configure the same allowlist.
• Keep bound-profile secret, owner and active/blocked verification on UDP and optional TCP. New downloads remain bound-only. A bound key cannot pass the legacy gate even if its embedded proof is removed.
• Emit profile.legacy_enabled and profile.legacy_login warnings so operators can identify the migration path and its use without logging secrets or assertions.

Compatibility

Legacy admission is opt-in. Omitted agent profile_binding still means required; an omitted or empty legacy_profile_nodes list allows no legacy nodes. New installations and the setup helper remain bound-only. v0.9.0 binaries and their published tag are unchanged; use v0.9.1 or later in the v0.9.x series for this exception.

Existing unbound profiles can reconnect without immediate reissue when their historical UDP endpoint, wrapping key and TLS trust are preserved and the migration path is explicitly configured. Their users must download and verify bound replacements before upgrading to v0.10.0. Existing bound UDP-only and dual-transport profiles need no new keys or secrets.

Schema remains 12 and database grants are unchanged. Installations already on v0.8.1 or later need no database migration for this patch. Upgrade the controller and VPN-host agents together in a maintenance window. For Lambda deployments, update both public and agent Lambdas as well as the host agent; changing Lambda alone does not configure an OpenVPN listener or its metadata gate. Arbitrary mixed agent/controller versions and database downgrades are not supported. The old embedded controller remains unsupported.

Configure the temporary migration path

1. Preserve the working configuration, keys, existing listener ports and database backup. Follow the migration procedure; do not rerun first-time setup over a working installation.
2. Retain separate legacy and bound listeners with distinct authenticated node identities, agents, management sockets, generation state, TUN devices and nonoverlapping VPN pools. This separation is for the security policies: bound UDP/TCP still shares one agent and address pool. Legacy mode supports only the old UDP transport.
3. Set the old agent to profile_binding: "legacy" and install tls-crypt-v2-verify "/usr/sbin/supivpn -verify-profile-metadata legacy" on that listener before exposing it. Keep required on the bound listener. Preserve all other OpenVPN security settings.
4. Add only the old authenticated node ID to top-level legacy_profile_nodes. On a combined VM configure its controller; with isolated Lambdas apply the same list to both public and agent components and all serving replicas/aliases. Omitted entries fail closed. Recovery needs no change.
5. Verify SAML login, group denial, session limits, reconnect and the bound-profile negative checks. Monitor migration warnings and finish moving users before v0.10.0. Drain and disable the old listener, remove its allowlist entries, and close its firewall/load-balancer route before the final upgrade.

For EC2, legacy and bound agents require distinct instances and authenticated IAM/fencing identities. Two agents sharing one EC2 identity are unsupported. HA replicas must agree on policy and route each profile format to the intended nodes. Removing an allowlist entry prevents new/incomplete admission; it does not terminate an established tunnel.

Security and validation limits

Legacy profiles still require verified SAML, current group authorization, replay prevention, node leases and global per-user connection limits. They do not bind their holder to a specific SAML owner. Keep browser login confirmation enabled. Blocking a bound profile does not revoke an old unbound key held by that user. Do not describe a mixed deployment as enforcing profile ownership everywhere.

Missing or incorrect new-format proofs, unknown or blocked profiles, owner mismatches and controller/database failures never select legacy admission. Historical authenticated metadata and bound metadata remain disjoint. Cross-format registration is refused rather than downgraded.

Local validation passed Go/race, PostgreSQL integration, signed synthetic SAML admission and group denial, policy removal before completion/fetch/ACK, combined and isolated database roles, and shared session limits. Unmodified upstream OpenVPN accepted historical Go/native-issued keys and refused cross-format keys, including a stripped bound profile. Debian package lifecycle/unit checks and Lambda ZIP builds passed for arm64 and amd64.

Native OpenVPN Connect, a live AWS deployment and a full Debian VM acceptance run were not repeated for this patch. Package checks do not establish running-systemd or reboot acceptance. The real Okta checks exercise signed/encrypted SAML and bound-profile issuance; they do not establish a legacy VPN tunnel or live AWS behavior.

The release commit 9677c3bb0f98ba6b01ea41a2fa399ae2d81ea23e passed main Checks, CodeQL, automatic Real Okta and a separate pre-release Real Okta run. Main checks include native arm64/amd64 unit/race/PostgreSQL/XMLSec, OpenVPN and OpenVPN 3 Linux, Debian packages/TLS setup, binary builds and bounded fuzzing. The first security-source attempt failed while downloading the vulnerability database after a connection reset; the failed jobs passed on retry without source or policy changes. Release attestation is intentionally skipped for main and must pass on the subsequent tag run before publication.

Both Okta summaries confirm plaintext/encrypted policy, wrong-recipient-key and group refusal, six browser profile downloads, cookie/one-use protections and fixture cleanup.

Packages

Commit: 9677c3bb0f98ba6b01ea41a2fa399ae2d81ea23e. License: AGPL-3.0-only.

Verified native ARM64 and AMD64 builds from Checks for this signed tag. Both bundles use format 3.

Debian 13 packages for ARM64 and AMD64, a shared metapackage and native Debian source are included. Install verified matching packages with apt install ./supivpn*.deb; see DEPLOYMENT.md.

GitHub build provenance was verified for all binary archives, Debian assets and Corresponding Source, including the tag commit and Checks run attempt 1.

Database schema: 12; compatible VM schemas: 7, 8, 9, 10, 11, 12.
Isolated Lambda required schema: 12.

Corresponding Source accompanies the binaries. Verify SHA256SUMS.asc with the pinned SupiVPN release key, then verify the downloaded files against SHA256SUMS before use.

SupiVPN v0.9.0

SupiVPN v0.9.0

Changes

• Keep UDP as the default and add optional TCP/443 fallback in one account-bound profile. TCP is disabled unless explicitly configured. Existing bound UDP-only profiles continue to work.
• Share each node's address pool across UDP and TCP without reserving half for either transport. One SupiVPN agent, node identity, generation and controller lease manage two unmodified upstream OpenVPN processes. Each transport uses a separate private management socket and TUN interface.
• Generate the optional TCP listener, systemd integration, host routes and firewall settings through Debian setup. Route hooks select the correct TUN for each admitted address without granting additional network capabilities to the agent. Losing either management channel stops the shared node before generation replacement.
• Handle a connection-limit conflict when an established UDP tunnel loses traffic and TCP reaches authentication before the old slot closes. One eligible same-profile, same-owner attempt receives a committed denial, waits 60 seconds in the agent, then requests a fresh client retry. The retry repeats profile, SAML, group, expiry and cluster-limit checks; it never evicts another tunnel, reserves an extra slot or allocates an IP while waiting. Its budget persists across controllers and nodes.
• Require profile ownership on every supported listener. Remove legacy unbound admission and document migration, coordinated upgrades and HA requirements.

Compatibility

Breaking change for unbound profiles: v0.9.0 ends their support earlier than the previously announced 0.8.x/0.9.x transition. v0.8.x is now the last compatible series. Migrate all unbound users while still on v0.8.x before upgrading. This is an explicit scope change, not a newly classified Critical vulnerability exception.

Missing agent profile_binding and controller profile.binding settings now select required; explicit legacy settings fail startup. The legacy metadata gate and embedded controller deployment are no longer supported. Use the separate PostgreSQL-backed controller and the required metadata gate on every OpenVPN listener.

Existing bound UDP-only profiles remain valid. Preserve their UDP endpoint and port, CA, exact server-name verification, wrapping key and inline profile credential. They do not need new secrets or keys. To gain the TCP entry, download a newly issued profile after TCP is enabled. Unknown formats, missing or incorrect proofs, blocked profiles, owner mismatches and infrastructure failures never select a weaker authentication path.

Schema 12 remains current. Installations already on v0.8.1 or later need no database migration for this release. Schema compatibility does not imply arbitrary mixed agent/controller versions: upgrade server components together in a maintenance window. Mixed v0.8/v0.9 server deployments have not been validated as a rolling-upgrade path.

Upgrade and enable TCP

1. Back up the database and operator configuration. On v0.8.x, issue and verify bound profiles for every user; stop and disable the former unbound listener. Keep the existing bound UDP port when consolidating the node.
2. Update the controller and agent together. For Lambda deployments, update both controller Lambdas and the VPN-host agent; changing Lambda alone does not update host admission, routing or listeners. Retain the existing node identity, generation state, group pools, TLS material, wrapping key and restricted database grants. Packages do not automatically restart working services.
3. Keep TCP disabled unless needed. For a fresh Debian deployment, set "tcp_fallback": {"enabled": true, "port": 443} in the setup input and review the plan. Do not rerun first-time setup over a working installation.
4. For an existing deployment, follow the transport guide to add the TCP management socket, second OpenVPN configuration, shared-pool route hooks on both transports, routing and firewall policy. Set the public controller's profile.tcp_fallback_port only after preparing the host listener. TCP/443 must be free; this is OpenVPN over TCP, not an HTTPS endpoint that can share a web-server listener.
5. Restart in the maintenance window and verify readiness, UDP-only reconnect, TCP fallback, owner/blocked-profile rejection and session limits before distributing new profiles. HA deployments require both transports on each participating node and corresponding load-balancer health checks; pool ranges must still be distinct between nodes.

Configuration and migration details:

• UDP and TCP transport guide
• Profile ownership and migration
• HA requirements
• Debian deployment

Recovery behavior and validation limits

Initial endpoint polling waits three seconds before trying another transport; DNS, scheduling and TLS add time. It does not shorten the browser authentication window. Silent loss of an already established UDP tunnel is different: with packaged keepalive timers, allow roughly two minutes plus fresh browser/network time for recovery. Fallback creates a new tunnel, may change its IP and does not preserve application connections. Clients that do not handle temporary authentication refusals need a manual reconnect after confirmed closure. TCP-over-TCP can perform poorly under packet loss.

The shared pool belongs to one node; it does not transfer tunnels or addresses between HA nodes. Blocking a profile prevents new admission, rather than continuously terminating an already admitted tunnel. Keep browser login confirmation enabled unless accepting its documented relay risk.

Local validation passed Go/race, PostgreSQL integration, native Community OpenVPN, OpenVPN 3 Linux, HA admission/refusal cases, vet and repository audit, plus Debian and Lambda builds for arm64 and amd64. Debian 13 checks on both architectures covered fresh TCP setup, disable/re-enable, old bound UDP-only profiles, established UDP loss, simultaneous UDP/TCP controller/database outages, cancellation, rekey, lease/session expiry, cold boot and package lifecycle.

Initial VM runs failed; corrected test phases passed separately on the same disposable VMs with unchanged runtime packages. This is not one uninterrupted full VM run. Native OpenVPN Connect TCP tunnels, live AWS/load-balancer HA and mixed v0.8/v0.9 server upgrades remain unverified. Local synthetic-SAML checks do not establish a production HA recovery time.

The merged release commit 615c2a4dbf6619e6306a83fe60ebb316a9814f35 passed Checks, CodeQL, automatic Real Okta and the separate pre-release Real Okta run. The Okta acceptance summaries confirm plaintext/encrypted policy, wrong-recipient-key and group denial, six browser profile downloads, one-use/cookie protections and cleanup. These checks exercise SAML and profile issuance, not a native Connect TCP tunnel or a live AWS deployment.

Packages

Commit: 615c2a4dbf6619e6306a83fe60ebb316a9814f35. License: AGPL-3.0-only.

Verified native ARM64 and AMD64 builds from Checks for this signed tag. Both bundles use format 3.

Debian 13 packages for ARM64 and AMD64, a shared metapackage and native Debian source are included. Install verified matching packages with apt install ./supivpn*.deb; see DEPLOYMENT.md.

GitHub build provenance was verified for all binary archives, Debian assets and Corresponding Source, including the tag commit and Checks run attempt 1.

Database schema: 12; compatible VM schemas: 7, 8, 9, 10, 11, 12.
Isolated Lambda required schema: 12.

Corresponding Source accompanies the binaries. Verify SHA256SUMS.asc with the pinned SupiVPN release key, then verify the downloaded files against SHA256SUMS before use.

SupiVPN v0.8.3

SupiVPN v0.8.3

Changes

• Remove explicit remote-cert-ku 80 and remote-cert-eku "TLS Web Server Authentication" from the shipped client template following a Windows client compatibility report. The template is delivered in the Linux bundle, public Lambda ZIP and Debian packages.
• Preserve CA trust, certificate validity, TLS 1.2 minimum and the exact server common-name check in account-bound downloads. Add handshake rejection tests for a mismatched server name, an untrusted CA and an expired certificate.
• Document how to update an existing template or imported profile without rotating its credential or changing its registered owner.

Compatibility

No database migration or profile reissuance is required; schema version 12 and the two-port 0.8.x/0.9.x migration window remain unchanged. Working older profiles continue to work.

Update the profile-serving controller/template, or the public Lambda ZIP. A package upgrade does not replace a configured template already copied to /etc, and no server upgrade rewrites an imported .ovpn. Remove only the two explicit KU/EKU directives from custom templates and affected profile files; re-import the edited file if the client requires it. Preserve the CA, verify-x509-name, inline profile credential and tls-crypt-v2 blocks. Downloading a new profile instead creates a separate credential.

Explicit KU/EKU-extension requirements are no longer imposed by these directives; TLS-library validation depends on the client. VPN server certificates must still be provisioned for TLS server authentication. Account-bound downloads retain exact CN checking, which is not wildcard/DNS-SAN verification. Legacy profiles still do not verify a specific server name and may accept another certificate under the trusted CA. This release does not add the bound-profile guarantee to the legacy path.

Windows UI/tunnel acceptance and a live AWS deployment have not been independently reproduced for this patch.

Packages

Commit: 405136386d8f88fd05dcd7823a712d03b525a444. License: AGPL-3.0-only.

Verified native ARM64 and AMD64 builds from Checks for this signed tag. Both bundles use format 3.

Debian 13 packages for ARM64 and AMD64, a shared metapackage and native Debian source are included. Install verified matching packages with apt install ./supivpn*.deb; see DEPLOYMENT.md.

GitHub build provenance was verified for all binary archives, Debian assets and Corresponding Source, including the tag commit and Checks run attempt 1.

Database schema: 12; compatible VM schemas: 7, 8, 9, 10, 11, 12.
Isolated Lambda required schema: 12.

Corresponding Source accompanies the binaries. Verify SHA256SUMS.asc with the pinned SupiVPN release key, then verify the downloaded files against SHA256SUMS before use.

SupiVPN v0.8.2

SupiVPN v0.8.2

This patch keeps confirmed VPN disconnects queued for cancellation across transient
controller/API failures, so the agent can release the occupied session slot when
the API recovers instead of abandoning cancellation after 30 seconds.

Changes since v0.8.1,
including PR #38.
Release commit: a89a1ccaf449b47382d1bfb4ae01f94247d9b2b9.

Changes

• Retain cancellation after OpenVPN confirms disconnection, or a complete ordered
  status response proves the connection is absent, while the node generation's
  lease remains live. A temporary cancellation outage alone no longer stops
  unrelated tunnels after 30 seconds.
• Keep idempotent retries, including a lost reply after cancellation commits.
  Backoff remains capped at 16 seconds, the shared worker at four calls per
  second, and the queue at 32 jobs.
• Add regression coverage for transport errors, HTTP 429/502/503, 90-second
  cancellation outages, lost committed replies, handler replacement, whole-API
  outages and clean generation restart through both Lambda gateway formats.
• Document a read-only query that distinguishes historical acknowledged rows
  from grants that still occupy session slots, plus safe recovery guidance.
• Include the documentation updates and lighter documentation-only CI from
  PRs #35 and #37. Code and release tags retain the full verification pipeline.

Compatibility

Upgrade the agent on each VPN node to receive this fix. Updating Lambda alone
cannot change the node agent's cancellation behavior. The agent API and database
schema are unchanged from v0.8.1; schema 12 remains current, with no new migration
or runtime grants. Existing client profiles remain valid and need no reissue.
No client settings, configuration defaults or OpenVPN binaries change.

For Debian installations, install the v0.8.2 packages and explicitly restart each
configured agent/OpenVPN pair in a maintenance window. Package upgrades leave
running processes untouched. Restart through the owning supivpn-node service
(or its configured instance), then verify readiness and a reconnect. Restarting
a pair disconnects its existing tunnels; update nodes in a controlled sequence.
Retain the node generation journal and do not reuse stale authorization state.
For Lambda-backed installations, update the node agent as well; matching Lambda
artifacts are included, but this patch introduces no Lambda runtime code change.

An upgrade from v0.8.0 or earlier still needs the previously documented
schema 12 migration.
Legacy profile migration remains supported throughout 0.8.x and 0.9.x through
the existing explicit two-port configuration; earliest enforcement remains 0.10.
Rolling back the agent to v0.8.1 restores the old cancellation behavior; no schema
downgrade is needed or provided by this patch.

Recovery and limitations

A slot remains occupied until cancellation commits or a verified clean generation
restart/fencing makes the old grant inactive. This fix does not delete old login
rows or release slots merely because time has passed. Historical acknowledged
rows from an older generation can remain without counting against session limits.

If the entire API is unavailable until the local 40-second lease expires, the
agent still stops. Recovery requires a clean supervised agent/OpenVPN pair restart
or verified fencing. Uncertain applied ACKs, permanent API refusals, stale
generations and exhausted queue capacity still fail closed. Restarting Lambda
alone is not proof that an old VPN tunnel has stopped.

See session diagnostics and recovery.
Do not delete login rows or clear slots based only on age, state or an expired
lease. Verify recovery by disconnecting and reconnecting without manual SQL cleanup.

The reported production incident was not reproduced against the live AWS
deployment. Local fault injection reproduced and fixed a relevant cancellation
defect; it does not establish that every stale-slot incident has the same cause.

Packages

Commit: a89a1ccaf449b47382d1bfb4ae01f94247d9b2b9. License: AGPL-3.0-only.

Verified native ARM64 and AMD64 builds from Checks for this signed tag. Both bundles use format 3.

Debian 13 packages for ARM64 and AMD64, a shared metapackage and native Debian source are included. Install verified matching packages with apt install ./supivpn*.deb; see DEPLOYMENT.md.

GitHub build provenance was verified for all binary archives, Debian assets and Corresponding Source, including the tag commit and Checks run attempt 1.

Database schema: 12; compatible VM schemas: 7, 8, 9, 10, 11, 12.
Isolated Lambda required schema: 12.

Corresponding Source accompanies the binaries. Verify SHA256SUMS.asc with the pinned SupiVPN release key, then verify the downloaded files against SHA256SUMS before use.

SupiVPN v0.8.1

SupiVPN v0.8.1

This patch fixes missing readable ownership information in the issued-profile
registry. It preserves existing client profiles and their authorization identity.

Changes since v0.8.0,
from PR #36.
Release commit: 994b80d04d1ec5e04a519002ae34cb34fb009bfa.

Changes

• Store the verified SAML NameID as issued_profiles.owner_username at profile
  issuance, including browser downloads and one-use OpenVPN Connect imports.
• Show the owner label in privileged profile list/status output and document the
  corresponding SQL query for Lambda operators.
• Recover labels for existing profiles from retained, agreeing verified login
  records during migration. When there is no remaining evidence, keep the label
  empty until a successful SAML admission with that profile. Never-used profiles
  and profiles whose login history was pruned remain valid with an empty label.
• Preserve profile IDs, proof hashes, subject hashes, active/blocked states,
  revisions and creation times. No username is embedded in the client file.

Compatibility

Database schema 12 is required for the updated bound-profile features and all
three isolated Lambda components. Prepare matching binaries and verify backups
before a maintenance window. Quiesce controllers, all three Lambda components
and recovery scheduling; drain VPN pairs if heartbeat continuity cannot be
maintained. Apply migration 012 with the explicit migrator, reapply the
restricted runtime grants, and resume with matching binaries. The public role
gains UPDATE on the owner-label column only; it still cannot update profile
proof, ownership identity, state or revision. Restricted SQL operators need
SELECT on the new column.

Migration 012 scans retained logins and issued profiles and takes DDL locks.
The existing 3-second lock and 10-second statement timeouts apply; a timeout
rolls back the migration. Migration and grants are separate transactions, so a
grant failure must stop the deployment before traffic resumes.

Existing .ovpn files do not need to be reissued. Legacy client migration remains
supported in the 0.8.x and 0.9.x series with the existing explicit two-port setup.
v0.8.0 binaries reject schema 12; mixed old/new Lambda runtimes and database
downgrades are not supported. After migration, runtime rollback requires a
verified schema-12-compatible build. Do not restore stale authorization state.
The updated VM runtime retains schemas 7 through 12 for legacy authorization;
bound-profile features require schema 12.

After upgrade, check profile list/status, a login using an existing bound
profile, and block/reactivate using the current revision.

See schema 11 to 12
and Lambda profile administration.

Boundaries

Owner labels are personal audit data, not authorization evidence. Admission
continues to require the profile proof, matching verified subject hash and active
state. An empty or conflicting historical label does not weaken these checks.
Concurrent row locks may defer filling an empty label to a later login.
Blocking a profile still prevents new admissions rather than disconnecting an
already established tunnel.

Local checks cover Go/race, PostgreSQL migrations and restricted roles, direct
and Server URL issuance, Debian arm64/amd64 package lifecycles, and Lambda builds.
Live AWS deployment and native OpenVPN Connect UI were not repeated for this patch.

Verification

Main Checks, CodeQL and pre-release Real Okta passed on the release commit. Real Okta covers SAML, encryption policy and legacy browser downloads; bound-profile owner labels, import handoff and restricted-role permissions are covered by synthetic integration tests.

Packages

Commit: 994b80d04d1ec5e04a519002ae34cb34fb009bfa. License: AGPL-3.0-only.

Verified native ARM64 and AMD64 builds from Checks for this signed tag. Both bundles use format 3.

Debian 13 packages for ARM64 and AMD64, a shared metapackage and native Debian source are included. Install verified matching packages with apt install ./supivpn*.deb; see DEPLOYMENT.md.

GitHub build provenance was verified for all binary archives, Debian assets and Corresponding Source, including the tag commit and Checks run attempt 1.

Database schema: 12; compatible VM schemas: 7, 8, 9, 10, 11, 12.
Isolated Lambda required schema: 12.

Corresponding Source accompanies the binaries. Verify SHA256SUMS.asc with the pinned SupiVPN release key, then verify the downloaded files against SHA256SUMS before use.

SupiVPN v0.8.0

SupiVPN v0.8.0

Commit: e780fec55347a34ca25a48d8476e897ce1b34881.

Go Supi! This release adds reusable VPN profiles bound to their verified SAML
owner, profile administration and browser-assisted OpenVPN Connect import.
OpenVPN remains an unmodified upstream component.

Changes

Profile ownership and import

• Bound profiles carry an opaque identifier and a random 256-bit proof, never
  a SAML username or IdP password. Issuance requires verified SAML and group
  authorization. Admission checks the proof, active state and matching SAML
  owner. PostgreSQL stores only the proof digest and owner hash.
• Profiles can be blocked or reactivated with revision checks. Blocking denies
  new admission; it does not terminate an established tunnel, ban an account,
  prevent a fresh authorized download or revoke old-format profiles.
• OpenVPN Connect Server URL discovery opens an SP-initiated SAML flow and
  produces a 60-second, one-use HTTPS import grant. Linux users sign in through
  the browser, download the .ovpn file and import it with OpenVPN 3 Linux.
• Browser confirmation, success and error pages use lightweight embedded styles,
  system fonts and restrictive CSP. No JavaScript or external assets are needed.
• Tunnel logs can correlate an opaque profile ID with a supplied Device ID.
  Device IDs are untrusted diagnostics and never authorize access.

Local administration

The new supivpn-cli Debian package is included in the supivpn metapackage. It
requires root on a combined node/controller Debian host; PostgreSQL may be
external. Commands cover service status, bounded profile inventory/status,
revision-checked block/activate and local session status/drop. The CLI has no
remote administration endpoint and accepts no arbitrary SQL or configuration path.

Lambda and split deployments do not support this CLI. Use the documented
restricted recovery operator path, or the temporary least-privilege SQL procedure
for profile state. Keep all operational credentials outside command history/logs.

Compatibility

Upgrade and two-minor transition

Profile binding and Server URL require schema 11. All three isolated Lambda
components require exactly schema 11, even with the new profile options disabled.
The combined VM runtime retains its existing legacy-mode compatibility with
schemas 7 through 10; those schemas cannot enable the new profile features.

Use a coordinated controller/agent upgrade. Back up the database and verify
restoration before migration. Reapply the documented restricted grants for
separate component roles. Plan a maintenance window for Lambda migration and
deploy matching public, agent and recovery versions before resuming admission;
do not assume mixed aliases or warm environments can span the schema/grant change.
Arbitrary mixed binary/schema versions and database downgrades are unsupported.
Rollback requires a consistent, tested database backup and matching binaries;
old binaries do not gain support for newly issued bound profiles.

Legacy profile support remains available throughout 0.8.x and 0.9.x, including
patch releases. Removal or default enforcement may begin no earlier than 0.10,
with separate release notes. An omitted agent profile_binding remains legacy
during this transition; required is an explicit operator choice. No timer closes
the legacy port automatically.

Run separate legacy and required OpenVPN/agent pairs with distinct trusted node
identities, sockets and nonoverlapping address pools. Install the authenticated
tls-crypt-v2 metadata gate on every legacy listener before issuing bound profiles.
New profiles must be refused on the old port, and old profiles on the new port.
Missing, malformed, blocked or mismatched new credentials must never fall back.
Operators can enforce ownership sooner by closing the legacy listener.

The setup helper does not automatically convert an existing deployment to two
listeners. Debian systemd templates support the explicit migration. For Lambda
and EC2, use separate node instances/IAM identities and appropriate port/target
group routing; two agents sharing one EC2 fencing identity are unsupported.

Public Lambda uses the same controller for binding and browser pages. For Server
URL, expose exact GET/HEAD /openvpn-api/profile, GET /profile/connect and GET
/profile/import/{token} routes alongside existing SAML routes. Preserve response
security headers and cookie handling, disable authentication/profile caching, and
redact import tokens and SAML data from gateway, proxy, WAF and analytics logs.
Existing Secrets Manager key loading remains supported.

Keep browser login confirmation enabled unless accepting its documented relay
risk. A legacy listener retains the old security behavior. A copied bound
profile together with its owner's SAML session can still authenticate: this is
account binding, not hardware attestation. Bound profiles require an exact VPN
server certificate common-name match; plan certificate renewal accordingly.

Security corrections

• Import expiry is checked against fresh database time after acquiring the row
  lock. Waiting for a lock no longer extends a one-use grant's validity.
• An undispatched or definitively rejected registration is no longer cancelled
  as though a database login existed, avoiding listener-wide failure. Uncertain
  requests and active sessions retain fail-closed cancellation.
• Combined-host profile operations use their existing runtime permissions;
  isolated component roles retain narrow functions without expanded grants.

Both reported findings have deterministic regression coverage and passed after
correction. The generic early-disconnect cancellation path also exists in
v0.7.1 source; exploitability on a released deployment and the complete affected
release range have not been independently established.

Validation and limitations

PR head 494f30d passed Checks and CodeQL,
including Go/race/PostgreSQL tests, XML/SAML fuzzing, dependency scans, native
OpenVPN and Linux-client checks, Debian packages and all three Lambda ZIP builds
and binary scans on arm64/amd64. A clean arm64 Debian VM with external PostgreSQL
passed both listeners, owner/proof/cross-port denial, CLI block/reactivate,
process continuity, reboot and package lifecycle. Later presentation-only changes
passed full integration and browser checks separately.

Native Connect 3.9.0 (6050) on macOS arm64 passed Server URL import with trusted
HTTPS and a signed synthetic IdP. Native Connect tunnels, other native platforms,
prefixed Server URL and the new bound-import flow with real Okta remain unverified.
The live AWS deployment of these new changes has not been tested. Main Checks
(40100246134), CodeQL (40100246378), main Real Okta (40100246127) and the explicit
pre-release Real Okta run (40105202433) passed on the release commit. Both Okta
runs verified the existing six-download plaintext/encrypted matrix and cleanup;
they do not establish acceptance of the new bound-import flow. Tag CI and release
provenance are separate mandatory publication gates.

Blocking is not an atomic disconnect. If it races with applied but unacknowledged
authorization, existing fail-closed acknowledgement behavior can stop that
listener. Keep independent administrative access. The profile registry grows per
issued profile; this release adds no automatic retention policy or device binding.

Operator guides

• Profile ownership and migration
• Local CLI
• Lambda profile administration
• Minimal Debian deployment

Packages

Commit: e780fec55347a34ca25a48d8476e897ce1b34881. License: AGPL-3.0-only.

Verified native ARM64 and AMD64 builds from Checks for this signed tag. Both bundles use format 3.

Debian 13 packages for ARM64 and AMD64, a shared metapackage and native Debian source are included. Install verified matching packages with apt install ./supivpn*.deb; see DEPLOYMENT.md.

GitHub build provenance was verified for all binary archives, Debian assets and Corresponding Source, including the tag commit and Checks run attempt 1.

Database schema: 11; compatible VM schemas: 7, 8, 9, 10, 11.
Isolated Lambda required schema: 11.

Corresponding Source accompanies the binaries. Verify SHA256SUMS.asc with the pinned SupiVPN release key, then verify the downloaded files against SHA256SUMS before use.

SupiVPN v0.7.1

SupiVPN v0.7.1

Patch release for public Lambda SAML assertion-encryption key delivery.

Changes

Fix SAML assertion-encryption key delivery in public Lambda. Version 0.7.0
supported only file-based keys; public Lambda can now load its dedicated RSA
recipient key directly from AWS Secrets Manager during initialization.

Configuration

In the public controller JSON, replace assertion_encryption.private_key_file
with assertion_encryption.private_key_secret_arn, using the complete ARN.
Keep certificate_file pointing to the matching public certificate, delivered
for example in a Lambda layer. Configure exactly one private-key source.

Store the raw, multiline PKCS#1 or PKCS#8 RSA PEM as SecretString. Do not use a
JSON wrapper, base64 wrapper or SecretBinary. Grant only the public execution
role GetSecretValue on the specific secret and, if needed, Decrypt on its
customer-managed KMS key. Agent and recovery do not need these permissions.

The public function reads AWSCURRENT once at initialization and retains the
parsed key in memory, without a filesystem copy. Retrieval failure, invalid PEM
or certificate mismatch prevents startup; there is no plaintext/file/previous-
version fallback. Warm environments do not refresh automatically: coordinate
secret, certificate and IdP rotation with a new Lambda deployment and retire
old environments. Only one recipient key is supported per process.

See the encryption guide
for the full configuration, IAM requirements and rollout limitations.

Compatibility

File-based VM configuration, encryption modes, database schema, dependency
versions and release workflow permissions are unchanged from v0.7.0.

Verification

Local unit/race tests, vet, repository checks and both architectures' Lambda
builds passed. Tests use mocked Secrets Manager reads and synthetic recipient
keys, including signed-assertion decryption and optional/required enforcement.
Live deployment IAM/KMS and endpoint connectivity have not been exercised.

Hosted Checks and CodeQL passed on the release commit. Real Okta passed
signed/encrypted assertion acceptance in optional and required modes,
wrong-recipient-key rejection, plaintext policy enforcement and six browser
profile downloads. These browser scenarios cover the SAML and profile flows;
they do not perform a live AWS Secrets Manager read.

Main Checks ·
CodeQL ·
Real Okta.

Source commit: d7fc06bc9bf04529af1943d2f5269347bcdce8e8.

Changes since v0.7.0.

Packages

Commit: d7fc06bc9bf04529af1943d2f5269347bcdce8e8. License: AGPL-3.0-only.

Verified native ARM64 and AMD64 builds from Checks for this signed tag. Both bundles use format 3.

Debian 13 packages for ARM64 and AMD64, a shared metapackage and native Debian source are included. Install verified matching packages with apt install ./supivpn*.deb; see DEPLOYMENT.md.

GitHub build provenance was verified for all binary archives, Debian assets and Corresponding Source, including the tag commit and Checks run attempt 1.

Database schema: 10; compatible VM schemas: 7, 8, 9, 10.
Isolated Lambda required schema: 10.

Corresponding Source accompanies the binaries. Verify SHA256SUMS.asc with the pinned SupiVPN release key, then verify the downloaded files against SHA256SUMS before use.

SupiVPN v0.7.0

SupiVPN v0.7.0

Security fixes for SAML/XML verification and VPN sign-in intent, plus optional
SAML assertion encryption. Upgrade deployments running 0.4.0 through 0.6.1.

Changes

• Bound XML signature-verification work: limit inclusive namespace prefixes,
  authenticate SignedInfo before processing the referenced document, and enforce
  the canonical-output budget consistently. See
  GHSA-45v3-cvr2-xcg6.
• Require an explicit browser confirmation before VPN SAML login by default.
  A GET displays the prompt; a protected same-origin POST starts authentication.
  This mitigates silent authorization of an attacker's pending VPN connection
  through a relayed login link. See
  GHSA-59hj-hg2f-54x4.
• Preserve the signed bearer NotBefore bound at final admission and reject
  malformed or ambiguous recipient PEM input.
• Add RSA-OAEP and AES-GCM assertion encryption with explicit disabled
  (default), optional and required modes. Trusted IdP signatures, audience,
  recipient, time, browser/request correlation, groups and replay checks remain
  mandatory. Encryption does not replace HTTPS or client/browser binding.
• Add real Okta acceptance for encrypted/plaintext policy, recipient keys,
  group denial, cookies, replay and six client profile downloads, run weekly,
  after relevant main changes and manually before releases.

Compatibility

VPN login now requires a confirmation click by default. Public reverse
proxies and API gateways must forward both GET and POST /login/{ticket} to the
controller. Configure this route before rolling out the update, and keep all
controller replicas on a consistent confirmation policy. Profile downloads
retain their own login flow.

The explicit operator opt-out is "vpn_login_confirmation": false. Omitted,
null or true keeps confirmation enabled. Disabling it restores the silent
relayed-link risk. Even with confirmation enabled, approving someone else's
request can authorize that person's connection: cryptographic binding between
browser and VPN client is not implemented. Only approve a login initiated by
your own VPN client. MFA and assertion encryption do not remove this limitation.

Existing plaintext IdP configurations continue to work with encryption disabled.
To enable encryption, provision a dedicated RSA recipient key and certificate,
roll out optional to all controllers, configure the IdP, verify VPN/profile
flows, then select required. Required mode rejects plaintext assertions. Only
one recipient key is loaded per process; automatic overlapping-key rotation is
not implemented. See the
encryption guide
for supported algorithms, file permissions and rollout details.

Database migration files and Go dependencies are unchanged from v0.6.1. Existing
VPN tunnels do not move between nodes; reconnecting after node loss requires a
new login and assigns a different IP. This release does not change those limits.
Maintain ingress rate, concurrency and body-size limits alongside the XML fixes.

Upgrade through the signed APT repository or verified
GitHub Release packages, following the
deployment guide.
The two advisory publications follow verification of the patched downloads and
APT delivery.

Verification

The release source passed main Checks and CodeQL, real Okta encrypted assertions,
XMLSec/OpenSSL interoperability, race and PostgreSQL integration tests, bounded
fuzzing, vulnerability scans and four clean Debian 13/systemd VM scenarios:
arm64 and amd64, each with local and external PostgreSQL. Interactive OpenVPN
Connect UI acceptance remains deferred; native OpenVPN integration passed.

The release workflow additionally requires successful tag checks and build
provenance before signing and publishing the exact tag-built assets.

Source commit: 73f1114c87e050d93ee31ec9a8f1d80d7afc8dd8.
Changes since v0.6.1.

Packages

Commit: 73f1114c87e050d93ee31ec9a8f1d80d7afc8dd8. License: AGPL-3.0-only.

Verified native ARM64 and AMD64 builds from Checks for this signed tag. Both bundles use format 3.

Debian 13 packages for ARM64 and AMD64, a shared metapackage and native Debian source are included. Install verified matching packages with apt install ./supivpn*.deb; see DEPLOYMENT.md.

GitHub build provenance was verified for all binary archives, Debian assets and Corresponding Source, including the tag commit and Checks run attempt 1.

Database schema: 10; compatible VM schemas: 7, 8, 9, 10.
Isolated Lambda required schema: 10.

Corresponding Source accompanies the binaries. Verify SHA256SUMS.asc with the pinned SupiVPN release key, then verify the downloaded files against SHA256SUMS before use.

SupiVPN v0.6.1

SupiVPN v0.6.1

Changes since v0.6.0.

Changes

• Document the live v0.6.0 APT repository (da87b0f3b6fe)
• Merge pull request #26 from SupiVPN/docs/apt-launch (f56ab6aca727)
• Document deployment options, scope and architecture limits (9b1bb50db9cc)
• Support verified remote PostgreSQL in Debian setup (3f5a3cf761eb)
• Merge pull request #27 from SupiVPN/feat/remote-database-setup (fe115fd45791)
• Test Debian VM deployment with external PostgreSQL (9360ce105996)
• Merge pull request #28 from SupiVPN/test/remote-database-vm (8a567f7b12c7)

Compatibility

These notes summarize commit subjects; they do not assert runtime or migration compatibility. Review configuration and migration changes before upgrading. The Release page reports schema compatibility from the verified package manifests.

Packages

Commit: 8a567f7b12c7019962954db76dba80311f995b77. License: AGPL-3.0-only.

Verified native ARM64 and AMD64 builds from Checks for this signed tag. Both bundles use format 3.

Debian 13 packages for ARM64 and AMD64, a shared metapackage and native Debian source are included. Install verified matching packages with apt install ./supivpn*.deb; see DEPLOYMENT.md.

GitHub build provenance was verified for all binary archives, Debian assets and Corresponding Source, including the tag commit and Checks run attempt 1.

Database schema: 10; compatible VM schemas: 7, 8, 9, 10.
Isolated Lambda required schema: 10.

Corresponding Source accompanies the binaries. Verify SHA256SUMS.asc with the pinned SupiVPN release key, then verify the downloaded files against SHA256SUMS before use.