pkvault seal/unseal: encrypt any file with the vault identity#3
Merged
Conversation
Clean rebuild of the seal-unseal branch from main containing only the pkvault/crypto/spec work (the previous branch had accidentally swept in unrelated pklinks files from a shared working tree). pkvault seal <file> / unseal <file.pkfile> wrap the PKFILE1 envelope (SPEC-FILE new §7.1: canonical single-file serialization, header then chunks in index order, no trailing bytes, .pkfile). Works anywhere on disk — a repo only upgrades the default recipient set: --recipient flags → manifest → yourself, with the chosen set always echoed. Sealing uses only public recipients (no unlock, write-only); unsealing resolves the per-file key through the agent's new op:"unseal-file" — the identity scalar never crosses the socket. @pksuite/crypto gains an unwrapFileKey alternative to identity in openFileEnvelope (copies in, copies out) and bumps to 0.2.0. Durability and data-loss hardening (review rounds 1–2): - input/output aliases detected by device/inode (case-insensitive filesystems, hard links) and refused even with --force, both commands - the crypto state is created after the input opens, geometry comes from fstat of the opened descriptor, and disposal runs before close on every failure path — a close error can never skip key disposal - all writes loop via txn.writeAllSync (short writes) - no-force installs use link(2): a destination created after the precheck fails E_EXISTS instead of being replaced by rename - destination directory fsynced after install (POSIX durability) - finalization inside the atomic window; 0600 plaintext outputs; input-mutation detection while sealing; no temp litter on failure Tests: crypto 21/21; pkvault 228/228 including hard-link and case-folded alias refusals and a race test that reaches the actual link(2) window via an injected destination.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
pkvault seal <file>/pkvault unseal <file.pkfile>— local file encryption as a vault utility, per the DIRECTIONS scope decision (single files, existing recipients, no folder sync, no watch modes).--recipientflags → manifest → yourself). The chosen set is always echoed — the one footgun the defaulting introduces is silently sealing to the wrong audience, so it's never silent.op:"unseal-file"unwraps the 16-byte per-file key inside the agent; the identity scalar still never crosses the socket.@pksuite/cryptogains anunwrapFileKeyalternative inopenFileEnvelopefor this holder pattern → 0.2.0..pkfile.--force.Tests
No new derivation strings — the
pksuite/filelabels were registered when file-v1 landed.