mirrors/hermes-agent
1
0
Fork 0
mirror of https://github.com/NousResearch/hermes-agent.git synced 2026-07-25 17:18:11 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions 6
hermes-agent/plugins/memory/openviking
History
pprism13 9291b786b4 fix(openviking): sanitize embedded newlines when writing .env secrets 
`_write_env_vars` in the OpenViking memory provider interpolates each
secret straight into a `KEY=VALUE` line, but the values only ever pass
through `_clean_config_value`, whose `value.strip()` trims surrounding
whitespace and leaves internal CR/LF intact. Because the file is strictly
line-oriented and is re-read via `read_text().splitlines()`, a value that
carries an embedded newline spills onto a second physical line, and the
tail is re-parsed as an independent `KEY=VALUE` entry on the next round
trip. A secret pasted with a trailing record (e.g. an `OPENVIKING_API_KEY`
copied with an extra line) therefore injects an arbitrary additional
variable into the persisted credentials file and silently corrupts it.

The fix neutralizes the line terminators at the single chokepoint where
values reach the file. A small `_env_line_safe` helper strips `\r`, `\n`,
and the NUL byte from each value, and both write sites in `_write_env_vars`
(the existing-key update branch and the appended-key branch) route through
it, so a value can only ever occupy the single line it is written on.

## What does this PR do?

Hardens the OpenViking memory provider's `.env` writer so a malformed or
pasted secret value can no longer break out of its `KEY=VALUE` line and
inject a rogue variable into the profile-scoped credentials file.

## Related Issue

N/A

## Type of Change

- [x] 🐛 Bug fix (non-breaking change that fixes an issue)

## Changes Made

- `plugins/memory/openviking/__init__.py`: add `_env_line_safe()` which
  removes `\r`, `\n`, and `\x00` from a value, and apply it to both the
  updated-key and appended-key write branches in `_write_env_vars()`.
- `tests/plugins/memory/test_openviking_provider.py`: add two regression
  tests covering a fresh write and an in-place key update with embedded
  CR/LF, asserting no injected line survives the read-back.

## How to Test

1. Run the targeted tests:
   `pytest tests/plugins/memory/test_openviking_provider.py -k env_writer -q`
2. Reverting the `_env_line_safe` sanitization makes
   `test_openviking_env_writer_strips_embedded_newlines_in_values` and
   `test_openviking_env_writer_strips_newlines_when_updating_existing_key`
   fail with a rogue `INJECTED_KEY=`/`ROGUE=1` line appearing in the file,
   confirming the tests pin the bug.
3. `ruff check plugins/memory/openviking/__init__.py` and
   `python scripts/check-windows-footguns.py plugins/memory/openviking/__init__.py`
   both pass.

## Checklist

### Code

- [x] I've read the Contributing Guide
- [x] My commit messages follow Conventional Commits
- [x] I searched for existing PRs to make sure this isn't a duplicate
- [x] My PR contains only changes related to this fix
- [x] I've run the relevant tests and they pass
- [x] I've added tests for my changes (required for bug fixes)
- [x] I've tested on my platform: macOS 15 (Darwin 25.5)

### Documentation & Housekeeping

- [x] I've updated relevant documentation (docstrings) — or N/A
- [x] I've updated `cli-config.yaml.example` if I added/changed config keys — N/A
- [x] I've updated `CONTRIBUTING.md` or `AGENTS.md` if I changed architecture or workflows — N/A
- [x] I've considered cross-platform impact (strips CR as well as LF) — done
- [x] I've updated tool descriptions/schemas if I changed tool behavior — N/A

(cherry picked from commit f29dd2df84)
2026-07-24 13:00:53 +05:30
..
__init__.py fix(openviking): sanitize embedded newlines when writing .env secrets 2026-07-24 13:00:53 +05:30
plugin.yaml feat(memory): improve OpenViking setup UX 2026-06-17 01:02:38 +08:00
README.md docs: clarify OpenViking local setup 2026-07-22 14:05:28 +05:30

README.md

OpenViking Memory Provider

Context database by Volcengine (ByteDance) with filesystem-style knowledge hierarchy, tiered retrieval, and automatic memory extraction.

Requirements

  • OpenViking installed with the openviking-server command available
  • OpenViking server config initialized and validated (openviking-server init, then openviking-server doctor)
  • OpenViking server running and reachable from Hermes

Setup

Prepare OpenViking first:

openviking-server init
openviking-server doctor
openviking-server

Then configure Hermes:

hermes memory setup    # select "openviking"

The setup can link to an existing ~/.openviking/ovcli.conf, copy its current connection values into Hermes, or create a minimal ovcli.conf when one does not exist.

Or manually:

hermes config set memory.provider openviking

Add the connection settings to the active profile's .env file. For the default profile that is ~/.hermes/.env; for a named profile use ~/.hermes/profiles/<profile>/.env.

OPENVIKING_ENDPOINT=http://127.0.0.1:1933
# OPENVIKING_API_KEY=...
# OPENVIKING_ACCOUNT=default
# OPENVIKING_USER=default
# OPENVIKING_AGENT=hermes

Config

OpenViking's server config is separate from Hermes:

  • ov.conf configures OpenViking storage, embedding/VLM models, auth, and server behavior. OpenViking reads it from --config, OPENVIKING_CONFIG_FILE, or ~/.openviking/ov.conf.
  • ovcli.conf stores client/CLI connection values such as url, api_key, account, and user. It is read from OPENVIKING_CLI_CONFIG_FILE or ~/.openviking/ovcli.conf.

Hermes-side provider config is read from environment variables in the active profile's .env:

Env Var Default Description
OPENVIKING_ENDPOINT http://127.0.0.1:1933 Server URL
OPENVIKING_API_KEY (none) User/admin API key for authenticated servers
OPENVIKING_ACCOUNT default Tenant account for local/trusted mode
OPENVIKING_USER default Tenant user for local/trusted mode
OPENVIKING_AGENT hermes Hermes peer ID in OpenViking, used for peer-scoped memories

When OPENVIKING_API_KEY is set, Hermes lets OpenViking derive account/user identity from the key. In local or trusted deployments without an API key, Hermes sends OPENVIKING_ACCOUNT and OPENVIKING_USER as identity headers.

Tools

Tool Description
viking_search Semantic search with fast/deep/auto modes
viking_read Read content at a viking:// URI (abstract/overview/full)
viking_browse Filesystem-style navigation (list/tree/stat)
viking_remember Store a fact directly with OpenViking content/write
viking_forget Delete one exact viking:// memory file URI
viking_add_resource Ingest URLs/docs into the knowledge base

Memory Writes And Deletes

viking_remember writes directly to OpenViking with POST /api/v1/content/write and mode=create. It creates peer-scoped memory files under viking://user/peers/${OPENVIKING_AGENT}/memories/...; OpenViking may return a canonical user-scoped form such as viking://user/default/peers/${OPENVIKING_AGENT}/memories/... in API-key mode. Explicit remembers do not depend on session commit extraction.

Hermes built-in memory tool additions are mirrored to OpenViking after the local memory operation succeeds:

Hermes action OpenViking operation
add content/write with mode=create under the configured peer memory namespace

Built-in replace and remove operations are not mirrored because Hermes native memory entries do not yet carry stable OpenViking file URIs. Use viking_forget when the user explicitly asks to delete a specific OpenViking memory URI.

viking_forget is intentionally narrow. It only accepts concrete user memory file URIs, such as viking://user/peers/hermes/memories/preferences/mem_abc123.md or the canonical viking://user/default/peers/hermes/memories/preferences/mem_abc123.md. Files directly under memories/, such as viking://user/default/memories/profile.md, are also allowed because OpenViking supports them. The tool rejects directories, resources, skills, sessions, generated summary files, and URIs with query strings or fragments. Use OpenViking's MCP, CLI, or admin APIs for broader resource and directory cleanup.