Tupi-guarani para “pequeno”

mirim

Um banco de dados SQL embarcado, cifrado em repouso, com exportações seladas pós-quânticas.

Núcleo Rust com #![forbid(unsafe_code)], armazenamento XChaCha20-Poly1305 e exportações ML-KEM-768. A atualização de manutenção 1.1.1 está em preparação, com correções de segurança e guias completos em português e inglês.

ML-KEM-768 · FIPS 203 XChaCha20-Poly1305 em repouso EN / PT-BR documentação AGPL-3.0 / comercial
exportação selada ilustração
db em claro
services
secrets
access_log
export selado
a3f1 9c4e
7bd0 228a
1655 e27f
↑ encapsulamento ML-KEM-768 ↑

chave envelopada por destinatário · quem está de fora não abre

1.1.1 · Preparação da versão

Manutenção com segurança e documentação claras.

As correções preservam os layouts binários existentes. Esta página apresenta a atualização do código-fonte; a versão estável anterior é a 1.1.0 até a conclusão da publicação.

Alterações da 1.1.1
ÁreaAlteração
Arquivos privadosCriação exclusiva de temporários com nomes aleatórios e permissões privadas em Unix; a geração de chaves evita sobrescrever arquivos existentes.
WALComandos grandes demais para o formato do WAL são recusados antes da confirmação, para manter escritas confirmadas recuperáveis.
Bloqueio de escritorBloqueio exclusivo em Unix e Windows pela API segura do Rust; plataformas ou sistemas de arquivos sem suporte recusam a abertura.
DesktopAtualização das dependências gráficas e descrição precisa da permanência do segredo na sessão durante checkpoints.
DocumentaçãoREADME e guia completos em português do Brasil, instruções de backup consistente e limites de segurança e plataforma explícitos.
PublicaçãoPreparação de artefatos e empacotamento para mais sistemas. A disponibilidade efetiva será indicada nos anexos da versão, não pela existência de um PR.

Changelog · Guia completo

Downloads

Escolha uma versão publicada.

A 1.1.1 está em preparação. Para a versão estável anterior, procure a 1.1.0 nos espelhos abaixo. Confira os anexos e as notas de cada versão; não há garantia de binários para todas as plataformas.

Espelhos de publicação
EspelhoDownloads
git.securityops.coVer versões e anexos
git.securityops.com.brVer versões e anexos
GitHubVer versões e anexos
CodebergVer versões e anexos

Verificar antes de instalar

  • sha256sum -c SHA256SUMS --ignore-missing
  • Cada arquivo a instalar precisa aparecer como OK. Um checksum não autentica sua origem.
  • Se houver uma assinatura .mf, use um verificador confiável e uma chave pública previamente autenticada.
  • mirim-sign verify <artifact> <artifact>.mf mirim-release.pub

Escolher a plataforma

  • Selecione sistema, arquitetura e versão pelos anexos reais; pacotes nativos e GUI podem ter disponibilidade diferente.
  • Os binários preparados da versão 1.1.1 para GNU/Linux x86_64 exigem glibc 2.34 ou mais recente para CLI, assinador e AppImage da CLI; a GUI exige glibc 2.39 ou mais recente. Compile o código-fonte em sistemas musl ou com glibc mais antiga.
  • A receita local do GNU Guix é para x86_64-linux e reempacota binários. Sua presença não comprova inclusão no Guix oficial.
  • Instalação para GNU/Linux, BSD, macOS e Windows

O que ele faz

Dados pequenos, mantidos privados e duráveis.

O mirim guarda dados que devem ficar em memória, cifrados em disco, e recuperáveis depois de uma queda: chaves, credenciais, registros de permissão, trilhas de auditoria, configuração.

Cifrado em repouso

Snapshots usam XChaCha20-Poly1305 e cabeçalhos autenticados. A chave vem de Argon2id ou de uma chave bruta de 32 bytes fornecida pela aplicação.

Exportações seladas pós-quânticas

ML-KEM-768 sela uma cópia para um ou vários destinatários. Cada destinatário abre com sua chave secreta. Autenticar a identidade do remetente exige uma assinatura.

Durabilidade à prova de queda

DurableDb sincroniza alterações no WAL antes de confirmar sucesso. O harness SIGKILL verifica quedas de processo; cortes físicos de energia também dependem do sistema de arquivos e do dispositivo.

SQL com índice

CREATE, INSERT, SELECT, UPDATE e DELETE com parâmetros, ORDER BY, LIMIT e COUNT(*). PRIMARY KEY e UNIQUE têm índices de igualdade; os dados ficam na RAM.

Rotação, e um só escritor

rotate_secret substitui o ciphertext atual e revincula o WAL. Sessões usam bloqueio exclusivo em Unix e Windows; a abertura falha se o sistema não oferecer bloqueio.

Embarque a partir de C

A API C tem contrato de ponteiros e tratamento de erros documentados. O harness usa ASan no Rust e ASan/UBSan no C; ponteiros inválidos continuam sendo responsabilidade do chamador.

Dialeto

Toda a superfície SQL, em uma tela.

Dois tipos, nenhuma coerção, nenhuma surpresa. O que segue não é um resumo da linguagem. É a linguagem.

cola de bolso
-- Comentarios de linha, e /* de bloco */.

CREATE TABLE users (
  id    INTEGER PRIMARY KEY,  -- unico, indexado
  email TEXT UNIQUE,          -- aceita varios NULL
  age   INTEGER
);

-- Uma linha por INSERT. Colunas omitidas viram NULL.
INSERT INTO users VALUES (1, 'ana@x.io', 30);
INSERT INTO users (id, email) VALUES (2, 'bia@x.io');

SELECT email, age FROM users
  WHERE age >= 18 AND email IS NOT NULL;
SELECT * FROM users ORDER BY age DESC;
SELECT id FROM users ORDER BY id LIMIT 10 OFFSET 20;
SELECT COUNT(*) FROM users WHERE age IS NULL;

-- Atomico por instrucao: uma violacao nao muda nada.
UPDATE users SET age = 31 WHERE id = 1;
DELETE FROM users WHERE id = 2;

+ Existe na linguagem

  • INTEGER (i64) e TEXT (UTF-8). Nada além disso.
  • PRIMARY KEY e UNIQUE de coluna única, cada um com um índice de igualdade O(1).
  • WHERE com comparações encadeadas por AND e IS [NOT] NULL.
  • ORDER BY, multichave e estável. NULL vem primeiro no ASC, por último no DESC.
  • LIMIT, OFFSET e COUNT(*).
  • Parâmetros ? vinculados. Valor vinculado é dado, nunca SQL.
  • Comentários de linha e de bloco.

- Ausente de propósito

  • Joins e subconsultas.
  • GROUP BY, OR, e toda agregação exceto COUNT(*).
  • Transações entre instruções. Cada instrução é atômica por si só.
  • Índices secundários além de PRIMARY KEY / UNIQUE, e planejador de consultas.
  • Coerção de tipos. REAL, BLOB, DATE, BOOLEAN.
  • FOREIGN KEY, NOT NULL, DEFAULT, CHECK, chaves compostas.
  • Dados maiores que a RAM. A durabilidade é real, o armazenamento fora de memória não é.

Entrada não confiável entra como parâmetro ? vinculado, nunca como texto SQL. Passo a passo completo no guia. Cinco esquemas prontos em samples/.

Adequação

Veja se os limites atendem à sua aplicação.

Configurações, segredos locais e pequenos conjuntos de estado podem se beneficiar de armazenamento criptografado. Avalie tamanho, consultas, concorrência e recuperação antes de escolher.

Limites e avaliação
AspectoComportamento
Dados pequenosO banco inteiro e seus índices precisam caber na RAM.
SQLTabelas, filtros, ordenação e parâmetros; sem joins ou transações entre comandos.
ÍndicesIgualdade em PRIMARY KEY e UNIQUE usa buscas hash de custo esperado constante; outros predicados percorrem linhas.
PersistênciaDurableDb usa snapshot + WAL. Db só persiste quando a aplicação salva explicitamente.
AvaliaçãoExecute cargo bench --locked --bench core no seu hardware e teste o comportamento no sistema de destino.

Criptografia

Primitivas com nome, e com o padrão delas.

O mirim combina primitivas das dependências RustCrypto em formatos próprios. A suíte inclui vetores criptográficos fixados; isso não equivale a uma certificação independente.

Inventário criptográfico
PapelPrimitivaParâmetrosPadrão
Encapsulamento de chaveML-KEM-768texto cifrado de 1088 bytes, rejeição implícitaFIPS 203
AssinaturasML-DSA-87assinatura de 4627 bytes, feature signFIPS 204
AEADXChaCha20-Poly1305nonce de 24 bytes, cabeçalho como dado associadoRFC 8439 e extensão
KDF de senhaArgon2id64 MiB, 3 passagens, 4 pistasRFC 9106
Derivação de chaveHKDF-SHA256string info com separação de domínio por formatoRFC 5869
HashSHA-256identidade do snapshot, digest do alvo do manifestoFIPS 180-4
AleatoriedadeCSPRNG do sistemavia getrandomplataforma

Falhas de autenticação retornam Error::Crypto. Erros públicos de estrutura, versão e tipo de segredo podem ser diferentes. Consulte SECURITY.md para o modelo completo.

Em disco

Formatos versionados e documentados.

Os layouts binários permanecem compatíveis nesta atualização de manutenção. O guia reúne a referência de tamanhos, campos e derivação de chaves.

Formatos de arquivo
ArtefatoMagicVersãoLayout
VaultMIRIM1\0\0v1 Cabeçalho de 50 bytes (magic, versão, id do KDF, salt, nonce), depois o texto cifrado AEAD do snapshot. Extensão .mrm.
Exportação selada, um destinatárioMIRIMSL1v1 Texto cifrado ML-KEM-768 de 1088 bytes, nonce de 24 bytes, depois o payload AEAD.
Exportação selada, vários destinatáriosMIRIMSL1v2 Payload cifrado uma vez sob uma chave aleatória, que é envelopada por destinatário: um texto cifrado KEM de 1088 bytes e uma chave envelopada de 48 bytes para cada. Qualquer um deles abre.
Write-ahead logMIRIMWL1v1 Cabeçalho de 41 bytes carregando o SHA-256 do vault que ele estende, depois registros AEAD com números de sequência consecutivos e autenticados. A recuperação pode truncar um registro final incompleto ou inválido.
Manifesto assinadoMIRIMMF1v1 4677 bytes: cabeçalho, tipo do alvo, contador, o SHA-256 do alvo, e uma assinatura ML-DSA-87 sobre os 50 primeiros. Extensão .mf.
Arquivo de confiançaMIRIMTS1v1 49 bytes: o maior contador aceito e o hash do último alvo aceito. Esta é a raiz de confiança local para rejeição de rollback.

Cabeçalhos de criptografia são autenticados, mas o estado local de confiança não é um ciphertext. Recuperação pode descartar uma cauda de WAL danificada ou um WAL de outro snapshot; isso não impede regressão maliciosa. Referência binária.

Garantia

Verificado mais de uma vez.

Métodos complementares verificam diferentes propriedades. A presença de um teste no repositório não comprova sua execução para uma versão ou plataforma.

  • +Modelo diferencial. Compara o avaliador SQL com um modelo independente em sequências geradas.
  • +Propriedades. Verifica ida e volta, replay, checkpoint e restrições de unicidade.
  • +Fuzzing. Cinco alvos cobrem wire, SQL, exportações, manifestos e WAL; uma execução finita não é exaustiva.
  • +FFI. Harness de conformidade C com sanitizadores e dependências verificadas separadamente.
  • +Recuperação. Harness SIGKILL para quedas de processo; não simula todos os cortes físicos de energia.
  • +Dependências. cargo audit, cargo deny e SBOM; GUI e FFI têm lockfiles próprios.
  • +Resultados. Consulte as notas da versão para saber quais verificações e plataformas realmente foram executadas.
secrets.mrm
$ mirim secrets.mrm
creating new vault: secrets.mrm
new passphrase:
repeat passphrase:
mirim 1.1.1 — .help for commands
mirim> .read samples/secrets_vault.sql
ok: ran 30 statement(s) from samples/secrets_vault.sql
mirim> SELECT COUNT(*) FROM access_log WHERE allowed = 0;
count(*)
--------
4
mirim> SELECT actor, ts FROM access_log
   ...> WHERE allowed = 0 ORDER BY ts DESC LIMIT 3;
actor        | ts
-------------------------
unknown-host | 1717301000
ex-employee  | 1717300800
svc-web      | 1717300500
mirim> 

Modelo de segurança

Conheça as proteções e seus limites.

Escolha sua implantação considerando memória, armazenamento, recuperação e confiança nas chaves.

Proteções

  • Armazenamento criptografado. Snapshots e registros do WAL protegem seu conteúdo com criptografia autenticada; metadados permanecem visíveis.
  • Frase-senha. Argon2id aumenta o custo de tentativas. Uma frase-senha fraca continua vulnerável a adivinhação.
  • Exportações. ML-KEM-768 é projetado para resistir a ataques quânticos conhecidos, sem garantia sobre toda criptoanálise futura.
  • Entradas malformadas. Os decodificadores verificam a estrutura e os comprimentos; isso não estabelece um limite total de memória.

Limites

  • Host comprometido. Memória aberta, swap e core dumps podem expor dados e segredos.
  • Regressão. Um invasor pode substituir o banco por cópias antigas ou truncar o WAL. Assinaturas exigem verificação explícita e estado de confiança protegido.
  • Metadados. Tamanho, existência, horários e padrões de acesso são visíveis, assim como o tamanho dos registros do WAL.
  • Concorrência. Sessões adquirem bloqueio exclusivo em Unix e Windows. vault::save direto e aliases de caminho exigem coordenação; plataformas sem bloqueio recusam a abertura.
  • Rotação. Backups antigos e blocos residuais não são apagados. Não há recuperação de segredo perdido.

Tempo constante depende principalmente das implementações criptográficas. Não há certificação independente de tempo constante do binário completo. SECURITY.md · Guia operacional

Novo · desktop

Uma interface que recusa por padrão.

O mirim-gui é um jeito pequeno e clicável de abrir um vault, feito sobre eframe e egui. Vive no próprio crate, para o núcleo continuar pequeno e sem unsafe.

  • +Local. A aplicação trabalha com bancos locais e executa consultas pelo mesmo núcleo.
  • +Escritas explícitas. Allow writes habilita comandos que alteram dados. A abertura pode criar ou reparar o WAL; não é leitura forense.
  • +Segredo na sessão. Os campos de login são limpos, mas DurableDb mantém uma cópia para checkpoints até encerrar.
  • +Durabilidade. Alterações confirmadas são sincronizadas; sessões adquirem bloqueio exclusivo em Unix e Windows.
  • +Controles. Ctrl+Enter executa SQL; há controles de checkpoint, frase-senha e uma janela Licenses com avisos de fontes disponíveis offline.
mirim-gui
# Compilar a partir do checkout
$ cargo build --release --locked \
  --manifest-path gui/Cargo.toml
$ ./gui/target/release/mirim-gui

Confira os anexos para binários prontos.

Licença

Licença dupla. Escolha a que serve.

Aberto por padrão sob AGPL-3.0-only. Existe uma licença comercial para os casos em que os termos da AGPL não servem.

AGPL-3.0-only código aberto

Os arquivos marcados com a opção pública podem ser usados sob AGPL-3.0-only, conforme seus termos. Arquivos MIT e dependências conservam suas próprias licenças.

Comercial sob consulta

A opção comercial exige contrato separado e assinado pelo titular dos direitos aplicáveis. LICENSE-COMMERCIAL é um aviso de consulta, não uma concessão pública. Contato: sac@securityops.co.

Termos completos em LICENSE e LICENSING.pt-BR.md. Copyright (c) 2026 Cristian Cezar Moisés.

1.1.1 · Em preparação

Leia o código e os guias.

A atualização 1.1.1 está em preparação. Consulte as notas e os anexos publicados para escolher uma versão; os guias explicam instalação, backup, API e verificação.