Implement keep: self-hosted E2E encrypted secrets sync
Server: Express + better-sqlite3 (WAL), multi-recipient key-wrapping
per IMPLEMENTATION.md's design — vaults/recipients/vault_grants/
access_log. Two auth paths: ADMIN_PASSWORD header for recipient
management and revoke (pure metadata operations), signed-request
auth (Ed25519 signature over method+path+timestamp+body-hash) for
push/pull/grant, mirroring the spirit of this project family's other
signed-handshake patterns without naming them.
CLI: identity init/show/set-id, push/pull/grant/log, admin recipient
add/list/remove and revoke. Grant is a client-side crypto operation
(the granter unwraps the vault's current key locally and reseals it
for the new recipient) rather than a server-side operation, since the
server never holds an unwrapped key to grant with.
Verified end-to-end with two independent local identities against a
live server and separately against the built Docker image: register,
push, pull (granted and ungranted), grant without re-pushing, admin
revoke, a subsequent rotation confirming the revoked recipient stays
excluded, and rejection of missing/malformed signed-request auth.
Two real bugs caught during verification, not just written up:
- libsodium-wrappers' published ESM build does a relative import only
resolvable under bundler-style resolution — broken under plain Node
ESM. Fixed via createRequire to force the CJS build.
- Express's req.path inside a sub-router is relative to the mount
point, which would have silently mismatched a client signing the
full request path. Fixed by verifying against req.originalUrl.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-07-12 19:38:24 +02:00
|
|
|
import { Router } from 'express';
|
|
|
|
|
import { randomBytes } from 'node:crypto';
|
2026-07-12 20:16:29 +02:00
|
|
|
import { listRecipients, createRecipient, deleteRecipient, deleteGrant, getAccessLog, logAccess, listVaults, listGrantsForVault } from './db.js';
|
Implement keep: self-hosted E2E encrypted secrets sync
Server: Express + better-sqlite3 (WAL), multi-recipient key-wrapping
per IMPLEMENTATION.md's design — vaults/recipients/vault_grants/
access_log. Two auth paths: ADMIN_PASSWORD header for recipient
management and revoke (pure metadata operations), signed-request
auth (Ed25519 signature over method+path+timestamp+body-hash) for
push/pull/grant, mirroring the spirit of this project family's other
signed-handshake patterns without naming them.
CLI: identity init/show/set-id, push/pull/grant/log, admin recipient
add/list/remove and revoke. Grant is a client-side crypto operation
(the granter unwraps the vault's current key locally and reseals it
for the new recipient) rather than a server-side operation, since the
server never holds an unwrapped key to grant with.
Verified end-to-end with two independent local identities against a
live server and separately against the built Docker image: register,
push, pull (granted and ungranted), grant without re-pushing, admin
revoke, a subsequent rotation confirming the revoked recipient stays
excluded, and rejection of missing/malformed signed-request auth.
Two real bugs caught during verification, not just written up:
- libsodium-wrappers' published ESM build does a relative import only
resolvable under bundler-style resolution — broken under plain Node
ESM. Fixed via createRequire to force the CJS build.
- Express's req.path inside a sub-router is relative to the mount
point, which would have silently mismatched a client signing the
full request path. Fixed by verifying against req.originalUrl.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-07-12 19:38:24 +02:00
|
|
|
import { requireAdminAuth } from './auth.js';
|
|
|
|
|
|
|
|
|
|
export const router = Router();
|
|
|
|
|
|
|
|
|
|
router.use(requireAdminAuth);
|
|
|
|
|
|
|
|
|
|
function newRecipientId(label: string): string {
|
|
|
|
|
const slug = label.toLowerCase().replace(/[^a-z0-9]+/g, '-').replace(/^-+|-+$/g, '').slice(0, 24);
|
|
|
|
|
const suffix = randomBytes(3).toString('hex');
|
|
|
|
|
return slug ? `${slug}-${suffix}` : suffix;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
router.get('/recipients', (_req, res) => {
|
|
|
|
|
res.json(listRecipients().map(r => ({ recipientId: r.recipient_id, label: r.label, publicKey: r.public_key, createdAt: r.created_at })));
|
|
|
|
|
});
|
|
|
|
|
|
|
|
|
|
router.post('/recipients', (req, res) => {
|
|
|
|
|
const body = req.body as { label?: string; publicKey?: string };
|
|
|
|
|
if (!body.label || !body.publicKey) {
|
|
|
|
|
res.status(400).json({ error: 'label and publicKey are required' });
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
const recipientId = newRecipientId(body.label);
|
|
|
|
|
createRecipient(recipientId, body.label, body.publicKey);
|
|
|
|
|
res.json({ recipientId });
|
|
|
|
|
});
|
|
|
|
|
|
|
|
|
|
router.delete('/recipients/:id', (req, res) => {
|
|
|
|
|
deleteRecipient(req.params.id);
|
|
|
|
|
res.json({ ok: true });
|
|
|
|
|
});
|
|
|
|
|
|
|
|
|
|
// Revocation is pure metadata deletion — no crypto material is touched,
|
|
|
|
|
// which is exactly why admin alone (no vault access of their own
|
|
|
|
|
// required) can perform it, unlike `grant`.
|
|
|
|
|
router.delete('/vaults/:key/grants/:recipientId', (req, res) => {
|
|
|
|
|
deleteGrant(req.params.key, req.params.recipientId);
|
|
|
|
|
logAccess(req.params.key, req.params.recipientId, 'revoke');
|
|
|
|
|
res.json({ ok: true });
|
|
|
|
|
});
|
|
|
|
|
|
|
|
|
|
router.get('/vaults/:key/log', (req, res) => {
|
|
|
|
|
res.json(getAccessLog(req.params.key));
|
|
|
|
|
});
|
2026-07-12 20:16:29 +02:00
|
|
|
|
|
|
|
|
// Cross-vault view — "which things have access to what" in one call,
|
|
|
|
|
// instead of walking every vault by hand with /vaults/:key/recipients
|
|
|
|
|
// (which is itself grant-gated per vault, and only shows one vault at a
|
|
|
|
|
// time). Admin-only since it reveals every vault's full grant list at
|
|
|
|
|
// once, not just the ones the caller happens to have a grant on.
|
|
|
|
|
router.get('/overview', (_req, res) => {
|
|
|
|
|
const byId = new Map(listRecipients().map(r => [r.recipient_id, r]));
|
|
|
|
|
const vaults = listVaults().map(v => ({
|
|
|
|
|
vaultKey: v.vault_key,
|
|
|
|
|
updatedAt: v.updated_at,
|
|
|
|
|
updatedBy: v.updated_by,
|
|
|
|
|
grants: listGrantsForVault(v.vault_key).map(g => ({
|
|
|
|
|
recipientId: g.recipient_id,
|
|
|
|
|
label: byId.get(g.recipient_id)?.label ?? null,
|
|
|
|
|
canWrite: g.can_write === 1,
|
|
|
|
|
})),
|
|
|
|
|
}));
|
|
|
|
|
res.json({
|
|
|
|
|
recipients: listRecipients().map(r => ({ recipientId: r.recipient_id, label: r.label, publicKey: r.public_key, createdAt: r.created_at })),
|
|
|
|
|
vaults,
|
|
|
|
|
});
|
|
|
|
|
});
|