Skip to content

[P1][Security] Restore Cast only with verified receiver trust #575

Description

@TheZupZup

Priority

P1 — priority security remediation, immediately after emergency containment. This must not delay the maintenance release.

Goal

Restore Cast support only after the receiver's identity has been cryptographically authenticated and the complete media handoff path has passed an independent security review. Preserve Linthra's open-source and F-Droid-compatible architecture where practical, without weakening security requirements to maintain compatibility.

Scope

  • Evaluate a maintained implementation, an auditable fork, or a narrowly scoped replacement rather than assuming an unreviewed dependency update is sufficient.
  • Establish an explicit receiver-authentication contract and a fail-closed readiness boundary.
  • Require successful authentication before any media handoff or other operation that requires a trusted receiver.
  • Bind the authenticated connection to the receiver selected by the user and handle connection changes, cancellation, and session lifecycle safely.
  • Review the implementation's trust model, protocol compatibility, dependency provenance, and supported platforms with the reporter in the private advisory.
  • Add positive interoperability tests with supported devices and negative authentication tests using controlled, non-production fixtures.
  • Review the credential exposure and authorization properties of the resulting media handoff before restoring production availability.
  • Retain the temporary production safeguard until the replacement and its tests are reviewed and approved. No runtime bypass or insecure fallback is acceptable.

Likely code areas

  • lib/core/services/cast/
  • lib/features/player/cast/
  • Production application wiring
  • Dependency manifests and lockfiles
  • Cast protocol integration tests and security documentation

Acceptance criteria

  • The receiver trust model and implementation choice are documented and privately reviewed.
  • Authentication failures, identity mismatches, and incomplete authentication cannot reach trusted readiness.
  • No credential-bearing media handoff can occur before the required trust checks succeed.
  • Controlled negative tests and supported-device interoperability tests pass.
  • Dependencies and packaged artifacts are reviewed for the approved implementation.
  • Production restoration is a separate, reviewed change and does not reintroduce an insecure fallback.
  • The reporter is offered an opportunity to review the remediation through the private advisory.

Disclosure coordination

The complete technical requirements, protocol-specific evidence, and security test scenarios belong in the private advisory. Do not reproduce them in public comments or PR descriptions before coordinated disclosure.

Related: #572, #573, #574, and the resolved private-contact request #545.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

bugSomething isn't workingpriority

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions