Skip to content

Security: mithilai/gforge-python

Security

SECURITY.md

Security Policy

GForge is a security tool. A weakness in it can quietly let a credential reach a public repository, so reports are taken seriously.

Supported versions

Only the latest published release receives security fixes.

Reporting a vulnerability

Do not open a public issue. Report privately through GitHub's private vulnerability reporting on this repository, or email mithilm21@gmail.com.

If the issue is inherited from the upstream Node implementation — a detection gap, a rule bypass, or an unsafe install behaviour that exists there too — please also report it to the upstream project at psspl-gaurang/gforge.

Please include:

  • the version (gforge version), OS, and Python version;
  • what you expected to happen and what happened instead;
  • a minimal reproduction.

Never include a real secret in a report. Use an obviously fake value with the same shape (length, alphabet, prefix). If a real credential has already been committed anywhere, rotate it first — a report is not a substitute for rotation.

What to expect

  • An acknowledgement within 5 working days.
  • An assessment and a target fix window within 10 working days.
  • Credit in the release notes, unless you prefer to stay anonymous.

Please give a reasonable window to ship a fix before public disclosure.

Scope

In scope:

  • Detection bypasses — a realistic credential shape that the engine misses.
  • Secret disclosure by GForge itself — any path where a matched value, or a value from a .env file, is written to a log, an error message, the terminal, or a file.
  • Install-time issues — command or path injection through the generated hook, unsafe file permissions in ~/.gforge, or an uninstall that fails to restore the user's original core.hooksPath.
  • Fail-open behaviour — any way a commit is allowed through unscanned when the scanner could not run. GForge is designed to fail closed.
  • Supply-chain issues in the self-update path.

Out of scope:

  • False positives. Use gforge:allow, .gforgeignore, or --no-verify, and open a normal issue.
  • git commit --no-verify. Bypassing hooks is a documented, deliberate Git feature; GForge is a guardrail, not an enforcement boundary against the person running the commit.
  • Secrets already present in history. GForge scans staged changes only.
  • Findings that require an attacker to already control the developer's machine or their global Git configuration.

A note on the threat model

GForge protects against accident, not against a determined local user. Anyone who can run git commit can also run git commit --no-verify or edit ~/.gforge/hooks. For an enforcement boundary, pair GForge with server-side push protection and secret scanning.

There aren't any published security advisories