mirror of https://github.com/diegosouzapw/OmniRoute.git synced 2026-08-17 20:52:15 +03:00

Files

blarovse 24ef1dc3d4 Sanitize test fixtures, add developer .env guidance, and add gitleaks… (#10411 )

* Sanitize test fixtures, add developer .env guidance, and add gitleaks workflow

- Replace realistic-looking AWS keys and PEM fixtures in unit tests with synthetic placeholders to avoid false positives from secret scanners.
- Add docs/DEVELOPER-ENVIRONMENT.md describing postinstall .env behavior and remediation guidance.
- Add .github/workflows/gitleaks.yml to run gitleaks on pull requests.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

* Add gitleaks baseline and CI baseline support; update ignore and PR body\n\n- Copy gitleaks-local.json -> gitleaks-baseline.json\n- Add --baseline-path to workflow\n- Allowlist baseline in .gitleaks.toml\n- Ignore gitleaks-local.json\n- Add PR_BODY.md with scan summary\n\nCo-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

* chore(security): fix gitleaks config, drop redundant baseline/CI, clean doc artifacts

- Fix the malformed .gitleaks.toml [[rules]] block: an inline [rules.allowlist]
  with only paths (no regex/path at rule level) made gitleaks refuse to load the
  config (`FTL Failed to load config ... both |regex| and |path| are empty`),
  turning the project's blocking check-secrets ratchet into a hard failure.
  Verified: check-secrets config now loads and exits 0.
- Reconcile with the existing gitleaks gate: remove the redundant
  .github/workflows/gitleaks.yml and root gitleaks-baseline.json (a second,
  differently-scoped scanning mechanism + an unreviewed 430-finding blanket
  baseline) — the project already runs scripts/check/check-secrets.mjs as a
  blocking ratchet in ci.yml/quality.yml and its .gitleaks.toml policy is to fix
  real findings, not blanket-allowlist them.
- Remove the stray PR_BODY.md automation artifact from the repo root.
- Fix the duplicated <div align="center"> tag in README.md.

Co-authored-by: diegosouzapw <8016841+diegosouzapw@users.noreply.github.com>

---------

Co-authored-by: OmniRoute Bot <noreply@omniroute.local>
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Co-authored-by: blarovse <312250233+blarovse@users.noreply.github.com>
Co-authored-by: diegosouzapw <8016841+diegosouzapw@users.noreply.github.com>

2026-08-17 08:23:10 -03:00

2.0 KiB

Raw Blame History

Developer environment notes

This page explains the project's local .env behavior and how to handle environment files and secrets when developing OmniRoute.

.env postinstall behavior

The project may generate a local .env file during npm install / postinstall for developer convenience. This file is intended only for local development and testing and must never be committed to version control.

Key points:

The repository's .gitignore already ignores .env* files (see the .gitignore entry). Do not remove or alter that rule unless you deliberately intend to commit a specific example file and have a documented process for it.
If a real secret is accidentally committed to the repo, rotate/revoke the credential immediately and remove it from the repository history (for example, using git filter-repo or an equivalent remediation workflow). Contact the security/contact owner if you need help.
For CI and production, use the CI secrets or a secrets manager (GitHub Actions Secrets, Azure Key Vault, HashiCorp Vault, etc.) rather than committing secrets to files.

Recommended local workflow

Keep .env in your local workspace only. Use .env.example (already tracked) to document required variables and acceptable example values.
When running tests locally that require secret-like values, prefer synthetic placeholders or runtime-generated ephemeral keys rather than real credentials.
Add a short comment in tests that use placeholders so reviewers understand the fixture is synthetic.

Scanner notes

Some compiled or binary assets (e.g., embedded base64 WASM blobs) can contain ASCII substrings that look like credentials and may trigger text-based secret scanners. If these assets are legitimate, either mark them in the scanner's allowlist or exclude the directories in the scanner config.

If you find a leak

Rotate/revoke the key immediately.
Remove the secret from the history and force-push a cleaned branch if necessary.
Notify maintainers and follow your org's incident response checklist.

2.0 KiB Raw Blame History