BadgeApp

Fundamentos

Geral

Qual é o nome legível do projeto?
Observe que outros projetos podem usar o mesmo nome.

Qual é uma breve descrição do projeto?

hMailServer is a free, open source email server for Microsoft Windows, implementing SMTP, IMAP and POP3. This is a maintained fork brought up to date with a current toolchain, current cryptography, and the transport-security and authentication standards expected of a mail server in 2026.

Qual é a URL do projeto (como um todo)?
https://www.progressiverobot.com/hmailserver-services

Qual é a URL do repositório de controle de versão (pode ser a mesma URL do projeto)?
https://github.com/Progressiverobot/hmailserver

Sob qual(is) licença(s) o projeto é liberado?
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.

Qual(is) linguagem(ns) de programação são usadas para implementar o projeto?
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".

Qual é o nome Common Platform Enumeration (CPE) do projeto (se houver um)?
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.

Outros comentários gerais sobre o projeto:

Controles 22/24 ●

Controles

Criterion [OSPS-AC-01.01]
Atendido

Não atendido

N/A

?

Quando um usuário tentar ler ou modificar um recurso sensível no repositório autorizado do projeto, o sistema DEVE exigir que o usuário complete um processo de autenticação multifator. ^{[OSPS-AC-01.01]}
Imponha autenticação multifator para o sistema de controle de versão do projeto, exigindo que os colaboradores forneçam uma segunda forma de autenticação ao acessar dados sensíveis ou modificar configurações do repositório. Passkeys são aceitáveis para este controle.

The only account able to modify the repository or read sensitive data is the maintainer (chrisholloway5, repository admin); the one other collaborator holds read-only access. The maintainer confirms a cryptographic second factor (authenticator app / passkey) is enabled on that account, and GitHub enforces the MFA challenge at authentication time. GitHub has additionally required 2FA for active code contributors platform-wide since 2023. Enabling the org-wide 2FA requirement is planned so the policy is enforced by setting rather than by practice. See https://github.com/Progressiverobot/hmailserver/settings/access

Criterion [OSPS-AC-02.01]
Atendido

Não atendido

N/A

?

Quando um novo colaborador for adicionado, o sistema de controle de versão DEVE exigir atribuição manual de permissão, ou restringir as permissões do colaborador aos menores privilégios disponíveis por padrão. ^{[OSPS-AC-02.01]}
A maioria dos sistemas públicos de controle de versão são configurados desta maneira. Certifique-se de que o sistema de controle de versão do projeto sempre atribua as menores permissões disponíveis aos colaboradores por padrão quando adicionados, concedendo permissões adicionais somente quando necessário.

The project uses GitHub, which never grants write access automatically: adding a collaborator requires a manual invitation with an explicitly chosen permission level. The Progressiverobot organization's default repository permission for members is 'read' (verified via the GitHub API on 2026-08-21), so any new member receives the lowest available privilege unless a maintainer manually grants more. The repository currently has a single human committer (chrisholloway5) plus dependabot[bot]; no collaborator holds unreviewed elevated access. See https://github.com/Progressiverobot/hmailserver

Criterion [OSPS-AC-03.01]
Atendido

Não atendido

N/A

?

Quando uma confirmação direta for tentada no ramo principal do projeto, um mecanismo de aplicação DEVE impedir que a mudança seja aplicada. ^{[OSPS-AC-03.01]}
Se o VCS for centralizado, defina proteção de ramo no ramo principal no VCS do projeto. Alternativamente, use uma abordagem descentralizada, como a do kernel Linux, onde as mudanças são primeiro propostas em outro repositório, e mesclar mudanças no repositório principal requer um ato separado específico.

An active branch ruleset ('Protect master: changes arrive by pull request') now enforces that changes to master arrive via pull request, and additionally blocks branch deletion and force pushes. Repository administrators hold a logged bypass — every bypass is recorded and visible in the ruleset insights — so the enforcement mechanism exists for all contributors while the sole maintainer's release workflow continues. Release tags are protected by a second, separate ruleset. See https://github.com/Progressiverobot/hmailserver/rules

Criterion [OSPS-AC-03.02]
Atendido

Não atendido

N/A

?

Quando for feita uma tentativa de excluir o ramo principal do projeto, o sistema de controle de versão DEVE tratar isso como uma atividade sensível e exigir confirmação explícita de intenção. ^{[OSPS-AC-03.02]}
Defina proteção de ramo no ramo principal no sistema de controle de versão do projeto para evitar exclusão.

master is the repository's default branch (verified via the GitHub API), and GitHub refuses deletion of the default branch outright: a push deleting it is rejected server-side ('refusing to delete the current branch'), the web UI offers no delete control for it, and the REST API returns an error. Deleting master would first require an administrator to deliberately change the default branch in repository settings — an explicit, separate confirmation of intent for a sensitive activity, satisfying this control. See https://github.com/Progressiverobot/hmailserver/branches

Criterion [OSPS-BR-01.01]
Atendido

Não atendido

N/A

?

Quando um pipeline de CI/CD opera com metadados não confiáveis, esses parâmetros DEVEM ser higienizados e validados antes de serem usados no pipeline. ^{[OSPS-BR-01.01]}
Os pipelines de CI/CD devem sanitizar (citar, escapar ou sair com valores esperados) todas as entradas de metadados que correspondam a fontes não confiáveis. Isso inclui dados como nomes de branch, mensagens de commit, tags, títulos de pull requests e informações de autoria.

All 10 CI/CD workflows on master were reviewed. No workflow uses pull_request_target, and no workflow interpolates untrusted metadata into shell 'run:' steps: no reference to PR titles/bodies, commit messages (head_commit/commits), branch names (github.head_ref/github.ref_name), or author/actor info appears anywhere. In PR-triggered CI the only github.event reference is github.event.pull_request.head.repo.full_name, used solely in 'if:' expression equality checks (ci.yml) — GitHub expression context, not a shell surface. The one pipeline that consumes genuinely untrusted third-party metadata, upstream-watch.yml, treats upstream commit subjects strictly as data: written to a file, emitted via a GITHUB_OUTPUT heredoc whose lines are SHA-prefixed, and passed as an env variable into a quoted gh argument. Maintainer-created release tags are consumed via env variables (sign-release.yml RELEASE_TAG/INPUT_TAG, sbom.yml TAG). Trusted-collaborator workflow_dispatch inputs (in scope for OSPS-BR-01.04 rather than this control) are passed via env (codeql.yml BUILD_CONFIGURATION, upstream-watch.yml UPSTREAM/SINCE_DAYS) or constrained by GitHub-validated choice enums (server-build.yml configuration: Release/Debug, inlined but limited to those two values); installer-smoke.yml inlines a free-form dispatch input (release_tag) into a run: step, but that input is only settable by collaborators with write access, not an untrusted source. See https://github.com/Progressiverobot/hmailserver/tree/master/.github/workflows

Criterion [OSPS-BR-01.03]
Atendido

Não atendido

N/A

?

Quando um pipeline de CI/CD opera em snapshots de código não confiável, ele DEVE impedir o acesso a credenciais e ativos privilegiados de CI/CD. ^{[OSPS-BR-01.03]}
Os pipelines de CI/CD devem isolar snapshots de código não confiável de credenciais e ativos privilegiados. Em particular, os projetos devem ter cuidado para garantir que os workflows que compilam ou executam código antes da revisão por um colaborador não tenham acesso às credenciais de CI/CD.

Every workflow that operates on untrusted PR snapshots (ci.yml, codeql.yml's C# job, dependency-review.yml, and verify-binary-provenance.yml — all triggered on pull_request to master) runs on ephemeral GitHub-hosted runners with top-level 'permissions: contents: read', and the repository's default workflow token permission is read-only. No workflow references any secret (zero 'secrets.' occurrences across all workflows on master), the repository has zero Actions or Dependabot secrets configured, and no workflow uses pull_request_target, so untrusted PR code has no credentials to reach. The privileged asset — the single self-hosted Windows runner — is used only by server-build.yml (workflow_dispatch only) and by codeql.yml's C++ job, which is explicitly gated by "if: github.event_name == 'schedule' || github.event_name == 'workflow_dispatch'", so fork PR code never executes on it. Workflows holding write permissions run only on trusted triggers: sign-release.yml (top-level permissions: {}; job-level id-token/contents write; release-created or maintainer dispatch), sbom.yml (job-level contents: write; push to master, release-created, or dispatch), and upstream-watch.yml/scorecard.yml (schedule, push to master, or dispatch). ci.yml additionally gates its coverage-upload job to same-repo PRs via a head.repo.full_name check. See https://github.com/Progressiverobot/hmailserver/tree/master/.github/workflows

Criterion [OSPS-BR-03.01]
Atendido

Não atendido

N/A

?

Quando o projeto listar um URI como um canal oficial do projeto, esse URI DEVE ser entregue exclusivamente usando canais criptografados. ^{[OSPS-BR-03.01]}
Configure os sites do projeto e os sistemas de controle de versão para usar canais criptografados como SSH ou HTTPS para transmissão de dados. Certifique-se de que todas as ferramentas e domínios referenciados na documentação do projeto só possam ser acessados por meio de canais criptografados.

Every official project channel is HTTPS-only: the repository, Releases, Issues, and Discussions at https://github.com/Progressiverobot/hmailserver (GitHub also serves git over SSH/HTTPS only), the maintainer's site https://www.progressiverobot.com, and the upstream forum linked from SUPPORT.md (https://www.hmailserver.com/forum/). A scan of all markdown documentation found no project channel offered over plain HTTP. Two third-party dependency download links in the build instructions (openssl.org, boost.org) are written as http:// — both hosts redirect to HTTPS and neither is a project channel, but updating them is recommended. See https://github.com/Progressiverobot/hmailserver/blob/master/README.md

Criterion [OSPS-BR-03.02]
Atendido

Não atendido

N/A

?

Quando o projeto listar uma URI como canal de distribuição oficial, esse canal DEVE ser protegido contra ataques de adversário no meio (adversary-in-the-middle) usando canais criptograficamente autenticados. ^{[OSPS-BR-03.02]}
Os artefatos distribuídos pelo projeto devem ser distribuídos por meio de canais que garantam integridade e autenticidade. O uso de HTTPS para downloads, versões assinadas ou distribuição por meio de gerenciadores de pacotes confiáveis são métodos aceitáveis para proteger contra ataques de adversário no meio.

The only official distribution channel is GitHub Releases at https://github.com/Progressiverobot/hmailserver/releases, delivered exclusively over HTTPS (TLS-authenticated). In addition, every release asset is signed: sign-release.yml signs each asset with Sigstore cosign keyless and verifies each signature before uploading it, so releases (e.g. v6.2.21) ship the installer plus .cosign.bundle files and signed CycloneDX/SPDX SBOMs. Release tags are protected by an active 'Protect release tags' ruleset. Together these provide cryptographic authentication of the channel and the artifacts. See https://github.com/Progressiverobot/hmailserver/releases

Criterion [OSPS-BR-07.01]
Atendido

Não atendido

N/A

?

O projeto DEVE impedir o armazenamento não intencional de dados sensíveis não criptografados, como segredos e credenciais, no sistema de controle de versão. ^{[OSPS-BR-07.01]}
Configure .gitignore ou equivalente para excluir arquivos que possam conter informações sensíveis. Use hooks de pré-commit e ferramentas de varredura automatizadas para detectar e prevenir a inclusão de dados sensíveis em commits.

GitHub secret scanning is enabled and secret scanning push protection is enabled for the repository (verified via the GitHub API on 2026-08-21: secret_scanning=enabled, secret_scanning_push_protection=enabled), so a push containing a detected credential is blocked before it lands in version control. A root .gitignore additionally excludes logs (.log), user-specific files (.user, *.suo), and build outputs. Dependabot security updates are also enabled. See https://github.com/Progressiverobot/hmailserver/blob/master/.gitignore

Criterion [OSPS-DO-01.01]
Atendido

Não atendido

N/A

?

Quando o projeto tiver feito uma versão, a documentação do projeto DEVE incluir guias do usuário para todas as funcionalidades básicas. ^{[OSPS-DO-01.01]}
Crie guias do usuário ou documentação para todas as funcionalidades básicas do projeto, explicando como instalar, configurar e usar os recursos do projeto. Se houver quaisquer ações perigosas ou destrutivas conhecidas disponíveis, inclua avisos altamente visíveis.

The project releases frequently (20+ releases in Aug 2026) and its documentation covers all basic functionality: the 544-line README documents capabilities, installing (including unattended install and supported platforms), administration (Control Panel GUI, REST admin API, client autoconfiguration), an extensive Configuration reference (~170 lines of settings with defaults and explanations), building, and running tests. Operator runbooks in hmailserver/docs cover diagnosing stalled mail, upgrading, migrating database backends, and high availability. All of this is on master and linked from the README's contents section. See https://github.com/Progressiverobot/hmailserver/blob/master/README.md

Criterion [OSPS-DO-02.01]
Atendido

Não atendido

N/A

?

Quando o projeto tiver feito uma versão, a documentação do projeto DEVE incluir um guia para relatar defeitos. ^{[OSPS-DO-02.01]}
É recomendado que os projetos usem o rastreador de issues padrão do seu VCS. Se uma fonte externa for usada, certifique-se de que a documentação do projeto e o guia de contribuição expliquem de forma clara e visível como usar o sistema de relatório. É recomendado que a documentação do projeto também estabeleça expectativas sobre como os defeitos serão triados e resolvidos.

The project has a clear defect-reporting guide on master: .github/SUPPORT.md directs defect reports to GitHub Issues and specifies exactly what a useful report contains (debug log excerpt, ERROR log, version, Windows version, database backend, expected behavior, reproducibility), redirects suspected security problems to private reporting via SECURITY.md, routes questions to Discussions, and sets triage expectations ('What to expect': reports are read, no response-time guarantee, fixes claimed only with a reproducing test). A structured bug_report.yml issue template with required fields (version, OS, database) enforces this at filing time, and the README links to both. See https://github.com/Progressiverobot/hmailserver/blob/master/.github/SUPPORT.md

Criterion [OSPS-GV-02.01]
Atendido

Não atendido

N/A

?

O projeto DEVE ter um ou mais mecanismos para discussões públicas sobre mudanças propostas e obstáculos de uso. ^{[OSPS-GV-02.01]}
Estabeleça um ou mais mecanismos para discussões públicas dentro do projeto, como listas de discussão, mensagens instantâneas ou rastreadores de issues, para facilitar a comunicação aberta e feedback.

Public discussion happens on the GitHub issue tracker, which is enabled and actively used (34 issues, 32 closed, answered by the maintainer), with structured bug-report and feature-request issue templates and a pull-request template for proposed changes; GitHub Discussions is also enabled on the repository (API-verified: has_issues and has_discussions both true). See https://github.com/Progressiverobot/hmailserver/issues

Criterion [OSPS-GV-03.01]
Atendido

Não atendido

N/A

?

A documentação do projeto DEVE incluir uma explicação do processo de contribuição, ou declarar claramente que contribuições públicas não são aceitas ^{[OSPS-GV-03.01]}
Crie um CONTRIBUTING.md ou diretório CONTRIBUTING/ para delinear o processo de contribuição incluindo as etapas para enviar mudanças e se engajar com os mantenedores do projeto.

.github/CONTRIBUTING.md on master explains the contribution process end to end: build instructions (toolchain, external libs, solutions, helper scripts), testing policy (keep the regression suite green, add tests for behavior changes), pull-request guidelines (branch from master, one logical change per PR, parameterised SQL only, INI-settings pattern for new features), an architecture orientation, and AGPLv3 licensing of contributions. See https://github.com/Progressiverobot/hmailserver/blob/master/.github/CONTRIBUTING.md

Criterion [OSPS-LE-02.01]
Atendido

Não atendido

N/A

?

A licença do código-fonte DEVE atender à Definição de Código Aberto da OSI ou à Definição de Software Livre da FSF. ^{[OSPS-LE-02.01]}
Adicione um arquivo LICENSE ao repositório do projeto com uma licença que seja uma licença aprovada pela Open Source Initiative (OSI), ou uma licença livre aprovada pela Free Software Foundation (FSF). Exemplos de tais licenças incluem MIT, BSD 2-clause, BSD 3-clause revisada, Apache 2.0, Lesser GNU General Public License (LGPL) e a GNU General Public License (GPL). Lançar para o domínio público atende a este controle se não houver outros obstáculos como patentes.

The source code is licensed AGPL-3.0, which is both OSI-approved and an FSF free software license. The LICENSE file at the repository root contains the full GNU Affero General Public License v3 text (verified by reading the file on master). See https://github.com/Progressiverobot/hmailserver/blob/master/LICENSE

Criterion [OSPS-LE-02.02]
Atendido

Não atendido

N/A

?

A licença dos ativos de software lançados DEVE atender à Definição de Código Aberto da OSI ou à Definição de Software Livre da FSF. ^{[OSPS-LE-02.02]}
Se uma licença diferente for incluída com ativos de software lançados, certifique-se de que seja uma licença aprovada pela Open Source Initiative (OSI), ou uma licença livre aprovada pela Free Software Foundation (FSF). Exemplos de tais licenças incluem MIT, BSD 2-clause, BSD 3-clause revisada, Apache 2.0, Lesser GNU General Public License (LGPL) e a GNU General Public License (GPL). Note que a licença para os ativos de software lançados pode ser diferente do código-fonte.

Released assets (Windows installer + SPDX/CycloneDX SBOMs, all cosign-signed) distribute the same AGPL-3.0 software as the source; no separate proprietary license is applied to releases. The installer displays the AGPL-3.0 text at install time (LicenseFile=license.rtf in section_setup.iss; hmailserver/installation/License.rtf verified to contain the GNU AGPL text). AGPL-3.0 is OSI-approved and FSF-free. See https://github.com/Progressiverobot/hmailserver/blob/master/hmailserver/installation/License.rtf

Criterion [OSPS-LE-03.01]
Atendido

Não atendido

N/A

?

A licença do código-fonte DEVE ser mantida no arquivo LICENSE, arquivo COPYING, diretório LICENSES/ ou diretório LICENSE/ do repositório correspondente. ^{[OSPS-LE-03.01]}
Inclua a licença do código-fonte do projeto no arquivo LICENSE, arquivo COPYING, diretório LICENSES/ ou diretório LICENSE/ do projeto para fornecer visibilidade e clareza sobre os termos de licenciamento. O nome do arquivo PODE ter uma extensão. Se o projeto tiver vários repositórios, garanta que cada repositório inclua o arquivo de licença.

The AGPL-3.0 license text is maintained in the LICENSE file at the root of the project's single authoritative repository; verified present on the master branch. See https://github.com/Progressiverobot/hmailserver/blob/master/LICENSE

Criterion [OSPS-LE-03.02]
Atendido

Não atendido

N/A

?

A licença dos ativos de software lançados DEVE ser incluída no código-fonte lançado, ou em um arquivo LICENSE, arquivo COPYING, ou diretório LICENSE/ junto aos ativos de lançamento correspondentes. ^{[OSPS-LE-03.02]}
Inclua a licença dos ativos de software lançados do projeto no código-fonte lançado, ou em um arquivo LICENSE, arquivo COPYING ou diretório LICENSE/ ao lado dos ativos de versão correspondentes para fornecer visibilidade e clareza sobre os termos de licenciamento. O nome do arquivo PODE ter uma extensão. Se o projeto tiver múltiplos repositórios, certifique-se de que cada repositório inclua o arquivo de licença.

Every GitHub release automatically includes the source archives, which contain the root LICENSE (AGPL-3.0). In addition, the installer asset itself embeds the license: section_setup.iss sets LicenseFile=license.rtf and hmailserver/installation/License.rtf (verified to be the GNU AGPL text) is shown to the user during setup, so the license accompanies the released software assets. See https://github.com/Progressiverobot/hmailserver/releases/latest

Criterion [OSPS-QA-01.01]
Atendido

Não atendido

N/A

?

O repositório de código-fonte do projeto DEVE ser publicamente legível em uma URL estática. ^{[OSPS-QA-01.01]}
Use um VCS comum como GitHub, GitLab ou Bitbucket. Certifique-se de que o repositório seja publicamente legível. Evite duplicação ou espelhamento de repositórios a menos que documentação altamente visível esclareça a fonte primária. Evite mudanças frequentes no repositório que impactariam a URL do repositório. Certifique-se de que o repositório seja público.

The project's source code is publicly readable at the static URL https://github.com/Progressiverobot/hmailserver (API-verified: visibility public, not archived, default branch master). This is the single authoritative repository; the README identifies it as the maintained fork of the discontinued upstream project, so there is no ambiguity about the primary source. See https://github.com/Progressiverobot/hmailserver

Criterion [OSPS-QA-01.02]
Atendido

Não atendido

N/A

?

O sistema de controle de versão DEVE conter um registro publicamente legível de todas as alterações feitas, quem fez as alterações e quando as alterações foram feitas. ^{[OSPS-QA-01.02]}
Use um VCS comum como GitHub, GitLab ou Bitbucket para manter um histórico de commits publicamente legível. Evite esmagar ou reescrever commits de uma forma que obscureça o autor de quaisquer commits.

The repository keeps a publicly readable git history on GitHub recording what changed, who changed it, and when: every commit carries author name, email, and timestamp (verified in the clone: commits authored by chrisholloway5 with full dates). History totals 494 commits by the maintainer plus 4 by dependabot[bot], with no history rewriting that obscures authorship. See https://github.com/Progressiverobot/hmailserver/commits/master

Criterion [OSPS-QA-02.01]
Atendido

Não atendido

N/A

?

Quando o sistema de gerenciamento de pacotes suportar, o repositório de código-fonte DEVE conter uma lista de dependências que representa as dependências diretas da linguagem. ^{[OSPS-QA-02.01]}
Isso pode assumir a forma de um arquivo de dependências de gerenciador de pacotes ou linguagem que enumera todas as dependências diretas, como package.json, Gemfile ou go.mod.

NuGet is the package manager for the .NET code, and the repository enumerates direct language dependencies in-tree: 26 .csproj files declare pinned PackageReference entries (e.g. hmailserver/source/Tools/ControlPanel/ControlPanel.csproj lists WPF-UI 4.3.0, LiveChartsCore.SkiaSharpView.WPF 2.0.5, QRCoder 1.8.0, System.Management 10.0.11, System.ServiceProcess.ServiceController 10.0.11), plus three packages.config files under hmailserver/test/. Dependabot monitors the nuget and github-actions ecosystems (.github/dependabot.yml). The native C++ server has no package management system (the criterion applies "when the package management system supports it"); its vendored dependencies are kept under libraries/ with per-library license files and a README, and Boost is built via libraries/build-dependencies.ps1. https://github.com/Progressiverobot/hmailserver/blob/master/.github/dependabot.yml

Criterion [OSPS-QA-04.01]
Atendido

Não atendido

N/A

?

Projetos com múltiplos repositórios DEVEM documentar uma lista das bases de código que fazem parte do projeto. ^{[OSPS-QA-04.01]}
Documente quaisquer repositórios de código de subprojetos adicionais produzidos pelo projeto e compilados em uma versão de lançamento. Esta documentação deve incluir o status e a intenção da respectiva base de código.

This criterion applies to projects with multiple repositories. hMailServer is a single-repository project: the C++ server, .NET Control Panel and tools, tests, fuzz harnesses, installer scripts, and documentation all live in the one authoritative repo, and releases are built entirely from it. There are no additional project codebases to list. See https://github.com/Progressiverobot/hmailserver

Criterion [OSPS-QA-05.01]
Atendido

Não atendido

N/A

?

O sistema de controle de versão NÃO DEVE conter artefatos executáveis gerados. ^{[OSPS-QA-05.01]}
Remova artefatos executáveis gerados no sistema de controle de versão do projeto. É recomendado que qualquer cenário em que um artefato executável gerado apareça como crítico para um processo, como testes, ele deve ser gerado no momento da compilação ou armazenado separadamente e buscado durante uma etapa de pipeline específica e bem documentada.

The repo tracks a generated executable: hmailserver/source/Tools/Interop/Interop.hMailServer.dll, the COM interop wrapper generated from the project's own type library, deliberately committed (disposition "retain-generated" in the binary inventory) so the .NET tools build without a registered typelib. The Baseline expects such artifacts to be produced at build time or fetched in a documented pipeline step. Compensating control: every committed binary is SHA-256-inventoried and verify-binary-provenance fails CI on any unlisted or changed binary — but the artifact remains in VCS. See https://github.com/Progressiverobot/hmailserver/blob/master/hmailserver/docs/third-party-binaries.json

Criterion [OSPS-QA-05.02]
Atendido

Não atendido

N/A

?

O sistema de controle de versão NÃO DEVE conter artefatos binários não revisáveis. ^{[OSPS-QA-05.02]}
Não adicione nenhum artefato binário não revisável ao sistema de controle de versão do projeto. Isso inclui binários de aplicativos executáveis, arquivos de biblioteca e artefatos similares. Não inclui recursos como imagens gráficas, arquivos de som ou música e conteúdo similar normalmente armazenado em formato binário.

master tracks ~40 unreviewable binaries: vendored third-party DLLs/EXE/MSIs (7za.exe, MariaDB Connector/C libmysql.dll and plugins, MSVC CRT redistributables, SQL CE MSIs, atl70.dll, isxdl.dll, ISC.dll) shipped by the installer. Compensating control: each is inventoried with SHA-256, version, publisher, license, upstream URL and disposition, and verify-binary-provenance fails CI on any unlisted or changed binary. Several are marked remove-duplicate/retain-review for cleanup, but the binaries remain in version control today, so this MUST is not met. See https://github.com/Progressiverobot/hmailserver/blob/master/hmailserver/docs/third-party-binaries.json

Criterion [OSPS-VM-02.01]
Atendido

Não atendido

N/A

?

A documentação do projeto DEVE conter contatos de segurança. ^{[OSPS-VM-02.01]}
Crie um arquivo security.md (ou com nome similar) que contenha contatos de segurança para o projeto.

.github/SECURITY.md on master (surfaced on the repository's Security tab) provides the project's security contact: private reporting via GitHub Security Advisories at https://github.com/Progressiverobot/hmailserver/security/advisories/new (private vulnerability reporting API-verified as enabled), with a documented fallback channel for reporters who cannot use GHSA, plus response-time targets and a coordinated disclosure policy. See https://github.com/Progressiverobot/hmailserver/blob/master/.github/SECURITY.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/14187/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 Progressive Robot e aos contribuidores do selo de melhores práticas OpenSSF.

hMailServer

Fundamentos

Geral

Controles 22/24 ●

Controles