Política de segurança

O Herkos lida com chaves privadas e mensagens criptografadas, por isso levamos a sério os relatos de segurança e preferimos saber de um problema cedo do que tarde.

Como relatar uma vulnerabilidade

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

Relate-o de forma privada pelo relato privado de vulnerabilidades do GitHub, ou por e-mail para security@herkos.email.

Coisas úteis para incluir: qual é o problema, como reproduzi-lo, em qual plataforma e versão você testou e o que um atacante poderia conseguir. Uma prova de conceito ajuda muito.

Nunca inclua num relato sua própria nsec, sua chave secreta ou o segredo do seu bunker.

Procuramos confirmar o recebimento dos relatos em poucos dias. Como o Herkos é um projeto pequeno, por favor, dê um prazo razoável para a correção antes de divulgar publicamente. Teremos prazer em dar crédito a você no aviso de segurança, a menos que prefira o contrário.

O que está no escopo

O próprio aplicativo Herkos: o tratamento e o armazenamento de chaves, a criptografia e descriptografia de mensagens (incluindo as verificações de remetente do NIP-59 e o isolamento do Cco em local_packages/nostr_mail), o bloqueio do aplicativo, a comunicação com relays e bridges, o tratamento de anexos e o processo de compilação e publicação.

O que está fora do escopo

O próprio protocolo Nostr e seus NIPs — relate esses problemas na origem.
Relays, bridges e servidores Blossom operados por terceiros. O Herkos vem com padrões, mas não os opera; relate os problemas aos seus operadores.
O projeto original Nostr Mail Client, a menos que o problema seja específico das mudanças feitas no Herkos.
A falta de um reforço que já documentamos como limitação conhecida (ver abaixo).

Limitações conhecidas, ditas com clareza

Estas são escolhas de projeto, não vulnerabilidades. Preferimos deixá-las por escrito a alguém descobri-las do pior jeito:

O e-mail para endereços tradicionais não é criptografado de ponta a ponta. As mensagens entre usuários do Nostr usam gift wrap NIP-17 e são criptografadas de ponta a ponta. Quando você escreve para um endereço de e-mail comum, um bridge converte a mensagem e consegue lê-la.
O bloqueio do aplicativo (PIN e biometria) é uma barreira de conveniência, não criptografia em repouso. Ele detém quem pega um dispositivo desbloqueado; não protege contra um atacante com acesso total ao dispositivo ou ao seu armazenamento.
No Windows, não é possível exigir apenas a autenticação biométrica. O Windows Hello não permite escolher o método, então o PIN do sistema sempre continua disponível como alternativa.
Perder sua chave significa perder a conta. Não há recuperação, de propósito.
Os metadados não ficam totalmente ocultos. Os relays podem observar padrões de conexão, e todo relay vê seu endereço IP, mesmo quando não consegue ler o conteúdo das mensagens. O que o Herkos não entrega (desde 30-09-2026) é quem está escrevendo para quem quando um relay pede autenticação NIP-42:
Descobrir para onde entregar. As listas de relays e de servidores Blossom de um destinatário são pedidas por uma conexão separada que nunca identifica você, 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 exibidos para qualquer outra pessoa (kind 0), e a lista de relays do DVM de agendamento quando você agenda ou cancela um e-mail, são pedidos da mesma forma: primeiro de modo anônimo e, se um relay insistir, com a chave temporária descrita abaixo, nunca com a sua (desde 01-10-2026; antes, um relay que pedia autenticação recebia sua chave e podia saber de quem era o perfil que você estava vendo). Apenas o seu próprio perfil continua sendo lido como você.
Entregar. Os gift wraps vão para os relays de DM do destinatário, por essa mesma conexão separada. Se algum deles exigir autenticação, o Herkos responde com uma chave criada para esse fim e mantida só na memória, nunca com a sua; cada conta no dispositivo tem a sua. O relay ainda consegue ver que o mesmo dispositivo (mesmo IP, mesma chave temporária) enviou vários envelopes durante uma sessão.
E-mails grandes. A cópia criptografada de um e-mail com mais de 32 KB é enviada a servidores Blossom, inclusive 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 o recebe de forma anônima e, se insistir numa autorização, uma assinada com a mesma chave temporária de antes (desde 01-10-2026; antes, todos os servidores recebiam sua chave). Um servidor que só aceita chaves conhecidas o recusa, e a cópia fica nos outros servidores.
Seus próprios dados. A sincronização da sua caixa postal, etiquetas, configurações e rascunhos se autentica, quando um relay pede, como a conta a que os dados pertencem, mesmo durante uma troca de conta. Nos seus próprios relays isso não lhes diz nada que eles já não soubessem: os pedidos citam sua chave de qualquer forma. Suas próprias listas de relays e de servidores Blossom são públicas e são pedidas sem identificar você, assim como os relays citados num link de e-mail.
O estado de leitura e as pastas são metadados públicos (por enquanto). Marcar um e-mail como lido, favorito, arquivado ou movido publica um evento de etiqueta NIP-32 não criptografado, ligado à sua chave pública, inclusive os nomes das pastas personalizadas. Um remetente que conhece o identificador de um e-mail que te enviou consegue saber quando você agiu sobre ele. Criptografar essas etiquetas está nos planos; até lá, trate os nomes das pastas como públicos.
As notificações push e o envio agendado usam serviços de terceiros. O servidor push (api.nmail.li por padrão) fica sabendo sua chave pública, um token push e quando você recebe e-mail; o DVM de agendamento fica sabendo sua chave pública e as mensagens já criptografadas que ele precisa publicar. Os dois são opcionais e estão documentados em PRIVACY.md. O texto de uma notificação push é escolhido pelo servidor push, e o Herkos só confia nele quando o UnifiedPush o entrega criptografado (RFC 8291); um conteúdo não criptografado apenas acorda o aplicativo para que ele mesmo busque o e-mail.
A versão web guarda sua chave no navegador, que é o lugar mais fraco para ela. Os aplicativos instalados entregam sua chave secreta ao armazenamento seguro do sistema operacional (Android Keystore, Gerenciador de Credenciais do Windows, libsecret, Chaveiro do iOS/macOS). Um navegador não tem nada disso: a chave fica no armazenamento da origem e passa pelo JavaScript a cada assinatura, ao alcance de qualquer código que rode na página — uma extensão do navegador com acesso a todos os sites, uma falha de XSS no aplicativo ou numa dependência, uma implantação adulterada — e de qualquer infostealer que copie o perfil do navegador. Também não existe um momento em que você verifica o código uma vez: um binário assinado é verificado na instalação, enquanto uma página web entrega código novo a cada visita. Entre na versão web com um assinador remoto (bunker NIP-46, Amber), para que a chave nunca chegue ao navegador, ou trate-a como uma identidade descartável e mantenha sua chave real num aplicativo instalado.
O e-mail que passa por um bridge só é tão confiável quanto o bridge. O Herkos verifica se uma mensagem marcada como vinda por um bridge foi mesmo assinada por um bridge que você configurou (ou por um dos padrões). Ele não consegue verificar nada sobre o endereço From: tradicional que o bridge repassa.
Os anexos são abertos pelo sistema operacional. O Herkos nunca executa tipos de arquivo executáveis ou de script e pergunta antes de entregar qualquer outro anexo sem pré-visualização ao aplicativo padrão do sistema, mas o aplicativo que abre o arquivo está fora do nosso controle.

Versões com suporte

As correções de segurança são aplicadas à versão publicada mais recente. Dado o tamanho do projeto, as versões antigas não são mantidas — por favor, atualize antes de relatar.