Files
hermes-agent/hermes_cli
ygd58 08baf96537 fix(runtime): exempt loopback custom-provider pool credentials from the usable-secret floor
Fixes #86864.

Legacy custom_providers configs commonly used short/placeholder
api_keys ('123', 'm') for local no-auth services like Ollama --
harmless for the endpoint itself, since Ollama accepts any key or no
key. A stricter has_usable_secret(value, min_length=4) gate added
later now rejects these, but only the credential-POOL resolution path
lacked the same "no-key-required" exemption every OTHER resolution
path in this file already has for exactly this scenario:

- The config-based custom_providers fallback (non-pool path) already
  ends with `api_key or "no-key-required"`.
- The "actual" provider's local-offline path already injects
  ACTUAL_LOCAL_NOAUTH_PLACEHOLDER before the usable-secret gate for a
  loopback base_url.
- _try_resolve_from_custom_pool() was the one gap: it returned the raw
  short pool credential unchanged, which then failed the downstream
  has_usable_secret() gate with a generic "No usable credentials found
  for custom" error that contradicts setup.status ("configured
  credentials" vs "runtime failed"), sending users hunting in the
  wrong direction.

Fixed by substituting the same "no-key-required" placeholder when the
pool's stored credential fails has_usable_secret() AND the base_url
resolves to a loopback hostname (using the existing _loopback_hostname
helper, matching the exemption scope the issue itself requested:
localhost/127.0.0.1/::1 only, not arbitrary remote endpoints with a
genuinely-too-short key).

Added 4 regression tests extending the existing
test_runtime_provider_resolution.py file, following its established
credential-pool mocking pattern: the exact reported 3-char repro
('123'), a 1-char case, a non-loopback sanity check confirming the
exemption stays scoped (a short key for a remote endpoint is NOT
silently exempted), and a sanity check that a genuinely usable
loopback key passes through unmodified. Verified as a genuine
regression by reverting the fix and confirming 2 tests fail with the
exact raw short key leaking through unchanged.

59/59 pass in the extended test file; 14/14 across two more related
custom-provider test files (no regression).
2026-08-16 01:48:59 -07:00
..
2026-08-13 11:52:47 -07:00
…
2026-08-10 12:43:46 -07:00