amadan
carlos / contra Public
4 of 4 sessions · Carbon
-
HumanFIRSTGive me the exact command I need to do to add this repo to the CI runner?
HumanLATESTGo ahead create the first commit
6 prompts · 75418681 tokens · 648 g CO₂e (central estimate)
-
HumanFIRSTShould we be using https://escodb.github.io/docs/intro.html ?
HumanLATEST<task-notification> <task-id>ac87fcf71f3fe46e1</task-id> <tool-use-id>toolu_01Jo6yvV82CYr5WokFEsTHhN</tool-use-id> <output-file>/home/paulca/.cache/tmp/claude-1001/-home-paulca-amadan-net-carlos-contra/ad0bdb88-8c0a-407a-8704-18d9e48389ca/tasks/ac87fcf71f3fe46e1.output</output-file> <status>completed</status> <summary>Agent "Evaluate stronger storage posture" finished</summary> <note>A task-notification fires each time this agent stops with no live background children of its own. The user can send it another message and resume it, so the same task-id may notify more than once.</note> <result>Review complete. I read everything listed plus Eleven's `store.go`, `merge.go`, `stateless.go`, `email.go`, `s3store.go`, `web/static/crypto.js`, `docs/accounts-and-recovery.md`, and CONTRA's `auth.go`, `signup.go`, `app.go`, `items.js`, `passkey.js`, `kit.js`, `pad.go`, `aead.go`. No files were modified. # Verdict up front The framing overstates Eleven. On identity the two systems are the same posture; on integrity CONTRA is stronger; on the blob shape Eleven is stronger only because its problem is tiny and single-writer. Per-item rows are the right v1 shape for CONTRA, but the item write path has a correctness bug that becomes a data-loss bug the day a second device or member writes, and a handful of cheap Eleven habits are worth lifting now. # Corrections to the framing **Eleven is not identifier-free.** `home/main.go`'s package comment ("no email, no username") is stale. `home/db.go` declares `email_anchors`, `siwa_anchors`, and `oidc_anchors`, each an HMAC under a separate env-held pepper; `docs/accounts-and-recovery.md` (2026-07-16) explicitly reversed "no email ever" after real lockouts. Eleven therefore has the pepper problem four times over, and its "always send a code, unknown addresses too" door is the same oracle-suppression trick as CONTRA's decoy salt. There is no stronger identity posture to adopt. **Eleven leaks write timing too.** `blobs(user_id, version, data, updated_at)` keeps the last 5 versions with timestamps. The single blob hides item count and which-item, not when-written. **Eleven binds no AAD.** `encryptBytes` is bare `AES-GCM(iv, ct)`; the envelope carries no user, object, or version binding, and its ETag is server-chosen. CONTRA's length-prefixed, domain-tagged AAD (`crypto/aead.go`) is strictly better. Do not trade it away. **Eleven's blob works because of two facts CONTRA lacks:** the payload is a server list under 16 KiB, and the only concurrent writers are one person's devices, with LWW-per-URL merge that the doc admits "can drop a concurrent reorder". # The hard trade: one blob per vault **What per-item rows leak today** (not written down anywhere): exact item count per vault (row count); per-item `created_at`/`updated_at` columns in the replicated file; item size class; and in transport, which item id a write touched. Reads leak nothing per item, because `/api/items` returns the whole vault and there is no per-item GET. Keep that property. **What one blob would hide:** count, per-item timing, which-item. **What it would not hide:** vault write timing, and vault size unless fixed-padded, which is impossible for a password vault (1PUX carries attachments; 16 KiB is roughly 30 items). Size classes would leak coarse count anyway. **Why it is incompatible with v1, independent of concurrency:** - Drop-box writes (`DESIGN.md`: ECIES-seal to `vP_j`, "re-encrypted under `K_vault` by the next writer who is unlocked") and agent create-only staging (AGENTS decision 5: "sealing to a public key needs no unlock") are writes by a party that cannot open the vault. They cannot produce the next blob. So "one blob" is really "one blob plus an inbox table", and the inbox has per-row residue for the most sensitive class of item: captured, unreviewed secrets. - Bandwidth: every edit uploads the whole vault, and every member's every poll downloads it. An iOS AutoFill extension under a memory budget would have to open the whole vault to fill one password. **The conflict-storm concern is overstated.** This is not EscoDB's problem. EscoDB has to give atomic multi-key updates over arbitrary keys on dumb storage. CONTRA's records are independent, have random ids and per-item versions, and are written a few times a day. Union-by-id, max-version-wins, tombstones for deletes converges in a CAS retry loop with no human involvement; the only case needing policy is two edits to the same item inside one RTT, and a password manager wants "keep both versions" there anyway. So the cost of one blob is bandwidth and the inbox, not merging. **Middle grounds:** - Per-member blob: reject. Items are shared, so N copies to reconcile, revocation multiplies, and membership is still visible. - Per-vault shards keyed by `hash(item_id) mod K`: A1-clean (item ids are random). Hides which-item to 1/K, count to per-shard size class. Costs resharding on growth, K-fold padding, and the inbox problem remains. Not v1. - Append-only sealed segments plus periodic snapshot: each write is a fixed-padded segment holding one or more item changes; segments sealed under `K_vault` and segments sealed to `vP_j` (drop-box, agent) are the same table, so the inbox stops being a separate residue class; appends need no CAS, only compaction does; the write count is the only residue and that is transport shape already. This is the honest v2 shape. It costs snapshot-plus-tail reads, compaction logic, and history semantics. Not before the protocol is proven once (decision 6). **Verdict:** keep per-item rows for v1. Adopt the four cheap changes below (CAS, epoch, timestamps, floor) and keep the wire API segment-compatible (batch writes, no per-item GET). # Ranked changes to adopt now Every one of these is compatible with v1 shared vaults; the first two are required by it. **1. Compare-and-swap on item writes.** `store.UpdateItem` (`internal/contra/store/store.go:345`) is `WHERE id = ? AND vault_id = ?` and writes whatever version the client sends. No precondition. Two devices editing the same item lose one edit silently; two members, likewise; and a client can reuse a version number, which undercuts the AAD's own anti-relabel intent. Fix: `WHERE id = ? AND vault_id = ? AND version = ?` with expected = new minus 1, zero rows affected returns 409 carrying the current version, exactly Eleven's `putBlob` contract applied per item. Same on delete. Buys correctness under any concurrency and scopes every conflict to one item. Costs a small client retry-and-merge path in `items.js`. **2. Vault epoch in the AAD, eager rotation in one transaction.** Add an epoch to the vault row and to the item AAD, `(vault_id, epoch, "item", item_id, version)`. Member removal becomes one endpoint: all items re-sealed under `K_vault'`, all member wraps reissued, the removed row deleted, applied in one SQLite transaction with CAS on the epoch; concurrent writers get 409, refetch the keyset, retry. Re-encrypting N rows versus one blob is the same bytes and negligible CPU; atomicity is the only thing that matters and per-item can have it. This also settles a wording conflict: AGENTS decision 1 says the key "rotates forward for new and changed items" (lazy), `DESIGN.md` says "items re-encrypted, run automatically on member removal" (eager). Lazy needs a per-row key-generation column, which leaks "changed since the removal". Eager is better on residue; reconcile the text to eager. **3. Drop `CreatedAt`/`UpdatedAt` from `Item` and order by id.** The server never needs them; the client sorts by sealed title. Do the same for `VaultMember.CreatedAt` (when sharing began) and `LoginChallenge.CreatedAt` (redundant with `ExpiresAt`). Then write item count, write timing, and which-item into the compromise matrix as at-rest and transport residue. Zero cost. **4. Padding floor.** 256-byte buckets on a JSON body of roughly 150 to 500 bytes give two or three classes that separate "login" from "login with notes" from "secure note". Eleven's real property is that the common case is uniform. Get it with `max(1024, next 256 multiple)`: nearly every login item becomes exactly 1 KiB + tag, and only notes and attachments stand out; use power-of-two buckets above the floor. Four times the bytes on small items is irrelevant (5000 items = 5 MiB). Change `pad.go`, `items.js`, `IsBucketAligned`, and the golden vectors. Attachments will need their own object type and padding rule; the 1 MiB `MaxBytesReader` in `vault.go` caps them today. **5. Batch write endpoint.** `PUT /api/items` taking a list. Import needs it (a 1PUX of 2000 items is 2000 requests today), it hides which-of-these at transport, and it is the shape a segment format would keep. **6. Fresh-auth gate on access-reducing operations.** Eleven's asymmetry: a bearer session reads and writes; anything that reduces who can get in requires a live ceremony inside 5 minutes. CONTRA gates delete item, and will gate remove member, delete vault, and remove passkey wrap, on the session alone. rastrillo's `sessions.Session` carries `AuthTime`; require it within N minutes or a fresh signed challenge. **7. Tombstones and one retained previous version, purge ceremony-gated.** A stolen browser session can currently delete every item with no product-level history. Eleven keeps 5 blob versions for exactly this. Residue cost: edit and delete counts become visible; that is the class Eleven accepts. Say so in the matrix. **8. Rate limiting and per-address send gap.** There is none anywhere in `internal/contra`. `/auth/begin` sends mail on every request; `/auth/salt` and `/auth/challenge` do a DB lookup and Argon2-parameter response for anyone. Eleven has a per-IP limiter on begin endpoints and a 30-second per-address gap. Abuse, cost, and the existence-oracle claims only hold under timing analysis if volume is capped. **9. Sign in by account id, not email.** The index is used for four things: signup dedupe, binding `Complete` to the proved address, finding the account at sign-in, and (per `DESIGN.md`) emailing the address on recovery. The second can be bound by the token alone. The third can use the account id: a fresh device needs the Account Key card anyway (decision 2), the card's QR can carry the full id alongside the key (today `kit.js` prints an 8-hex-char handle, 32 bits, not an identifier), and enrolled devices already cache by account id (`account.js:131`). Then `/auth/salt` and `/auth/challenge` take an account id, the decoy-salt machinery goes away (random 128-bit ids need no existence defence), and the pepper leaves the sign-in hot path entirely. What the index still buys is dedupe and the recovery-notification email; note that the notification is unimplementable as written, because the server holds only an HMAC and cannot mail it. It works only if recovery is initiated by typing the address (Eleven's transient-use pattern). Owner's call: keep the index for those two (my recommendation, with the pepper off-instance as already ruled), or drop it and accept duplicate accounts (Eleven needed account merge for that) and device-only notification. Related: "passkey for quick sign-in" (decision 3) is not built. There is no WebAuthn credential stored, no assertion verified, and no passkey sign-in route; `passkey.js` only adds a PRF wrap inside an existing passphrase session. A discoverable-credential login is the identifier-free door, and when it lands the credential public key is a new column that needs its canary. **10. Caps.** `AddPasskey` accepts unbounded wraps per account; add a per-credential and per-account cap. Add a per-vault item quota for the free rung (decision 9). **11. Optional: stateless challenges.** HMAC-signed challenge tokens would retire `login_challenges` from the replicated file the way Eleven retired `ceremony_proofs`. The trade: single-use goes away within the TTL. Rows are already deleted on spend, so the gain is WAL and free-page residue only. Low priority. # Reject - **One blob per vault as the storage model.** Drop-box and agent writers cannot produce it; whole-vault bandwidth per edit; no partial sync for AutoFill; attachments break fixed padding. - **Fixed 16 KiB.** Wrong scale for this data. Use a floor plus buckets. - **One blob per member.** N copies of shared data; revocation multiplies; membership still visible. - **"The credential is the identity."** Decision 3 forbids it, and Eleven itself abandoned it after a week of lockouts. - **Lazy per-item key rotation.** Needs a key-generation column that leaks change-since-removal. - **Per-vault pseudonymous member slots.** Already rejected in `DESIGN.md`; a blob would not change it, since member wrap rows exist either way. # Already right - Per-item rows with a whole-vault list read and no per-item GET. - AAD binding, client-minted ids bound before the server sees ciphertext, server-enforced quantisation (Eleven only caps size). - Sharing graph published as accepted residue. - `W_pw` and `W_rc` never removed is Eleven's last-method guard by construction. - The blind-index posture equals Eleven's actual posture. - 404-not-403 and the owner filter in SQL. # Two things to write down **Rollback.** `DESIGN.md` and the comments in `store.go` and `items.js` say the version in the AAD stops rollback. It stops relabelling. A server that serves the old `(version, nonce, ciphertext)` triple consistently produces a blob that opens. Detecting rollback needs client-side memory of the highest version seen per item (or a vault head), and for multi-device a sealed manifest. Eleven has the same gap, worse. Do not claim rollback protection in copy until that exists; it is post-v1. **The framework's sessions table.** `TestMercilessGreps` scopes the DDL check to CONTRA's own tables by design. rastrillo's sessions table lives in the same replicated file and holds sign-in timing per account, which is transport shape at rest. Add it to the compromise matrix.</result> <usage><subagent_tokens>179724</subagent_tokens><tool_uses>31</tool_uses><duration_ms>429138</duration_ms></usage> </task-notification>
8 prompts · 369598700 tokens · 3380 g CO₂e (central estimate)
-
HumanFIRSTcontinue
HumanLATESTMPLv2 licence
5 prompts · 22891663 tokens · 255 g CO₂e (central estimate)
-
HumanPROMPT
1 prompt