hMailServer

Projetos que seguem as melhores práticas abaixo podem se autocertificar voluntariamente e mostrar que alcançaram um selo de melhores práticas da Open Source Security Foundation (OpenSSF).

Não existe um conjunto de práticas que possa garantir que o software nunca terá defeitos ou vulnerabilidades; mesmo métodos formais podem falhar se as especificações ou suposições estiverem erradas. Nem existe qualquer conjunto de práticas que possa garantir que um projeto sustentará uma comunidade de desenvolvimento saudável e bem-funcionada. No entanto, seguir as melhores práticas pode ajudar a melhorar os resultados dos projetos. Por exemplo, algumas práticas permitem revisão multipessoal antes do lançamento, o que pode ajudar a encontrar vulnerabilidades técnicas difíceis de encontrar e ajudar a construir confiança e desejo de interação repetida entre desenvolvedores de diferentes empresas. Para ganhar um selo, todos os critérios DEVE e NÃO DEVE devem ser atendidos, todos os critérios DEVERIA devem ser atendidos OU não atendidos com justificativa, e todos os critérios SUGERIDO devem ser atendidos OU não atendidos (queremos que sejam considerados pelo menos). Se você quiser inserir texto de justificativa como um comentário genérico, em vez de ser uma justificativa de que a situação é aceitável, inicie o bloco de texto com '//' seguido de um espaço. Feedback é bem-vindo via site do GitHub como questões ou pull requests Há também uma lista de discussão para discussão geral.

Fornecemos com prazer as informações em vários idiomas, no entanto, se houver qualquer conflito ou inconsistência entre as traduções, a versão em inglês é a versão autoritativa.
Se este é o seu projeto, por favor mostre o status do seu selo básico na página do seu projeto! O status do selo básico se parece com isto: O nível do selo básico para o projeto 14949 é in_progress Aqui está como incorporar o selo básico:
Você pode mostrar o status do seu selo básico incorporando isto no seu arquivo markdown:
[![OpenSSF Baseline](https://www.bestpractices.dev/projects/14949/baseline)](https://www.bestpractices.dev/projects/14949)
ou incorporando isto no seu HTML:
<a href="https://www.bestpractices.dev/projects/14949"><img src="https://www.bestpractices.dev/projects/14949/baseline"></a>


Estes são os critérios de Nível Básico 3. Estes são critérios da versão v2026.08.28.

Baseline Series: Nível Básico 1 Nível Básico 2 Nível Básico 3

        

 Fundamentos

  • Geral

    Observe que outros projetos podem usar o mesmo nome.

    hMailServer is a free, open-source mail server for Windows and Linux, implementing SMTP, IMAP and POP3, with webmail, a REST API and a Control Panel. It is a maintained fork of Martin Knafve's hMailServer, brought up to date with a current toolchain, current cryptography, and the transport-security and authentication standards expected of a mail server in 2026.

    Use o formato de expressão de licença SPDX; exemplos incluem "Apache-2.0", "BSD-2-Clause", "BSD-3-Clause", "GPL-2.0+", "LGPL-3.0+", "MIT" e "(BSD-2-Clause OR Ruby)". Não inclua aspas simples ou aspas duplas.
    Se houver mais de uma linguagem, liste-as como valores separados por vírgula (espaços opcionais) e ordene-as da mais usada para a menos usada. Se houver uma longa lista, liste pelo menos as três primeiras mais comuns. Se não houver linguagem (por exemplo, este é um projeto apenas de documentação ou apenas de teste), use o caractere único "-". Use uma capitalização convencional para cada linguagem, por exemplo, "JavaScript".
    O Common Platform Enumeration (CPE) é um esquema de nomenclatura estruturado para sistemas de tecnologia da informação, software e pacotes. Ele é usado em vários sistemas e bancos de dados ao relatar vulnerabilidades.

    This entry replaces https://www.bestpractices.dev/en/projects/14187, which was made through a GitHub login. GitHub suspended the project account on 18 September 2026, so that entry can no longer be edited. The project has lived on GitLab since 22 September 2026: https://gitlab.com/Progressiverobot/hmailserver. Every answer here was checked again against the project on 26 September 2026.

 Controles 17/21 ●

  • Controles


    Suficiente para um badge!

    Quando um trabalho recebe permissões em um pipeline de CI/CD, o código-fonte ou configuração DEVE atribuir apenas os privilégios mínimos necessários para a atividade correspondente. [OSPS-AC-04.02]
    Configure os pipelines de CI/CD do projeto para atribuir as menores permissões disponíveis a usuários e serviços por padrão, elevando as permissões apenas quando necessário para tarefas específicas. Em alguns sistemas de controle de versão, isso pode ser possível no nível organizacional ou de repositório. Se não, defina permissões no nível superior do pipeline.

    The CI file on master grants no job an ID token or a secret. The release jobs in the next batch are the only ones that ask for an ID token: release-authenticode for audience api://AzureADTokenExchange, and release-sign for audience sigstore. Both run only for a protected v* tag, and the build/ci/repo-hygiene.py check fails any job that asks for id_tokens or secrets and can run for a merge request. See https://gitlab.com/Progressiverobot/hmailserver/-/blob/master/.gitlab-ci.yml


    Suficiente para um badge!

    Os pipelines de CI/CD que aceitam entradas de colaboradores confiáveis DEVEM sanitizar e validar essas entradas antes de usá-las no pipeline. [OSPS-BR-01.04]
    Os pipelines de CI/CD devem sanitizar (citar, escapar ou sair com valores esperados) todas as entradas de colaboradores em execuções explícitas de workflow. Embora os colaboradores sejam geralmente confiáveis, as entradas manuais em um workflow não podem ser revisadas e podem ser abusadas por uma tomada de conta ou ameaça interna.

    GitLab pipelines here accept no collaborator input. The project's minimum role for pipeline variables is 'no one allowed', so nobody can pass variables when starting a pipeline, and .gitlab-ci.yml defines no spec:inputs. The manual jobs take no parameters, and what a schedule sets is only compared in rules. The GitHub workflow that interpolated a dispatch input (installer-smoke.yml) no longer runs and is removed in the next batch. See https://gitlab.com/Progressiverobot/hmailserver/-/blob/master/.gitlab-ci.yml


    Suficiente para um badge!

    Quando um lançamento oficial for criado, todos os ativos dentro desse lançamento DEVEM estar claramente associados ao identificador de lançamento ou outro identificador único para o ativo. [OSPS-BR-02.02]
    Atribua um identificador de versão único a cada ativo de software produzido pelo projeto, seguindo uma convenção de nomenclatura ou esquema de numeração consistente. Exemplos incluem SemVer, CalVer ou id de commit do git.

    Each release's files are in the package registry under the version, e.g. /packages/generic/hmailserver/6.3.3/, and are linked from the release with that tag. The installer and the packages also carry the version in their file names (hMailServer-6.3.3-x64.exe, hmailserver_6.3.3_amd64.deb). See https://gitlab.com/Progressiverobot/hmailserver/-/releases/v6.3.3


    Suficiente para um badge!

    O projeto DEVE definir uma política para gerenciar segredos e credenciais usadas pelo projeto. A política deve incluir diretrizes para armazenar, acessar e rotacionar segredos e credenciais. [OSPS-BR-07.02]
    Documente como segredos e credenciais são gerenciados e usados dentro do projeto. Isso deve incluir detalhes sobre como os segredos são armazenados (por exemplo, usando uma ferramenta de gerenciamento de segredos), como o acesso é controlado e como os segredos são rotacionados ou atualizados. Certifique-se de que informações sensíveis não sejam codificadas diretamente no código-fonte ou armazenadas em sistemas de controle de versão.

    SECURITY.md, 'Secrets and credentials', is the policy. No token, password or signing key is committed, and the test keys are throwaway fixtures. Release-asset signing is keyless (Sigstore), and the tag-signing keys' public halves are in allowed_signers. A secret is rotated when a maintainer leaves, when its pipeline changes hands, on any suspicion of exposure, and before it expires. GOVERNANCE.md says only Christopher Holloway holds the credentials under 'Critical assets'. See https://gitlab.com/Progressiverobot/hmailserver/-/blob/master/SECURITY.md


    Suficiente para um badge!

    Quando o projeto tiver feito um lançamento, a documentação do projeto DEVE conter instruções para verificar a integridade e autenticidade dos ativos de lançamento. [OSPS-DO-03.01]
    As instruções no projeto devem conter informações sobre a tecnologia usada, os comandos a serem executados e a saída esperada. Quando possível, evite armazenar essa documentação no mesmo local que o pipeline de construção e lançamento para evitar que uma única violação comprometa tanto o software quanto a documentação para verificar a integridade do software.

    SECURITY.md, "Verifying a release", gives the commands. git verify-tag against the committed allowed signers file checks the tag. cosign verify-blob, with the bundle, certificate identity and OIDC issuer, checks each asset of the releases up to 6.3.3. Get-AuthenticodeSignature checks the Windows installer from 6.3.1. It also names the tool each check uses. See https://gitlab.com/Progressiverobot/hmailserver/-/blob/master/SECURITY.md#verifying-a-release


    Suficiente para um badge!

    Quando o projeto tiver feito um lançamento, a documentação do projeto DEVE conter instruções para verificar a identidade esperada da pessoa ou processo que criou o lançamento de software. [OSPS-DO-03.02]
    A identidade esperada pode estar na forma de IDs de chave usados para assinar, emissor e identidade de um certificado sigstore ou outras formas similares. Quando possível, evite armazenar essa documentação no mesmo local que o pipeline de construção e lançamento para evitar que uma única violação comprometa tanto o software quanto a documentação para verificar a integridade do software.

    SECURITY.md, 'Verifying a release', says release tags verify against the committed allowed_signers file, which holds one key, christopher.j.holloway@outlook.com's (.github/ on master, .gitlab/ from the next batch). Assets up to 6.3.3 must carry the Sigstore identity ^https://github.com/Progressiverobot/hmailserver/ with the issuer https://token.actions.githubusercontent.com. The next batch adds the GitLab identity and the issuer https://gitlab.com for releases from 6.3.5. See https://gitlab.com/Progressiverobot/hmailserver/-/blob/master/SECURITY.md#verifying-a-release


    Suficiente para um badge!

    Quando o projeto tiver feito um lançamento, a documentação do projeto DEVE incluir uma declaração descritiva sobre o escopo e a duração do suporte para cada lançamento. [OSPS-DO-04.01]
    Para comunicar o escopo e a duração do suporte para os ativos de software lançados pelo projeto, o projeto deve ter um arquivo SUPPORT.md, uma seção "Support" em SECURITY.md ou outra documentação explicando o ciclo de vida do suporte, incluindo a duração esperada de suporte para cada lançamento, os tipos de suporte fornecidos (por exemplo, correções de bugs, atualizações de segurança) e quaisquer políticas ou procedimentos relevantes para obter suporte.

    SECURITY.md's "Supported versions" names the supported line (6.3.x) and says a fix ships in the next release, with no back-ports because there are no maintenance branches. SUPPORT.md describes the support offered: issues, the forum, what to expect, and no guaranteed response time. See https://gitlab.com/Progressiverobot/hmailserver/-/blob/master/SECURITY.md#supported-versions


    Suficiente para um badge!

    Quando o projeto tiver feito um lançamento, a documentação do projeto DEVE fornecer uma declaração descritiva de quando lançamentos ou versões não receberão mais atualizações de segurança. [OSPS-DO-05.01]
    Para comunicar o escopo e a duração do suporte para correções de segurança, o projeto deve ter um SUPPORT.md ou outra documentação explicando a política do projeto para atualizações de segurança.

    SECURITY.md says only the 6.3 line receives security fixes and everything older than 6.3 does not. A fix ships in the next 6.3 release and is not back-ported, so a release stops receiving security updates once a newer one is published. See https://gitlab.com/Progressiverobot/hmailserver/-/blob/master/SECURITY.md#supported-versions


    Suficiente para um badge!

    A documentação do projeto DEVE ter uma política de que os colaboradores de código sejam revisados antes de conceder permissões elevadas a recursos sensíveis. [OSPS-GV-04.01]
    Publique uma política aplicável na documentação do projeto que exija que colaboradores de código sejam revisados e aprovados antes de receberem permissões elevadas a recursos sensíveis, como aprovação de merge ou acesso a segredos. É recomendado que a verificação inclua estabelecer uma linhagem justificável de identidade, como confirmar a associação do contribuidor com uma organização confiável conhecida.

    GOVERNANCE.md, 'Becoming a maintainer', sets the rule for escalated access: a sustained record of correct, tested changes and willingness to take on the release and security duties, decided by the maintainers. It records openly that the second maintainer was appointed from within Progressive Robot Ltd before building that record. Only Progressiverobot, the project's one member above Developer, can grant a GitLab role. See https://gitlab.com/Progressiverobot/hmailserver/-/blob/master/GOVERNANCE.md#becoming-a-maintainer


    Insuficiente para um badge.

    Quando o projeto tiver feito um lançamento, todos os ativos de software compilados lançados DEVEM ser entregues com uma lista de materiais de software. [OSPS-QA-02.02]
    É recomendado gerar automaticamente SBOMs no momento da compilação usando uma ferramenta que foi verificada quanto à precisão. Isso permite que os usuários ingiram esses dados de forma padronizada junto com outros projetos em seu ambiente.

    Every release from v6.2.3 on carries SPDX and CycloneDX SBOMs (hmailserver.spdx.json, hmailserver.cyclonedx.json) beside its installer and packages, but five earlier releases still listed (v6.0.0-B1, v6.0.0, v6.1.0, v6.2.1, v6.2.2) carry an installer with no SBOM. https://gitlab.com/Progressiverobot/hmailserver/-/releases


    Suficiente para um badge!

    Quando o projeto tiver feito um lançamento compreendendo múltiplos repositórios de código-fonte, todos os subprojetos DEVEM impor requisitos de segurança que sejam tão rigorosos ou mais rigorosos que a base de código principal. [OSPS-QA-04.02]
    Quaisquer repositórios de código de subprojeto adicionais produzidos pelo projeto e compilados em um lançamento devem impor requisitos de segurança conforme aplicável ao status e intenção da respectiva base de código. Além de seguir os requisitos correspondentes da Linha de Base OSPS, isso pode incluir exigir uma revisão de segurança, garantir que esteja livre de vulnerabilidades e garantir que esteja livre de problemas de segurança conhecidos.

    Releases are built from one repository alone: the server, the .NET tools, the web front ends and the vendored third-party code (inventoried in hmailserver/docs/third-party-binaries.json) all live there, so there are no subproject repositories to hold to the primary codebase's requirements. https://gitlab.com/Progressiverobot/hmailserver


    Suficiente para um badge!

    A documentação do projeto DEVE documentar claramente quando e como os testes são executados. [OSPS-QA-06.02]
    Adicione uma seção à documentação de contribuição que explique como executar os testes localmente e como executar os testes no pipeline de CI/CD. A documentação deve explicar o que os testes estão testando e como interpretar os resultados.

    CONTRIBUTING.md's Testing section says how to run the Windows regression suite (the bench, build/preflight-tests.ps1, build/run-tests.ps1) and the Linux suite (dotnet test with the HMTEST_* settings), what they exercise and how to read the result; 'The checkers' and hmailserver/docs/ContinuousIntegration.md say which checks and suites each GitLab CI job runs, where, and for which refs. RELEASE.md requires the full suite, zero failures, on the exact binary that ships. https://gitlab.com/Progressiverobot/hmailserver/-/blob/master/CONTRIBUTING.md#testing


    Suficiente para um badge!

    A documentação do projeto DEVE incluir uma política de que todas as mudanças importantes no software produzido pelo projeto devem adicionar ou atualizar testes da funcionalidade em um conjunto de testes automatizado. [OSPS-QA-06.03]
    Adicione uma seção à documentação de contribuição que explique a política para adicionar ou atualizar testes. A política deve explicar o que constitui uma mudança importante e quais testes devem ser adicionados ou atualizados.

    CONTRIBUTING.md makes it policy: 'Add or update regression tests for a change of behaviour' (Merge requests), and 'A fix ships with a test that fails against the build before it' (Writing a test); RELEASE.md requires a negative-control test for every defect fix. https://gitlab.com/Progressiverobot/hmailserver/-/blob/master/CONTRIBUTING.md#merge-requests


    Insuficiente para um badge.

    Quando um commit for feito no branch principal, o sistema de controle de versão do projeto DEVE exigir pelo menos uma aprovação humana não-autora das mudanças antes do merge. [OSPS-QA-07.01]
    Configure o sistema de controle de versão do projeto para exigir pelo menos uma aprovação humana não-autora das mudanças antes de fazer merge no branch de lançamento ou principal. Isso pode ser alcançado exigindo que um pull request seja revisado e aprovado por pelo menos um outro colaborador antes que possa ser feito o merge.

    No approval rule is configured on GitLab, so nothing requires a non-author human approval before a change reaches master; CONTRIBUTING.md says so. One active maintainer lands changes, each checked by adversarial review passes run by AI agents, fixture gates and the full regression gate before it lands, which is not two-person review. https://gitlab.com/Progressiverobot/hmailserver/-/blob/master/CONTRIBUTING.md#merge-requests


    Suficiente para um badge!

    Quando o projeto tiver feito um lançamento, o projeto DEVE realizar uma modelagem de ameaças e análise de superfície de ataque para entender e proteger contra ataques em caminhos de código críticos, funções e interações dentro do sistema. [OSPS-SA-03.02]
    Modelagem de ameaças é uma atividade onde o projeto analisa a base de código, processos e infraestrutura associados, interfaces, componentes-chave e "pensa como um hacker" e faz um brainstorming de como o sistema pode ser quebrado ou comprometido. Cada ameaça identificada é listada para que o projeto possa então pensar em como evitar proativamente ou fechar quaisquer lacunas/vulnerabilidades que possam surgir. Certifique-se de que isso seja atualizado para novos recursos ou mudanças críticas.

    Sections 3 and 4 of ASSURANCE-CASE.md are the threat model and attack-surface analysis: actors A1-A6 with their assumed capabilities, the assets, the principal attack surfaces (protocol parsers, MIME parsing, TLS, the scanner and DNS paths, persistence, and the REST, metrics and web-services listeners) and trust boundaries B1-B6 with the check made at each. https://gitlab.com/Progressiverobot/hmailserver/-/blob/master/ASSURANCE-CASE.md#3-threat-model


    Suficiente para um badge!

    Quaisquer vulnerabilidades nos componentes de software que não afetem o projeto DEVEM ser registradas em um documento VEX, complementando o relatório de vulnerabilidade com detalhes de não explorabilidade. [OSPS-VM-04.02]
    Estabeleça um feed VEX comunicando o status de explorabilidade de vulnerabilidades conhecidas, incluindo detalhes de avaliação ou quaisquer mitigações em vigor impedindo que código vulnerável seja executado.

    The project keeps an OpenVEX document, .github/hmailserver.openvex.json (moving to .gitlab/ with the next batch), with a not_affected statement and its justification for every advisory dismissed as not affecting the project: five today, for zlib and Boost advisories found by the dependency-scan OSV query. SECURITY.md requires a statement for each such dismissal, and the dependency-scan job honours the document. https://gitlab.com/Progressiverobot/hmailserver/-/blob/master/.github/hmailserver.openvex.json


    Suficiente para um badge!

    A documentação do projeto DEVE incluir uma política que defina um limite para a correção de descobertas de SCA relacionadas a vulnerabilidades e licenças. [OSPS-VM-05.01]
    Documente uma política no projeto que defina um limite para remediação de descobertas de SCA relacionadas a vulnerabilidades e licenças. Inclua o processo para identificar, priorizar e remediar essas descobertas.

    SECURITY.md's Vulnerability management policy sets the SCA thresholds: a high or critical advisory in a dependency is fixed, or the dependency replaced, before the next release and within 14 days; moderate within 30 days; low within 90 days or with the next refresh; a licence incompatible with AGPL-3.0-or-later is treated as high. It says how findings are found (the dependency-scan job's Trivy and OSV queries, Renovate) and how a not-affected one is recorded in the VEX document. https://gitlab.com/Progressiverobot/hmailserver/-/blob/master/SECURITY.md#dependencies-software-composition-analysis


    Suficiente para um badge!

    A documentação do projeto DEVE incluir uma política para tratar violações de SCA antes de qualquer lançamento. [OSPS-VM-05.02]
    Documente uma política no projeto para abordar os resultados aplicáveis de Análise de Composição de Software antes de qualquer lançamento, e adicione verificações de status que confirmem a conformidade com essa política antes do lançamento.

    SECURITY.md: a release is not cut while a known high or critical advisory against a shipped dependency is open; the dependency-scan report of the release's commit is read first, and every component it marks UNKNOWN is checked by hand against the release's SBOM. That check is made by hand: the dependency-scan job is defined in .gitlab-ci.yml, not blocking, and has not yet run on GitLab. https://gitlab.com/Progressiverobot/hmailserver/-/blob/master/SECURITY.md#dependencies-software-composition-analysis


    Insuficiente para um badge.

    Todas as mudanças na base de código do projeto DEVEM ser avaliadas automaticamente em relação a uma política documentada para dependências maliciosas e vulnerabilidades conhecidas em dependências, e então bloqueadas em caso de violações, exceto quando declaradas e suprimidas como não exploráveis. [OSPS-VM-05.03]
    Crie uma verificação de status no sistema de controle de versão do projeto que execute uma ferramenta de Análise de Composição de Software em todas as alterações na base de código. Exija que a verificação de status seja aprovada antes que as alterações possam ser mescladas.

    Not every change is evaluated and blocked. The dependency-scan job (Trivy and OSV, honouring the VEX document) is defined for master, batch* and v* pipelines on the project's runner only, is allow_failure, and has not yet run on GitLab; merge requests do not reach it, and Renovate waits for the owner's token and schedule. GitHub's blocking dependency review ran until 18 September 2026. https://gitlab.com/Progressiverobot/hmailserver/-/blob/master/hmailserver/docs/ContinuousIntegration.md


    Suficiente para um badge!

    A documentação do projeto DEVE incluir uma política que defina um limite para a correção de descobertas de SAST. [OSPS-VM-06.01]
    Documente uma política no projeto que defina um limite para remediação de resultados de Teste de Segurança de Aplicação Estática (SAST). Inclua o processo para identificar, priorizar e remediar esses resultados.

    SECURITY.md's Vulnerability management policy sets the SAST threshold: an error-level finding, or a high or critical security finding, is fixed before merge; medium within 30 days; low or note-level with the next change to that file or dismissed with a written reason; no release with an open error-level finding. It names the tools (cppcheck, clang-tidy and Semgrep in CI, MSVC /analyze by hand) and how suppressions are recorded. https://gitlab.com/Progressiverobot/hmailserver/-/blob/master/SECURITY.md#source-code-static-analysis


    Insuficiente para um badge.

    Todas as mudanças na base de código do projeto DEVEM ser avaliadas automaticamente em relação a uma política documentada para vulnerabilidades de segurança e bloqueadas em caso de violações, exceto quando declaradas e suprimidas como não exploráveis. [OSPS-VM-06.02]
    Crie uma verificação de status no sistema de controle de versão do projeto que execute uma ferramenta de Teste de Segurança de Aplicação Estática (SAST) em todas as alterações na base de código. Exija que a verificação de status seja aprovada antes que as alterações possam ser mescladas.

    SAST does not yet block changes. The static-analysis (cppcheck, clang-tidy) and semgrep jobs are defined for master, batch* and v* pipelines only, are allow_failure against committed baselines until triaged, do not read the Windows-only sources, and have not yet run on GitLab; GitLab SAST and secret detection come with the next batch. CodeQL ran on GitHub until 18 September 2026. https://gitlab.com/Progressiverobot/hmailserver/-/blob/master/hmailserver/docs/ContinuousIntegration.md#security-scanning



Você pode usar ferramentas e sistemas de IA para propor alterações por meio de uma URL simples, como https://www.bestpractices.dev/pt-BR/projects/14949/choose/edit?osps_ac_01_01_status=Met&osps_ac_01_01_justification=GitHub+enforced. Veja nosso sistema de propostas de automação para saber como fazer isso. Estes dados estão disponíveis sob o Community Data License Agreement – Permissive, Version 2.0 (CDLA-Permissive-2.0). Isso significa que um Destinatário de Dados pode compartilhar os Dados, com ou sem modificações, desde que o Destinatário de Dados disponibilize o texto deste acordo com os Dados compartilhados. Por favor, dê crédito a christopher holloway e aos contribuidores do selo de melhores práticas OpenSSF.

Entrada de selo do projeto de propriedade de: christopher holloway.
Entrada criada em 2026-09-26 05:28:20 UTC, última atualização em 2026-09-26 06:16:51 UTC. Selo de aprovação alcançado pela última vez em 2026-09-26 05:45:21 UTC.