v3.0.3
git-tidy 3.0.3 — round sixteen
3.0.2 could hard-delete a certificate. The exemption added there was meant to
apply to trash.sensitive alone, and _protects returned early on that branch and
never reached the clean.ignored_keep line — so a .pem holding no private key
lost its protection, was deleted outright with no quarantine, and did not
appear in the report at all. Three documents promise the opposite in as many
words, one of them the file git-tidy init writes into the user's config.
local_state is checked first now, and unconditionally.
The 64 KB peek made the same hole lose real keys. A haproxy.pem is
cat fullchain.pem privkey.pem, and a long chain puts the key past it: the
file was read, declared harmless and deleted. It reads the whole file now, up
to a ceiling no bundle approaches; anything larger keeps its protection unread.
doctor --fix:
- A remote with two credentialed url values reported the first strip as
failed, because the read-back narrowed by setting rather than by value and
found the second one still there. It sent somebody to hand-edit a file that
was already clean, and exited 1. - A URL stored with surrounding whitespace never matched its own value-pattern,
built from a trimmed copy, so git appended one more url= on every run for
ever. Values are read with -z and untouched now, and --fixed-value is used
where git has it. - A dirty detached HEAD was summarised as "uncommitted changes — left on their
branch", which put it in FORCE_CAN_FIX. --force sets sync.stash, which this
path does not read; in a repository with no remote nothing rescues it, so the
advice was simply wrong. And it is on no branch.
Also: rmtree removes what it can before raising, so a directory that could not
be emptied was reported as a pure failure while three files had really gone.
And PyYAML's Reader refuses a non-printable character anywhere, quoted scalars
included — the check looked outside the quotes only, so \x00 and \x7f loaded on
every shipped binary and were a ReaderError from a checkout.