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.
secrets
access_log
7bd0 228a
1655 e27f
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.
| Área | Mudanç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.
| Plataforma | Arquivo | Tamanho | Instale 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.gzCLI, 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. |
# 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
# 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.
-- 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 KEYeUNIQUEde coluna única, cada um com um índice de igualdade O(1).WHEREcom comparações encadeadas por AND eIS [NOT] NULL.ORDER BY, multichave e estável. NULL vem primeiro no ASC, por último no DESC.LIMIT,OFFSETeCOUNT(*).- 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 excetoCOUNT(*).- 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.
| Carga de trabalho | mirim 1.1.0 | SQLite | Leitura |
|---|---|---|---|
| commit durável, 1 instrução, com fsync | 578 µs | 782 µ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 ms | 3,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 ms | 33,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 µs | 0,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 ms | nã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.
| Dimensão | mirim 1.1 | SQLite | SQLCipher | DuckDB 1.4+ | libSQL / Turso | redb / sled |
|---|---|---|---|---|---|---|
| Tipo | SQL embarcado | SQL embarcado | SQL embarcado, cifrado | SQL analítico embarcado | SQL embarcado, fork do SQLite | Chave-valor embarcado |
| Implementação | Rust seguro, forbid(unsafe_code) | C | C, SQLite mais extensão | C++ | C e Rust | Rust |
| Cifrado em repouso | Sim, padrão e único modo | Não, o SEE é add-on pago | Sim | Sim, desde a 1.4 (set. 2025) | Sim | Não |
| Cifra em repouso | XChaCha20-Poly1305, snapshot inteiro | nenhuma | AES-256-CBC + HMAC-SHA512, por página | AES-256-GCM ou CTR, por página | AEGIS, AES-GCM ou ChaCha20-Poly1305, por página | nenhuma |
| KDF de senha | Argon2id, memory-hard (64 MiB, t=3) | nenhum | PBKDF2-HMAC-SHA512, 256 mil iterações | chave crua | chave crua | nenhum |
| Pós-quântico | Exportações seladas ML-KEM-768, manifestos assinados ML-DSA-87 | Não | Não | Não | Não | Não |
| RSA ou curva elíptica nos formatos | Nenhum | n/a | n/a | n/a | n/a | n/a |
| Durabilidade em queda | WAL, fsync antes do ack, testado com SIGKILL | WAL ou journal | o do SQLite | WAL | WAL | Sim, log ou copy-on-write |
| Superfície SQL | Subconjunto mínimo | SQL completo | SQL completo | SQL analítico rico | SQL completo | Nenhuma, API chave-valor |
| Dados maiores que a RAM | Não | Sim | Sim | Sim | Sim | Sim |
| Concorrência | Um escritor, um processo | Multileitor, um escritor | a do SQLite | Um processo | Múltipla, com replicação | MVCC (redb) |
| Tamanho | 477 KiB de CLI, cripto inclusa | menos de 900 KiB de biblioteca | SQLite mais cripto | dezenas de MB | vários MB | pequeno |
| Build reprodutível, SBOM, release assinada | Os três | não | não | não | não | não |
| Licença | AGPL-3.0-only ou comercial | Domínio público | Estilo BSD | MIT | MIT | MIT / 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.
| Papel | Primitiva | Parâmetros | Padrão |
|---|---|---|---|
| Encapsulamento de chave | ML-KEM-768 | texto cifrado de 1088 bytes, rejeição implícita | FIPS 203 |
| Assinaturas | ML-DSA-87 | assinatura de 4627 bytes, feature sign | FIPS 204 |
| AEAD | XChaCha20-Poly1305 | nonce de 24 bytes, cabeçalho como dado associado | RFC 8439 e extensão |
| KDF de senha | Argon2id | 64 MiB, 3 passagens, 4 pistas | RFC 9106 |
| Derivação de chave | HKDF-SHA256 | string info com separação de domínio por formato | RFC 5869 |
| Hash | SHA-256 | identidade do snapshot, digest do alvo do manifesto | FIPS 180-4 |
| Aleatoriedade | CSPRNG do sistema | via getrandom | plataforma |
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.
| Artefato | Magic | Versão | Layout |
|---|---|---|---|
| Vault | MIRIM1\0\0 | v1 | 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ário | MIRIMSL1 | v1 | Texto cifrado ML-KEM-768 de 1088 bytes, nonce de 24 bytes, depois o payload AEAD. |
| Exportação selada, vários destinatários | MIRIMSL1 | v2 | 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 log | MIRIMWL1 | v1 | 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 assinado | MIRIMMF1 | v1 | 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ça | MIRIMTS1 | v1 | 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 auditecargo denya cada push.
$ 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
.mrmsem 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
flockconsultivo é 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.
# 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.