fix(security): expand .gitignore to comprehensive secrets baseline - #304
Conversation
Replaces the 11-line stub with a 392-line org-wide secrets-only .gitignore baseline (first layer of defence per push-protection.md). Covers: dotenv family, AWS/GCP/Azure/cloud credentials, Kubernetes kubeconfigs, Docker auth, Helm secrets, SSH/TLS keys, API key files, database connection strings, OAuth tokens, package-registry auth, Terraform/Vault state, IaC credentials, browser profiles, IDE config with embedded tokens, AI tooling keys, and Claude Code worktrees. Intentionally scoped to secrets only — build artefacts and OS cruft stay in per-repo .gitignores. Negations (`!*.example`, `!*.template`) preserve committed placeholder files. Salvaged from PR #88 (cherry-pick of .gitignore only; workflow/script changes in that PR were superseded by dev-lead refactors on main). Co-Authored-By: Claude Sonnet 4.6 (1M context) <noreply@anthropic.com>
There was a problem hiding this comment.
Copilot wasn't able to review any files in this pull request.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
|
Warning Rate limit exceeded
You’ve run out of usage credits. Purchase more in the billing tab. ⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Dev-Lead — human-pr (no-changes)No changes were needed for this PR. |
|
There was a problem hiding this comment.
Code Review
This pull request significantly expands the .gitignore file to establish a comprehensive 'secrets only' baseline for the organization, covering cloud credentials, IaC state, and modern AI tooling. Feedback focuses on refining the scope to avoid false positives by removing public certificate formats (*.cer, *.truststore) and ensuring consistency across IDE settings by allowing Zed's configuration file. Additionally, the reviewer noted that the placement of negation rules should be adjusted to align with the file's internal ordering guidelines to improve maintainability and reduce duplication.
| # Private keys — any common format | ||
| *.pem | ||
| *.key | ||
| *.cer |
There was a problem hiding this comment.
The *.cer extension is typically used for public X.509 certificates, not private keys. Since *.crt and *.cert are explicitly allowed (lines 141 and 143), *.cer should be removed from this 'Private keys' section to avoid false positives in projects that include public certificates, remaining consistent with the 'SECRETS ONLY' scope.
| *.pfx | ||
| *.jks | ||
| *.keystore | ||
| *.truststore |
There was a problem hiding this comment.
A *.truststore file contains public certificates of trusted Certificate Authorities (CAs) and does not typically contain private keys (which are stored in a keystore). Including it in a 'secrets only' baseline is likely a false-positive that could interfere with Java-based projects that need to distribute custom CA bundles.
| !*.pub | ||
| !*.pub.pem | ||
| !public.pem | ||
| !public_key.pem | ||
| !*.crt | ||
| !ca.crt | ||
| !*.cert |
There was a problem hiding this comment.
This block of negations is separated from the patterns they modify (e.g., *.pem on line 108 and *.key on line 109). The 'Ordering note' on lines 12-15 explicitly recommends keeping negations immediately after the broad patterns they carve out of. Following this rule would also help avoid the duplication seen later in the file (e.g., *.enc.yaml is negated both at line 95 and line 343).
| .cursor/mcp.json | ||
| .cursor-server/ | ||
| .windsurf/ | ||
| .zed/settings.json |
There was a problem hiding this comment.
This ignores the primary configuration file for the Zed editor. This is inconsistent with the treatment of VS Code (where settings.json is allowed) and prevents teams from sharing project-specific editor settings (e.g., indentation, linting). Unless Zed's settings.json is known to cache credentials (unlike VS Code's), it should be removed from the ignore list.
Dev-Lead — fix-bot-comment (no-changes)Engine ran but made no changes. |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: f96d75e03f
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| .cursor/mcp.json | ||
| .cursor-server/ | ||
| .windsurf/ | ||
| .zed/settings.json |
There was a problem hiding this comment.
Stop ignoring committed Zed project settings
Ignoring .zed/settings.json blocks the repository’s project-level Zed configuration from being added, which breaks shared editor behavior (formatting, language overrides, project tasks/remote settings) for teams that intentionally version this file. This turns a normal project config path into an untracked local-only file and can cause inconsistent tooling behavior across contributors.
Useful? React with 👍 / 👎.
| known_hosts | ||
| authorized_keys |
There was a problem hiding this comment.
Avoid ignoring SSH host-policy files
known_hosts and authorized_keys are public policy artifacts (host key pinning and allowed public keys), not secrets; ignoring them makes new/updated copies silently untrackable with normal git add . flows. In infrastructure repos that commit these files for SSH hardening, this can prevent required trust-policy updates from landing and leads to configuration drift across environments.
Useful? React with 👍 / 👎.
| # GPG / PGP | ||
| *.gpg | ||
| *.pgp | ||
| *.asc |
There was a problem hiding this comment.
Don’t blanket-ignore armored signature files
Ignoring *.asc blocks committing detached OpenPGP signatures and ASCII-armored public key files, which are commonly published with release artifacts to support integrity verification. In repos that distribute signed bundles, this pattern makes those verification assets disappear from normal staging and weakens reproducible release workflows.
Useful? React with 👍 / 👎.



Summary
Salvaged from PR #88 (cherry-pick of
.gitignoreonly).Expands the 11-line stub into a 392-line org-wide secrets-only baseline — the first layer of defence per
standards/push-protection.md. The workflow/script changes in PR #88 were fully superseded by 20+ commits of dev-lead refactoring on main, so those are discarded.What's covered
.env,.envrc,.env.vault.keys, negations for*.example/*.template)*secret*,*credential*,*apikey*, etc.).npmrcwith tokens,pip.conf,~/.pypirc).claude/worktrees/,.claude/scheduled_tasks.lock)Intentionally secrets only — build artefacts, OS cruft, and editor swap files belong in per-repo
.gitignores.Why close PR #88 instead of rebasing it
PR #88's non-
.gitignorechanges (workflow caching, engine.sh additions, review-one-pr.sh tweaks) all landed on main through subsequent PRs. Rebasing the full branch would produce conflicts across 5+ files that have been significantly restructured by the dev-lead refactor.Closes #88
🤖 Generated with Claude Code