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 2. 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 16/19 ●

  • Controles


    Suficiente para um badge!

    Quando uma tarefa de CI/CD é executada sem permissões especificadas, o sistema de CI/CD DEVE definir como padrão as permissões da tarefa para as menores permissões concedidas no pipeline. [OSPS-AC-04.01]
    Configure as definições do projeto para atribuir as menores permissões disponíveis a novos pipelines por padrão, concedendo permissões adicionais somente quando necessário para tarefas específicas.

    A GitLab CI job that declares nothing gets only its own CI_JOB_TOKEN, which works on a limited set of API endpoints. The project refuses job-token pushes to the repository, and its inbound job-token allowlist holds only the project itself. A job gets no OIDC ID token unless it declares one. The five project CI/CD variables are Azure identifiers, not secrets, and all are protected. See https://gitlab.com/Progressiverobot/hmailserver/-/blob/master/.gitlab-ci.yml


    Suficiente para um badge!

    Quando um lançamento oficial é criado, esse lançamento DEVE receber um identificador de versão único. [OSPS-BR-02.01]
    Atribua um identificador de versão único a cada versão de lançamento produzida pelo projeto, seguindo uma convenção de nomenclatura ou esquema de numeração consistente. Exemplos incluem SemVer, CalVer ou id de commit git.

    Every release has a unique SemVer tag (v6.3.0 to v6.3.3 on GitLab, with earlier releases re-published under their original tags). Tags are annotated and SSH-signed from v6.2.23-alpha2 on, and the v* tag pattern is protected. See https://gitlab.com/Progressiverobot/hmailserver/-/releases


    Suficiente para um badge!

    Quando um lançamento oficial é criado, esse lançamento DEVE conter um registro descritivo de modificações funcionais e de segurança. [OSPS-BR-04.01]
    Certifique-se de que todos os lançamentos incluam um registro de alterações descritivo. É recomendado garantir que o registro de alterações seja legível por humanos e inclua detalhes além das mensagens de commit, como descrições do impacto de segurança ou relevância para diferentes casos de uso. Para garantir a legibilidade por máquina, coloque o conteúdo sob um cabeçalho markdown como \"## Changelog\"."

    Every release on GitLab carries human-written notes on functional and security changes (6.3.3's run to about 25 KB), and CHANGELOG.md keeps the same log per version, including the 6.3.4 section. See https://gitlab.com/Progressiverobot/hmailserver/-/blob/master/CHANGELOG.md


    Suficiente para um badge!

    Quando um pipeline de compilação e lançamento ingere dependências, ele DEVE usar ferramentas padronizadas quando disponíveis. [OSPS-BR-05.01]
    Use ferramentas comuns para o seu ecossistema, como gerenciadores de pacotes ou ferramentas de gerenciamento de dependências para ingerir dependências no momento da compilação. Isso pode incluir o uso de um arquivo de dependências, arquivo de bloqueio ou manifesto para especificar as dependências necessárias, que são então incorporadas pelo sistema de compilação.

    The .NET projects use NuGet with committed lock files, restored with --locked-mode. The Linux build takes its libraries from the distribution's packages, in a CI image built from build/ci/linux.Dockerfile. OpenSSL, Boost and libpq are built from source archives at pinned versions, each checked against its SHA-256 (libraries/build-*.ps1), and every fetched binary input is pinned by hash in hmailserver/docs/third-party-binaries.json. See https://gitlab.com/Progressiverobot/hmailserver/-/blob/master/SECURITY.md


    Suficiente para um badge!

    Quando um lançamento oficial é criado, esse lançamento DEVE ser assinado ou contabilizado em um manifesto assinado incluindo os hashes criptográficos de cada ativo. [OSPS-BR-06.01]
    Assine todos os ativos de software lançados no momento da construção com uma assinatura criptográfica ou atestados, como assinatura GPG ou PGP, assinaturas Sigstore, proveniência SLSA ou VSAs SLSA. Inclua os hashes criptográficos de cada ativo em um manifesto assinado ou arquivo de metadados.

    Every asset of the releases from 6.2.19 to 6.3.3 carries its own keyless Sigstore bundle, and the Windows installer is Authenticode-signed since 6.3.1. From 6.3.4 every release also carries a SHA256SUMS manifest with each asset's SHA-256, signed with the release-tag SSH key listed in the repository's allowed_signers file (ssh-keygen -Y sign; checked with ssh-keygen -Y verify). How to verify each: 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 descrição de como o projeto seleciona, obtém e rastreia suas dependências. [OSPS-DO-06.01]
    É recomendado publicar essas informações juntamente com a documentação técnica e de design do projeto em um recurso publicamente visível, como o repositório de código-fonte, site do projeto ou outro canal.

    Several documents describe how dependencies are chosen, obtained and tracked. hmailserver/docs/ThirdPartyBinaries.md records each third-party build input: what it is, where it comes from, how the build fetches and hash-checks it, and why it is needed. SECURITY.md, "Supply chain" and "Dependencies", covers the pinned native libraries, the NuGet lock files, the dependency-scan job (Trivy and OSV) and Renovate (renovate.json). CONTRIBUTING.md lists the prerequisites. See https://gitlab.com/Progressiverobot/hmailserver/-/blob/master/hmailserver/docs/ThirdPartyBinaries.md


    Suficiente para um badge!

    A documentação do projeto DEVE incluir instruções sobre como compilar o software, incluindo bibliotecas, frameworks, SDKs e dependências necessários. [OSPS-DO-07.01]
    Recomenda-se publicar essas informações junto com a documentação de colaboradores do projeto, como em CONTRIBUTING.md ou outra documentação de tarefas de desenvolvimento. Isso também pode ser documentado usando alvos de Makefile ou outros scripts de automação.

    README.md, "Building hMailServer", and CONTRIBUTING.md, "Prerequisites" and "Building", give the toolchain (Visual Studio 2026 / v145, Inno Setup, Perl, Python; clang and CMake on Linux). They say how to build OpenSSL, Boost and libpq, and how to get the hash-checked build inputs, with the build scripts under build/. See https://gitlab.com/Progressiverobot/hmailserver/-/blob/master/CONTRIBUTING.md#building


    Suficiente para um badge!

    A documentação do projeto DEVE incluir uma lista dos membros do projeto com acesso a recursos sensíveis. [OSPS-GV-01.01]
    Documente os participantes do projeto e seus papéis através de artefatos como members.md, governance.md, maintainers.md ou arquivo similar dentro do repositório de código-fonte do projeto. Isso pode ser tão simples quanto incluir nomes ou identificadores de conta em uma lista de mantenedores, ou mais complexo dependendo da governança do projeto.

    GOVERNANCE.md, 'Maintainers', names the project's two maintainers and their accounts: Christopher Holloway (Progressiverobot on GitLab, the Owner; chrisholloway5 on GitHub) and Zain Ul Abidin (Zainulabidin90 on GitHub; zainulabidin1990 on GitLab from the next batch). A table shows which duties each holds, and 'Critical assets' lists the credentials. GitLab's member list shows the three accounts and their roles. See https://gitlab.com/Progressiverobot/hmailserver/-/blob/master/GOVERNANCE.md#maintainers


    Suficiente para um badge!

    A documentação do projeto DEVE incluir descrições dos papéis e responsabilidades dos membros do projeto [OSPS-GV-01.02]
    Documente os participantes do projeto e seus papéis através de artefatos como members.md, governance.md, maintainers.md ou arquivo similar dentro do repositório de código-fonte do projeto.

    GOVERNANCE.md describes the Maintainer, Contributor and Reporter roles and each one's responsibilities (accepting changes, releasing, security response, direction, infrastructure). It also has a table of which maintainer holds which duty today. See https://gitlab.com/Progressiverobot/hmailserver/-/blob/master/GOVERNANCE.md#roles-and-responsibilities


    Suficiente para um badge!

    A documentação do projeto DEVE incluir um guia para contribuidores de código que inclua os requisitos para contribuições aceitáveis. [OSPS-GV-03.02]
    Estenda o conteúdo de CONTRIBUTING.md ou CONTRIBUTING/ na documentação do projeto para delinear os requisitos para contribuições aceitáveis, incluindo padrões de codificação, requisitos de testes e diretrizes de submissão para contribuidores de código. É recomendado que este guia seja a fonte da verdade tanto para contribuidores quanto para aprovadores.

    CONTRIBUTING.md sets the requirements for an acceptable contribution: one logical change, regression tests for behaviour changes, a warning-free build, parameterised SQL only, and settings in the database. It also covers the checkers to run, code style and licence headers, the change checklists (schema, COM, REST, UI), commit rules and DCO sign-off. See https://gitlab.com/Progressiverobot/hmailserver/-/blob/master/CONTRIBUTING.md


    Insuficiente para um badge.

    O sistema de controle de versão DEVE exigir que todos os contribuidores de código afirmem que estão legalmente autorizados a fazer as contribuições associadas em cada commit. [OSPS-LE-01.01]
    Inclua um DCO no repositório do projeto, exigindo que os contribuidores de código afirmem que estão legalmente autorizados a confirmar as contribuições associadas em cada commit. Use uma verificação de status para garantir que a afirmação seja feita. Um CLA também satisfaz este requisito. Alguns sistemas de controle de versão, como o GitHub, podem incluir isso nos termos de serviço da plataforma.

    CONTRIBUTING.md requires a DCO Signed-off-by, naming the commit's author, on every commit of a merge request from a fork. The sign-off job in .gitlab-ci.yml checks it, but no merge request has run it yet. The maintainers' own commits, which are almost all of master, are exempt and carry no sign-off, so not every commit carries the assertion. See https://gitlab.com/Progressiverobot/hmailserver/-/blob/master/CONTRIBUTING.md#sign-off


    Insuficiente para um badge.

    Quando um commit é feito na branch primária, quaisquer verificações de status automatizadas para commits DEVEM passar ou ser manualmente ignoradas. [OSPS-QA-03.01]
    Configure o sistema de controle de versão do projeto para exigir que todas as verificações de status automatizadas passem ou exijam reconhecimento manual antes que um commit possa ser mesclado na branch primária. É recomendado que quaisquer verificações de status opcionais NÃO sejam configuradas como um requisito de aprovação ou reprovação que os aprovadores possam ser tentados a ignorar.

    master is protected (only Maintainers push, no force-push) and GitLab's 'pipelines must succeed' setting is on for merge requests, but changes reach master by the maintainer's fast-forward push, which no status check gates: .gitlab-ci.yml defines the checks, but no full pipeline has run on GitLab yet. Every change is landed only after the maintainer's own full regression gate, the whole Windows suite split across two machines plus the whole Linux suite. https://gitlab.com/Progressiverobot/hmailserver/-/blob/master/hmailserver/docs/ContinuousIntegration.md


    Insuficiente para um badge.

    Antes de um commit ser aceito, os pipelines de CI/CD do projeto DEVEM executar pelo menos um conjunto de testes automatizados para garantir que as alterações atendam às expectativas. [OSPS-QA-06.01]
    Testes automatizados devem ser executados antes de cada mesclagem na branch primária. O conjunto de testes deve ser executado em um pipeline de CI/CD e os resultados devem ser visíveis a todos os contribuidores. O conjunto de testes deve ser executado em um ambiente consistente e deve ser executado de uma maneira que permita aos contribuidores executar os testes localmente. Exemplos de conjuntos de testes incluem testes unitários, testes de integração e testes de ponta a ponta.

    No CI/CD pipeline tests a change before it is accepted yet. .gitlab-ci.yml defines the whole Windows suite (windows-gate), the whole Linux suite (linux-suite) and the .NET tests on the project's own runners for master, batch* and v* pipelines, but no pipeline running them has run on GitLab (every push pipeline so far was skipped). Today every change is landed only after the maintainer's own full regression gate: the whole Windows suite split across two machines, plus the whole Linux suite. GitHub Actions ran the CI tests until 18 September 2026. https://gitlab.com/Progressiverobot/hmailserver/-/blob/master/hmailserver/docs/ContinuousIntegration.md


    Suficiente para um badge!

    Quando o projeto tiver feito um lançamento, a documentação do projeto DEVE incluir documentação de design demonstrando todas as ações e atores dentro do sistema. [OSPS-SA-01.01]
    Inclua designs na documentação do projeto que expliquem as ações e atores. Atores incluem qualquer subsistema ou entidade que possa influenciar outro segmento no sistema. Certifique-se de que isso seja atualizado para novos recursos ou mudanças que quebrem compatibilidade.

    ARCHITECTURE.md is the design document: the server's modules (SMTP, IMAP, POP3, the delivery queue, anti-spam and anti-virus, persistence over four database backends), the COM API as the management seam, the REST, metrics, web-services and ManageSieve listeners, scheduled work, the Linux build and the tests. ASSURANCE-CASE.md adds the actors (A1-A6) and the trust boundaries between them (B1-B6). https://gitlab.com/Progressiverobot/hmailserver/-/blob/master/ARCHITECTURE.md


    Suficiente para um badge!

    Quando o projeto tiver feito um lançamento, a documentação do projeto DEVE incluir descrições de todas as interfaces de software externas dos ativos de software lançados. [OSPS-SA-02.01]
    Documente todas as interfaces de software (APIs) dos ativos de software lançados, explicando como os usuários podem interagir com o software e quais dados são esperados ou produzidos. Certifique-se de que isso seja atualizado para novos recursos ou mudanças que quebrem compatibilidade.

    README.md's Capabilities and Administration sections describe every external interface: SMTP, IMAP and POP3 with their extensions, ManageSieve, CardDAV and CalDAV, the REST API (which serves its own OpenAPI document at /api/v1/openapi.json), the Control Deck and webmail, Prometheus /metrics and health probes, OTLP export, SNMP and the COM API, with a document per feature under hmailserver/docs. https://gitlab.com/Progressiverobot/hmailserver/-/blob/master/README.md


    Suficiente para um badge!

    Quando o projeto tiver feito um lançamento, o projeto DEVE realizar uma avaliação de segurança para compreender os problemas de segurança potenciais mais prováveis e impactantes que poderiam ocorrer dentro do software. [OSPS-SA-03.01]
    Realizar uma avaliação de segurança informa tanto os membros do projeto quanto os consumidores a jusante que o projeto compreende quais problemas poderiam surgir dentro do software. Compreender quais ameaças poderiam se concretizar ajuda o projeto a gerenciar e tratar riscos. Essa informação é útil para os consumidores a jusante demonstrarem a perspicácia e as práticas de segurança do projeto. Certifique-se de que isso seja atualizado para novos recursos ou mudanças disruptivas.

    ASSURANCE-CASE.md is the project's security assessment: security claims C1-C7 argued with evidence, the threat model and trust boundaries, a CWE-by-CWE argument of how common weaknesses are countered, and the residual risk, with a status note on which checks ran on GitHub and what replaces them on GitLab. https://gitlab.com/Progressiverobot/hmailserver/-/blob/master/ASSURANCE-CASE.md


    Suficiente para um badge!

    A documentação do projeto DEVE incluir uma política de divulgação coordenada de vulnerabilidades (CVD), com um prazo claro para resposta. [OSPS-VM-01.01]
    Crie um arquivo SECURITY.md na raiz do diretório, descrevendo a política do projeto para divulgação coordenada de vulnerabilidades. Inclua um método para relatar vulnerabilidades. Estabeleça expectativas sobre como o projeto responderá e tratará problemas relatados.

    SECURITY.md is the coordinated vulnerability disclosure policy: report privately by confidential GitLab issue or Service Desk email; acknowledgement within 5 working days, initial assessment within 10, a fix within 90 days of acknowledgement, and publication when the fix ships or at 90 days, whichever comes first. https://gitlab.com/Progressiverobot/hmailserver/-/blob/master/SECURITY.md


    Suficiente para um badge!

    A documentação do projeto DEVE fornecer um meio de relatar vulnerabilidades de forma privada diretamente aos contatos de segurança do projeto. [OSPS-VM-03.01]
    Forneça um meio para que pesquisadores de segurança relatem vulnerabilidades privadamente ao projeto. Isso pode ser um endereço de e-mail dedicado, um formulário web, ferramentas especializadas do VCS, endereços de e-mail para contatos de segurança ou outros métodos.

    SECURITY.md gives two private routes straight to the maintainers: a confidential GitLab issue with the Security template, visible only to the reporter and the project's members, or email to the Service Desk address contact-project+progressiverobot-hmailserver-86730559-issue-@incoming.gitlab.com, which GitLab files as a confidential issue, so no account is needed. https://gitlab.com/Progressiverobot/hmailserver/-/blob/master/SECURITY.md#reporting-a-vulnerability


    Suficiente para um badge!

    A documentação do projeto DEVE publicar publicamente dados sobre vulnerabilidades descobertas. [OSPS-VM-04.01]
    Forneça informações sobre vulnerabilidades conhecidas em um canal público previsível, como uma entrada CVE, postagem em blog ou outro meio. Na medida do possível, essa informação deve incluir versão(ões) afetada(s), como um consumidor pode determinar se está vulnerável e instruções para mitigação ou remediação.

    SECURITY.md: when a fix ships, the release notes describe the vulnerability, the confidential issue is made public, and a CVE ID requested through GitLab (a CNA) is quoted. The first vulnerability found in this fork, the JScript event-script injection fixed in 6.3.4, is described in CHANGELOG.md on master with the affected versions (6.0.0 to 6.3.3), the configurations exposed and the fix. https://gitlab.com/Progressiverobot/hmailserver/-/blob/master/CHANGELOG.md



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.