Seguridad del desarrollador

Tu clave de firma

• Es lo que garantiza que un paquete es tuyo. Quien la tenga puede firmar código que cualquier instalación que confíe en ti ejecutará con los permisos de la API.
• Guárdala en un gestor de contraseñas (con copia). No la subas a ningún repositorio (añade *.pem al .gitignore), no la pegues en chats ni la copies a servidores de compilación compartidos.
• hury-plugin keygen la crea con permisos 600 y no sobrescribe una existente.
• En integración continua, pásala por la variable HURY_PLUGIN_SIGNING_KEY desde el gestor de secretos del CI, no la dejes en el repositorio. Firma solo en compilaciones de ramas protegidas.
• La clave oficial de Hury (~/.hury/plugin-signing.pem) no sale del equipo del autor ni va a ninguna web. Ni este portal ni su firmador la tienen o la pueden usar. Si alguien te ofrece «firmar con la clave de Hury», no es Hury.

El firmador del navegador

• Corre en tu pestaña con WebCrypto Ed25519 (o @noble/curves empaquetado). No hay backend.
• La página /herramientas/firmador se sirve con Content-Security-Policy: … connect-src 'none': el navegador impide cualquier conexión de red desde ella. La clave privada y el zip no pueden enviarse. Puedes comprobarlo con el botón «Probar el bloqueo de red» o abriendo las herramientas de desarrollo.
• Aun así, un navegador con extensiones no es tan seguro como una terminal limpia: una extensión maliciosa puede leer lo que haya en cualquier página. Para claves valiosas, firma con la CLI en un equipo de confianza.
• El generador de claves crea el par en la pestaña y no guarda nada; descarga la privada y no la puedes recuperar después.

Lo que ejecuta tu plugin

Un plugin no tiene aislamiento (sandbox):

• Su código de API corre con los mismos permisos que la API: acceso a la base de datos entera, a los ajustes y a las claves que la API descifra. Escríbelo como si fuera código del núcleo.
• Su código de panel corre en el navegador de quien lo abre, con su sesión.
• Por eso el dueño de la instalación decide en qué claves confía (PLUGIN_TRUSTED_KEYS). Ese poder no se delega a la interfaz.

Buenas prácticas:

• Valida toda entrada con zod (parse) y limita longitudes.
• Permisos en cada ruta; no te fíes de que el panel oculte un botón.
• Parametriza el SQL: usa Kysely; no concatenes texto en consultas. En migraciones, nada dinámico.
• No guardes secretos en el paquete (claves de APIs, contraseñas): se pueden leer del .zip y del navegador. Usa los ajustes del host y su cifrado.
• Audita los cambios con audit(...) en la misma transacción.
• No registres datos personales en logs.
• Los eventos de dominio corren dentro de la transacción del núcleo: un error tuyo la deshace. Sé mínimo y comprueba que el módulo esté encendido.
• Dependencias: lo que empaquetas (p. ej. qrcode en el panel) es código tuyo; mantenlo al día.

Lo que verifica el instalador

Antes de escribir nada en disco: zip válido, sin rutas absolutas ni .., firma Ed25519 de checksums.json válida con una clave aceptada, huella correcta de cada fichero, plugin.json válido y apiVersion compatible. Un cambio de un solo byte en cualquier fichero invalida el paquete.

Si algo sale mal

• Perdiste la clave privada: genera otra y pide a los dueños que la añadan; vuelve a firmar tus plugins.
• Crees que alguien la tiene: avisa de inmediato a quien confía en ti para que la quite de PLUGIN_TRUSTED_KEYS, y rota la clave.
• Un plugin tuyo hace algo que no debe: apágalo en Ajustes → Módulos (sus rutas dejan de responder y el panel no carga su código) y, si hace falta, desinstálalo.