Política de segurança

O Herkos trata chaves privadas e mensagens cifradas, por isso levamos a sério as comunicações de segurança e preferimos saber de um problema cedo do que tarde.

Comunicar uma vulnerabilidade

Por favor, não abra uma issue pública para problemas de segurança.

Comunique-o em privado através da comunicação privada de vulnerabilidades do GitHub, ou por email para security@herkos.email.

O que convém incluir: qual é o problema, como reproduzi-lo, em que plataforma e versão o testou, e o que um atacante conseguiria fazer. Uma prova de conceito ajuda muito.

Nunca inclua num relatório a sua própria nsec, chave secreta ou segredo do bunker.

Procuramos confirmar a receção dos relatórios em poucos dias. Como o Herkos é um projeto pequeno, conceda-nos um prazo razoável para uma correção antes de o divulgar publicamente. Teremos todo o gosto em creditá-lo no aviso, salvo se preferir o contrário.

O que está abrangido

A própria aplicação Herkos: tratamento e armazenamento de chaves, cifragem e decifragem de mensagens (incluindo as verificações do remetente NIP-59 e o isolamento do Bcc em local_packages/nostr_mail), o bloqueio da aplicação, a comunicação com relays e bridges, o tratamento de anexos, e o processo de compilação e publicação.

O que não está abrangido

O protocolo Nostr e os seus NIPs em si — comunique esses problemas a montante.
Relays, bridges e servidores Blossom operados por terceiros. O Herkos vem com predefinições mas não os opera; comunique os problemas aos respetivos operadores.
O projeto original Nostr Mail Client, salvo se o problema for específico de alterações feitas no Herkos.
Falta de reforço que já documentamos como limitação conhecida (ver abaixo).

Limitações conhecidas, ditas com clareza

São compromissos de conceção, não vulnerabilidades. Preferimos escrevê-los a que alguém os descubra da pior maneira:

O correio para endereços tradicionais não é cifrado ponta a ponta. As mensagens entre utilizadores do Nostr usam gift wrap NIP-17 e são cifradas ponta a ponta. Quando escreve para um endereço de email comum, um bridge converte a mensagem e consegue lê-la.
O bloqueio da aplicação (PIN e biometria) é uma barreira de conveniência, não cifragem em repouso. Impede quem pegue num dispositivo desbloqueado; não protege contra um atacante com acesso total ao dispositivo ou ao seu armazenamento.
No Windows, não é possível impor autenticação apenas biométrica. O Windows Hello não permite escolher o método, por isso o PIN do sistema fica sempre disponível como alternativa.
Perder a chave significa perder a conta. Não há recuperação, por conceção.
Os metadados não ficam totalmente ocultos. Os relays podem observar padrões de ligação, e todos os relays veem o seu endereço IP, mesmo quando não conseguem ler o conteúdo das mensagens. O que o Herkos não revela (desde 30-09-2026) é quem escreve a quem quando um relay pede autenticação NIP-42:
Procurar onde entregar. As listas de relays e de servidores Blossom de um destinatário são pedidas numa ligação separada que nunca o identifica, primeiro em relays que não exigem autenticação (purplepag.es, user.kindpag.es, nos.lol, offchain.pub).
Perfis e o agendador. O nome e a imagem mostrados para qualquer outra pessoa (kind 0), e a lista de relays do DVM de agendamento quando agenda ou cancela um email, são pedidos da mesma forma: primeiro de forma anónima e, se um relay insistir, com a chave temporária descrita abaixo, nunca com a sua (desde 01-10-2026; antes, um relay que pedisse autenticação recebia a sua chave, e podia saber de quem era o perfil que estava a ver). Só o seu próprio perfil continua a ser lido em seu nome.
Entregar. Os gift wraps vão para os relays DM do destinatário, nessa mesma ligação separada. Se um deles exigir autenticação, o Herkos responde com uma chave criada para o efeito e guardada apenas em memória, nunca com a sua; cada conta no dispositivo tem a sua. O relay continua a poder ver que o mesmo dispositivo (mesmo IP, mesma chave temporária) enviou vários envelopes durante uma sessão.
Emails grandes. A cópia cifrada de um email com mais de 32 KB é enviada para servidores Blossom, incluindo os dos destinatários. Só os seus próprios servidores (a sua lista Blossom) recebem o envio autorizado com a sua chave. Qualquer outro servidor recebe-o de forma anónima e, se insistir numa autorização, uma assinada com a mesma chave temporária de cima (desde 01-10-2026; antes, todos os servidores recebiam a sua chave). Um servidor que só aceite chaves conhecidas recusa-o, e a cópia fica nos outros servidores.
Os seus próprios dados. A sincronização da sua caixa de correio, etiquetas, definições e rascunhos autentica-se, quando um relay o pede, como a conta a que os dados pertencem, mesmo durante uma mudança de conta. Nos seus próprios relays isso não lhes diz nada que não soubessem: os pedidos já nomeiam a sua chave. As suas próprias listas de relays e de servidores Blossom são públicas e são pedidas sem o identificar, tal como os relays indicados numa ligação de email.
O estado de leitura e as pastas são metadados públicos (por agora). Marcar um email como lido, destacado, arquivado ou movido publica um evento de etiqueta NIP-32 não cifrado ligado à sua chave pública, incluindo os nomes das pastas próprias. Um remetente que conheça o identificador de um email que lhe enviou consegue saber quando agiu sobre ele. Cifrar estas etiquetas está previsto; até lá, considere públicos os nomes das pastas.
As notificações push e o envio agendado usam serviços de terceiros. O servidor push (api.nmail.li por predefinição) fica a saber a sua chave pública, um token push e quando recebe correio; o DVM de agendamento fica a saber a sua chave pública e as mensagens já cifradas que tem de publicar. Ambos são opcionais e estão documentados no PRIVACY.md. O texto de uma notificação push é escolhido pelo servidor push, e o Herkos só confia nele quando o UnifiedPush o entrega cifrado (RFC 8291); um conteúdo não cifrado apenas acorda a aplicação para ir buscar o correio ela própria.
A versão web guarda a sua chave no navegador, que é o sítio mais fraco para ela. As aplicações instaladas entregam a sua chave secreta ao armazenamento seguro do sistema operativo (Android Keystore, Gestor de Credenciais do Windows, libsecret, o porta-chaves do iOS/macOS). Um navegador não tem nada disso: a chave fica no armazenamento da origem e passa pelo JavaScript em cada assinatura, ao alcance de qualquer código que corra na página — uma extensão do navegador com acesso a todos os sites, uma falha de XSS na aplicação ou numa dependência, uma implantação adulterada — e de qualquer infostealer que copie o perfil do navegador. Também não existe nenhum momento em que verifique o código uma vez: um binário assinado é verificado na instalação, enquanto uma página web envia código novo em cada visita. Entre na versão web com um assinante remoto (bunker NIP-46, Amber), para que a chave nunca chegue ao navegador, ou trate-a como uma identidade descartável e guarde a sua chave verdadeira numa aplicação instalada.
O correio que passa por um bridge só é tão fiável quanto o bridge. O Herkos verifica que uma mensagem marcada como vinda através de um bridge foi mesmo assinada por um bridge que configurou (ou um dos predefinidos). Não consegue verificar nada sobre o endereço From: tradicional que o bridge transmite.
Os anexos são abertos pelo sistema operativo. O Herkos nunca executa tipos de ficheiro executáveis ou de script e pergunta antes de entregar qualquer outro anexo sem pré-visualização à aplicação predefinida do sistema, mas a aplicação que abre o ficheiro está fora do nosso controlo.

Versões suportadas

As correções de segurança são aplicadas à última versão publicada. Dada a dimensão do projeto, as versões anteriores não são mantidas — atualize antes de comunicar um problema.