From: Kache Hit Date: Mon, 24 Nov 2025 18:40:49 GMT Subject: Re: Filter smudge for secret restoration: no disk access? Message-ID: In-Reply-To: On Mon Nov 24, 2025 at 1:01 AM PST, Johannes Sixt wrote: > A smudge filter must read its stdin and write the result to stdout. The > presence of %f in the configuration does not change this. > > The filter can inspect the file name it receives via the %f token (note: > the *name* of the file, not the file itself) to draw additional hints > how to process the data, but it still has to read stdin and write to stdout. Yes, I underststand. I'm asking why it's necessary that smudge not read from disk, even as it properly satisfies that stdin/stdout operation, as in my Python implementation of `smudge()` On Mon Nov 24, 2025 at 1:49 AM PST, Chris Torek wrote: > For sanity purposes, if no other reasons, it might be wise to store a > "file with secrets" under a file with a name such that it is **never** > controlled by Git (i.e., always listed in a .gitignore or equivalent, > or outside the working tree entirely), and to store instead, in Git, a > "template file with secrets that are replaced". That way, the secrets > either exist on disk (and are secret because Git is blind to them), or > do not exist at all (and are therefore secret to Git). The template > file controls the template and nothing else; the secret-data file has > both secrets and, perhaps, data that are extracted from the > Git-controlled file as well. > > In this manner, a "to-be-smudged" file named foo.template might > control some external-to-Git manipulation of an invisible-to-Gt file > named foo.secret, and no clean filter would be required at all, though > one could inspect and strip secrets accidentally copied into a > foo.template. I'm familiar with this practice, e.g. committing an `.env.template` which is used to create an `.env` file with secrets within. However, this is my dotfiles repo that includes `~/.config`. There are config files that store credentials right next to configuration, managed by software that I don't control. Although I could still apply that pattern by ignoring `foo.yml` and committing a redacted `foo.template.yml`, I'd have to manually upstream changes back to the template as the config file changes. Another use case is to ignore changes to a specific line without losing the working copy. Some software saves a volatile "last_updated_at" or "last_opened" field into config that doesn't need to be committed. This could also be useful for https://stackoverflow.com/questions/16244969 and https://stackoverflow.com/questions/61091219 - Kache