English · Português
gentropic.org / security
Ferramentas que não exigem nada da máquina onde rodam
A GCU desenvolve ferramentas pequenas, de arquivo único, que não precisam de instalador, de rede nem de permissões especiais para rodar — e que permitem que você verifique cada uma dessas afirmações por conta própria, em vez de aceitá-las sob confiança. São livres e de código aberto, e funcionam onde a maioria dos softwares não chega, por razões que você pode checar. Esta página descreve o que as ferramentas fazem, o que pedem do host e exatamente como confirmar cada afirmação.
Esta página é submetida ao mesmo padrão das ferramentas que descreve: é um único documento estático, sem scripts, sem requisições de rede e sem fontes ou CDNs de terceiros — tudo o que ela carrega é servido desta mesma origem. Se essa é uma afirmação que vale a pena checar, o código-fonte já está aberto para você em Exibir código-fonte.
Verifique você mesmo — cinco minutos
Você não precisa aceitar nada disto sob confiança. Cada propriedade afirmada nesta página corresponde a algo que você pode confirmar diretamente, em poucos minutos, com ferramentas que já tem na máquina.
- Baixe o
lamina.htmlda versão fixada (release) indicada abaixo. - Calcule o hash — shasum -a 256 lamina.html — ele confere com o SHA-256 publicado e com o DOI do Zenodo.
- Abra o arquivo. DevTools → Rede → carregue um arquivo → zero requisições.
- Exiba o código-fonte — ele é legível; aqui está o repositório a partir do qual é construído.
- Desconecte a rede por completo. Continua funcionando.
- Exporte algo — ele grava apenas o único arquivo que você escolher, pela caixa de diálogo Salvar do sistema operacional. Nada silencioso; em lugar nenhum que você não tenha escolhido.
O que um host restrito controla — e o que sobrevive
Ambientes sérios deixaram de policiar a computação (o navegador é o runtime mais capaz de qualquer máquina gerenciada, e não pode ser removido sem quebrar os aplicativos web dos quais a organização depende) e passaram a policiar o alcance. Veja exatamente o que cada controle bloqueia, e a resposta do perfil endurecido:
| Controle do host | Bloqueia | Perfil hardened |
|---|---|---|
unsafe-eval (CSP) | eval / new Function | Zero geração de código em runtime — backend de closures, nunca eval |
wasm-unsafe-eval | compilação de WASM | Removido (ou habilitável por admin) |
import() remoto | código remoto | Apenas imports empacotados / locais |
| Trusted Types | construção de Function | Igual — sem geração de código |
| origem segura | crypto.subtle, workers, armazenamento | Servida de uma origem HTTPS interna / loopback |
connect-src 'none' | saída de rede | Alcance zero por construção — o air-gap é o recurso |
Perfis
Cada ferramenta declara o perfil mais estrito que cumpre. O perfil é definido pelos dois eixos que um
revisor pondera primeiro — se a ferramenta gera código em tempo de execução, e se acessa a rede.
(Os nomes dos perfis são canônicos, em inglês, como as chaves do capability.json.)
| Perfil | Geração de código (runtime) | Rede / alcance |
|---|---|---|
| Sealed | Nenhuma | Nenhum — sobrevive à CSP mais estrita e ao Trusted Types; air-gapped, e de forma demonstrável (desconecte e rode) |
| Connected | Nenhuma | Um conjunto declarado de endpoints — sem geração de código, mas não air-gapped |
| Full | usa eval / Function | A versão de potência total, para ambientes que permitem geração de código em runtime |
Duas capacidades são declaradas de forma ortogonal, como flags sobre o perfil, porque não alteram nem a história de geração de código nem a de rede:
| +WASM | Usa WebAssembly (precisa de wasm-unsafe-eval) para computação pesada. |
|---|---|
| +GPU | Usa WebGL / WebGPU. Não é governado pela CSP — os shaders são compilados pelo driver da GPU, não por eval, então isto não quebra um perfil Sealed. Pode ser desativado por política do navegador, e adiciona superfície de ataque do processo de GPU (mitigada pelo sandbox de GPU do navegador). |
Uma origem segura servida (um site HTTPS interno, ou um servidor em loopback) só é exigida por
ferramentas que usam service workers para cache offline, ou que dependem de
crypto.subtle para autoverificação por hash — ambos pouco confiáveis a
partir de uma origem file://. Todo o resto, incluindo uma ferramenta Sealed +GPU, roda
como um arquivo único aberto a partir do disco. (Uma página file:// é um contexto
seguro; é a sua origem opaca, não o gate de contexto seguro, que limita aqueles dois recursos.)
Como cada garantia é estabelecida
Nem toda propriedade nesta página é sustentada da mesma forma, e a diferença é o ponto central. Cada afirmação é estabelecida de uma destas maneiras — da mais forte para a mais fraca — e a declaração de cada ferramenta marca qual:
| Imposta pelo host | A própria política do navegador a torna impossível, não apenas ausente — "sem geração de código" sob um script-src sem unsafe-eval; "sem rede" sob connect-src 'none'. Uma versão falha não consegue violar um limite imposto pelo host. É o tipo mais forte, e está genuinamente disponível aqui. |
|---|---|
| Demonstrável | Você pode observá-la diretamente — desconecte a rede e a ferramenta continua funcionando. |
| Inspecionável | Você pode lê-la no código-fonte, e o hash publicado confirma que o código-fonte é o que roda — por exemplo, "lê apenas os arquivos que você abre". |
| Melhor esforço | Pretendida e acreditada, mas nem imposta pelo host nem diretamente testável. Onde uma propriedade se apoia apenas nisto, a declaração diz isso claramente. |
lamina — declaração de capacidades
o lamina é a primeira ferramenta que publicamos, e uma escolha sensata para avaliar primeiro: ela cumpre o perfil mais estrito, Sealed. Ela abre um arquivo — mesmo de vários gigabytes — e permite percorrê-lo, filtrá-lo e exportá-lo: em janela e somente-leitura sobre a origem, e rodando inteiramente offline. Sua declaração de capacidades está exposta abaixo, e as formas legíveis por máquina que suas próprias ferramentas podem consumir estão linkadas aqui — capability.json, csp.txt e sbom.json.
| Perfil | Sealed — sem geração de código em runtime, sem rede, sem WASM, sem GPU |
|---|---|
| Executa | geração de código em runtime Não (sem eval / new Function) · wasm Não · import remoto Não |
| Alcance | rede Nenhum (connect-src 'none') · telemetria Nenhuma |
| Arquivos | leitura — apenas arquivos que você abre (seletor / arrastar-e-soltar) · escrita — apenas exportação iniciada por você, para um caminho que você escolhe na caixa Salvar do SO · E/S silenciosa ou arbitrária Nenhuma |
| Exige do host | origem segura Sim · admin Não · instalação Não |
Isto é a mesma coisa que foi revisada, inalterada?
A integridade se apoia numa única cadeia verificável, da origem ao arquivo em execução: um repositório de propriedade da organização com histórico completo, uma release assinada e com tag, o SHA-256 do artefato construído, e um DOI do Zenodo que congela aquela versão exata como um registro citável e hospedado pelo CERN. Em conjunto, eles permitem estabelecer que o arquivo que você revisou, o arquivo em execução e o arquivo com este hash são um e o mesmo.
| Release | <tag — emitida pelo build> |
|---|---|
| SHA-256 | <hash — emitido pelo build> |
| DOI do Zenodo | <doi — na primeira release congelada> |
| Origem | github.com/gentropic/auditable (ext/lamina + tools/lamina) |
As duas perguntas que um revisor faz
Uma vez que você deixa de confiar nas extensões de arquivo como indicador de capacidade, restam dois modelos coerentes de governança — e um artefato da GCU responde a ambos, por construção:
| Governar a fronteira | presuma computação arbitrária, controle o alcance → air-gapped, connect-src 'none', alcance voluntariamente zero — e demonstrável: puxe o cabo. |
|---|---|
| Governar a procedência | identidade + integridade → fixado por hash, congelado, auditável sob CC0 — "isto é a coisa revisada, inalterada". |
Arquivos para suas ferramentas
- capability.json — declaração de capacidades legível por máquina
- csp.txt — a CSP exata sob a qual o artefato é construído para rodar
- sbom.json — SBOM em CycloneDX (zero dependências em runtime, no formato que seu scanner consome)
- .well-known/security.txt — contato + política conforme a RFC 9116
Perguntas frequentes do revisor
- Ela se comunica de volta com algum servidor?
- Não.
connect-src 'none'; zero requisições de rede; puxe o cabo e verifique. - Precisa de admin ou de um instalador?
- Não. É um documento web aberto no seu navegador gerenciado, sob a sua CSP.
- Ela pode ler arquivos arbitrários?
- Não. Apenas os arquivos que você abrir explicitamente; ela não pode navegar pelo disco.
- Telemetria / análise?
- Nenhuma. Não há caminho de rede pelo qual sair.
- Como são tratadas atualizações e CVEs?
- Você fixa uma release nomeada e atualiza quando você decidir, fixando uma nova. Zero dependências em runtime significa uma superfície de CVE quase nula.
- Podemos hospedar nossa própria cópia?
- Sim — essa é a forma de implantação pretendida. Você mantém uma cópia fixada; nós não operamos nada; desinstalar = apagar o arquivo.
- E se o autor desaparecer?
- Nada quebra. É software livre e de código aberto (CC0 / MIT); sua cópia não tem operador nem dependência de nós.
O que isto não é
Não é "certificado como seguro". Nós não vendemos um selo de segurança, e desconfiaríamos de quem vendesse. Uma revisão de segurança é uma avaliação com escopo definido, e a decisão de aceitar o risco residual pertence à sua organização — não a nós, e não a um relatório que nós tenhamos encomendado. O que podemos oferecer é tudo de que você precisa para tomar essa decisão bem.
Não é software instalado disfarçado. Independentemente de como um artefato é empacotado — como arquivo, atalho ou instalador — o que de fato roda é HTML no seu navegador gerenciado, sob a sua política de segurança de conteúdo. O empacotamento muda como a ferramenta é descoberta e inventariada; não muda o que executa, nem onde.
Não é um contrato de suporte, e sua autoria é divulgada, não escondida. As ferramentas são software livre e de código aberto: você roda sua própria cópia fixada, sem operador e sem dependência contínua de nós. Quando a pessoa que propõe uma implantação também é funcionária da organização, isso é um conflito de interesse a declarar claramente — e uma razão para que a organização que implanta, e não o autor, seja dona da decisão.
Usar uma ferramenta da GCU no seu trabalho
Se você chegou a esta página porque gostaria de usar uma destas ferramentas na sua organização, a coisa mais útil que você pode fazer é também a mais sem graça: leve-a pelo seu fluxo normal de aprovação, em vez de rodá-la sem avisar. Rodar um bom software por fora ainda deixa um software não revisado num sistema gerenciado — e coloca você, e não a ferramenta, na posição incômoda quando alguém perguntar o que é aquilo e quem autorizou.
Esta página existe para tornar essa aprovação simples. Direcione quem aprova — sua equipe de TI ou de segurança — para ela; entregue a eles a declaração de capacidades e os demais artefatos acima; e apresente-a pelo que ela é: uma ferramenta bem delimitada e verificável, levada pelo processo adequado. O precedente que isso abre — uma categoria revisável que sua organização já viu e aceitou — é tão importante quanto a própria ferramenta.