You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
✅ UPDATE 2026-05-31: the public v1.0.0 tag was deleted from origin and verified gone (it was the only ref exposing .env.local; no GitHub Release existed). Remaining actions: rotate the Gemini key + the other.env.localsecrets, and add tag-scanning to CI.
P1 BLOCKER / live incident. A live Google/Gemini API key is already publicly fetchable in tag v1.0.0 of the public repo, the repo-root .env.local holds live Apple signing + ASC + GitHub PAT + Linear secrets in plaintext, and CI's gitleaks job structurally cannot catch either (runs only on main, never on tags). Treat all of these as compromised, rotate, purge published history, and close the scanner blind spot.
Findings:
Live Gemini key public in tag v1.0.0 (BLOCKER). Commit c673baa02b76 added .env.local = geminiApiKey=AIzaSy... (canonical 39-char Google key, blob fbd198c8). Verified live: git show v1.0.0:.env.local returns the key, git ls-remote --tags origin v1.0.0 → 56261f6c on origin, gh api repos/arul28/ADE reports private:false. Main is clean (c673baa02 is NOT an ancestor of main), so it looks safe but isn't. Only v1.0.0 of all v* tags contains the file. Fix: revoke/rotate the Gemini key now; delete/rewrite the public v1.0.0 tag/release (git filter-repo --path .env.local --invert-paths) and force-push a clean tag (or remove the tag on origin).
Repo-root.env.localholds live signing/ASC/PAT/Linear secrets in plaintext (HIGH). On-disk, 14 lines, currently untracked (gitignored at .gitignore:42). Line 1 is a bare 40-char ghp_... PAT (raw token, naive scanners miss it), plus CSC_LINK, CSC_KEY_PASSWORD, APPLE_API_KEY_P8 (full -----BEGIN PRIVATE KEY----- PEM), APPLE_API_KEY_ID, APPLE_API_ISSUER, ADE_LINEAR_API=lin_api_... — exactly what release-core.yml:148-165 consumes. The finding above proves this filename reached a public tag once, so the gitignore guard has already failed. Fix: rotate the PAT, Developer ID cert + CSC_KEY_PASSWORD, ASC .p8, and Linear key; move signing/ASC material out of the repo working dir (~/.asc/secrets manager / CI secrets); add a pre-commit hook blocking any .env* and any BEGIN PRIVATE KEY block.
gitleaks cannot see tag-only history.secret-scan (.github/workflows/ci.yml:53-61) runs gitleaks-action@v2, but CI triggers are push/pull_request: branches:[main] (ci.yml:3-7) — never tags; since v1.0.0 is unreachable from main, gitleaks structurally can't catch the leak. Fix: add a CI/scheduled gitleaks step scanning all refs incl. tags (gitleaks detect --log-opts='--all').
Verification confidence: High. Leaked key, public-tag presence, and repo visibility independently reproduced via git/gh; the working-tree .env.local (14 lines incl. a PEM block) and the gitleaks main-only trigger confirmed in-tree.
P1 BLOCKER / live incident. A live Google/Gemini API key is already publicly fetchable in tag
v1.0.0of the public repo, the repo-root.env.localholds live Apple signing + ASC + GitHub PAT + Linear secrets in plaintext, and CI's gitleaks job structurally cannot catch either (runs only onmain, never on tags). Treat all of these as compromised, rotate, purge published history, and close the scanner blind spot.Findings:
c673baa02b76added.env.local=geminiApiKey=AIzaSy...(canonical 39-char Google key, blobfbd198c8). Verified live:git show v1.0.0:.env.localreturns the key,git ls-remote --tags origin v1.0.0→56261f6con origin,gh api repos/arul28/ADEreportsprivate:false. Main is clean (c673baa02is NOT an ancestor of main), so it looks safe but isn't. Onlyv1.0.0of allv*tags contains the file. Fix: revoke/rotate the Gemini key now; delete/rewrite the publicv1.0.0tag/release (git filter-repo --path .env.local --invert-paths) and force-push a clean tag (or remove the tag on origin)..env.localholds live signing/ASC/PAT/Linear secrets in plaintext (HIGH). On-disk, 14 lines, currently untracked (gitignored at.gitignore:42). Line 1 is a bare 40-charghp_...PAT (raw token, naive scanners miss it), plusCSC_LINK,CSC_KEY_PASSWORD,APPLE_API_KEY_P8(full-----BEGIN PRIVATE KEY-----PEM),APPLE_API_KEY_ID,APPLE_API_ISSUER,ADE_LINEAR_API=lin_api_...— exactly whatrelease-core.yml:148-165consumes. The finding above proves this filename reached a public tag once, so the gitignore guard has already failed. Fix: rotate the PAT, Developer ID cert +CSC_KEY_PASSWORD, ASC.p8, and Linear key; move signing/ASC material out of the repo working dir (~/.asc/secrets manager / CI secrets); add a pre-commit hook blocking any.env*and anyBEGIN PRIVATE KEYblock.secret-scan(.github/workflows/ci.yml:53-61) runsgitleaks-action@v2, but CI triggers arepush/pull_request: branches:[main](ci.yml:3-7) — never tags; since v1.0.0 is unreachable from main, gitleaks structurally can't catch the leak. Fix: add a CI/scheduled gitleaks step scanning all refs incl. tags (gitleaks detect --log-opts='--all').Verification confidence: High. Leaked key, public-tag presence, and repo visibility independently reproduced via git/gh; the working-tree
.env.local(14 lines incl. a PEM block) and the gitleaks main-only trigger confirmed in-tree.