hMailServer

遵循以下最佳实践的项目将能够自愿的自我认证，并显示他们已经实现了核心基础设施计划（OpenSSF）徽章。

没有一套可以保证软件永远不会有缺陷或漏洞的做法；如果规范或假设是错误的，即使合适的方法也可能失败。也没有哪些做法可以保证一个项目能够维持健康和运作良好的开发者社区。但是，遵循最佳做法可以帮助改善项目的成果。例如，一些做法可以在发布之前进行多人评估，这可以帮助您找到其他难以找到的技术漏洞，并帮助建立信任，并希望不同公司的开发人员之间进行重复的交互。要获得徽章，必须满足所有“必须”和“禁止”的条款，满足所有“应该”条款或有合适的理由，和所有“建议”条款必须满足或未满足（至少希望考虑）。欢迎通过 GitHub网站创建问题或提出请求进行反馈。另外还有一个一般讨论邮件列表。

如果这是您的项目，请在项目页面上显示您的基准徽章状态！基准徽章状态如下所示： 项目14949的基准徽章等级为in_progress 以下是如何嵌入基准徽章：
您可以通过将其嵌入到Markdown文件中来显示您的基准徽章状态：
[![OpenSSF Baseline](https://www.bestpractices.dev/projects/14949/baseline)](https://www.bestpractices.dev/projects/14949)
或者将其嵌入到HTML中：
<a href="https://www.bestpractices.dev/projects/14949"><img src="https://www.bestpractices.dev/projects/14949/baseline"></a>


这些是基准等级3的标准。 这些是标准版本 v2026.08.28。

Baseline Series: 基准等级1 基准等级2 基准等级3

        

 基本

  • 常规

    请注意，其他项目可能使用相同的名称。

    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.

    请使用 SPDX许可证表达格式;例子包括“Apache-2.0”，“BSD-2-Clause”，“BSD-3-Clause”，“GPL-2.0+”，“LGPL-3.0 +”，“MIT”和“(BSD-2-Clause OR Ruby)”。
    如果有多种语言，请将它们列为逗号分隔值（可选空格），并将它们从最多到最少使用。如果有长列表，请至少列出前三个最常见的列表。如果没有语言（例如，这是仅文档或仅测试项目），请使用单个字符“ - ”。请使用每种语言的常规大小写，例如“JavaScript”。
    通用平台枚举（CPE）是用于信息技术系统，软件和软件包的结构化命名方案。在报告漏洞时，它可用于多个系统和数据库。

    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.

 控制 17/21 ●

  • 控制


    足够获得徽章！

    当在CI/CD管道中为作业分配权限时，源代码或配置必须仅分配相应活动所需的最低权限。 [OSPS-AC-04.02]
    配置项目的CI/CD流水线，默认为用户和服务分配最低可用权限，仅在特定任务需要时才提升权限。在某些版本控制系统中，这可以在组织或代码仓库级别实现。如果不行，请在流水线的顶层设置权限。

    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


    足够获得徽章！

    接受可信协作者输入的 CI/CD 流水线在流水线中使用该输入之前，必须对其进行清理和验证。 [OSPS-BR-01.04]
    CI/CD 流水线应对显式工作流执行中的所有协作者输入进行清理（引用、转义或在期望值时退出）。虽然协作者通常是可信的，但工作流的手动输入无法经过审查，可能被账户劫持或内部威胁所滥用。

    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


    足够获得徽章！

    当创建正式发布版本时，该发布版本中的所有资产必须明确关联到发布标识符或资产的其他唯一标识符。 [OSPS-BR-02.02]
    为项目生成的每个软件资产分配唯一的版本标识符，遵循一致的命名约定或编号方案。示例包括SemVer、CalVer或git提交ID。

    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


    足够获得徽章！

    项目必须定义管理项目使用的秘密和凭证的策略。该策略应包括存储、访问和轮换秘密和凭证的指南。 [OSPS-BR-07.02]
    记录项目内如何管理和使用秘密和凭证。这应包括如何存储秘密（例如，使用秘密管理工具）、如何控制访问以及如何轮换或更新秘密的详细信息。确保敏感信息不会硬编码在源代码中或存储在版本控制系统中。

    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


    足够获得徽章！

    当项目已发布版本时，项目文档必须包含验证发布资产完整性和真实性的说明。 [OSPS-DO-03.01]
    项目中的说明应包含所使用技术、要运行的命令以及预期输出的信息。如果可能，避免将此文档存储在构建和发布流水线的相同位置，以避免单一漏洞同时危及软件和验证软件完整性的文档。

    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


    足够获得徽章！

    当项目已发布版本时，项目文档必须包含验证软件发布作者的预期身份的说明。 [OSPS-DO-03.02]
    预期身份可能采用用于签名的密钥ID、来自sigstore证书的颁发者和身份或其他类似形式。如果可能，避免将此文档存储在构建和发布流水线的相同位置，以避免单一漏洞同时危及软件和验证软件完整性的文档。

    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


    足够获得徽章！

    当项目已发布版本时，项目文档必须包含关于每个发布版本支持范围和持续时间的描述性声明。 [OSPS-DO-04.01]
    为了传达项目发布的软件资产的支持范围和持续时间，项目应有SUPPORT.md文件、SECURITY.md中的"支持"部分或其他文档，说明支持生命周期，包括每个发布版本的预期支持持续时间、提供的支持类型（例如，错误修复、安全更新）以及获取支持的任何相关策略或程序。

    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


    足够获得徽章！

    当项目已发布版本时，项目文档必须提供描述性声明说明何时发布版本或版本将不再接收安全更新。 [OSPS-DO-05.01]
    为了传达安全修复的支持范围和持续时间，项目应有SUPPORT.md或其他文档，说明项目的安全更新策略。

    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


    足够获得徽章！

    项目文档必须制定一项政策，规定在向代码协作者授予提升权限以访问敏感资源之前对其进行审核。 [OSPS-GV-04.01]
    在项目文档中发布可执行的策略，要求在授予对敏感资源（例如合并批准或访问秘密）的提升权限之前审查和批准代码协作者。建议审查包括建立可证明的身份血统，例如确认贡献者与已知可信组织的关联。

    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


    不足以获得徽章。

    当项目已发布版本时，所有编译的已发布软件资产必须附带软件物料清单。 [OSPS-QA-02.02]
    建议在构建时使用经过准确性审查的工具自动生成SBOM。这使用户能够以标准化的方式将此数据与其环境中的其他项目一起提取。

    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


    足够获得徽章！

    当项目已发布包含多个源代码仓库的版本时，所有子项目必须执行与主代码库一样严格或更严格的安全要求。 [OSPS-QA-04.02]
    项目生成并编译到发布版本中的任何其他子项目代码仓库必须根据相应代码库的状态和意图执行安全要求。除了遵循相应的OSPS基线要求外，这还可能包括要求进行安全审查、确保其没有漏洞以及确保其没有已知的安全问题。

    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


    足够获得徽章！

    项目文档必须清楚地记录测试的运行时间和方式。 [OSPS-QA-06.02]
    在贡献文档中添加一个章节，说明如何在本地运行测试以及如何在CI/CD管道中运行测试。文档应说明测试的测试内容以及如何解释测试结果。

    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


    足够获得徽章！

    项目文档必须包含一项政策，规定对项目生成的软件所做的所有重大更改都应在自动化测试套件中添加或更新相应功能的测试。 [OSPS-QA-06.03]
    在贡献文档中添加一个章节，说明添加或更新测试的政策。该政策应说明什么是重大更改以及应该添加或更新哪些测试。

    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


    不足以获得徽章。

    当向主分支提交时，项目的版本控制系统必须在合并之前要求至少一名非作者人工审批更改。 [OSPS-QA-07.01]
    配置项目的版本控制系统，要求在合并到发布分支或主分支之前至少有一名非作者人工审批更改。这可以通过要求拉取请求在合并之前必须由至少另一位协作者审查和批准来实现。

    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


    足够获得徽章！

    当项目发布版本时，项目必须执行威胁建模和攻击面分析，以理解和防护针对系统内关键代码路径、函数和交互的攻击。 [OSPS-SA-03.02]
    威胁建模是一项活动，其中项目查看代码库、相关流程和基础设施、接口、关键组件，并"像黑客一样思考"，集思广益探讨系统可能如何被破坏或受到损害。每个识别的威胁都会被列出，以便项目可以考虑如何主动避免或关闭可能出现的任何漏洞/脆弱点。确保为新功能或破坏性更改更新此分析。

    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


    足够获得徽章！

    软件组件中不影响本项目的任何漏洞必须在VEX文档中予以记录，通过补充不可利用性的详细信息来完善漏洞报告。 [OSPS-VM-04.02]
    建立VEX供给源，传达已知漏洞的可利用性状态，包括评估细节或任何阻止易受攻击代码执行的缓解措施。

    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


    足够获得徽章！

    项目文档必须包含一项政策，为与漏洞和许可证相关的软件成分分析（SCA）发现结果的修复设定阈值。 [OSPS-VM-05.01]
    在项目中记录一项政策，定义与漏洞和许可证相关的SCA发现的修复阈值。包括识别、优先级排序和修复这些发现的流程。

    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


    足够获得徽章！

    项目文档必须包含一项政策，要求在任何发布之前处理软件成分分析（SCA）违规问题。 [OSPS-VM-05.02]
    在项目中记录一项政策，在任何发布之前解决适用的软件组成分析结果，并添加状态检查以验证在发布之前符合该政策。

    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


    不足以获得徽章。

    对项目代码库的所有更改都必须根据针对恶意依赖项和依赖项中已知漏洞的书面政策进行自动评估，并在出现违规情况时予以阻止，但已声明并抑制为不可利用的情况除外。 [OSPS-VM-05.03]
    在项目的版本控制系统中创建一个状态检查，对代码库的所有更改运行软件组成分析工具。要求状态检查在更改可以合并之前必须通过。

    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


    足够获得徽章！

    项目文档必须包含一项政策，为静态应用程序安全测试（SAST）发现结果的修复设定阈值。 [OSPS-VM-06.01]
    在项目中记录一项政策，定义静态应用程序安全测试（SAST）发现的修复阈值。包括识别、优先级排序和修复这些发现的流程。

    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


    不足以获得徽章。

    对项目代码库的所有更改都必须根据书面政策针对安全弱点进行自动评估，并在出现违规情况时予以阻止，但已声明并抑制为不可利用的情况除外。 [OSPS-VM-06.02]
    在项目的版本控制系统中创建一个状态检查，对代码库的所有更改运行静态应用程序安全测试（SAST）工具。要求状态检查在更改可以合并之前必须通过。

    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



您可以使用工具和AI系统通过简单的URL提交变更建议，例如 https://www.bestpractices.dev/zh-CN/projects/14949/choose/edit?osps_ac_01_01_status=Met&osps_ac_01_01_justification=GitHub+enforced。请参阅我们的自动化提案系统，了解具体操作方法。 该数据可在社区数据许可协议 – 许可性，版本 2.0 (CDLA-Permissive-2.0)下获取。这意味着数据接收方可以共享数据，无论是否经过修改，只要数据接收方在共享数据时提供本协议文本。请注明christopher holloway和OpenSSF最佳实践徽章贡献者。

项目徽章条目拥有者： christopher holloway.
最后更新于 2026-09-26 05:28:20 UTC, 最后更新于 2026-09-26 06:16:51 UTC。 最后在 2026-09-26 05:45:21 UTC 获得通过徽章。