Tupi-guarani para “pequeno”

mirim

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

3.789 linhas de Rust seguro sob #![forbid(unsafe_code)]. Nenhum RSA e nenhuma curva elíptica em qualquer arquivo que ele escreve, então não sobra nada para um futuro computador quântico desfazer depois.

ML-KEM-768 · FIPS 203 XChaCha20-Poly1305 em repouso binário de 477 KiB AGPL-3.0 / comercial
canal seguro estabelecido
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

Versão 1.1.0 · 15 de julho de 2026

Ergonomia de consulta, e pacotes que você instala.

Nenhum formato em disco mudou. Todo vault, exportação selada, log e manifesto da 1.0.0 abre sem alteração na 1.1.0, o SQL novo é só de consulta, e a pilha criptográfica não se moveu. Esta versão cuida das partes que você toca: moldar resultados, carregar um arquivo, e obter um binário sem compilador.

O que a 1.1.0 adiciona
ÁreaMudança
SQL ORDER BY coluna [ASC|DESC] (multichave, estável), LIMIT n [OFFSET m], COUNT(*), e comentários de linha -- e de bloco /* */. Todas são palavras contextuais, então uma coluna chamada order, count ou limit continua sendo aceita sem aspas.
CLI .read <caminho> executa todas as instruções de um arquivo .sql. .schema imprime os CREATE TABLE reconstruídos.
Biblioteca Db::execute_script e mirim::split_statements carregam um arquivo com várias instruções, dividindo com consciência de strings e comentários. Db::schema_sql e Db::table_columns fazem introspecção do esquema.
Exemplos Cinco bancos realistas em samples/: um cofre de segredos, um placar de CTF, uma frota de dispositivos, uma trilha de auditoria e um gerenciador de senhas. A CI carrega os cinco a cada push. cargo run --example gen_samples ./out materializa vaults cifrados e uma exportação selada.
Desktop mirim-gui, uma interface offline pequena sobre eframe/egui. Abre pelo motor cifrado e durável, e fica somente leitura até você permitir escrita.
Empacotamento .deb, .rpm e um tarball Linux, um manifesto SHA256SUMS, e uma assinatura ML-DSA-87 destacada para cada artefato.
Documentação Um guia para iniciantes, e uma comparação com fontes contra SQLite, SQLCipher, DuckDB, libSQL/Turso, redb e sled.
Tamanho A CLI stripped saiu de 436 KiB para 477 KiB. O crescimento são os recursos de consulta. A pilha criptográfica está inalterada.

Histórico completo no changelog, no formato Keep a Changelog, com versionamento semântico.

Download

mirim 1.1.0 para Linux x86-64.

Todo artefato está listado no SHA256SUMS e carrega uma assinatura ML-DSA-87 destacada, produzida pela própria ferramenta de assinatura do mirim. Os builds de release são reprodutíveis: o job compila duas vezes e se recusa a publicar se os dois digests não baterem.

Artefatos assinados · git.securityops.co
PlataformaArquivoTamanhoInstale com
Debian, Ubuntu mirim_1.1.0-1_amd64.deb 277 KiB sudo apt install ./mirim_1.1.0-1_amd64.deb
Fedora, RHEL, openSUSE mirim-1.1.0-1.x86_64.rpm 300 KiB sudo dnf install ./mirim-1.1.0-1.x86_64.rpm
Qualquer Linux mirim-1.1.0-x86_64-linux.tar.gz 4,7 MiB tar xzf mirim-1.1.0-x86_64-linux.tar.gz
CLI, ferramenta de assinatura, GUI, os cinco exemplos e a documentação.
Só a interface gráfica mirim-gui-1.1.0-x86_64-linux 9,5 MiB chmod +x mirim-gui-1.1.0-x86_64-linux
Código-fonte v1.1.0.tar.gz fonte cargo build --release · Rust 1.96.0, fixado em rust-toolchain.toml
Checksums SHA256SUMS 844 B sha256sum -c SHA256SUMS --ignore-missing
Chave de assinatura mirim-release.pub 2,5 KiB Chave pública ML-DSA-87. Também versionada em keys/ no repositório.
verifique, depois instale
# 1. checksums
$ sha256sum -c SHA256SUMS --ignore-missing
mirim_1.1.0-1_amd64.deb: OK

# 2. assinatura pos-quantica (ML-DSA-87)
$ mirim-sign verify mirim_1.1.0-1_amd64.deb \
      mirim_1.1.0-1_amd64.deb.mf mirim-release.pub
ok

# 3. instale
$ sudo apt install ./mirim_1.1.0-1_amd64.deb
$ mirim notas.mrm
ou compile voce mesmo
# Guix
$ guix shell rust rust:cargo gcc-toolchain -- \
      cargo build --release

# Debian / Ubuntu
$ sudo apt install curl build-essential
$ curl --proto '=https' --tlsv1.2 -sSf \
      https://sh.rustup.rs | sh
$ cargo build --release

# com a ferramenta de assinatura, ou so a biblioteca
$ cargo build --release --features cli,sign
$ cargo build --release --no-default-features
Digests SHA-256 de cada artefato da 1.1.0
c7be647a9bc4251c985db233cc79e934fa3d21226b6bc68f336df4c44d1737df  mirim-1.1.0-1.x86_64.rpm
06b1968f8f82fff743efc64b0724793d13a2913e5aa1ff1ad2feb19833dc7175  mirim-1.1.0-1.x86_64.rpm.mf
ec12a859015d57a4615f04aea673f67ab6a44292889d70081a2b5623f6ba9ca7  mirim-1.1.0-x86_64-linux.tar.gz
1cf660b778952cfce737910cb982d86ca970871415ce8aa5ac401c9070aaff8b  mirim-1.1.0-x86_64-linux.tar.gz.mf
4415a703c6a4616d13fc6a39b7d4c5e003c6d1afdc98e05f5df0a7b44db10a89  mirim-gui-1.1.0-x86_64-linux
cacc3174fbef141fcb1133419611c4d51216a436a860eb8f38fa35608d738180  mirim-gui-1.1.0-x86_64-linux.mf
9dc874c918a8d6811ca4d500df1912044503c4e1e1650c1862aabab501559648  mirim-release.pub
73232994a8106337ed30d83bab1fec36cd3415d1a5210fffbed00a907ad93b35  mirim_1.1.0-1_amd64.deb
716e2d940e52102664f3eb5d107bebb1e58d9e184f5946703e3c261f77cb5fad  mirim_1.1.0-1_amd64.deb.mf

macOS e Windows: compile a partir do código. O procedimento é cargo build --release com a toolchain fixada, e nada além disso.
Espelhos: os mesmos bytes estão no Codeberg e no GitHub. O SHA256SUMS é idêntico nos três, então verifique contra o que você confia e baixe de onde for rápido.

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

Todo vault é XChaCha20-Poly1305 sobre o snapshot. A chave vem do Argon2id (RFC 9106, 64 MiB, 3 passagens) ou de uma chave de 32 bytes que você guarda. O cabeçalho é autenticado como dado associado. Os saves são atômicos.

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

Sele um banco para um destinatário ou para vários com ML-KEM-768 (FIPS 203). Cada destinatário abre com a própria chave. Quem está de fora não abre de jeito nenhum.

Durabilidade à prova de queda

Um write-ahead log cifrado, com fsync antes de a instrução ser confirmada. Um ok sobrevive a kill -9 e à falta de energia, verificado por um harness SIGKILL de 60 iterações, com zero commits confirmados perdidos.

SQL com índice

CREATE, INSERT, SELECT, UPDATE, DELETE com parâmetros vinculados, além de ORDER BY, LIMIT e COUNT(*). Colunas PRIMARY KEY e UNIQUE são indexadas, então checagem de duplicata e busca pontual são O(1).

Rotação, e um só escritor

rotate_secret recifra o vault e revincula o log sob um novo segredo, em um passo atômico. No Unix, um flock consultivo faz o segundo processo falhar com Error::Locked em vez de corromper o log.

Embarque a partir de C

Uma ABI C (mirim-ffi) atrás de um único header, com todo panic contido na fronteira. É a única superfície unsafe deliberada, e roda sob AddressSanitizer e UBSan dos dois lados.

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 */ (1.1.0).

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, e qualquer 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/.

Medido

Todo número aqui é reproduzível.

Sem adjetivos. Medianas do Criterion em x86-64, em memória, contra o SQLite via rusqlite com a biblioteca embutida. Onde o mirim é mais lento, está escrito.

13,4ms
Inserção em massa, 10 mil linhas com PRIMARY KEY
2,5× mais rápido que o SQLite (33,6 ms)
1,42µs
SELECT pontual por chave primária, 10 mil linhas
2,3× mais lento que o SQLite (0,62 µs)
578µs
Commit durável, uma instrução, com fsync
limitado por fsync, cifrar não custa nada visível
477KiB
CLI stripped, pilha criptográfica inclusa
opt-level=z, LTO, Linux x86-64
cargo bench --bench core
Carga de trabalhomirim 1.1.0SQLiteLeitura
commit durável, 1 instrução, com fsync 578 µs782 µs SQLite em modo WAL com synchronous=FULL. Os dois são limitados por fsync, então a cifragem por registro do mirim fica invisível aqui.
inserção em massa com PRIMARY KEY, 1 mil linhas 1,23 ms3,40 ms A checagem de duplicata de cada insert é uma sondagem O(1) no índice, não uma varredura de linhas.
inserção em massa com PRIMARY KEY, 10 mil linhas 13,4 ms33,6 ms A construção por append mais hash do mirim sai na frente de uma árvore B nesta carga em memória.
SELECT pontual por chave primária, 10 mil linhas 1,42 µs0,62 µs A árvore B por rowid do SQLite ganha. O mirim fica a 2,3× dela, contra 33× mais lento quando a busca ainda era varredura.
checkpoint, 1 mil linhas 4,18 msnão há Dobra o log em um snapshot novo. Não há operação comensurável no SQLite.

rustc 1.96.0, 30 amostras em 3 s (grupos duráveis com 20). O armazenamento era virtualizado, então os números de fsync em especial variam em discos reais. Igualdade em coluna não indexada ainda varre O(linhas), e o DELETE reconstrói o índice da tabela afetada depois: assintoticamente igual, uma constante modesta.

Comparação

Onde o mirim realmente difere.

Não é em poder de SQL. SQLite, DuckDB e libSQL passam longe do mirim nisso, por projeto. A diferença é a postura de segurança: o mirim é o único aqui que deriva a chave em repouso com um KDF memory-hard por padrão, e o único que oferece selagem e assinatura pós-quânticas.

Bancos embarcados, lado a lado
Dimensão mirim 1.1 SQLite SQLCipher DuckDB 1.4+ libSQL / Turso redb / sled
Tipo SQL embarcadoSQL embarcadoSQL embarcado, cifradoSQL analítico embarcadoSQL embarcado, fork do SQLiteChave-valor embarcado
Implementação Rust seguro, forbid(unsafe_code)CC, SQLite mais extensãoC++C e RustRust
Cifrado em repouso Sim, padrão e único modoNão, o SEE é add-on pagoSimSim, desde a 1.4 (set. 2025)SimNão
Cifra em repouso XChaCha20-Poly1305, snapshot inteironenhumaAES-256-CBC + HMAC-SHA512, por páginaAES-256-GCM ou CTR, por páginaAEGIS, AES-GCM ou ChaCha20-Poly1305, por páginanenhuma
KDF de senha Argon2id, memory-hard (64 MiB, t=3)nenhumPBKDF2-HMAC-SHA512, 256 mil iteraçõeschave cruachave cruanenhum
Pós-quântico Exportações seladas ML-KEM-768, manifestos assinados ML-DSA-87NãoNãoNãoNãoNão
RSA ou curva elíptica nos formatos Nenhumn/an/an/an/an/a
Durabilidade em queda WAL, fsync antes do ack, testado com SIGKILLWAL ou journalo do SQLiteWALWALSim, log ou copy-on-write
Superfície SQL Subconjunto mínimoSQL completoSQL completoSQL analítico ricoSQL completoNenhuma, API chave-valor
Dados maiores que a RAM NãoSimSimSimSimSim
Concorrência Um escritor, um processoMultileitor, um escritora do SQLiteUm processoMúltipla, com replicaçãoMVCC (redb)
Tamanho 477 KiB de CLI, cripto inclusamenos de 900 KiB de bibliotecaSQLite mais criptodezenas de MBvários MBpequeno
Build reprodutível, SBOM, release assinada Os trêsnãonãonãonãonão
Licença AGPL-3.0-only ou comercialDomínio públicoEstilo BSDMITMITMIT / Apache-2.0

+ Escolha o mirim quando

  • O conjunto de dados é pequeno, sensível e durável: credenciais, uma trilha de auditoria, um cofre pessoal, um inventário de frota.
  • Você quer a chave em repouso derivada de uma senha com um KDF memory-hard, por padrão e não por configuração.
  • Você precisa de exportações seladas pós-quânticas, ou de artefatos assinados com cripto pós-quântica.
  • Você quer ler o motor inteiro e reproduzir o binário byte a byte.

- Escolha outra coisa quando

  • Você precisa de SQL de verdade, dados fora de memória ou suporte amplo a linguagens: SQLite ou libSQL, com SQLCipher ou a cifragem do libSQL para proteção em repouso. Nenhum dos dois é pós-quântico.
  • Sua carga é analítica ou colunar sobre dados maiores: DuckDB.
  • Você não precisa de SQL: redb ou sled, um chave-valor embarcado rápido.
  • Seus dados passam do tamanho da memória. O conjunto de trabalho do mirim vive na RAM, e isso não é um defeito para consertar depois.

Os números são medidos aqui, citados da documentação de cada fornecedor, ou fatos simples do formato em disco. A análise completa, com todas as fontes, está em docs/comparison.md.

Criptografia

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

Nenhuma cifra caseira, e nenhum protocolo inventado internamente. Cada primitiva é uma implementação revisada, exercitada contra os vetores de teste oficiais.

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

A decapsulação do ML-KEM é por rejeição implícita, então chave errada e arquivo adulterado são indistinguíveis: os dois viram um único Error::Crypto sem detalhe. A suíte fixa vetores oficiais, todos extraídos por máquina das fontes: AEAD da RFC 8439 §2.8.2, KATs do NIST ACVP FIPS 203 (keyGen e encap/decap, incluindo um caso de rejeição implícita com texto cifrado modificado), KATs do NIST ACVP FIPS 204 (keyGen, sigGen determinístico com contexto, e sigVer com negativos de assinatura modificada), e o vetor Argon2id da RFC 9106 §5.3.

Em disco

Seis formatos. Todos congelados desde a 1.0.0.

Estes layouts continuarão legíveis. Uma mudança que quebrasse formato seria uma nova versão maior, e a 1.1.0 não encostou em um único byte de nenhum deles.

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. Um registro final partido, o único dano que uma queda honesta produz, é truncado na abertura.
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.

Todo cabeçalho é vinculado como dado associado AEAD, então um bit invertido em qualquer lugar falha na autenticação e não existe decodificação parcial de arquivo adulterado. Chaveamento e AAD vinculam cada registro do log aos bytes exatos do snapshot que ele estende, então replay entre vaults, reordenação e emenda falham fechado. Os layouts byte a byte estão no README.

Garantia

Verificado mais de uma vez.

O mesmo comportamento é verificado por métodos independentes, então um bug precisa escapar de todos eles.

  • +Modelo diferencial. O motor contra um oráculo independente, sobre sequências de instruções geradas.
  • +Testes de propriedade. Invariantes de ida e volta, de replay e de checkpoint sob proptest.
  • +Cinco alvos de fuzz. Decodificação do wire, abertura de exportação selada (v1 e v2), verificação de manifesto, texto SQL, e replay do WAL. O decodificador do wire está em 72% de cobertura de linha com o corpus atual.
  • +Miri nas suítes de lógica. ASan e UBSan na FFI em C, com os dois lados instrumentados.
  • +Queda de energia. Um harness SIGKILL de 60 iterações. Zero commits confirmados perdidos.
  • +Builds reprodutíveis. Duas compilações, idênticas bit a bit, ou a release não sai.
  • +Cadeia de suprimentos. Um SBOM CycloneDX 1.5 versionado, com a CI falhando em qualquer desvio, mais cargo audit e cargo deny a cada push.
secrets.mrm
$ mirim secrets.mrm
creating new vault: secrets.mrm
new passphrase:
repeat passphrase:
mirim 1.1.0 — .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 ameaças

Os não-objetivos são a metade que importa.

Uma ferramenta que só diz o que defende está vendendo alguma coisa. Aqui está a forma do modelo; o SECURITY.md traz o texto completo, e vale ler antes de depender de qualquer coisa disto.

+ O que o mirim protege

  • Roubo de disco e vazamento de backup. Quem pega o .mrm sem a senha aprende o tamanho do arquivo, e que ele é um vault do mirim. Nada além disso.
  • Adulteração, cabeçalho incluído. O cabeçalho de 50 bytes é dado associado. Qualquer bit invertido falha na autenticação, e não há decodificação de melhor esforço.
  • Força bruta de senha, dentro da qualidade da senha. Argon2id com 64 MiB e 3 passagens eleva o custo por tentativa. Não salva uma senha fraca.
  • Colher agora, decifrar depois. Não existe RSA, curva elíptica ou Diffie-Hellman clássico em nenhum dos formatos.
  • Oráculos de falha de decifragem. Chave errada, destinatário errado e dado adulterado viram o mesmo erro, sem detalhe.
  • Arquivos hostis. O decodificador confere os limites de todo comprimento antes de alocar, e falha fechado em qualquer violação estrutural.

- Contra o que ele não protege

  • Um host comprometido. Malware, um root hostil ou um depurador anexado com o vault aberto vê texto em claro e captura a senha. Swap e core dumps não são mitigados.
  • Rollback, só em parte. O arquivo de confiança torna o rollback detectável, desde que o estado local esteja íntegro. Quem consegue reescrever esse arquivo consegue zerá-lo.
  • Truncação do log. Apagar o log, ou adulterar o registro final, equivale a voltar ao último checkpoint mais um prefixo.
  • Metadados do log. Contagem e tamanho dos registros são visíveis em disco e revelam o número de mutações e o tamanho aproximado de cada uma. Não há padding.
  • Resíduo de texto cifrado após rotação. A rotação substitui os arquivos. Ela não destrói o texto cifrado antigo em blocos livres, journals ou backups.
  • Metadados em geral. Tamanho, existência, horário de modificação e padrão de acesso do arquivo são visíveis.
  • Trava fora do Unix. O flock consultivo é um caminho Unix. Fora dele, um escritor só é garantido por você.

Postura de tempo constante, revisada ponto a ponto e registrada no SECURITY.md: nenhum desvio, comparação ou índice de tabela pertencente ao mirim depende de material secreto. Dois sinais de tempo deliberados permanecem e estão documentados, ambos sem oráculo controlável por atacante. Reporte uma vulnerabilidade pelo contato no SECURITY.md.

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.

  • +Offline. Não existe código de rede em lugar nenhum da interface. Ela toca o arquivo de vault local que você abre, e nada mais.
  • +Somente leitura até você permitir. Instruções que alteram dados são recusadas até você marcar Allow writes, então uma consulta descuidada não muda nada.
  • +A senha é zerada no instante em que o vault abre, e nunca é escrita em lugar nenhum.
  • +Cifrado e durável. Abre pelo mesmo motor durável, então toda escrita confirmada passou por fsync e a trava de um escritor mantém a segunda instância de fora.
  • +Tabelas, uma grade e dois botões. Rode SQL com Ctrl+Enter. Um clique para checkpoint, um para trocar a senha.
mirim-gui
# pronto, a cada release
$ chmod +x mirim-gui-1.1.0-x86_64-linux
$ ./mirim-gui-1.1.0-x86_64-linux

# ou do codigo, no proprio crate
$ cd gui && cargo build --release
   Compiling mirim-gui v1.1.0
    Finished `release` profile [optimized]
$ ./target/release/mirim-gui

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

Use, modifique e distribua livremente. A cláusula de uso em rede (seção 13) se aplica: um mirim modificado oferecido como serviço de rede precisa compartilhar o código com os usuários desse serviço. Declarado como license = "AGPL-3.0-only".

Comercial sob consulta

Dispensa as obrigações de copyleft e de uso em rede sob termos negociados, para embarcar em código fechado ou rodar um serviço modificado sem publicar o código. Fale com a Security Ops pelo securityops.co.

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

Estável · 1.1.0

Leia o código. Os formatos estão congelados.

Os layouts de vault, log, exportação selada e manifesto estão fixos e continuarão legíveis. 3.789 linhas são um fim de semana de leitura, e no final você consegue reproduzir o binário.