Problem 1 — ESO empty resolution (caused an outage)
ExternalSecrets resolves the HomeLab 1P item ntfy-mathias-ios field password to an empty value, even though op item get reads it fine (14 chars). Two ExternalSecrets are affected: ntfy-mathias-pass (monitoring) and email-triage-secrets (email-triage) — both show ETA_NTFY_PASS / mathias = 0 bytes. Other HomeLab items (gmail-app-pw-*, DMABE_LLMAPI_KEY) resolve fine.
Impact: on the 2026-06-19 ntfy restart, the empty NTFY_MATHIAS_PASS made the acl-bootstrap ntfy user change-pass mathias prompt on a missing tty → set -e crash → initContainer CrashLoopBackOff → ntfy down ~5 min. Mitigated (commit hardens upsert_user to skip empty passwords, keeping the persisted auth.db value) — but the root cause is unfixed: 1P-based ntfy password rotation will not apply until ESO resolves this item again.
Likely suspects: onepassword-connect cache staleness, or the item being created/edited in a way connect does not re-read. Try: restart onepassword-connect; re-create/touch the item; compare with a known-good item.
Problem 2 — agent uses anonymous publish
email-triage-agent publishes the daily digest to email-digestanonymously (an everyone wo ACL grant) because the human admin cred could not be wired (Problem 1) and using it was poor hygiene anyway. Give the agent a dedicated ntfy user + token (e.g. agent-koala or a new email-triage user) with wo on email-digest, source it via ESO, and drop the anonymous grant.
Risk
LOW — ntfy works now (auth.db persists). This is hardening + hygiene.
## Problem 1 — ESO empty resolution (caused an outage)
ExternalSecrets resolves the HomeLab 1P item `ntfy-mathias-ios` field `password` to an **empty** value, even though `op item get` reads it fine (14 chars). Two ExternalSecrets are affected: `ntfy-mathias-pass` (monitoring) and `email-triage-secrets` (email-triage) — both show ETA_NTFY_PASS / mathias = 0 bytes. Other HomeLab items (gmail-app-pw-*, DMABE_LLMAPI_KEY) resolve fine.
Impact: on the 2026-06-19 ntfy restart, the empty `NTFY_MATHIAS_PASS` made the acl-bootstrap `ntfy user change-pass mathias` prompt on a missing tty → `set -e` crash → initContainer CrashLoopBackOff → ntfy down ~5 min. **Mitigated** (commit hardens upsert_user to skip empty passwords, keeping the persisted auth.db value) — but the root cause is unfixed: **1P-based ntfy password rotation will not apply** until ESO resolves this item again.
Likely suspects: onepassword-connect cache staleness, or the item being created/edited in a way connect does not re-read. Try: restart onepassword-connect; re-create/touch the item; compare with a known-good item.
## Problem 2 — agent uses anonymous publish
email-triage-agent publishes the daily digest to `email-digest` **anonymously** (an `everyone wo` ACL grant) because the human admin cred could not be wired (Problem 1) and using it was poor hygiene anyway. Give the agent a **dedicated ntfy user + token** (e.g. `agent-koala` or a new `email-triage` user) with `wo` on `email-digest`, source it via ESO, and drop the anonymous grant.
## Risk
LOW — ntfy works now (auth.db persists). This is hardening + hygiene.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Problem 1 — ESO empty resolution (caused an outage)
ExternalSecrets resolves the HomeLab 1P item
ntfy-mathias-iosfieldpasswordto an empty value, even thoughop item getreads it fine (14 chars). Two ExternalSecrets are affected:ntfy-mathias-pass(monitoring) andemail-triage-secrets(email-triage) — both show ETA_NTFY_PASS / mathias = 0 bytes. Other HomeLab items (gmail-app-pw-*, DMABE_LLMAPI_KEY) resolve fine.Impact: on the 2026-06-19 ntfy restart, the empty
NTFY_MATHIAS_PASSmade the acl-bootstrapntfy user change-pass mathiasprompt on a missing tty →set -ecrash → initContainer CrashLoopBackOff → ntfy down ~5 min. Mitigated (commit hardens upsert_user to skip empty passwords, keeping the persisted auth.db value) — but the root cause is unfixed: 1P-based ntfy password rotation will not apply until ESO resolves this item again.Likely suspects: onepassword-connect cache staleness, or the item being created/edited in a way connect does not re-read. Try: restart onepassword-connect; re-create/touch the item; compare with a known-good item.
Problem 2 — agent uses anonymous publish
email-triage-agent publishes the daily digest to
email-digestanonymously (aneveryone woACL grant) because the human admin cred could not be wired (Problem 1) and using it was poor hygiene anyway. Give the agent a dedicated ntfy user + token (e.g.agent-koalaor a newemail-triageuser) withwoonemail-digest, source it via ESO, and drop the anonymous grant.Risk
LOW — ntfy works now (auth.db persists). This is hardening + hygiene.