Skip to content

v0.8.7 — Remediation Safety Fixes

Choose a tag to compare

View all tags
@neil-data neil-data released this 17 Sep 11:29
· 6 commits to main since this release
v0.8.7
df7769a

Highlights

This release fixes three issues found during live verification of v0.8.0's new envguard fix command. All three affected real, common scenarios rather than obscure edge cases, and are fixed here before fix sees wider use.

Fixed

  • fix failed to parse files containing a UTF-8 byte-order-mark (BOM) — scan, check, and ci have always correctly handled BOM-prefixed files (the default output of Out-File -Encoding utf8 in PowerShell), but fix's code-rewriting logic rejected them with a "Failed to parse Python syntax: invalid non-printable character U+FEFF" error, reporting them as requiring manual remediation. fix now handles BOM-prefixed files the same way the rest of EnvGuard always has.

  • fix --apply could leave a real secret exposed to Git — after moving a hardcoded secret into .env, fix did not ensure .env was excluded from version control. In a repository with no existing .gitignore, this left the newly created .env — containing the real, unmasked secret value — as a plain untracked file, one git add . away from being committed into Git history. fix --apply now automatically creates or updates .gitignore to exclude .env and its common variants (.env.local, .env.*.local) as part of every remediation.

  • fix incorrectly re-scanned .env as source code — after .env was populated with a real secret value, a subsequent fix run detected that secret inside .env itself and proposed rewriting it, producing a meaningless no-op diff. .env and .env.example are now correctly excluded from fix's scan targets, since they are remediation destinations, not source files to be remediated.

Verified in this release

  • All three fixes reproduced against the exact failing scenarios from v0.8.0 before the fix, and reconfirmed resolved afterward using the same reproduction steps.
  • Re-verified that fix's core safety behaviors — dry-run-by-default, refusal to run on a dirty Git working tree, and the fallback for structurally unsafe rewrites (f-strings, conditional expressions, function calls) — continue to work correctly and were unaffected by these fixes.
  • Confirmed the new .gitignore entry is created with real content (.env, .env.local, .env.*.local) and that git status no longer flags a freshly created .env as requiring attention.

Recommendation: Anyone who used envguard fix --apply under v0.8.0 should check their repository's .gitignore and confirm .env was not committed before this fix was available.

Assets 2
Loading