hermes-agent

Files

T

shehjaddev d205cef418 fix(redact): mask assignments in secret-bearing file reads

read_file/search_files passed file_read=True, which folded into code_file=True and skipped
the ENV/JSON/YAML assignment passes, so an opaque prefix-less credential under a
credential-shaped key reached the model in cleartext from a secret-bearing file — the
file-read half of the #110228 gate (#110567).

Two defects on that path, both fixed here:

- The rendered line-number gutter ("5|      ADS_API_TOKEN: ..." from read_file,
  "6:      ADS_API_TOKEN: ..." from grep -n / cat -n) defeated the line-anchored patterns,
  so the real rendered read leaked exactly what the raw text masked. A gutter-free fixture
  cannot see this, which is why the tool-level tests carry the real render shape.
- _is_secret_file_arg() could not see the RESOLVED Hermes home: the default home's basename
  is an installation detail (".hermes" on POSIX, "hermes" under AppData/Local on Windows) and
  a resolved path never spells $HERMES_HOME, so the managed Windows home's config.yaml was
  classified as ordinary YAML on both the file-read and the terminal surface.

Changes:

- redact_sensitive_text(): secret_file= re-enables the assignment passes for content the
  caller classified with _is_secret_file_arg, keeping code_file behaviour everywhere else.
  It is authoritative over code_file, so a caller cannot be fail-open on the security flag
  by setting both.
- _redact_assignments(): mask_nonreusable selects the non-reusable sentinel for file reads,
  so the #35519 write-back hazard stays closed.
- _should_redact_assignment(): no longer re-masks an already-masked value, which was erasing
  the vendor label the sentinel deliberately keeps.
- _is_secret_file_arg(): consult the resolved Hermes home for the config.yaml arm.
- _CFG_ANCHORED_RE / _YAML_ASSIGN_RE: tolerate a rendered line-number gutter.
- file_tools.py: classify the resolved path at all three file-read call sites.

Closes #110567

2026-09-15 06:26:29 -07:00

emails

fix(redact): mask assignments in secret-bearing file reads

2026-09-15 06:26:29 -07:00

README.md

fix(ci): make tests, workflows, and attribution reliable under load (#66373 )

2026-07-17 20:55:24 +00:00

README.md

This directory replaces appending entries to AUTHOR_MAP in scripts/release.py. The old dict caused constant merge conflicts when several salvage PRs landed at once — every PR edited the same lines of the same file. Here, each mapping is its own file, and file additions never conflict.

Adding a mapping

One file per commit-author email, under emails/:

python3 scripts/add_contributor.py <email> <github-login>
# or by hand:
echo "<github-login>" > contributors/emails/<email>

File name = the exact commit-author email (as shown by git log --format='%ae').
File content = the GitHub login on the first non-comment line. Lines starting with # are comments (use them for the PR reference).

Example — contributors/emails/jane.doe@example.com:

janedoe
# PR #12345 salvage (gateway: fix session key routing)

Rules

Do NOT add new entries to AUTHOR_MAP in scripts/release.py. That dict is frozen legacy data; the release tooling merges it with this directory (directory entries win on duplicates).
GitHub noreply emails (<id>+<login>@users.noreply.github.com and <login>@users.noreply.github.com) auto-resolve — no file needed.
The Contributor Attribution Check CI job fails a PR whose commits carry an unmapped email; the failure message prints the exact command to run.

README.md

Contributor email → GitHub login mappings

Adding a mapping

Rules