Email and Telegram warnings on security timer starts with deduplication and low-noise delivery #3
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Implement verified opt-in email and Telegram channels using Rust worker + PostgreSQL transactional outbox. Send concise actionable warning whenever settings relaxation/opt-out/delay change, wallet assignment, unlock, recovery or authority rotation starts a timer; cover security-relevant other settings with clear policy. Use event identity idempotency, bounded retries/backoff, durable failure state, coalesce related events without hiding distinct dangerous timers, optional single near-execution reminder and digest for benign activity. No per-transfer spam. Security timer starts cannot be hidden in routine digest/rate-limiting overload; cap abuse and surface summary/overflow count. Include action, wallet/token, start/deadline, cancel/dispute link to configured trusted domain; no sensitive evidence, credentials or request-supplied arbitrary links.
Require email double opt-in and Telegram bot one-time pairing confirmation; changing/removing channels warns the previous verified contact and follows existing delay where applicable. Contact compromise alone grants no wallet authority, recovery, or timer bypass. No live messaging to real recipients without explicit user send instruction; verify providers through sandbox/owned endpoints only, record production readiness separately.
Dependency: API schema/events; implementation parallel with UI after initial backend foundation.
Working rules
User authorizes implementation and worker coordination. Trusted CL8Y governance is an explicit trust assumption; separate containment, unpause, recovery authorization, execution and key rotation. No social account alone establishes asset ownership. Never publish PII, secrets or private incident operations. Work in small reviewable increments, with bounded focused security tests; no broad soak runs or very long scripts. Publish commits/PRs and factual evidence. Keep acceptance open until actually met; source success does not establish live deployment. No automatic closing keywords in PR descriptions before full acceptance.
Implementation assigned to BB worker
thr_wur9hgwhec, coordinated bythr_4rw76j9kerin security epic.Dependency/order: Backend schema and finalized chain-event types before durable outbox integration. Parallel with frontend after foundation.
Worker is active in an isolated worktree. It owns implementation and truthful acceptance evidence, with independent review before production completion. Initial orchestration does not establish code/deployment acceptance.
Implementation is published in PR #5. The API is a working Rust/PostgreSQL service with ADR-036 wallet authentication, exact-origin/CSRF sessions, independent wallet proofs and delayed dual-consent profile assignments; these are explicitly distinct from chain authority. The accessible TypeScript frontend is integrated, and its exact ABI continuation is in progress against independently reviewed token/controller schema pin
2d70d43c651ecd4491c0736c89ae2975ee825686.Finalized receipt ingestion, checkpoint/replay/divergence handling, transactional warning outbox, bounded controller fanout, encrypted double-opt-in email/Telegram pairing, retry and visible delivery uncertainty are implemented. Nine focused backend checks passed against owned disposable PostgreSQL, including an owned loopback receipt fixture. UI checks use owned API/provider doubles; there have been no real-recipient test sends or chain transactions.
Independent auth/security/deployment review identified and drove fixes for proxy admission, connection starvation, lease/retry ambiguity, worker session-forgery privileges, activation filtering, cross-profile email floods and untrusted-event checkpoint poisoning. Final source/UI/live review remains in progress. Coolify's dedicated portal PostgreSQL resource is now running; API/static/worker release and exact live migration/source/worker/backup receipts remain pending. No feature or production acceptance is inferred from source or database startup.
No deployed security-v1 token/controller identities exist per the contract lead, so live chain coverage and signing remain unavailable until verified deployment configuration is supplied. Notification provider credentials are absent, gating those channels only. Issues #1–#4 stay open for their unverified acceptance. Research followups #6/#7 are separate future scope.
Durable notification owner continues issue #3 under the portal lead. Provider increment: PR #9, source
6fe52e0ba4d753bf15fa9c5b974452e0a720ddf8, pending fresh independent security review.Authorized provider investigation confirmed dedicated Mailu sender enrollment is available. Prepared a disabled, non-admin sender with a narrowly restricted staged credential in authorized workload custody; scope/readback and an idempotent repeat passed. No mail was sent, and live portal source/configuration remain unchanged. The adapter requires STARTTLS with hostname validation and a fixed sender. Outbox transport persistence prevents ambiguous SMTP deliveries being replayed through Resend's idempotency path.
Focused checks passed: locked Cargo check; synthetic SMTP TLS/ambiguity/fixed-envelope tests (2); bounded retry unit test (1); disposable PostgreSQL17 outbox/lease integration; synthetic scoped enrollment/idempotence tests (2). This is source and disabled-enrollment evidence, not production delivery acceptance.
Issue remains open. Agent-owned acceptance still requires separately reviewed fixed gateway/network integration, verified actual outbound source, scoped sender activation and owned/sandbox delivery evidence. Independent portal Telegram bot enrollment remains pending: the existing authorized setup paths provide neither a portal bot token nor an authorized bot-creation identity; unrelated polling bots are not reused. No real-recipient tests or human engineering handoff.
Verified scoped deployment is live at https://security.cl8y.com. Source PR #5 and deployment-recipe/receipt PR #8 are merged to main; checkout
/home/answorld/repos/cl8y-wallet-securitywas fast-forwarded without overwriting changes.Actual workload source:
e44569e45b15dbee4b0347dff742f92bd85bedb2. Immutable OCI manifest:sha256:07b476118ac7ca8a8af9653471026d02c0e615ace174231bd50aea06392b607e; tested config digest:sha256:556024673401ce7337c00ab54a40230abc6e1ffe45d03a41af27eb1ea7c772d9. Separately reviewed runtime hook:b8aa303154b25d3017816c258b0daeb8954b7b26; it selects the deployment's unique private PostgreSQL hostname and preserves credentials, volumes and trust. Immutable tags preserve both source references. Current main also contains post-release operator recipe/receipts; the running artifact remains pinned.Actual evidence: TLS health 200 with matching source and migration 5; advancing matching worker; all 16 live owned-wallet checks passed (signed login, one-use replay rejection, independent second wallet, dual-consent >=24h assignment, cancellation, secure cookie/logout); all 13 exact-image persistence/privilege/owned-restore checks passed. Independent reviewer verified source, HTTPS/redirect/security headers, one authorized invalid forwarded-header negative probe, source/migration/heartbeat, runtime UID/credential/DDL boundaries, private networking and backup/restore. No real-recipient messages or chain transactions were sent.
Public receipts: live, storage.
Full production acceptance remains OPEN; issues #1–#4 are not closed by source merge or this deployment:
thr_n4vtxxfcb7/coordinatorthr_4rw76j9kerown that dependency; UI ownerthr_yc2yevrgcwowns subsequent real-chain/wallet acceptance. Live defaults are never invented.thr_ywz2dcyd3p, provider PR #9. Authorized scoped Mailu enrollment was found and completed in disabled/test-restricted state, so email is pending adapter/gateway/review/owned proof rather than falsely called unavailable. Fresh review is on hold for durable retry-window aging across pending/blocked states; fixing before activation. Independent Telegram bot registration/token capability remains to be established; unrelated polling bots are not reused. Current delivery readiness is false and no real sends are claimed.thr_tj2burwn8bis continuing authorized scoped enrollment/inventory/restore proof. Live local backup/scratch restore passed; off-host recovery has not been invented.Independent reviewer
thr_rbd98geiraremains assigned for fresh provider/deployment increments. No human approval, reading, monitoring or credential handoff is requested; all remaining technical work has explicit active agent ownership.Independent source review cleared provider PR #9 at exact source
bc40b1b6b8120875221e342eff8418de4b3a541d. The reviewer independently ran SMTP tests (2), worker retry test (1), actual disposable PostgreSQL integration (1), enrollment mocks (2), and verified migration 6 checksums plus the 1–5 to 6 transition. The Resend retry window now covers pending, blocked and sending states; SMTP requires an explicit worker delivery switch that defaults off.Disabled scoped sender preparation and idempotent custody readback succeeded, with zero sends. This is source and disabled-enrollment clearance only: no live SMTP delivery, runtime gateway/NAT/TLS or recipient acceptance is claimed, and the live portal is unchanged. Gateway/image/runtime integration and owned/sandbox delivery remain with the deployment owner and notification owner. Independent portal Telegram bot token/creation authority is still the precise missing capability after the authorized setup/inventory investigation; unrelated bots are untouched.
Issue #3 remains open with this notification thread as durable owner. No pre-migration-6 worker rollback is safe after SMTP activation. No real-recipient tests or human engineering handoff.
PlasticDigits referenced this issue2026-10-31 06:16:59 +00:00
Email notification delivery is now enabled in production on live source
4fbe03977337925f6185b393a8aa39437095b097, migration6. The coordinator's independently accepted production-mode deployment2m1j26wruzlryqvry8heju3jfinished 2026-11-01 02:34:37 UTC using reviewed hook5c6e750676640047ed4498b9ab2a741d71318084; it removed only the owned-recipient allowlist. Worker private/notification isolation, API/PostgreSQL exclusion and fixed gateway DNS passed. Public 02:37:59 UTC health and the advancing matching worker reported email/delivery ready, pending0 and failed0. This mode change sent no additional operator message. Final scoped email production record.Actual acceptance used exactly one reviewed owned API/IMAP trial and three notices: signed-wallet opt-in/code confirmation with replay rejection, assignment timer with its exact deadline, and the previous verified channel's removal warning while it remained effective through its delay. No real-recipient operator test, direct SQL write, chain transaction or raw message/credential output occurred. Exact owned-delivery receipt.
The coordinator separately accepted fresh schema6 off-host recovery: the restored snapshot retained all three real SMTP sent rows with nonempty first-attempt timestamps and full saved timer/outbox/contact metadata. The owned profile was present with zero active source sessions before scratch authentication invalidation. After that proof, exactly the smoke receiver was disabled and its scoped token revoked with 404/custody-CAS readback; the current receiver credential was removed. The normal sender remains enabled with its verified gateway
/32and nonadmin/no-IMAP/no-spoof scope. Outbox/profile/checkpoint/mailbox evidence was preserved; no extra SMTP/IMAP login, logout or send was needed. Schema6 off-host recovery, receiver retirement, normal sender readback.Issue #3 stays open for Telegram: fresh scoped inventory found no independent portal bot token or authorized BotFather/managed-bot creation identity. Unrelated bots were neither called nor borrowed. Primary creation contract. Email acceptance does not establish Telegram or full-portal/chain acceptance.
PlasticDigits referenced this issue2026-11-01 04:45:06 +00:00
2026-11-01 Telegram continuation: user selected the existing @cl8y_ops_bot and securely enrolled its token. Fresh identity checks match bot ID 8983775406; its webhook is empty. Existing identified integrations send alerts without polling. The portal adapter is independently reviewed and merged (PR #22); its exact image is published. Generic relay/operator implementation stays in the private cl8y-security repository. Live restricted-egress proof and the separately reviewed release are in progress. Telegram remains disabled until those checks pass; no messages have been sent and no update polling has been started by this work. Email remains active on schema 6. End-to-end Telegram delivery will be reported only after a legitimate opt-in pairing or an explicitly owned recipient, without test messages to existing ops groups.
Telegram is now enabled at https://security.cl8y.com using the user-selected @cl8y_ops_bot. Production deployment yhrljlomqnicdekmqkeoci8v finished on source
357d15da9fand unchanged schema 6. Independent HTTPS checks verified matching API/worker versions, an advancing heartbeat, email and Telegram readiness, successful Telegram polling, zero pending/failed notices, security headers and origin boundaries. The reviewed runtime checks verified the restricted relay path, worker-only provider credentials and resource/network bounds. Generic operations remain private in cl8y-security; application adapter PR #22 is merged. The temporary operator is disarmed.No unsolicited test messages or contact actions were performed. Private pairing, confirmation and notice delivery to an actual opted-in Telegram user remain unverified; do not treat polling success as an end-to-end delivery receipt. Email delivery evidence from the earlier owned trial remains unchanged. Keep this issue open for that remaining delivery evidence and eventual verified chain-event coverage; chain features remain unavailable with security-v1 deployment coverage 0/35. No webhook or allowed-update configuration was changed.