LabFox is an unofficial third-party GitLab client. It authenticates to GitLab instances on the user's behalf and therefore handles credentials that grant full API access to source code, CI/CD, and private infrastructure. Security reports are taken seriously, and this document explains how to send one without making the problem worse.

Security fixes are assessed against:

• the latest code on the dev branch (the default branch and the target for all contributor pull requests)
• released versions on the main branch

Older tags and forks are not covered. The project is in early development and has no runnable build yet, so most reports at this stage concern the source code rather than a shipped binary.

Report privately through GitHub private vulnerability reporting:

Report a vulnerability

Or from the repository: Security tab → Report a vulnerability.

This opens a draft security advisory visible only to you and the maintainers.

If you cannot use GitHub advisories, email inquiry@sloki9637.com instead. Advisories are preferred: they keep the report, the fix, and the disclosure in one place.

Do not attempt to reach maintainers privately through public issues, pull request comments, or social media.

Do not open a public issue or pull request that contains:

• GitLab Personal Access Tokens (glpat-...), OAuth access tokens, or refresh tokens
• Authorization headers or any other raw credential material
• self-hosted GitLab instance hostnames, internal URLs, or other details about private infrastructure
• private source code, diffs, job logs, or API responses taken from a real instance
• exploit steps or proof-of-concept code for an unfixed issue

If you have already posted any of the above publicly, say so in your report so the exposure can be handled first. Assume a leaked token is compromised and revoke it in GitLab immediately.

A useful report includes:

• the affected component (for example packages/gitlab_api, packages/secure_storage, the Dio interceptor layer, deep-link handling)
• the commit or branch you looked at
• what an attacker gains, and what access they need to get it
• reproduction steps, with tokens, hostnames, and employer-confidential data redacted

No response time is promised. LabFox is maintained by a single maintainer.

In scope:

• storage or leakage of GitLab Personal Access Tokens and OAuth access/refresh tokens
• failures in the Authorization-header masking interceptor, or any path where a credential can reach logs, crash reports, or error output
• TLS and certificate handling for self-hosted instances, including certificate validation bypasses and custom-CA handling
• deep-link handling and OAuth redirect handling
• exposure of the local cache (Drift/SQLite database, on-disk artifacts, screenshots of sensitive views)
• vulnerable dependencies
• any network traffic sent to a host other than the GitLab instance the user configured

Out of scope:

• vulnerabilities in GitLab itself — report those to GitLab Inc. through GitLab's own process
• misconfiguration of a user's GitLab server, network, proxy, or CA store
• issues in third-party Flutter tooling, unless LabFox uses it in a way that creates the flaw
• reports generated by automated scanners without a demonstrated impact on LabFox

Stated as the intended design, so deviations from it are treated as security bugs:

• Personal Access Tokens and OAuth tokens are stored through platform secure storage (flutter_secure_storage). They are never written to the Drift/SQLite database, never stored in plaintext, and never written to logs.
• Outbound requests carry an Authorization header to the user-configured GitLab instance. A Dio interceptor masks that header so it cannot reach logs or error reports.
• Instance hostnames are treated as sensitive. Users routinely connect to internal corporate or home-lab servers, and the hostname alone discloses private infrastructure.

If you find code that contradicts any of the above, that is a vulnerability, not a style issue.

Do not test against GitLab instances, accounts, projects, groups, or data that you do not own or do not have explicit written permission to assess. Use your own instance or a throwaway GitLab.com account. Do not run scans, brute-force attempts, or denial-of-service tests against anyone else's infrastructure, and do not access another user's data to prove an issue.

Reports that required unauthorized access to produce will not be acted on.

• SUPPORT.md — where to ask non-security questions
• CONTRIBUTING.md — contribution process
• README — project overview and scope