Re: Filter smudge for secret restoration: no disk access?

From: Chris Torek <chris.torek@gmail.com>
Date: Nov 24, 2025, 09:49 UTC
Message-ID: <CAPx1GvcXkXMpWgOyMWdfHXGEDJQY4wJrJV0p7LHBMeQFPMDHnQ@mail.gmail.com>
In-Reply-To: <9aa7cfdb-fc50-4ceb-936c-2ed441c462a3@kdbg.org>

On Mon, Nov 24, 2025 at 1:01 AM Johannes Sixt <j6t@kdbg.org> wrote:

> 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.

It can, of course, also read and/or write anything else on disk.

When and how this is actually useful is another matter entirely.

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.

Chris