Severity: Low · Area: Infra + config · Category: dead-code
Location: shared/configs/shared_config.py:45
What's wrong
shared_config.py hard-codes HAOS_USE_SSL = True (not env-configurable), but a repo-wide grep shows no consumer imports it. The value actually used is services/agent/selene_agent/utils/config.py:47 HAOS_USE_SSL = os.getenv("HAOS_USE_SSL", "") — default falsy — consumed as verify=bool(config.HAOS_USE_SSL) in api/homeassistant.py:41. So the shared config advertises 'SSL verification on' while the effective default is verification OFF, and the same string-truthiness trap as DEBUG_LOGGING applies (HAOS_USE_SSL="false" would evaluate truthy in the agent's copy).
How it fails
An operator auditing shared_config.py concludes Home Assistant TLS verification is enabled; in reality the agent's HA REST calls run with verify=False by default, silently accepting MITM'd certificates — and setting HAOS_USE_SSL=false in .env to document that would paradoxically flip verification ON in the agent copy.
Suggested fix
Delete the dead constant from shared_config.py (or make it the single env-parsed boolean source of truth) and give the agent's utils/config.py a proper boolean parse consistent with the intended default.
Adversarial verification — both skeptics confirmed
Skeptic 1 (confirmed) — Confirmed, not refuted. shared/configs/shared_config.py:45 hard-codes HAOS_USE_SSL = True and no importer of shared_config (tts config, stt config/main, shared logger) references it — it is dead. The live value is services/agent/selene_agent/utils/config.py:47, a raw string defaulting to "", consumed at api/homeassistant.py:41 as verify=…
Skeptic 2 (confirmed) — Confirmed in full. shared/configs/shared_config.py:45 hard-codes HAOS_USE_SSL = True and no code consumes it — the only shared_config importer (shared/scripts/logger.py) never references it. The live value is services/agent/selene_agent/utils/config.py:47 (os.getenv("HAOS_USE_SSL", ""), default falsy), consumed at api/homeassistant.py:41…
Filed from a multi-agent audit of 855f5cc: 16 reviewers over ~42k lines produced 170 raw findings; each was handed to 2 independent agents prompted to refute it, and only findings both confirmed were kept (19 refuted, 10 split-verdict, 127 unique confirmed). Line numbers are 1-indexed against 855f5cc and will drift as the code changes.
Severity: Low · Area: Infra + config · Category:
dead-codeLocation:
shared/configs/shared_config.py:45What's wrong
shared_config.py hard-codes
HAOS_USE_SSL = True(not env-configurable), but a repo-wide grep shows no consumer imports it. The value actually used is services/agent/selene_agent/utils/config.py:47HAOS_USE_SSL = os.getenv("HAOS_USE_SSL", "")— default falsy — consumed asverify=bool(config.HAOS_USE_SSL)in api/homeassistant.py:41. So the shared config advertises 'SSL verification on' while the effective default is verification OFF, and the same string-truthiness trap as DEBUG_LOGGING applies (HAOS_USE_SSL="false" would evaluate truthy in the agent's copy).How it fails
An operator auditing shared_config.py concludes Home Assistant TLS verification is enabled; in reality the agent's HA REST calls run with verify=False by default, silently accepting MITM'd certificates — and setting HAOS_USE_SSL=false in .env to document that would paradoxically flip verification ON in the agent copy.
Suggested fix
Delete the dead constant from shared_config.py (or make it the single env-parsed boolean source of truth) and give the agent's utils/config.py a proper boolean parse consistent with the intended default.
Adversarial verification — both skeptics confirmed
Filed from a multi-agent audit of
855f5cc: 16 reviewers over ~42k lines produced 170 raw findings; each was handed to 2 independent agents prompted to refute it, and only findings both confirmed were kept (19 refuted, 10 split-verdict, 127 unique confirmed). Line numbers are 1-indexed against855f5ccand will drift as the code changes.