@dotrino/vaultd 0.53.0 → 0.58.0

package/src/daemon.js

@@ -16,8 +16,11 @@
  */
 import fs from 'node:fs'
 import path from 'node:path'
+import { takeLock } from '../lib/src/lock.js'
 import { startVaultManager } from './manager.js'
 import { dataDir, writeJson, readJson } from './paths.js'
+import { parseInvite } from '../lib/src/invite.js'
+import { watchBinary } from './selfupdate.js'
 import { VERSION } from './version.js'
 
 const readJsonSafe = (f) => readJson(f, null)
@@ -32,21 +35,33 @@ const rm = (f) => { try { fs.rmSync(f, { force: true }) } catch (_) {} }
  * datos, los dos con tu identidad y los dos conectados al proxy; el segundo pisaba el pid
  * de `state.json`, así que el CLI solo le hablaba a uno y el otro quedaba de fantasma.
  *
- * El candado es el propio `state.json`: si el pid que hay sigue vivo, no arrancamos. Un
- * pid muerto (se cortó la luz) no estorba. Con `DOTRINO_VAULT_DIR` distintos conviven
- * cuantas quieras: lo que colisiona es el directorio, no el programa.
+ * El candado vive en `vault.lock` (ver `lib/src/lock.js`) y funciona TAMBIÉN entre
+ * máquinas: `O_EXCL` para la exclusión y un latido para que un corte de luz no deje el
+ * directorio bloqueado para siempre. Antes era un pid, y un pid no cruza contenedores ni
+ * hosts — dos contenedores sobre el mismo volumen arrancaban los dos.
+ *
+ * Con `DOTRINO_VAULT_DIR` distintos conviven cuantas quieras, y es así como se ponen
+ * varias bóvedas en un mismo disco: cada una con su directorio entero, sin nada
+ * compartido. Lo que colisiona es el directorio, no el programa.
  */
 function assertSingleInstance (dir) {
-  let s = null
-  try { s = JSON.parse(fs.readFileSync(path.join(dir, 'state.json'), 'utf8')) } catch (_) { return }
-  const pid = Number(s?.pid)
-  if (!pid || pid === process.pid) return
-  try { process.kill(pid, 0) } catch (_) { return } // no existe: el candado es de un muerto
-  console.error('A vault is already running on this data (process %d).', pid)
-  console.error('  data: %s', dir)
-  console.error('Two vaults on the same directory step on each other: stop the other one,')
-  console.error('or use DOTRINO_VAULT_DIR to give this one its own directory.')
-  process.exit(3)
+  try {
+    const { release } = takeLock(dir)
+    // Se suelta al salir por las buenas. Si el proceso muere de golpe el candado se queda,
+    // y por eso caduca por latido: uno inmortal sería peor que ninguno.
+    const soltar = () => { try { release() } catch (_) {} }
+    process.once('exit', soltar)
+    for (const sig of ['SIGINT', 'SIGTERM']) process.once(sig, () => { soltar(); process.exit(0) })
+  } catch (e) {
+    if (e?.code !== 'vault-locked') throw e
+    console.error('A vault is already running on this data.')
+    console.error('  %s', e.message)
+    console.error('  data: %s', dir)
+    console.error('Two vaults on the same directory are not two vaults: they are the SAME one')
+    console.error('running twice — same master key, both sealing records as the same sealer.')
+    console.error('Stop the other one, or use DOTRINO_VAULT_DIR to give this one its own.')
+    process.exit(3)
+  }
 }
 
 export async function runDaemon () {
@@ -129,6 +144,19 @@ export async function runDaemon () {
   // --- SIGUSR1: iniciar emparejamiento ---
   const pairFile = path.join(dir, 'pair.json')
   let pendingApproval = false // lo pidió `pair --approval`; se aplica al aprobar
+  /**
+   * Lo pidió `pair --admin`: el aparato que entre por ESTA invitación podrá administrar.
+   *
+   * Sigue en pie la regla de que **ningún QR concede administración**: el QR no lleva
+   * nada. Lo que hay es una nota LOCAL de esta bóveda, y el permiso se aplica en el
+   * mismo gesto que ya era la puerta —aprobar con el código tecleado aquí—, exactamente
+   * igual que `--approval`. Es el mismo `caps <ID> +administra` que harías a mano un
+   * segundo después, sin tener que ir a buscar el ID.
+   *
+   * Existe por el contenedor: allí cada paso cuesta un `docker exec`, y el primer aparato
+   * de una bóveda recién desplegada es SIEMPRE la consola.
+   */
+  let pendingAdmin = false
   const pairReqFile = path.join(dir, 'pair-request.json')
   async function handlePairingRequest () {
     try {
@@ -174,6 +202,7 @@ export async function runDaemon () {
       // `pair --approval`: el aparato que entre por esta invitación pedirá el visto bueno del
       // teléfono cada vez que reciba claves privadas (se aplica al aprobarlo, abajo).
       pendingApproval = !!pairReq?.approval
+      pendingAdmin = !!pairReq?.admin
       // `profile`/`profileName`: la CUENTA del vault a la que entra el dispositivo.
       // Con varias bóvedas en el mismo daemon, el QR sale de UNA y quien empareja
       // tiene que verlo (lo muestran la TUI y `dotrino-vault pair`). El nombre viaja
@@ -209,6 +238,10 @@ export async function runDaemon () {
   const rejectReqFile = path.join(dir, 'reject-request.json')
   const revokeReqFile = path.join(dir, 'revoke-request.json')
   const secretReqFile = path.join(dir, 'secret-request.json')
+  // MULTIVAULT: esta bóveda se UNE a la cuenta de otra. Va por aquí y no por `pair` porque
+  // es el papel contrario — aquí no se invita a nadie, se acepta una invitación ajena.
+  const joinReqFile = path.join(dir, 'join-request.json')
+  const joinResFile = path.join(dir, 'join.json')
   const secretsListFile = path.join(dir, 'secrets-list.json')
   /**
    * Por qué falló la última orden de variables. La consola pide el cambio y el volcado
@@ -279,7 +312,7 @@ export async function runDaemon () {
       case 'list': return {} // el volcado de perfiles ya se hace abajo
       // `id`: quien la crea necesita saber CUÁL quedó, no adivinar por nombre (dos
       // cuentas pueden llamarse igual). Lo usa «emparejar en una cuenta nueva».
-      case 'add': { const p = await mgr.add(req.name, { adopt: !!req.adopt }); return { done: `perfil creado: ${p.name || p.id}`, id: p.id, adopt: !!req.adopt } }
+      case 'add': { const p = await mgr.add(req.name, { adopt: !!req.adopt, kek: req.kek || null }); return { done: `perfil creado: ${p.name || p.id}${req.kek ? ' (clave del disco en el KMS)' : ''}`, id: p.id, adopt: !!req.adopt } }
       case 'rm': { const r = await mgr.remove(req.profile); return { done: `perfil borrado: ${r.name || r.id}` } }
       case 'rename': { const p = mgr.profiles.rename(ref(), req.name); return { done: `perfil renombrado: ${p.name}` } }
       case 'use': { const p = mgr.profiles.setCurrent(ref()); return { done: `perfil activo: ${p.name || p.id}` } }
@@ -354,6 +387,18 @@ export async function runDaemon () {
           const r = await vault.approveDevice(appr.code); rm(pendingEnrollFile); rm(pairFile)
           if (pendingApproval && r?.cert?.sub) { try { await vault.setApproval(r.cert.sub, true); console.log('[vault] the new device will need approval on every key request') } catch (e) { console.error('[vault] could not flag approval: %s', e.message) } }
           pendingApproval = false
+          // `pair --admin`: se le SUMA `admin` a lo que ya tiene, no se le reescriben los
+          // permisos — el aparato acaba de entrar con el scope que pidió la invitación.
+          if (pendingAdmin && r?.deviceId) {
+            try {
+              const rec = await vault.profileMembers()
+              const m = (rec?.members || []).find((x) => x.id === r.deviceId)
+              if (!m?.pub) throw new Error('the device is not in the record yet')
+              await vault.setCaps(m.pub, [...new Set([...(m.caps || []), 'admin'])])
+              console.log('[vault] the new device can ADMINISTER this account (console)')
+            } catch (e) { console.error('[vault] could not grant admin: %s', e.message) }
+          }
+          pendingAdmin = false
           console.log('[vault] aprobado %s', r.deviceId)
           answer({ ok: true, deviceId: r.deviceId || null })
         } catch (e) {
@@ -394,6 +439,62 @@ export async function runDaemon () {
         } catch (e) { console.error('[vault] revocation failed:', e.message) }
         rm(revokeReqFile)
       }
+      /**
+       * UNIRSE A LA CUENTA DE OTRA BÓVEDA (multivault). La llave que entra como miembro es
+       * la de ESTA bóveda —no una de aparato inventada—, que es lo que después permite
+       * darle `+sella` y que sea el respaldo de verdad de la otra.
+       *
+       * El código de confirmación lo genera esta bóveda y hay que TIPEARLO en la otra: la
+       * misma defensa de siempre, para que una invitación interceptada no baste.
+       */
+      const join = readJsonSafe(joinReqFile)
+      if (join?.qr) {
+        rm(joinReqFile)
+        rm(joinResFile)
+        // LA CUENTA AJENA VA EN UN PERFIL DEL GESTOR, no en una cuenta interna de la
+        // identidad. Antes esto usaba `enrollDevice(…, { join: 'new' })`, que crea una
+        // cuenta más DENTRO de la identidad de un perfil que ya existía —y el gestor no se
+        // enteraba—: no había instancia de bóveda para ella, nadie se identificaba en el
+        // proxio con esa llave, y el aviso de la otra bóveda —con el acta donde acababa de
+        // conceder `sella`— no llegaba a ninguna parte. Se unía y no servía para nada.
+        //
+        // Un perfil nace vacío y `adopt: true`, que es la marca que deja a `joinProfile`
+        // cambiar su acta recién nacida por la que traiga la otra bóveda; sin ella, unirse
+        // sería pisar una cuenta con datos y se rechaza, que es lo correcto por defecto.
+        let nacido = null
+        try {
+          const p = await mgr.add(join.name || 'cuenta de la otra bóveda', { adopt: true, kek: join.kek || null })
+          nacido = p.id
+          const id = mgr.get(p.id)?.identity
+          if (!id) throw new Error('no identity for the new profile')
+          const off = id.onVault?.((e) => {
+            if (e?.phase === 'challenge' && e.code) {
+              console.log('[vault] type this code in the other vault:  %s', e.code)
+              writeJson(joinResFile, { at: Date.now(), code: e.code, state: 'waiting', profile: p.id })
+            }
+          })
+          // `'current'` y no `'new'`: el perfil que se acaba de crear ES el sitio, y su
+          // llave recién hecha es la que entra en el acta de la otra bóveda. Crear ahí
+          // dentro otra cuenta más sería el bug de arriba otra vez, un nivel más abajo.
+          const r = await id.enrollDevice(join.qr, { label: join.label || 'bóveda', join: 'current' })
+          off?.()
+          // LA CUENTA RECIÉN ADOPTADA PASA A SER LA ACTIVA, y no es un capricho: es la
+          // razón por la que se hizo el `join`. Sin esto, el `Perfil 1` vacío que nace en
+          // el primer arranque sigue siendo el destino por defecto y todo lo que hagas
+          // después —emparejar un aparato, aprobarlo— entra en la cuenta equivocada sin
+          // decir nada. En un contenedor que arranca para respaldar una cuenta, ese perfil
+          // vacío no es más que un accidente del primer arranque.
+          try { mgr.profiles.setCurrent(p.id) } catch (_) {}
+          console.log('[vault] joined the account of the other vault (record #%s) as profile %s (now the active one)', r?.acta?.seq ?? '?', p.id)
+          writeJson(joinResFile, { at: Date.now(), state: 'done', seq: r?.acta?.seq ?? null, profile: p.id })
+        } catch (e) {
+          console.error('[vault] could not join:', e.message)
+          // El perfil nació para esto y está vacío: si el intento no llegó a término se va
+          // con él. Si no, cada reintento dejaba una cuenta fantasma en el conmutador.
+          if (nacido) { try { await mgr.remove(nacido) } catch (_) {} }
+          writeJson(joinResFile, { at: Date.now(), state: 'error', error: e.message })
+        }
+      }
       // Secretos: `secret set/rm` (por SCOPE) y `secret device set/rm` (por APARATO),
       // del CLI o de la TUI. El archivo con el valor vive un instante en el mismo dir
       // 0700 del vault y se borra al consumir.
@@ -642,7 +743,7 @@ export async function runDaemon () {
 
   // --- apagado limpio ---
   const shutdown = (sig) => {
-    console.log(`\n[vault] ${sig} → deteniendo…`)
+    console.log(`\n[vault] ${sig} → stopping…`)
     rm(pairFile); rm(pendingEnrollFile)
     try { mgr.close() } catch (_) {}
     process.exit(0)
@@ -650,6 +751,69 @@ export async function runDaemon () {
   process.on('SIGTERM', () => shutdown('SIGTERM'))
   process.on('SIGINT', () => shutdown('SIGINT'))
 
+  /**
+   * ARRANCAR YA UNIDO A UNA CUENTA — lo que hace desplegable un contenedor.
+   *
+   * El problema del contenedor no es la bóveda: es el PRIMER APARATO. Una bóveda recién
+   * levantada tiene que **enseñar** una invitación y **recibir** de vuelta un código
+   * tecleado, y un contenedor no tiene pantalla ni teclado. Con una sola bóveda no hay
+   * salida: alguien tiene que entrar (`docker exec`, `kubectl exec`, ECS Exec).
+   *
+   * Con dos, sí la hay, y es este camino: **la invitación la hace la bóveda que TIENE un
+   * humano delante** (tu PC) y el contenedor solo la acepta. Entonces todo lo interactivo
+   * pasa del lado donde hay alguien —el código se teclea allí— y el contenedor no
+   * necesita más que dos cosas que ya tiene: la invitación al arrancar, y su registro.
+   *
+   *     docker run -e DOTRINO_JOIN="$(dotrino-vault pair --quiet)" …
+   *     docker logs -f dotrino-vault      → «type this code in the other vault: 123456»
+   *     dotrino-vault approve 123456      (en tu PC)
+   *
+   * `DOTRINO_JOIN_FILE` es lo mismo apuntando a un archivo, y es lo que hay que usar en
+   * serio: una variable de entorno la ve cualquiera con `docker inspect`, y aunque la
+   * invitación caduque y sea de un solo uso, no tiene por qué quedar ahí escrita.
+   *
+   * SE HACE UNA VEZ. La invitación consumida se anota y no se vuelve a intentar aunque la
+   * variable siga puesta: si no, cada reinicio del contenedor pediría entrar otra vez.
+   */
+  function bootstrapJoin () {
+    const raw = process.env.DOTRINO_JOIN_FILE
+      ? (() => { try { return fs.readFileSync(process.env.DOTRINO_JOIN_FILE, 'utf8') } catch (e) { console.error('[vault] could not read DOTRINO_JOIN_FILE: %s', e.message); return '' } })()
+      : (process.env.DOTRINO_JOIN || '')
+    const texto = String(raw).trim()
+    if (!texto) return
+
+    let qr = null
+    try { qr = parseInvite(texto) } catch (_) {}
+    if (!qr?.sn || !qr?.iss || !qr?.proxy) {
+      console.error('[vault] the invitation in DOTRINO_JOIN is not valid; ignoring it')
+      return
+    }
+    const marca = path.join(dir, 'bootstrap.json')
+    const hecho = readJsonSafe(marca)
+    if (hecho?.sn === qr.sn) return // ya se usó: un reinicio no vuelve a pedir entrar
+
+    writeJson(marca, { at: Date.now(), sn: qr.sn, iss: qr.iss })
+    writeJson(path.join(dir, 'join-request.json'), {
+      qr,
+      label: 'bóveda',
+      ...(process.env.DOTRINO_JOIN_NAME ? { name: process.env.DOTRINO_JOIN_NAME } : {})
+    })
+    console.log('[vault] joining the account of another vault (invitation from the deployment)…')
+    console.log('[vault] the code to type in the OTHER vault will appear below')
+    serve()
+  }
+  bootstrapJoin()
+
+  // ACTUALIZAR EL PAQUETE = ACTUALIZAR EL SERVICIO. El instalador no puede reiniciarnos
+  // (somos un servicio de USUARIO y él corre como root), así que lo hacemos nosotros: si
+  // el binario cambia en el disco, nos vamos y systemd nos levanta con el nuevo. Solo bajo
+  // systemd; ver `src/selfupdate.js` para por qué eso no es negociable.
+  const vigia = watchBinary({
+    log: console.log,
+    exit: () => shutdown('new binary installed')
+  })
+  if (vigia) console.log('[vault] watching for updates: a new binary restarts the service on its own')
+
   console.log('[vault] servicio listo.')
   return mgr
 }

package/src/keyowner.js

@@ -0,0 +1,83 @@
+/**
+ * keyowner.js — ESTE DIRECTORIO ES DE ESTA LLAVE, Y DE NINGUNA OTRA.
+ *
+ * Es lo único que hay que proteger (dueño, 2026-08-30): *«cada proceso tenga un directorio
+ * alusivo a su llave para que nunca se mezclen»*.
+ *
+ * Y lo que hay detrás es que **no hay datos compartidos**. Cada bóveda tiene su directorio
+ * entero —su identidad, sus perfiles, sus sobres— así que dos procesos nunca escriben el
+ * mismo archivo. No hace falta fusionar nada ni repartir carpetas por dentro: hace falta
+ * que nadie acabe, por accidente, arrancando con la identidad de otro.
+ *
+ * Cómo se accidenta uno: un `docker compose` duplicado, un `DOTRINO_VAULT_DIR` copiado de
+ * otro servicio, un respaldo restaurado encima. Sin esto, el proceso arranca tan tranquilo
+ * con una maestra que no es la suya y se identifica en el proxio como otro.
+ *
+ * La marca va EN CLARO a propósito: es una pubkey, no un secreto, y tiene que poder
+ * leerse antes de abrir nada.
+ */
+import fs from 'node:fs'
+import path from 'node:path'
+import { pubkeyId } from '@dotrino/identity/capabilities'
+
+export const OWNER_FILE = 'key.json'
+
+/**
+ * EL NOMBRE DE LA CARPETA SALE DE LA LLAVE.
+ *
+ * Una llave, una carpeta (dueño, 2026-08-30): un proceso con varios perfiles tiene varias
+ * llaves maestras y, por tanto, varias carpetas. Con el nombre derivado de la llave eso
+ * deja de ser algo que se comprueba y pasa a ser imposible por construcción — dos llaves
+ * no pueden caer en la misma carpeta porque no se llaman igual.
+ *
+ * Empieza por la huella que se le enseña a una persona (`AB12-CD34`, la misma que sale en
+ * `members` y en `profile ls`), para poder mirar el disco y reconocer de quién es cada
+ * una; y sigue con 16 hex más, porque para *garantizar* que no chocan hacen falta más bits
+ * de los que caben en algo que se lee en voz alta. Quitándole los guiones, el nombre
+ * EMPIEZA por el mismo id que la bóveda imprime al arrancar (`listo · id 0571465f61a2fac8`),
+ * así que se puede casar el log con la carpeta de un vistazo.
+ *
+ * Ojo con la palabra «maestra»: cuando esta bóveda se une a la cuenta de otra (`join`), su
+ * llave sigue siendo la misma pero pasa a ser MIEMBRO del acta ajena, no su master. Lo que
+ * nombra la carpeta es la llave que esta bóveda tiene para ese perfil, que no cambia
+ * nunca; lo que cambia es su papel.
+ */
+export async function keyDirName (pub) {
+  const h = await pubkeyId(pub)                 // SHA-256 del JWK canónico, 64 hex
+  const label = h.slice(0, 8).toUpperCase()
+  return `${label.slice(0, 4)}-${label.slice(4, 8)}-${h.slice(8, 24)}`
+}
+
+/** De quién es este directorio, o `null` si todavía no lo dice. */
+export function keyOwnerOf (dir) {
+  try { return JSON.parse(fs.readFileSync(path.join(dir, OWNER_FILE), 'utf8'))?.pub || null } catch (_) { return null }
+}
+
+/**
+ * Comprueba que este directorio es de esta llave, o lo marca si está por estrenar.
+ * Lanza con `code: 'key-mismatch'` si es de otra — sin tocar nada.
+ */
+export function assertKeyOwnsDir (dir, pub) {
+  if (!pub) return null            // sin llave todavía: no hay nada que comparar
+  const previo = keyOwnerOf(dir)
+
+  if (previo && previo !== pub) {
+    const e = new Error(
+      'this data directory belongs to a DIFFERENT identity. Two vaults must never share one: ' +
+      'each process needs its own directory, or one ends up running with the other\'s master key. ' +
+      'Point this one at its own DOTRINO_VAULT_DIR. Nothing was modified.'
+    )
+    e.code = 'key-mismatch'
+    throw e
+  }
+
+  if (!previo) {
+    try {
+      fs.mkdirSync(dir, { recursive: true, mode: 0o700 })
+      fs.writeFileSync(path.join(dir, OWNER_FILE), JSON.stringify({ pub, at: Date.now() }, null, 2) + '\n', { mode: 0o600 })
+    } catch (_) { /* si no se puede marcar, no se bloquea el arranque */ }
+  }
+  return pub
+}
+
+export default { assertKeyOwnsDir, keyOwnerOf, keyDirName, OWNER_FILE }

package/src/manager.js

@@ -12,6 +12,8 @@ import { startVault } from './vault.js'
 import { openProfiles } from './profiles.js'
 import { installNodeGlobals } from './node-globals.js'
 import { dataDir, ensureDir } from './paths.js'
+import { Identity } from '@dotrino/identity/node'
+import { atRestFor } from './atrest.js'
 
 /**
  * D12 (`docs/acta-de-perfil.md`): la bóveda **no** borra una cuenta que ella manda si
@@ -49,7 +51,26 @@ export async function startVaultManager ({ root = dataDir(), proxyUrl, log = con
     onAutoLock: (id) => log('[vault] profile %s locked itself after %d min idle (the console; devices keep working)',
       id, Math.round(profiles.autoLockMs / 60000))
   })
-  const migrated = profiles.migrate()
+  /**
+   * ACUÑAR (o simplemente LEER) la llave de una carpeta, y cerrarla enseguida.
+   *
+   * Existe porque el nombre de la carpeta sale de la llave y hay que saber cuál es antes
+   * de poder ponérselo. La llave se genera en memoria y se escribe acto seguido —no hay
+   * costura entre las dos cosas en `Identity.connect`—, así que se acuña donde sea y
+   * después se mueve la carpeta.
+   *
+   * Se CIERRA (`destroy`) antes de devolver: quien llama va a renombrar la carpeta, y una
+   * identidad abierta se quedó con la ruta vieja como texto.
+   */
+  async function mintKey (dir) {
+    const identity = await Identity.connect({ dir, atRest: atRestFor(dir) })
+    try {
+      if (!identity.me?.publickey) await identity.setMyNickname('')
+      return identity.me?.publickey || null
+    } finally { try { identity.destroy() } catch (_) {} }
+  }
+
+  const migrated = await profiles.migrate(mintKey)
   if (migrated?.migrated) log('[vault] identidad mono-perfil migrada al perfil %s', migrated.id)
 
   const running = new Map() // id -> instancia de startVault
@@ -79,7 +100,15 @@ export async function startVaultManager ({ root = dataDir(), proxyUrl, log = con
   }
 
   for (const p of profiles.list()) {
-    try { await open(p.id) } catch (e) { log('[vault] no se pudo abrir el perfil %s: %s', p.id, e.message) }
+    // ANTES de abrir: la carpeta tiene que llamarse como su llave. Es toda la migración
+    // (mover la data a la carpeta que le toca) y va aquí porque es el único momento en que
+    // la identidad está cerrada — renombrarla abierta la deja escribiendo en la ruta vieja.
+    let id = p.id
+    try {
+      id = await profiles.ensureNamedByKey(p.id, mintKey)
+      if (id !== p.id) log('[vault] profile %s renamed to %s (the folder is named after its key)', p.id, id)
+    } catch (e) { log('[vault] could not name the folder of %s after its key: %s', p.id, e.message) }
+    try { await open(id) } catch (e) { log('[vault] no se pudo abrir el perfil %s: %s', id, e.message) }
   }
 
   const get = (id) => {
@@ -109,8 +138,8 @@ export async function startVaultManager ({ root = dataDir(), proxyUrl, log = con
      * (camino A): la bóveda pone el sitio y la llave que entrará como miembro, pero la
      * cuenta la trae el dispositivo y se adopta al emparejar.
      */
-    async add (name, { adopt = false } = {}) {
-      const p = profiles.add(name, { adopt })
+    async add (name, { adopt = false, kek = null } = {}) {
+      const p = await profiles.add(name, { adopt, kek, mintKey })
       await open(p.id)
       log('[vault] perfil creado%s: %s (%s)', adopt ? ' (a la espera de adoptar una cuenta)' : '', p.name || '(sin nombre)', p.id)
       return profiles.get(p.id)

package/src/passwords.js

@@ -27,7 +27,8 @@ export const PASSWORDS_CAP = 'passwords'
  *   `cek`         la llave de la bóveda de contraseñas (CryptoKey AES-GCM)
  *   `isAllowed(pubkey)`   qué aparatos pueden pedir — lo decide el acta, no esto
  *   `encPubOf(pubkey)`    su llave de cifrado, para sellarle la respuesta
- *   `needsApproval(pubkey)`  si ese aparato está marcado para aprobar
+ *   `needsApproval(pubkey)`  si ese aparato está marcado para aprobar. Se compone con el
+ *                        criterio del propio protocolo: solo lo PRIVADO pregunta
  *   `approve({ pubkey, op })`  pide el visto bueno (el teléfono) y espera
  *   `devices()` / `unlink(pubkey)`   administración, opcional
  *   `audit(op, info)`  la bitácora del vault
@@ -53,9 +54,19 @@ export function createPasswordDesk (opts = {}) {
     vault,
     isAllowed,
     encPubOf,
-    // La aprobación es del APARATO y dura mientras el vault siga encendido, igual que
-    // los cajones de secretos: una por arranque, sin ventana que vigilar.
-    needsApproval: (op, _payload, pubkey) => op === 'get' && needsApproval(pubkey),
+    // Dos condiciones, y las dos tienen que darse:
+    //
+    //   · que ese APARATO esté marcado para aprobar (la política del vault: se pide una
+    //     vez y dura mientras el vault siga encendido, igual que los cajones de secretos);
+    //   · y que lo que pide sea PRIVADO — una contraseña, un código de dos pasos, o un
+    //     campo que el usuario marcó. Rellenar un nombre no es sacar un secreto, y pedir
+    //     permiso para todo enseña a decir que sí sin mirar.
+    //
+    // El segundo criterio se toma del propio responder (`wantsPrivate`) en vez de
+    // reescribirlo aquí: si cada bóveda tuviera su idea de qué es privado, serían tres
+    // bóvedas distintas otra vez.
+    needsApproval: async (op, payload, pubkey) =>
+      needsApproval(pubkey) && await responder.wantsPrivate(op, payload),
     approve,
     admin: devices && unlink ? { devices, unlink } : null,
     onRequest: (r) => {