Politica di sicurezza

Herkos gestisce chiavi private e messaggi cifrati, quindi prendiamo sul serio le segnalazioni di sicurezza e preferiamo sapere di un problema presto piuttosto che tardi.

Segnalare una vulnerabilità

Per favore non aprire una issue pubblica per i problemi di sicurezza.

Segnalalo in privato tramite la segnalazione privata di vulnerabilità di GitHub, oppure via email a security@herkos.email.

Cose utili da includere: qual è il problema, come riprodurlo, su quale piattaforma e versione l'hai testato e cosa potrebbe ottenere un attaccante. Una prova di concetto aiuta molto.

Non includere mai il tuo nsec, la tua chiave segreta o il segreto del tuo bunker in una segnalazione.

Cerchiamo di confermare la ricezione delle segnalazioni entro pochi giorni. Poiché Herkos è un piccolo progetto, concedi un tempo ragionevole per una correzione prima di renderla pubblica. Saremo lieti di citarti nell'avviso, a meno che tu non preferisca altrimenti.

Cosa rientra nell'ambito

L'applicazione Herkos in sé: gestione e conservazione delle chiavi, cifratura e decifratura dei messaggi (compresi i controlli sul mittente NIP-59 e l'isolamento del Bcc in local_packages/nostr_mail), il blocco dell'app, la comunicazione con relay e bridge, la gestione degli allegati e la pipeline di build e rilascio.

Cosa non rientra nell'ambito

Il protocollo Nostr e i suoi NIP in quanto tali — segnalali a monte.
Relay, bridge e server Blossom gestiti da terzi. Herkos li include come predefiniti ma non li gestisce; segnala i problemi ai loro operatori.
Il progetto originale Nostr Mail Client, a meno che il problema non riguardi specificamente modifiche fatte in Herkos.
Irrobustimenti mancanti che documentiamo già come limiti noti (vedi sotto).

Limiti noti, detti chiaramente

Questi sono compromessi di progettazione, non vulnerabilità. Preferiamo metterli per iscritto piuttosto che qualcuno li scopra a proprie spese:

La posta verso indirizzi tradizionali non è cifrata end-to-end. I messaggi tra utenti Nostr usano il gift wrap NIP-17 e sono cifrati end-to-end. Quando scrivi a un indirizzo email tradizionale, un bridge converte il messaggio e può leggerlo.
Il blocco dell'app (PIN e biometria) è una barriera di comodità, non una cifratura a riposo. Ferma chi prende in mano un dispositivo sbloccato; non protegge da un attaccante con pieno accesso al dispositivo o alla sua memoria.
Su Windows non si può imporre l'autenticazione solo biometrica. Windows Hello non consente di scegliere il metodo, quindi il PIN di sistema resta sempre disponibile come alternativa.
Perdere la chiave significa perdere l'account. Non c'è recupero, per scelta.
I metadati non sono del tutto nascosti. I relay possono osservare gli schemi di connessione, e ogni relay vede il tuo indirizzo IP, anche quando non può leggere il contenuto dei messaggi. Ciò che Herkos non rivela (dal 30-09-2026) è chi scrive a chi quando un relay chiede l'autenticazione NIP-42:
Cercare dove consegnare. Gli elenchi di relay e di server Blossom di un destinatario vengono richiesti su una connessione separata che non ti identifica mai, prima su relay che non richiedono autenticazione (purplepag.es, user.kindpag.es, nos.lol, offchain.pub).
Profili e pianificatore. Il nome e l'immagine mostrati per chiunque altro (kind 0), e l'elenco di relay della DVM di pianificazione quando programmi o annulli un'email, vengono richiesti allo stesso modo: prima in forma anonima e, se un relay insiste, con la chiave temporanea descritta più sotto, mai con la tua (dal 01-10-2026; prima, un relay che chiedeva l'autenticazione otteneva la tua chiave, e poteva sapere di chi stavi guardando il profilo). Solo il tuo profilo viene ancora letto a tuo nome.
Consegnare. I gift wrap vanno ai relay DM del destinatario, su quella stessa connessione separata. Se uno di essi richiede l'autenticazione, Herkos risponde con una chiave creata apposta e conservata solo in memoria, mai con la tua; ogni account sul dispositivo ha la propria. Il relay può comunque vedere che lo stesso dispositivo (stesso IP, stessa chiave temporanea) ha inviato più buste durante una sessione.
Email di grandi dimensioni. La copia cifrata di un'email oltre i 32 KB viene caricata su server Blossom, compresi quelli dei destinatari. Solo i tuoi server (il tuo elenco Blossom) ricevono il caricamento autorizzato con la tua chiave. Qualsiasi altro server lo riceve in forma anonima e, se insiste per un'autorizzazione, una firmata con la stessa chiave temporanea di cui sopra (dal 01-10-2026; prima, ogni server otteneva la tua chiave). Un server che accetta solo chiavi conosciute lo rifiuta, e la copia resta sugli altri server.
I tuoi dati. La sincronizzazione della tua casella, delle etichette, delle impostazioni e delle bozze si autentica, quando un relay lo chiede, come l'account a cui appartengono i dati, anche durante un cambio di account. Sui tuoi relay questo non dice loro nulla che non sapessero già: le richieste nominano comunque la tua chiave. I tuoi elenchi di relay e di server Blossom sono pubblici e vengono richiesti senza identificarti, e così i relay indicati in un link di un'email.
Lo stato di lettura e le cartelle sono metadati pubblici (per ora). Segnare un'email come letta, preferita, archiviata o spostata pubblica un evento etichetta NIP-32 non cifrato legato alla tua chiave pubblica, compresi i nomi delle cartelle personalizzate. Un mittente che conosce l'identificativo di un'email che ti ha inviato può sapere quando ci hai agito sopra. La cifratura di queste etichette è prevista; fino ad allora, considera pubblici i nomi delle cartelle.
Le notifiche push e l'invio programmato usano servizi di terze parti. Il server push (api.nmail.li per impostazione predefinita) apprende la tua chiave pubblica, un token push e quando ricevi posta; la DVM di pianificazione apprende la tua chiave pubblica e i messaggi già cifrati che deve pubblicare. Entrambi sono facoltativi e documentati in PRIVACY.md. Il testo di una notifica push è scelto dal server push, e Herkos se ne fida solo quando UnifiedPush lo consegna cifrato (RFC 8291); un payload non cifrato si limita a risvegliare l'app perché scarichi la posta da sé.
La versione web tiene la tua chiave nel browser, che è il posto più debole in cui tenerla. Le app installate affidano la tua chiave segreta all'archivio sicuro del sistema operativo (Android Keystore, Gestione credenziali di Windows, libsecret, il portachiavi di iOS/macOS). Un browser non ha nulla di tutto ciò: la chiave sta nell'archiviazione dell'origine e passa da JavaScript a ogni firma, alla portata di qualsiasi codice eseguito nella pagina — un'estensione del browser con accesso a tutti i siti, un bug XSS nell'app o in una dipendenza, un rilascio manomesso — e di qualsiasi infostealer che copi il profilo del browser. Non c'è nemmeno un momento in cui verifichi il codice una volta per tutte: un binario firmato viene controllato all'installazione, mentre una pagina web serve codice nuovo a ogni visita. Accedi alla versione web con un firmatario remoto (bunker NIP-46, Amber), così la chiave non raggiunge mai il browser, oppure trattala come un'identità usa e getta e tieni la tua vera chiave in un'app installata.
La posta tramite bridge è affidabile solo quanto il bridge. Herkos verifica che un messaggio indicato come proveniente da un bridge sia stato davvero firmato da un bridge che hai configurato (o da uno di quelli predefiniti). Non può verificare nulla sull'indirizzo From: tradizionale che il bridge inoltra.
Gli allegati vengono aperti dal sistema operativo. Herkos non avvia mai tipi di file eseguibili o script e chiede conferma prima di passare qualsiasi altro allegato non visualizzabile all'app predefinita del sistema, ma l'app che apre il file è fuori dal nostro controllo.

Versioni supportate

Le correzioni di sicurezza vengono applicate all'ultima versione rilasciata. Viste le dimensioni del progetto, le versioni precedenti non sono mantenute — aggiorna prima di segnalare.