Politique de sécurité

Herkos manipule des clés privées et des messages chiffrés : nous prenons donc les signalements de sécurité au sérieux et préférons entendre parler d'un problème tôt plutôt que tard.

Signaler une vulnérabilité

Merci de ne pas ouvrir de ticket public pour un problème de sécurité.

Signalez-le en privé via le signalement privé de vulnérabilités de GitHub, ou par courriel à security@herkos.email.

Éléments utiles à inclure : la nature du problème, comment le reproduire, la plateforme et la version testées, et ce qu'un attaquant pourrait obtenir. Une preuve de concept aide beaucoup.

N'incluez jamais votre propre nsec, votre clé secrète ou le secret de votre bunker dans un signalement.

Nous nous efforçons d'accuser réception des signalements sous quelques jours. Herkos étant un petit projet, merci de laisser un délai raisonnable pour un correctif avant toute divulgation publique. Nous serons heureux de vous citer dans l'avis de sécurité, sauf si vous préférez le contraire.

Ce qui entre dans le périmètre

L'application Herkos elle-même : la gestion et le stockage des clés, le chiffrement et le déchiffrement des messages (y compris les vérifications d'expéditeur NIP-59 et l'isolation du Cci dans local_packages/nostr_mail), le verrouillage de l'application, la communication avec les relais et les bridges, la gestion des pièces jointes, ainsi que la chaîne de compilation et de publication.

Ce qui n'entre pas dans le périmètre

Le protocole Nostr et ses NIP eux-mêmes — signalez-les en amont.
Les relais, bridges et serveurs Blossom exploités par des tiers. Herkos est livré avec des réglages par défaut mais ne les exploite pas ; signalez les problèmes à leurs opérateurs.
Le projet d'origine Nostr Mail Client, sauf si le problème est propre aux modifications apportées dans Herkos.
L'absence d'un durcissement que nous documentons déjà comme limite connue (voir ci-dessous).

Limites connues, dites franchement

Ce sont des compromis de conception, pas des vulnérabilités. Nous préférons les écrire plutôt que de laisser quelqu'un les découvrir à ses dépens :

Le courrier vers des adresses classiques n'est pas chiffré de bout en bout. Les messages entre utilisateurs de Nostr utilisent le gift wrap NIP-17 et sont chiffrés de bout en bout. Quand vous écrivez à une adresse électronique ordinaire, un bridge convertit le message et peut le lire.
Le verrouillage de l'application (code PIN et biométrie) est une barrière de confort, pas un chiffrement au repos. Il arrête quelqu'un qui ramasse un appareil déverrouillé ; il ne protège pas contre un attaquant ayant un accès complet à l'appareil ou à son stockage.
Sous Windows, l'authentification uniquement biométrique ne peut pas être imposée. Windows Hello ne permet pas de choisir la méthode : le code PIN du système reste donc toujours disponible en solution de repli.
Perdre sa clé, c'est perdre le compte. Il n'y a pas de récupération, par conception.
Les métadonnées ne sont pas entièrement cachées. Les relais peuvent observer les schémas de connexion, et chaque relais voit votre adresse IP, même lorsqu'il ne peut pas lire le contenu des messages. Ce que Herkos ne dévoile pas (depuis le 30/09/2026), c'est qui écrit à qui lorsqu'un relais demande une authentification NIP-42 :
Chercher où livrer. Les listes de relais et de serveurs Blossom d'un destinataire sont demandées sur une connexion séparée qui ne vous identifie jamais, d'abord auprès de relais qui n'exigent pas d'authentification (purplepag.es, user.kindpag.es, nos.lol, offchain.pub).
Les profils et le planificateur. Le nom et l'image affichés pour toute autre personne (kind 0), ainsi que la liste de relais du DVM de planification lorsque vous programmez ou annulez un courriel, sont demandés de la même façon : d'abord anonymement et, si un relais insiste, avec la clé temporaire décrite ci-dessous, jamais avec la vôtre (depuis le 01/10/2026 ; auparavant, un relais qui demandait une authentification obtenait votre clé et pouvait savoir quel profil vous consultiez). Seul votre propre profil est encore lu en votre nom.
Livrer. Les gift wraps partent vers les relais DM du destinataire, sur cette même connexion séparée. Si l'un d'eux exige une authentification, Herkos répond avec une clé créée à cet effet et conservée uniquement en mémoire, jamais avec la vôtre ; chaque compte de l'appareil a la sienne. Le relais peut tout de même voir que le même appareil (même IP, même clé temporaire) a envoyé plusieurs enveloppes au cours d'une session.
Les courriels volumineux. La copie chiffrée d'un courriel de plus de 32 Ko est téléversée sur des serveurs Blossom, y compris ceux des destinataires. Seuls vos propres serveurs (votre liste Blossom) reçoivent un téléversement autorisé avec votre clé. Tout autre serveur le reçoit anonymement et, s'il exige une autorisation, une autorisation signée avec la même clé temporaire que ci-dessus (depuis le 01/10/2026 ; auparavant, chaque serveur obtenait votre clé). Un serveur qui n'accepte que des clés connues le refuse, et la copie reste sur les autres serveurs.
Vos propres données. La synchronisation de votre boîte aux lettres, de vos étiquettes, de vos réglages et de vos brouillons s'authentifie, lorsqu'un relais le demande, en tant que le compte auquel appartiennent les données, même pendant un changement de compte. Sur vos propres relais, cela ne leur apprend rien qu'ils ne sachent déjà : les requêtes nomment de toute façon votre clé. Vos propres listes de relais et de serveurs Blossom sont publiques et sont demandées sans vous identifier, tout comme les relais cités dans un lien de courriel.
L'état de lecture et les dossiers sont des métadonnées publiques (pour l'instant). Marquer un courriel comme lu, favori, archivé ou déplacé publie un événement d'étiquette NIP-32 non chiffré, lié à votre clé publique, y compris le nom des dossiers personnalisés. Un expéditeur qui connaît l'identifiant d'un courriel qu'il vous a envoyé peut savoir quand vous avez agi dessus. Le chiffrement de ces étiquettes est prévu ; en attendant, considérez les noms de dossiers comme publics.
Les notifications push et l'envoi programmé utilisent des services tiers. Le serveur push (api.nmail.li par défaut) apprend votre clé publique, un jeton push et quand vous recevez du courrier ; le DVM de planification apprend votre clé publique et les messages déjà chiffrés qu'il doit publier. Les deux sont optionnels et documentés dans PRIVACY.md. Le texte d'une notification push est choisi par le serveur push, et Herkos ne s'y fie que lorsque UnifiedPush le livre chiffré (RFC 8291) ; une charge utile non chiffrée ne fait que réveiller l'application pour qu'elle aille chercher le courrier elle-même.
La version web garde votre clé dans le navigateur, l'endroit le plus faible pour elle. Les applications installées confient votre clé secrète au stockage sécurisé du système d'exploitation (Android Keystore, Gestionnaire d'identifiants Windows, libsecret, trousseau iOS/macOS). Un navigateur n'a rien de tout cela : la clé réside dans le stockage de l'origine et transite par JavaScript à chaque signature, à la portée de tout code qui s'exécute dans la page — une extension de navigateur ayant accès à tous les sites, une faille XSS dans l'application ou dans une dépendance, un déploiement altéré — et de tout logiciel voleur d'informations qui copie le profil du navigateur. Il n'y a pas non plus de moment où vous vérifiez le code une fois pour toutes : un binaire signé est vérifié à l'installation, alors qu'une page web livre du code neuf à chaque visite. Connectez-vous à la version web avec un signataire distant (bunker NIP-46, Amber), pour que la clé n'atteigne jamais le navigateur, ou traitez-la comme une identité jetable et gardez votre vraie clé dans une application installée.
Le courrier passé par un bridge n'est pas plus fiable que le bridge. Herkos vérifie qu'un message présenté comme venant d'un bridge a bien été signé par un bridge que vous avez configuré (ou l'un de ceux par défaut). Il ne peut rien vérifier de l'adresse From: classique que le bridge relaie.
Les pièces jointes sont ouvertes par le système d'exploitation. Herkos ne lance jamais de fichiers exécutables ou de scripts, et demande confirmation avant de confier toute autre pièce jointe sans aperçu à l'application par défaut du système, mais l'application qui ouvre le fichier échappe à notre contrôle.

Versions prises en charge

Les correctifs de sécurité sont appliqués à la dernière version publiée. Vu la taille du projet, les versions plus anciennes ne sont pas maintenues — merci de mettre à jour avant de signaler un problème.