chore(deps): npm audit fix — clear transitive undici advisories by teknium1 · Pull Request #49113 · NousResearch/hermes-agent

teknium1 · 2026-06-19T15:11:05Z

Summary

Clears the 2 npm audit advisories (1 high, 1 moderate), both from transitive undici.

Changes

package-lock.json — npm audit fix, lockfile-only (no package.json edits):
- undici 6.26.0 → 6.27.0 — high (TLS validation bypass / Set-Cookie header injection / keep-alive response-queue poisoning class). Pulled via node-gyp (→ @electron/rebuild) and ui-tui.
- jsdom's nested undici 7.27.2 → 7.28.0 — moderate. Pulled via jsdom (vitest / apps/desktop test dep).
- Incidental in-range reconciliations during the install: dompurify 3.4.10 → 3.4.11 (patch), and the web workspace's already-declared vitest ^4.1.5 devDep synced into the lockfile.

Both undici bumps are in-range (no --force). All advisory paths are dev/build-time transitive deps — neither undici ships in the runtime agent.

Validation

package dir	before	after
root	2 (1 high, 1 moderate)	0
ui-tui	1 high	0
apps/desktop	2 (1 high, 1 moderate)	0

All three resolve through the root workspace node_modules; only the root package-lock.json changed.

Infographic

Resolves the 2 npm audit advisories (1 high, 1 moderate), both from transitive undici: - undici 6.26.0 -> 6.27.0 (high: TLS bypass / header injection / response queue poisoning class, via node-gyp + ui-tui) - jsdom's undici 7.27.2 -> 7.28.0 (moderate, via jsdom test dep) Both are in-range bumps (no --force). Lockfile also reconciled two pre-existing manifest drifts during the install: dompurify 3.4.10 -> 3.4.11 (in-range patch) and the web workspace's already-declared vitest ^4.1.5 devDep. No package.json changes. npm audit reports 0 vulnerabilities in root, ui-tui, and apps/desktop after.

github-actions · 2026-06-19T15:11:57Z

🔎 Lint report: `hermes/hermes-d14bb0f8` vs `origin/main`

ruff

Total: 0 on HEAD, 0 on base (➖ 0)

🆕 New issues: none

✅ Fixed issues: none

Unchanged: 0 pre-existing issues carried over.

ty (type checker)

Total: 11157 on HEAD, 11157 on base (➖ 0)

🆕 New issues: none

✅ Fixed issues: none

Unchanged: 5847 pre-existing issues carried over.

Diagnostics are surfaced as warnings — this check never fails the build.

…es (NousResearch#49113) Resolves the 2 npm audit advisories (1 high, 1 moderate), both from transitive undici: - undici 6.26.0 -> 6.27.0 (high: TLS bypass / header injection / response queue poisoning class, via node-gyp + ui-tui) - jsdom's undici 7.27.2 -> 7.28.0 (moderate, via jsdom test dep) Both are in-range bumps (no --force). Lockfile also reconciled two pre-existing manifest drifts during the install: dompurify 3.4.10 -> 3.4.11 (in-range patch) and the web workspace's already-declared vitest ^4.1.5 devDep. No package.json changes. npm audit reports 0 vulnerabilities in root, ui-tui, and apps/desktop after.

根因:bake_tirith 以 HERMES_HOME=/opt/hermes 跑,ensure_installed → load_config → ensure_hermes_home 把 /opt/hermes(及 skills/、cron/、 logs/ 等)chmod 0700 并播种 SOUL.md。merge v2026.7.1 前靠后置的 `chmod -R a+rX` 兜底;上游 NousResearch#49113 为省构建时间删掉该步改用 COPY --chmod 后,0700 被永久烘进镜像层 → 运行时 hermes uid 对 /opt/hermes 无读/执行权 → cont-init 全部 `unable to exec /opt/hermes/.venv/bin/python: Permission denied`, 54 个 docker 集成测试超时,Docker CI 双架构长期全红。修法:烘焙以 HERMES_HOME=/tmp/tirith-bake 跑,chmod/播种垃圾全落 scratch;仅用 `install -m 0755` 把校验过的二进制提升到 /opt/hermes/bin/tirith(运行时 PATH 首位,`which tirith` 解析不变, 与运行时 HERMES_HOME=/opt/data 无关),然后删除 scratch。不回加 chmod -R(避免重造上游刚删的构建耗时与 merge 冲突面)。同步更新 tests/docker/test_runtime_bundle_contract.py 合同测试: 断言改为「烘焙必须用 scratch home + 二进制提升进 /opt/hermes/bin」, 并加 `HERMES_HOME=/opt/hermes` 不得出现的回归守卫。本机验证(无 docker,静态+真跑安装器):以 scratch home 跑 Dockerfile 同款 bake 脚本 → 0700/SOUL.md 全落 scratch、二进制 19MB 落 scratch/bin/tirith;install -m 0755 提升后 `tirith --version` = tirith 0.3.3 正常执行,which 经 PATH 解析, scratch 删净;合同测试 3 条全过。 Co-authored-by: Claude Fable 5 <noreply@anthropic.com>

…es (NousResearch#49113) Resolves the 2 npm audit advisories (1 high, 1 moderate), both from transitive undici: - undici 6.26.0 -> 6.27.0 (high: TLS bypass / header injection / response queue poisoning class, via node-gyp + ui-tui) - jsdom's undici 7.27.2 -> 7.28.0 (moderate, via jsdom test dep) Both are in-range bumps (no --force). Lockfile also reconciled two pre-existing manifest drifts during the install: dompurify 3.4.10 -> 3.4.11 (in-range patch) and the web workspace's already-declared vitest ^4.1.5 devDep. No package.json changes. npm audit reports 0 vulnerabilities in root, ui-tui, and apps/desktop after.

Installing a memory provider (Honcho, mem0, hindsight, ...) from the dashboard Plugins page failed on hosted deployments with a permission error: the setup endpoint shelled out to `uv pip install --python sys.executable`, which targets the sealed read-only venv under /opt/hermes (immutable hosted image, NS-579/#49113). The correct mechanism already exists: tools/lazy_deps.py redirects installs to the writable durable target on the data volume (HERMES_LAZY_INSTALL_TARGET=/opt/data/lazy-packages) when the venv is sealed (HERMES_DISABLE_LAZY_INSTALLS=1), appends the target to the END of sys.path (core venv always wins collisions), and constrains shared deps to core-venv versions. The dashboard installer simply never used it. Fix: - tools/lazy_deps.py: new public install_specs() — installs arbitrary manifest-declared pip specs through the same environment routing as ensure(): venv-scoped by default, durable-target on sealed images, refused with an actionable reason when gated off (config kill switch or sealed venv without a target — never surfaces raw EROFS/EACCES). Specs are validated with _spec_is_safe(); post-install it invalidates import/metadata caches so availability rechecks in the same process see the new packages without a restart. Never raises. - hermes_cli/web_server.py: _install_memory_provider_pip_dependencies now calls install_specs() instead of building its own uv/pip subprocess. Blocked installs surface the gate reason in the setup results; the response's status block reflects post-install availability (stale 'missing deps' state clears immediately). - hermes_cli/memory_setup.py, plugins/memory/honcho/cli.py, plugins/memory/mem0/_setup.py: CLI setup wizards routed through install_specs() too — same sealed-venv failure mode, same fix. No hosted setup path writes to /opt/hermes anymore; provider discovery and installation now use the same environment (sys.path activation is shared with the lazy-install bootstrap in hermes_bootstrap). Tests: - tests/tools/test_lazy_deps.py: TestInstallSpecs — gating matrix (sealed+no-target blocked with immutable-deployment reason, config kill switch, sealed+target proceeds), spec-safety rejection before any subprocess, venv-scoped vs --target command display, failure stderr passthrough, never-raises contract. - tests/hermes_cli/test_web_server.py: setup endpoint routes pip through lazy_deps (regression guard asserts no direct 'pip install' subprocess), blocked-reason surfacing, same-response availability recheck clears stale missing state. Fixes NS-605 (Plain T-1111).

…es (NousResearch#49113) Resolves the 2 npm audit advisories (1 high, 1 moderate), both from transitive undici: - undici 6.26.0 -> 6.27.0 (high: TLS bypass / header injection / response queue poisoning class, via node-gyp + ui-tui) - jsdom's undici 7.27.2 -> 7.28.0 (moderate, via jsdom test dep) Both are in-range bumps (no --force). Lockfile also reconciled two pre-existing manifest drifts during the install: dompurify 3.4.10 -> 3.4.11 (in-range patch) and the web workspace's already-declared vitest ^4.1.5 devDep. No package.json changes. npm audit reports 0 vulnerabilities in root, ui-tui, and apps/desktop after.

Installing a memory provider (Honcho, mem0, hindsight, ...) from the dashboard Plugins page failed on hosted deployments with a permission error: the setup endpoint shelled out to `uv pip install --python sys.executable`, which targets the sealed read-only venv under /opt/hermes (immutable hosted image, NS-579/NousResearch#49113). The correct mechanism already exists: tools/lazy_deps.py redirects installs to the writable durable target on the data volume (HERMES_LAZY_INSTALL_TARGET=/opt/data/lazy-packages) when the venv is sealed (HERMES_DISABLE_LAZY_INSTALLS=1), appends the target to the END of sys.path (core venv always wins collisions), and constrains shared deps to core-venv versions. The dashboard installer simply never used it. Fix: - tools/lazy_deps.py: new public install_specs() — installs arbitrary manifest-declared pip specs through the same environment routing as ensure(): venv-scoped by default, durable-target on sealed images, refused with an actionable reason when gated off (config kill switch or sealed venv without a target — never surfaces raw EROFS/EACCES). Specs are validated with _spec_is_safe(); post-install it invalidates import/metadata caches so availability rechecks in the same process see the new packages without a restart. Never raises. - hermes_cli/web_server.py: _install_memory_provider_pip_dependencies now calls install_specs() instead of building its own uv/pip subprocess. Blocked installs surface the gate reason in the setup results; the response's status block reflects post-install availability (stale 'missing deps' state clears immediately). - hermes_cli/memory_setup.py, plugins/memory/honcho/cli.py, plugins/memory/mem0/_setup.py: CLI setup wizards routed through install_specs() too — same sealed-venv failure mode, same fix. No hosted setup path writes to /opt/hermes anymore; provider discovery and installation now use the same environment (sys.path activation is shared with the lazy-install bootstrap in hermes_bootstrap). Tests: - tests/tools/test_lazy_deps.py: TestInstallSpecs — gating matrix (sealed+no-target blocked with immutable-deployment reason, config kill switch, sealed+target proceeds), spec-safety rejection before any subprocess, venv-scoped vs --target command display, failure stderr passthrough, never-raises contract. - tests/hermes_cli/test_web_server.py: setup endpoint routes pip through lazy_deps (regression guard asserts no direct 'pip install' subprocess), blocked-reason surfacing, same-response availability recheck clears stale missing state. Fixes NS-605 (Plain T-1111).

…ricted network Three independent build fixes, none of which change the image contents on a Docker/BuildKit runner with unrestricted network access: * `COPY --link --chmod=a+rX,go-w` is rejected by buildah/podman, which parses octal modes only and aborts with "Error parsing chmod a+rX,go-w". Octal is not a substitute: a fixed 0755 would mark every regular file executable, which is exactly what `X` exists to avoid. Reverted to a plain COPY plus a separate `chmod -R` pass — the pre-NousResearch#49113 behaviour, at the cost of one walk of ~30k files. * s6-overlay tarballs now fall back to a GitHub reverse-proxy mirror when the direct release download fails. The fallback is still SHA256-verified, which is load-bearing rather than belt-and-braces: some proxies answer 200 with an HTML landing page instead of the asset, and only the checksum catches it. Build with --build-arg S6_OVERLAY_MIRROR= to disable. * NPM_REGISTRY build-arg for networks where registry.npmjs.org resets mid-install. Defaults to the upstream registry, so CI is unchanged, and package-lock.json integrity hashes still gate every tarball. Also ignore .claude/ and CLAUDE.md, which are local agent configuration.

Installing a memory provider (Honcho, mem0, hindsight, ...) from the dashboard Plugins page failed on hosted deployments with a permission error: the setup endpoint shelled out to `uv pip install --python sys.executable`, which targets the sealed read-only venv under /opt/hermes (immutable hosted image, NS-579/NousResearch#49113). The correct mechanism already exists: tools/lazy_deps.py redirects installs to the writable durable target on the data volume (HERMES_LAZY_INSTALL_TARGET=/opt/data/lazy-packages) when the venv is sealed (HERMES_DISABLE_LAZY_INSTALLS=1), appends the target to the END of sys.path (core venv always wins collisions), and constrains shared deps to core-venv versions. The dashboard installer simply never used it. Fix: - tools/lazy_deps.py: new public install_specs() — installs arbitrary manifest-declared pip specs through the same environment routing as ensure(): venv-scoped by default, durable-target on sealed images, refused with an actionable reason when gated off (config kill switch or sealed venv without a target — never surfaces raw EROFS/EACCES). Specs are validated with _spec_is_safe(); post-install it invalidates import/metadata caches so availability rechecks in the same process see the new packages without a restart. Never raises. - hermes_cli/web_server.py: _install_memory_provider_pip_dependencies now calls install_specs() instead of building its own uv/pip subprocess. Blocked installs surface the gate reason in the setup results; the response's status block reflects post-install availability (stale 'missing deps' state clears immediately). - hermes_cli/memory_setup.py, plugins/memory/honcho/cli.py, plugins/memory/mem0/_setup.py: CLI setup wizards routed through install_specs() too — same sealed-venv failure mode, same fix. No hosted setup path writes to /opt/hermes anymore; provider discovery and installation now use the same environment (sys.path activation is shared with the lazy-install bootstrap in hermes_bootstrap). Tests: - tests/tools/test_lazy_deps.py: TestInstallSpecs — gating matrix (sealed+no-target blocked with immutable-deployment reason, config kill switch, sealed+target proceeds), spec-safety rejection before any subprocess, venv-scoped vs --target command display, failure stderr passthrough, never-raises contract. - tests/hermes_cli/test_web_server.py: setup endpoint routes pip through lazy_deps (regression guard asserts no direct 'pip install' subprocess), blocked-reason surfacing, same-response availability recheck clears stale missing state. Fixes NS-605 (Plain T-1111).

teknium1 requested a review from a team June 19, 2026 15:11

daimon-nous Bot added type/security Security vulnerability or hardening P3 Low — cosmetic, nice to have dependencies Pull requests that update a dependency file javascript labels Jun 19, 2026

austinpickett approved these changes Jun 19, 2026

View reviewed changes

ethernet8023 approved these changes Jun 19, 2026

View reviewed changes

teknium1 merged commit b266ad7 into main Jun 19, 2026
35 checks passed

teknium1 deleted the hermes/hermes-d14bb0f8 branch June 19, 2026 15:20

ethernet8023 mentioned this pull request Jun 24, 2026

faster docker builds #51024

Merged

18 tasks

karlligamesvc-spec mentioned this pull request Jul 6, 2026

fix(hc-180): tirith 烘焙改用 scratch home——根治 0700 污染镜像层致 Docker CI 双架构全红 karlligamesvc-spec/hermes-agent#65

Merged

liuhao1024 mentioned this pull request Jul 11, 2026

fix(docker): replace BuildKit-only COPY flags with universal COPY + RUN chmod #62852

Open

13 tasks

alt-glitch mentioned this pull request Jul 12, 2026

fix(docker): replace COPY --link with plain COPY + chmod for Podman compatibility #63334

Closed

This was referenced Jul 23, 2026

fix(photon): support immutable install trees for the iMessage sidecar (NS-606) #69910

Closed

fix: route memory-provider dependency installs through the lazy_deps durable target (NS-605) #72335

Closed

Navigation Menu

Uh oh!

chore(deps): npm audit fix — clear transitive undici advisories - #49113

chore(deps): npm audit fix — clear transitive undici advisories#49113
teknium1 merged 1 commit into
mainfrom
hermes/hermes-d14bb0f8

teknium1 commented Jun 19, 2026

Uh oh!

github-actions Bot commented Jun 19, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Uh oh!

Conversation

teknium1 commented Jun 19, 2026

Summary

Changes

Validation

Infographic

Uh oh!

github-actions Bot commented Jun 19, 2026

🔎 Lint report: hermes/hermes-d14bb0f8 vs origin/main

ruff

ty (type checker)

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

🔎 Lint report: `hermes/hermes-d14bb0f8` vs `origin/main`