mirror of
https://github.com/diegosouzapw/OmniRoute.git
synced 2026-08-17 20:52:15 +03:00
24ef1dc3d4
* 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>
30 lines
2.0 KiB
Markdown
30 lines
2.0 KiB
Markdown
# 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
|
|
|
|
1. Rotate/revoke the key immediately.
|
|
2. Remove the secret from the history and force-push a cleaned branch if necessary.
|
|
3. Notify maintainers and follow your org's incident response checklist.
|