Segurança

Itens são instruções e código que rodam nas máquinas dos desenvolvedores com as permissões deles, então a revisão é a fronteira: nada fora de um espaço de trabalho pessoal é lançado até que um moderador, admin do espaço de trabalho ou root que não seja o autor o aprove, e o root aprovar o próprio trabalho fica registrado como override. As sinalizações de risco (hooks, servidores MCP, políticas de permissões, linhas de status, executáveis, scripts de shell, endereços de rede) mostram aos revisores o que ler com atenção; elas nunca bloqueiam. Skills, comandos e agentes são texto que ainda pode mandar uma ferramenta de IA rodar comandos, e nenhuma sinalização pega toda linha desse tipo: o revisor os lê.

• Instalar não roda nada. O rmk grava arquivos e confere o sha256 de cada download com o registro e o rmk.lock; quem roda o que foi gravado é a ferramenta de IA.
• Onde ficam os segredos. O arquivo de configurações guarda o AUTH_SECRET, que assina os cookies de login, e o DATABASE_URL, com a senha do banco de dados; o setup o grava legível só pelo dono. Os tokens de acesso são guardados como hashes, e as senhas, com argon2. Quem ler o arquivo de configurações pode fazer login como qualquer pessoa até que o segredo seja substituído (abaixo).
• Login. Cinco tentativas por minuto por e-mail; com o login em duas etapas, um código de um app depois da senha, que um root pode exigir dos revisores ou de todos (Configurações). Uma senha sozinha não obtém um token do rmk para uma conta com login em duas etapas. Os segredos dele são criptografados com uma chave derivada do AUTH_SECRET, o único segredo: o servidor se recusa a iniciar enquanto o BETTER_AUTH_SECRETS estiver definido.
• Provedores de identidade. Só o root os configura, e cada um é testado antes de poder ser ativado. Os client secrets deles são criptografados com uma chave derivada do AUTH_SECRET, vinculada ao provedor, e nunca mais aparecem. Todo login confere a assinatura do provedor na resposta, que a resposta pertence a esse login e que o e-mail está verificado; um issuer precisa ser https://. O Ronne faz login das pessoas só pelas próprias rotas: a biblioteca de login não responde a mais nada vindo do navegador. O root sempre pode fazer login com senha, e o disable-sso desativa todos os provedores (Bloqueio e provedores com falha).
• O que o Ronne não criptografa. O banco de dados, os itens guardados e os backups são tão seguros quanto o disco e o servidor de banco de dados em que estão: criptografe-os onde você os roda.
• Privado não é criptografado. Um espaço de trabalho privado fica invisível para quem não é membro em todo lugar, mas o root vê todos os espaços de trabalho, e quem roda o servidor pode ler tudo (Público e privado).

O modelo de ameaças percorre cada fronteira: quem pode atacá-la, o que impede cada ameaça e as lacunas conhecidas, com o que vai fechá-las. Para relatar uma vulnerabilidade no próprio Ronne, siga a política de segurança: em privado, nunca em uma issue pública. Só o release mais recente recebe correções (Atualizar).

O Ronne não criptografa os próprios arquivos: a plataforma faz isso melhor, e uma chave dentro do app seria mais um segredo para perder.

• O disco do servidor para o SQLite, os itens armazenados e os backups: LUKS no Linux, FileVault no macOS, ou os volumes criptografados do seu provedor de nuvem.
• A do próprio banco para PostgreSQL e MySQL: a criptografia do serviço gerenciado, ou o disco do servidor de banco.
• Arquivos que saem da máquina: backup --encrypt (AES-256-GCM, com uma chave derivada da sua frase-senha).