Política de seguridad

Herkos maneja claves privadas y mensajes cifrados, así que nos tomamos en serio los informes de seguridad y preferimos enterarnos pronto antes que tarde.

Cómo informar de una vulnerabilidad

No abras una incidencia pública para un problema de seguridad.

Comunícalo en privado a través del informe privado de vulnerabilidades de GitHub, o por correo a security@herkos.email.

Conviene incluir: cuál es el problema, cómo reproducirlo, en qué plataforma y versión lo has probado, y qué podría conseguir un atacante. Una prueba de concepto ayuda mucho.

Nunca incluyas tu propia nsec, clave secreta o secreto de bunker en un informe.

Intentamos acusar recibo en unos pocos días. Como Herkos es un proyecto pequeño, te pedimos un plazo razonable para corregirlo antes de hacerlo público. Nos gusta acreditarte en el aviso, salvo que prefieras lo contrario.

Qué entra en el alcance

La propia aplicación Herkos: el manejo y almacenamiento de claves, el cifrado y descifrado de mensajes (incluidas las comprobaciones de remitente NIP-59 y el aislamiento de Bcc en local_packages/nostr_mail), el bloqueo de la app, la comunicación con relays y bridges, el manejo de adjuntos, y el proceso de compilación y publicación.

Qué queda fuera

• El protocolo Nostr y sus NIP en sí — eso se reporta upstream.
• Relays, bridges y servidores Blossom operados por terceros. Herkos trae valores por defecto, pero no los gestiona; informa a sus operadores.
• El proyecto original Nostr Mail Client, salvo que el problema sea específico de los cambios hechos en Herkos.
• El endurecimiento que ya documentamos como limitación conocida (más abajo).

Limitaciones conocidas, dichas claramente

Son decisiones de diseño, no vulnerabilidades. Preferimos escribirlas que dejar que alguien las descubra por las malas:

• El correo a direcciones tradicionales no va cifrado de extremo a extremo. Entre usuarios de Nostr se usa gift wrap NIP-17 y sí lo está. Cuando escribes a una dirección de correo normal, un bridge convierte el mensaje y puede leerlo.
• El bloqueo de la app (PIN y biometría) es una barrera de conveniencia, no cifrado en reposo. Frena a quien coge un dispositivo desbloqueado; no protege frente a un atacante con acceso completo al dispositivo o a su almacenamiento.
• En Windows no se puede exigir solo biometría. Windows Hello no permite seleccionar el método, así que el PIN del sistema sigue siempre disponible como alternativa.
• Perder tu clave es perder la cuenta. No hay recuperación, por diseño.
• Los metadatos no están del todo ocultos. Los relays pueden observar patrones de conexión aunque no puedan leer el contenido. En concreto, cuando Herkos consulta dónde entregar un mensaje (la lista de relays de DM del destinatario) en un relay que exige autenticación NIP-42, se autentica con tu clave, de modo que ese relay puede ver que estás a punto de escribir a esa persona. Corregirlo requiere el control de identidad por petición de la NDK 0.9 (el SDK original lo hace desde nostr_mail 3.1.0); está en la hoja de ruta.
• Con varias cuentas en un mismo dispositivo, el reto NIP-42 de un relay lo responde la cuenta que esté activa cuando llega, que durante un cambio de cuenta puede no ser aquella cuyos datos se pedían. Misma causa y misma solución que el punto anterior.
• El estado de lectura y las carpetas son metadatos públicos (por ahora). Marcar un correo como leído, destacado o archivado, o moverlo, publica un evento de etiqueta NIP-32 sin cifrar ligado a tu clave pública, incluidos los nombres de las carpetas personalizadas. Quien te envió un correo y conoce su id puede saber cuándo actuaste sobre él. Cifrar esas etiquetas está previsto; hasta entonces, trata los nombres de carpeta como públicos.
• Las notificaciones push y el envío programado usan servicios de terceros. El servidor push (api.nmail.li por defecto) conoce tu clave pública, un token push y cuándo recibes correo; el DVM programador conoce tu clave pública y los mensajes —ya cifrados— que debe publicar. Ambos son opcionales y están documentados en PRIVACY.md. El texto de una notificación push lo elige el servidor push; en la variante con servicios de Google pasa por FCM en claro, y en UnifiedPush solo se considera fiable cuando llega cifrado (RFC 8291).
• El correo puenteado vale lo que valga el bridge. Herkos verifica que un mensaje marcado como procedente de un bridge realmente fue firmado por un bridge que tienes configurado (o uno de los de serie). No puede verificar nada sobre la dirección From: tradicional que el bridge retransmite.
• Los adjuntos los abre el sistema operativo. Herkos nunca lanza ficheros ejecutables ni de script, y pregunta antes de entregar al sistema cualquier otro adjunto que no pueda previsualizar, pero la aplicación que abre el fichero queda fuera de nuestro control.

Versiones con soporte

Las correcciones de seguridad se aplican a la última versión publicada. Dado el tamaño del proyecto, las versiones anteriores no se mantienen: actualiza antes de informar.