Local encryption v2: session-based unlock and the approval panel

.bumpy/local-encrypt-identity-layer.md

@@ -0,0 +1,17 @@
+---
+varlock: minor
+---
+
+Locally encrypted values now unlock once per session instead of re-prompting every five minutes. Approving an unlock covers every value it names until the session ends, and you choose what ends it: screen lock, sleep (the default), or only an explicit lock. The approval panel is drawn by the encryption daemon, so it can show you which process is actually asking and which keys it wants, before anything is decrypted.
+
+On macOS that panel says what the unlock actually covers: each key with how many values it opens, expanding to everything that key protects. Env files are listed with the value names each one defined, and varlock's value cache is listed alongside them with how many cached values it holds and which plugins and files filled it, since one approval on a key opens all of it. What it lists is the whole of what that approval will open, worked out before the panel appears, so it reads the same however the run happens to reach its first encrypted value. The panel also shows the line of processes leading to whoever is asking, from the app you launched down to the command that ran. A request from a coding-agent session is shown as coming from that session, by name and start time, with everything running inside it marked, and the panel says so when nobody is watching that agent or when it is working outside the project being unlocked. The panel is also explicit about which varlock is asking: the standalone binary, or varlock's JavaScript running under node or bun, which is a different thing with different guarantees. Marks on each step say what was checked and what was not, and hovering one spells it out.
+
+The panel now asks two questions rather than one. Under how long an approval lasts sits one checkbox, "Auto-unlock all items in this vault", ticked by default. Unticking it holds the approval to exactly the values on the panel, and that is enforced by the daemon: it binds the approval to the encrypted values it was shown, and anything else raises a fresh panel instead of being handed over quietly. While the box is ticked the panel says so plainly, describing the grant as covering the vault and the listed values as what it covers right now, so nothing opens later that the panel implied it would not. Choosing "once" hides the checkbox and grants narrow, since "just this, right now" is what the word already means; it is an answer about time, so it never changes what varlock remembers about breadth. A broad approval still stops at the vaults it was shown. The value cache is never narrowed by the checkbox and the panel says so: its entries are rewritten whenever a cached value is renewed, so it is always covered as a whole.
+
+How long an approval lasts is one row, read from least to most permissive: once, 10 minutes, 1 hour, a duration you set, and this session. Picking the custom rung reveals a field and a minutes/hours toggle, bounded by the same 12 hour cap as everything else. The rung keeps its name whatever number you set, since it sits at a fixed place in an ordered row; the number itself is in the field, which is on screen whenever that rung is selected, and in the sentence under the controls. A custom window shorter than the default is a tightening like any other, so it is remembered and preselected the next time you are asked.
+
+Which option is preselected follows the request. A key you have approved before, in its own project, with a person at the keyboard, opens on the broad default. Anything less ordinary starts narrower: a first approval of a key, an agent session, or somebody else's script driving varlock; and narrower still when nobody is watching the session, when it is working outside the project it is unlocking, or when the code asking has no signature macOS accepts. If you tighten an approval, varlock remembers that and preselects it next time, saying on the panel that it did. It only ever remembers tightening, never widening, so ticking the box again forgets it. `varlock lock --forget-preferences` clears what is remembered for the current project, and `--forget-all-preferences` clears the lot.
+
+New commands to see and manage that: `varlock sessions` lists what is currently unlocked, and `varlock lock` now takes `--current` to end just this terminal's session or `--session <id>` to end one you name. On macOS the menu bar shows the same sessions and can lock them individually.
+
+Existing encrypted values keep working with no action required. To move them onto the new model, run `varlock encrypt --upgrade` (try `--dry-run` first to see what would change). Their panel is also honest now about what approving them buys: macOS reuses one scan for up to five minutes on that path, which the panel used to describe as a single read.

eslint.config.mjs

@@ -43,6 +43,12 @@ export default tseslint.config(
       '**/dist-test',
       '**/node_modules',
       '**/.turbo',
+      // SwiftPM build output. Generated JSON, and anyone who builds the Swift
+      // package would otherwise get a red lint they did not cause.
+      'packages/encryption-binary-swift/swift/.build',
+      // Cargo build output, for the same reason: it is full of generated JSON,
+      // and running `cargo test` should not turn the lint red.
+      'packages/encryption-binary-rust/target',
       'packages/eslint-custom-rules',
       'packages/env-spec-parser/src/grammar.js',
       'packages/varlock-website/.astro',

packages/encryption-binary-rust/Cargo.toml

@@ -30,10 +30,14 @@ zeroize = "1"
 [target.'cfg(unix)'.dependencies]
 libc = "0.2"
 
-# Platform — Linux (nix for peer credentials in IPC, secret-service for keyring storage)
+# Platform — Linux (nix for peer credentials in IPC, secret-service for keyring
+# storage, zbus for the logind sleep/lock signals that end unlock sessions).
+# zbus is already in the tree underneath secret-service; naming it here pins the
+# same version rather than adding to the dependency set.
 [target.'cfg(target_os = "linux")'.dependencies]
 nix = { version = "0.29", features = ["process", "socket", "user", "fs"] }
 secret-service = { version = "4", default-features = false, features = ["rt-async-io-crypto-rust"] }
+zbus = "4"
 
 # Platform — Windows
 [target.'cfg(target_os = "windows")'.dependencies]
@@ -51,6 +55,17 @@ windows = { version = "0.58", features = [
     "Win32_Security_Authorization",
     "Win32_System_Threading",
     "Win32_System_Memory",
+    # Peer session scoping: parent process walk + process creation times
+    "Win32_System_Diagnostics_ToolHelp",
+    # Sleep-inclusive monotonic clock for grant deadlines (QueryInterruptTime)
+    "Win32_System_WindowsProgramming",
+    # Lock events: suspend notifications, and workstation lock via a
+    # message-only window
+    "Win32_System_Power",
+    "Win32_System_RemoteDesktop",
+    "Win32_System_LibraryLoader",
+    # WNDCLASSW carries GDI handle fields, so the window class needs this too
+    "Win32_Graphics_Gdi",
     # Windows Hello (UserConsentVerifier)
     "Security_Credentials_UI",
     "Foundation",

packages/encryption-binary-rust/README.md

@@ -43,17 +43,75 @@ Binaries ship uncompressed. Do not reintroduce UPX (or any other executable pack
 
 ## Architecture
 
-- `src/main.rs` — CLI interface (generate-key, encrypt, decrypt, status, daemon)
-- `src/crypto.rs` — ECIES encryption using pure Rust crates (no OpenSSL)
-- `src/key_store/` — Platform-specific key protection:
-  - `windows_tpm.rs` — NCrypt TPM seal (Platform Crypto Provider)
-  - `windows.rs` — DPAPI fallback
-  - `windows_hello.rs` — Windows Hello presence gate (daemon)
-  - `linux.rs` — TPM2 via tpm2-tools
-  - `scalar.rs` — shared P-256 scalar ↔ PKCS8 helpers
-- `src/daemon.rs` — Long-lived IPC daemon for biometric session caching
-- `src/ipc.rs` — IPC server (Unix socket on Linux, named pipe on Windows)
-- `src/daemon_client.rs` — Named pipe client for `--via-daemon` mode (WSL2 support)
+- `src/main.rs`: CLI interface (generate-key, encrypt, decrypt, status, daemon)
+- `src/crypto.rs`: ECIES encryption using pure Rust crates (no OpenSSL)
+- `src/key_store/`: Platform-specific key protection:
+  - `windows_tpm.rs`: NCrypt TPM seal (Platform Crypto Provider)
+  - `windows.rs`: DPAPI fallback
+  - `windows_hello.rs`: Windows Hello presence gate (daemon)
+  - `linux.rs`: TPM2 via tpm2-tools
+  - `scalar.rs`: shared P-256 scalar ↔ PKCS8 helpers
+- `src/identity_sessions/`: identity-backed unlock sessions (see below)
+- `src/secure_mem.rs`: locked, dump-excluded, zeroize-on-drop buffers
+- `src/daemon.rs`: Long-lived IPC daemon for biometric session caching
+- `src/ipc.rs`: IPC server (Unix socket on Linux, named pipe on Windows)
+- `src/daemon_client.rs`: Named pipe client for `--via-daemon` mode (WSL2 support)
+
+## Identity sessions
+
+Values are encrypted to an identity key rather than straight to the device key:
+
+```
+device key (NCrypt/TPM, DPAPI, TPM2, Secret Service) -> identity key -> values
+```
+
+The daemon holds the unwrapped identity key on behalf of one session so a whole
+env file resolves without a prompt per value. A grant is what makes that holding
+legitimate. The ops are the same ones the macOS (Swift) daemon speaks, so a
+client cannot tell the two apart:
+
+- `unlock-session`: open or extend a session's hold on one or more keys
+- `decrypt-v2`: decrypt a batch of identity payloads under a live grant
+- `list-sessions`: every live grant, with no key material
+- `invalidate-session`: drop everything, one session, or one grant
+
+`ping` reports `protocolVersion: 3`.
+
+Rules worth knowing:
+
+- A grant is keyed by (session x key). The session is resolved from the
+  connecting process, never from anything in the message.
+- Scopes are `once`, `session`, and `duration`, all capped at 12 hours.
+- Deadlines are held on both the wall clock and a sleep-inclusive monotonic
+  clock, and whichever runs out first ends the grant.
+- Every authorization is appended to `<user varlock dir>/audit/authorizations.jsonl`
+  and read back off disk before any plaintext is returned. A decrypt whose record
+  cannot be written is refused.
+- Nothing is persisted. A daemon restart loses every session on purpose.
+
+### What ends a session early
+
+`lockOn` is `screenLock`, `sleep` (the default), or `none`, taken from the
+unlock, then from `sessions.lockOn` in the user config file, then from the
+default. The daemon's ready line reports which triggers it actually wired:
+
+| event | Windows | Linux |
+| --- | --- | --- |
+| `sleep` | `PowerRegisterSuspendResumeNotification` | logind `PrepareForSleep` |
+| `screenLock` | `WTSRegisterSessionNotification` | logind session `Lock` |
+
+Desktop-environment screensaver locks on Linux (GNOME, KDE) do not always reach
+logind, and are not yet wired. A machine with no source for an event runs its
+sessions to their TTL instead, and says so on stderr at startup.
+
+### Where the key is held
+
+macOS re-wraps the identity key under a per-session Secure Enclave key. Neither
+NCrypt nor TPM2 gives a cheap equivalent, so the hold here is guarded memory: a
+fixed-size allocation that never grows, `mlock`/`VirtualLock`ed, marked
+`MADV_DONTDUMP` on Linux, and zeroized when the session ends. The daemon also
+disables core dumps and clears `PR_SET_DUMPABLE` on Linux at startup. A
+TPM-resident session key is a later step.
 
 ## WSL2 Support