Skip to content

Security: ForgeWireLabs/repopact-workbench

SECURITY.md

Workbench Security Policy

RepoPact Workbench is a Tauri desktop/mobile application that uses a Rust backend, React/TypeScript interface, and an exact pinned revision of RepoPact Core. Workbench owns presentation, local repository sessions, filesystem observation, and platform integration. Core owns governance semantics, validation, graph and analysis results, and typed repository mutations. Read the Core security policy for Core's package and semantic-engine scope; it does not replace this policy.

Reporting a vulnerability

Use the private vulnerability reporting form to report suspected Workbench security issues. GitHub private vulnerability reporting is enabled for this repository. Do not report suspected vulnerabilities through public issues or post credentials, tokens, or private repository data there.

Include the affected Workbench revision and platform, relevant input and workflow, expected security property, and reproducible impact when safe to share. Ordinary feature requests and reproducible non-sensitive bugs can be reported through GitHub Issues.

Security-sensitive surfaces

  • Local repositories: opening a repository does not make its records trustworthy. Core validation describes conformance to implemented rules; it is not repository authentication or a guarantee that its contents are safe.
  • Mutation review: Workbench asks Core to construct typed plans, shows diagnostics, requires explicit review and apply, and revalidates afterward. Plans are session-bound; stale plans are rejected. These controls are not a general operating-system sandbox or a guarantee against every host-level threat.
  • GitHub access: network access is optional. Workbench does not need GitHub for local repository use. User authorization tokens belong in the platform credential store, not repository files, frontend persistence, evidence, or logs. The packaged GitHub client ID, app slug, and value GitHub calls a client secret are application metadata in a distributed client, not user secrets or proof of a genuine binary. Never treat that value as confidential authority.
  • Snapshot import: GitHub imports are immutable commit snapshots without a .git directory or remote write-back. Downloads are bounded and pass through the existing archive validation and staged publication pipeline; this does not remove the need to review imported source before running it.
  • Platform credentials: the current code selects native credential backends. The recorded Windows runtime proof and Android credential-backend proof have different scope; GitHub authorization commands are not currently wired into the Android app. Linux/macOS runtime behavior must not be inferred from the abstraction or a build.

The latest recorded GitHub App registration state in canonical WI067 evidence is dated 2026-09-16 and says that no production app had been registered at that checkpoint. This repository snapshot contains no newer registration evidence. Treat GitHub authorization availability as unconfirmed until an operator records an updated status; do not infer registration from the source code or from a build-time configuration path.

Platform and release limits

Workbench is a source-build preview and its app version is independent from Core's. The current platform evidence is linked from the README: Windows x64 desktop checks and Android API 35 x86_64 scenarios have recorded results; Linux WSL2 headless checks do not establish Linux graphical runtime support. macOS and iOS are untested. No published installer availability or support commitment should be inferred from source code or a local build.

There aren't any published security advisories