Prevent files from accidental add

[thomasa88]

I'm setting up chezmoi and I'm happily adding a lot of files. However, I want some files to never enter chezmoi as they contain a bit sensitive local host only configurations.

Is there any keyword I can write in such files to make chezmoi refuse to add those files?

> echo "# chezmoi-sensitive" >> my_file.conf
> chezmoi add my_file.conf
Error: Will not add my_file.conf as it is marked as containing sensitive information ('chezmoi-sensitive')

[thomasa88]

A git commit hook could probably be a band-aid 🤔

E.g. https://stackoverflow.com/a/64240810/106019 :

# Source - https://stackoverflow.com/a/64240810
# Posted by axiac, modified by community. See post 'Timeline' for change history
# Retrieved 2026-05-16, License - CC BY-SA 4.0

#!/usr/bin/env bash


# The text that refuses the commit
# Change it to match your needs; keep it enclosed in single quotes
MARKER='// DONT COMMIT'


# Verify the staged files for the presence of the marker text
if git diff --cached --name-only | xargs grep -q "$MARKER"; then
  echo 'Cannot commit because the "no-commit" marker has been found in one of the staged files.' 1>&2
  # Refuse to commit
  exit 1
fi

[Lockszmith-GH]

nice hack

[bradenhilton]

.chezmoiignore will do this:

❯ cat ~/.local/share/chezmoi/.chezmoiignore
testfile.txt

❯ chezmoi add ~/testfile.txt
chezmoi: warning: ignoring testfile.txt

[halostatue]

Chezmoi 2.70 uses betterleaks not gitleaks.

I'm not sure if it is reading a betterleaks config.

[thomasa88]

It looks to be hardcoded to me:
c.betterleaksDetector, c.betterleaksDetectorErr = detect.NewDetectorDefaultConfig()

chezmoi/internal/cmd/config.go

Line 1597 in 2e418c0

c.betterleaksDetector, c.betterleaksDetectorErr = detect.NewDetectorDefaultConfig()

It leads down to

var (
	//go:embed betterleaks.toml
	DefaultConfig string
)

in betterleaks.

I thought that maybe I could do a quick binary hack to change a line in betterleaks.toml embedded into chezmoi, but I did not find the string (Compressed? snap in the way?) :p strings /snap/chezmoi/current/chezmoi | grep matchesAny -> no results

[halostatue]

No. Exposing a *leaks config path or a standard file read instead of the default would make a reasonable feature request.

[twpayne]

chezmoi does not read any betterleaks config. betterleaks is compiled into the binary and uses the default betterleaks configuration.

The keyword idea is interesting, but I'm generally against it for several reasons:

• It requires chezmoi to interpret the contents of the destination file, and changes chezmoi's behavior. Currently, chezmoi doesn't do anything like this.
• It's not a general solution. Only files that include the keyword in some kind of comment can be managed this way.
• There are lots of weird edge cases. For example, what should chezmoi do if it creates a file with the keyword? Should chezmoi ignore the file?

.chezmoiignore already exists for this purpose, is entirely within the source state, is unambiguous, and works with all file types.

[thomasa88]

I will not press the issue, but here are some replies:

• Regarding interpreting keywords, I mean that chezmoi is already doing that through betterleaks.
• I agree that that the file must be able to store the secret keyword without affecting the file's functionality.
• Good point on creating a file with the keyword. What happens today if it generates a file that betterleaks bails on?

On the hacky path:
Better string grepping fu today! strings /snap/chezmoi/current/chezmoi | grep keywords reveals the betterleaks config. However, I did realize that betterleaks requires the secret to have high entropy. It also seems possible to add betterleaks:allow into a file, but not betterleaks:deny.

Putting secret=YmVkcm9jay5hbWF6b25hd3MuY29t in a file makes betterleaks/chezmoi complain :). But both that and a possible betterleaks:allow is a bit fragile, in case betterleaks changes or another tool than betterleaks is used.

chezmoi: /home/thomas/trash/test-chezmoi-betterleaks.txt:1: Detected a Generic API Key, potentially exposing access to various services and sensitive operations.