Política de assinatura de código

1. O que esta política determina

Esta página indica quais artefatos de lançamento do KalderaShield são assinados, por quem, sob qual custódia de chaves e quem responde pela aprovação de cada assinatura. A versão-fonte do mesmo documento no repositório: CODE_SIGNING_POLICY.md

2. Windows

Free code signing provided by SignPath.io, certificate by SignPath Foundation.

Estado: candidatura ainda não submetida. O KalderaShield tenciona candidatar-se à SignPath Foundation e preparou esta política antecipadamente, porque os termos deles exigem que ela exista antes de uma candidatura. A candidatura não foi submetida e não há decisão pendente. Nada nesta secção deve ser lido como uma afirmação de que algum artefacto Windows esteja assinado atualmente. Não está. Até que a primeira versão assinada seja efetivamente publicada, a formulação honesta é a tabela de estado abaixo, e esta secção será atualizada antes dessa versão, não depois.

Os ficheiros a assinar são o instalador NSIS (KalderaShield_<version>_x64-setup.exe), o pacote MSI para implementação gerida (KalderaShield_<version>_x64.msi) e o executável portátil que não exige instalação (KalderaShield_<version>_x64-portable.exe). Os três são compilados a partir deste repositório e publicados na página de lançamentos. Nenhum artefacto que não seja compilado a partir deste repositório é assinado com o certificado deste projeto, e nenhum binário de terceiros é reassinado com ele.

Custódia das chaves: a chave privada é gerada e guardada no HSM da SignPath. Este projeto nunca a possui, nunca a exporta e nunca a transmite a um agente de compilação nem a uma máquina de programador. A assinatura ocorre do lado da SignPath, em resposta a um pedido de assinatura que a CI deste repositório submete e que uma pessoa aprova.

Cadeia: é criada uma tag de versão → o GitHub Actions compila os ficheiros (fluxos de trabalho públicos, ações de terceiros fixadas por SHA de commit, permissões dos tokens apenas de leitura) → a compilação envia-os para a SignPath e abre um pedido de assinatura sem assinar → um aprovador aprova ou rejeita → a SignPath assina com o certificado da Foundation → o ficheiro assinado é publicado juntamente com SHA256SUMS.txt. Cada lançamento exige aprovação manual; não existe um caminho de assinatura não assistido e nenhum será acrescentado.

Uma assinatura válida da SignPath Foundation significa que o binário é uma compilação automatizada e verificável do código-fonte deste repositório no commit indicado pelo lançamento. Não significa que o software tenha sido auditado, e não é uma aprovação de segurança da aplicação. Este projeto publica um modelo de ameaças e documentação de portões de qualidade, mas não tem uma auditoria de segurança independente concluída:

3. Funções da equipa

O KalderaShield é mantido por uma só pessoa. Isto é declarado aqui em vez de ser apresentado como uma equipa, porque as funções abaixo são as que a SignPath exige e um único mantenedor só pode preenchê-las honestamente sozinho. Todas as contas com acesso de escrita a este repositório usam autenticação multifator.

Autores — pessoas que podem modificar o código-fonte sem revisão adicional:

hafgit99 — github.com/hafgit99

Esta é a única conta com acesso de escrita. O repositório pertence a uma conta pessoal e não a uma organização, pelo que o caminho de escrita é uma única identidade com MFA.

Revisores — pessoas que revem cada alteração proposta por alguém sem permissão de commit antes da integração:

hafgit99

Atualmente não há colaboradores sem permissão de commit, pelo que esta função está, na prática, não apenas fraca mas vaga.

Aprovadores — pessoas que aprovam cada pedido de assinatura antes de o artefacto ser assinado:

hafgit99

Limitação conhecida: com uma única pessoa nas três funções, quem escreve o código também aprova a sua assinatura. O modelo da SignPath pressupõe que um aprovador é "de confiança para toda a equipa", o que pressupõe mais de um membro. Acrescentar um segundo aprovador está previsto mas ainda não foi feito. Quem considere isto desqualificador deve dizê-lo agora e não depois da aprovação.

4. Política de privacidade

Nos termos pedidos pela SignPath: este programa não transfere qualquer informação para outros sistemas ligados em rede, a menos que tal seja expressamente solicitado pelo utilizador ou pela pessoa que o instala ou o utiliza.

O KalderaShield é um gestor de senhas offline-first e de conhecimento zero. O conteúdo do cofre é cifrado no dispositivo com chaves derivadas da senha mestra e nunca é transmitido. Não há conta, serviço de sincronização, telemetria nem análise. Os binários Windows não contêm qualquer cliente de rede para além dos próprios componentes do sistema operativo. Texto completo: Política de privacidade. O comportamento de componentes de terceiros que afeta os utilizadores está coberto por LICENSE-3RD-PARTY.md.

5. Outras plataformas

macOS — os artefactos são assinados com um Apple Developer ID e notarizados pela Apple. O certificado ainda não foi emitido, pelo que nenhum artefacto macOS está assinado e nenhum é publicado. Linux — .deb, .rpm e .AppImage são publicados com assinaturas GPG destacadas (.sig); SBOM e pacotes de extensões do navegador com assinaturas Sigstore sem chave (.sigstore.json). Android — os APK de lançamento são assinados com um keystore de lançamento guardado nos segredos do GitHub Actions; a assinatura Android é separada da Authenticode. Nenhuma plataforma é descrita como assinada antes de o ser.

Estado atual: Linux, Android e a extensão do navegador estão publicados e assinados. Windows é publicado apenas como pré-visualização sem assinatura: uma pré-visualização, não um lançamento estável, e o latest não aponta para ela. Os ficheiros sem assinatura acionam o aviso do SmartScreen "O seu PC está protegido" e terá de clicar em "Mais informações" → "Executar mesmo assim" — é o esperado. Verifique o resumo SHA-256 no SHA256SUMS.txt antes de o executar. A candidatura à SignPath Foundation ainda não foi submetida. macOS não está publicado nem assinado (certificado ainda não emitido).

Os artefactos Windows não são publicados como um lançamento: a cadeia de lançamento trata um lançamento de ambiente de trabalho sem assinatura como uma falha, e nenhum workflow em .github/workflows/ consegue publicar um. A pré-visualização é montada e carregada à mão, a partir da máquina de quem mantém o projeto através do formulário de lançamentos do GitHub, e marcada como pré-lançamento: assim é visivelmente provisória, o latest nunca aponta para ela e o próximo lançamento assinado substitui-a. Esse caminho é deliberado, não um atalho. O repositório contém uma porta de segurança (npm run security:release-signing) que rejeita qualquer workflow capaz de transformar uma compilação sem assinatura numa publicação, e a sua afirmação final é que sem os segredos de assinatura um lançamento de ambiente de trabalho público é impossível por desenho. Acrescentar uma exceção para um workflow tornaria essa afirmação falsa em troca de uma comodidade. Manter o carregamento no browser preserva a garantia. A porta está documentada no Guia de assinatura de código e artefactos; o procedimento passo a passo está no Plano: o site, depois a pré-visualização Windows sem assinatura.

6. Comunicar um problema

Se acredita que um artefacto assinado com um certificado da SignPath Foundation viola esta política, comunique-o a support@signpath.io com o resumo do artefacto e o motivo. Para qualquer outra questão sobre estes artefactos, use security@kalderashield.com; o processo de divulgação está em SECURITY.md.

Em caso de divergência, prevalece o texto em turco desta política.