[ammanviii]

Summary

Release/profile mobile builds currently reject a non-default HTTPS gateway port, such as https://push.example:8444. This prevents separately signed personal builds from using a valid private HTTPS gateway on a non-default port, even though native gateway-origin canonicalization already preserves it.

Permit explicit ports in the existing 1..65535 range. Keep HTTPS mandatory for release/profile builds and preserve credential, path, query, and fragment rejection. Update the build error and mobile documentation. No TLS, App Attest, transcript audience, relay authentication, or push protocol behavior changes.

- Release/profile: HTTPS origin with no explicit port
+ Release/profile: HTTPS origin with an optional valid port

Related issue

Related context: #5206 (self-hosted relay operators). This does not enable the public App Store application's push gateway or address its enrollment availability. No matching existing port-policy PR was found in the duplicate search.

Testing

• Regression first: the real iOS build-phase test and release/profile predicate test fail on the unmodified validator; both pass after the fix.
• Tests exercise Release and Profile configurations, both direct build settings and encoded Dart defines, explicit :443/:8444, valid port bounds, malformed/out-of-range ports, HTTP, credentials, paths, queries and fragments.
• Native tests preserve the explicit port and keep the registered App Attest transcript audience unchanged.
• Hermit-pinned Flutter 3.47.7 / Dart 3.13.5: just mobile-install mobile-check mobile-test passed. Configured suite: 3735 passed, 16 skipped. Unconfigured-build suite: 4 passed. Gateway-recipe suite: 9 passed.
• swift test --package-path mobile/ios/BuzzPushKit: 97 XCTest and 65 Swift Testing tests passed.
• Independent CodeRabbit review: no findings.
• Complete unsigned iOS release build with an explicit HTTPS :8444 gateway: passed on Xcode 27.0 (27A266a).
• The same patch was built and signed with private local overrides, then installed and launched on a physical iPhone as build 2026102101. On October 27, device tools confirmed that build is installed; read-only backend checks confirm fresh registration and an active, enabled, unexpired relay lease. On October 28, the owner provided an iPhone Notification Center screenshot and explicitly confirmed that tapping the notification opened the correct thread; see human verification below.

Verification refresh — October 27

Exact PR head: ab31b7a6f15a2b7b2f5e41ba56829c361728f3d5; working tree clean.

• just mobile-check mobile-test: passed. Analysis reports no issues; configured suite 3735 passed / 16 skipped; unconfigured suite 4 passed.
• Focused real iOS build-phase / gateway-origin regression file: 4 passed, including Release/Profile forwarding through build settings and encoded Dart defines.
• Focused Swift port preservation and registered-transcript-audience tests: 2 passed. The earlier complete native suite remains 97 XCTest + 65 Swift Testing tests passed on the same patch.
• CHECK_FILE_SIZES_BASE=1a54eec3dbfd049f98dfca678c3060c5c3a8f0a1 just file-size-check: passed against the contribution base.
• No production source changes since the independently reviewed and signed patch.
• Upstream CI run requires maintainer approval to run workflows from this fork. DCO, Semgrep OSS and zizmor checks passed. The separate Codex Security Review needs a repository writer to authorize this exact head; it has not run.

Server-side delivery verification — October 28

Read-only checks of the personal relay and push gateway, using the installed build 2026102101 with the explicit HTTPS gateway port:

• Latest push record: October 28 at 14:50:33 UTC (10:50:33 a.m. EDT). The relay records delivered on its first attempt, matching the phone's current endpoint and lease generation.
• Gateway counters since process start: 2 admitted deliveries, 2 APNs send attempts, and 2 APNs accepted outcomes. These cumulative counters corroborate successful server-to-Apple handoff; they are not per-device delivery receipts.
• No synthetic notification was sent during this verification. No credentials, tokens, device identifiers, or message contents are included here.
• Limit: APNs acceptance does not prove that iOS received or displayed a notification, played a sound, or opened the correct message when tapped. The owner has now independently confirmed visible presentation on the iPhone and navigation to the correct thread, as recorded below. Lock-state at arrival and notification sound were not established by this evidence.

Human iPhone verification — October 28

• The owner supplied a screenshot showing the Buzz notification in iPhone Notification Center and explicitly confirmed: “Yes straight from the iPhone and it opened it to the correct thread.”
• This verifies notification presentation on the physical iPhone and successful navigation to the correct thread in the personal build. It complements the server-side relay/APNs evidence; it is not a claim of public App Store support or a guarantee of delivery under every device condition.
• The screenshot contains private conversation content and is not uploaded here. Lock-state at arrival and sound were not separately confirmed.
• Independent agent review, agent execution of the affected build/test workflow, and subsequent human testing are complete for the unchanged PR head ab31b7a6f15a2b7b2f5e41ba56829c361728f3d5.

buzz-review-completed

Evidence

• Before: release/profile validation exits 1 for an explicit HTTPS port.
• After: the production build phase accepts the same origin and forwards its exact Dart define; malformed/non-HTTPS origins remain rejected.

Merge Danger

Door: two-way. Reverting restores the prior build restriction.

Blast Radius: mobile-builds. This expands accepted build configuration only; it does not select a gateway, enable push on a relay, or change runtime verification.

[github-actions]

🔐 Codex Security Review

Status: review required for the current range.

The current range is 3ed07e5c758fe14c3712e6e8309dfe90942f1d81...ab31b7a6f15a2b7b2f5e41ba56829c361728f3d5.
A new review must complete for this exact range. When manual authorization
is required, a user with write access must comment exactly
@buzz-security-review ab31b7a6f15a2b7b2f5e41ba56829c361728f3d5 to authorize a new review.
Any previous review applies only to its recorded range.