hMailServer

本サイトが提示する下記のベストプラクティスを実行するプロジェクトは、Open Source Security Foundation (OpenSSF) バッジを達成したことを自主的に自己認証し、そのことを外部に示すことができます。

ソフトウェアに欠陥や脆弱性がないことを保証する手立てはありません。形式論的な証明ができたとしても、仕様や前提が間違っていると誤動作の可能性があります。また、プロジェクトが健全で、かつ機能的な開発コミュニティであり続けることを保証する手立てもありません。しかし、ベストプラクティスの採用は、プロジェクトの成果の向上に寄与する可能性があります。たとえば、いくつものベストプラクティスがリリース前の複数人によるレビューを定めていますが、それによりレビュー以外では発見困難な技術的脆弱性を見つけるのを助け、同時に異なる企業の開発者間の信頼を築き、さらに交流を続けることに対する意欲を生んでいます。バッジを獲得するには、すべてのMUSTおよびMUST NOT基準を満たさなければなりません。すべてのSHOULD基準も満たさなければなりませんが、正当な理由がある場合は満たさなくても構いません。そしてすべてのSUGGESTED基準も満たさなければなりませんが、満たさないとしても、少なくとも考慮することが望まれます。フィードバックは、 GitHubサイトのissueまたはpull requestとして提示されれば歓迎します。また、議論のためのメールリストも用意されています。

私たちは多言語で情報を提供していますが、翻訳版に矛盾や意味の不一致がある場合は、英語版を正式な記述とします。
これがあなたのプロジェクトである場合は、プロジェクトページにベースラインバッジステータスを表示してください！ベースラインバッジステータスは次のようになります： プロジェクト14187のベースラインバッジレベルはin_progressです ベースラインバッジを埋め込む方法は次のとおりです：
ベースラインバッジステータスを表示するには、マークダウンファイルに以下を埋め込みます：
[![OpenSSF Baseline](https://www.bestpractices.dev/projects/14187/baseline)](https://www.bestpractices.dev/projects/14187)
または、HTMLに以下を埋め込みます：
<a href="https://www.bestpractices.dev/projects/14187"><img src="https://www.bestpractices.dev/projects/14187/baseline"></a>


これらはベースラインレベル1の基準です。 これらは基準バージョン v2026.08.28 の評価項目です。

Baseline Series: ベースラインレベル1 ベースラインレベル2 ベースラインレベル3

        

 基本的情報

  • 一般

    他のプロジェクトが同じ名前を使用していないか注意してください。

    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.

    SPDXライセンスの表現形式を使用してください。 例：「Apache-2.0」、「BSD-2-Clause」、「BSD-3-Clause」、「GPL-2.0+」、「LGPL-3.0+」、「MIT」、「(BSD-2-Clause OR Ruby)」。一重引用符または二重引用符を含めないでください。
    複数の言語がある場合は、コンマを区切り（スペースを入れてもよい）としてリストし、使用頻度の高いものから順に並べます。使用言語が多くある場合は、少なくとも最初の3つの最も多く使われるものをリストアップしてください。言語がない場合（例：ドキュメントだけ、またはテスト専用のプロジェクトの場合）、1文字 " - "を使用します。言語ごとにある大文字・小文字の慣用を踏襲してください（例：「JavaScript」）。
    Common Platform Enumeration（CPE）は、情報技術（IT）システム、ソフトウェア、およびパッケージのための構造化された命名体系です。脆弱性を報告する際に、多くのシステムやデータベースで使用されています。

 管理策 22/24 ●

  • 管理策


    バッジには十分です！

    ユーザーがプロジェクトの権威リポジトリにある機密リソースを読み取ったり変更したりしようとする場合、システムは多要素認証プロセスの完了をユーザーに要求しなければなりません。 [OSPS-AC-01.01]
    プロジェクトのバージョン管理システムに多要素認証を強制し、協力者が機密データにアクセスしたりリポジトリ設定を変更したりする際に第2の認証形式を提供するよう要求します。パスキーはこの管理として許容されます。

    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


    バッジには十分です！

    新しい協力者が追加される場合、バージョン管理システムは手動による権限割り当てを要求するか、デフォルトで協力者の権限を最低利用可能な特権に制限しなければなりません。 [OSPS-AC-02.01]
    ほとんどの公開バージョン管理システムは、この方法で設定されています。プロジェクトのバージョン管理システムが、協力者を追加する際にデフォルトで常に利用可能な最低限の権限を割り当て、必要な場合にのみ追加の権限を付与するように設定してください。

    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


    バッジには十分です！

    プロジェクトのプライマリブランチに直接コミットが試行された場合、強制メカニズムが変更の適用を防止しなければなりません。 [OSPS-AC-03.01]
    バージョン管理システムが集中型の場合は、プロジェクトのバージョン管理システムのプライマリブランチにブランチ保護を設定してください。あるいは、Linuxカーネルのような分散型アプローチを使用します。この場合、変更はまず別のリポジトリで提案され、プライマリリポジトリへの変更のマージには特定の個別の操作が必要です。

    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


    バッジには十分です！

    プロジェクトのプライマリブランチの削除が試行された場合、バージョン管理システムはこれを機密性の高い活動として扱い、意図の明示的な確認を要求しなければなりません。 [OSPS-AC-03.02]
    プロジェクトのバージョン管理システムのプライマリブランチにブランチ保護を設定して削除を防止してください。

    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


    バッジには十分です！

    CI/CDパイプラインが信頼できないメタデータを処理する場合、それらのパラメータはパイプラインで使用する前にサニタイズおよび検証されなければならない。 [OSPS-BR-01.01]
    CI/CDパイプラインは、信頼できないソースに対応するすべてのメタデータ入力をサニタイズ（期待値の引用、エスケープ、または終了）する必要があります。これには、ブランチ名、コミットメッセージ、タグ、プルリクエストのタイトル、作者情報などのデータが含まれます。

    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


    バッジには十分です！

    CI/CDパイプラインが信頼されていないコードスナップショットで動作する場合、特権のあるCI/CDクレデンシャルおよびアセットへのアクセスを防止しなければなりません。 [OSPS-BR-01.03]
    CI/CDパイプラインは、信頼されていないコードスナップショットを特権のあるクレデンシャルおよびアセットから分離する必要があります。特に、プロジェクトは、協力者によるレビュー前にコードをビルドまたは実行するワークフローが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


    バッジには十分です！

    プロジェクトがURIを公式プロジェクトチャンネルとしてリストする場合、そのURIは暗号化されたチャンネルを使用して排他的に配信されなければなりません。 [OSPS-BR-03.01]
    プロジェクトのウェブサイトおよびバージョン管理システムを、データ送信にSSHまたはHTTPSなどの暗号化されたチャンネルを使用するように設定してください。プロジェクトドキュメントで参照されるすべてのツールとドメインが、暗号化されたチャンネルを介してのみアクセスできるようにしてください。

    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


    バッジには十分です！

    プロジェクトが公式配布チャネルとしてURIを掲載する場合、そのチャネルは暗号学的に認証されたチャネルを使用して、中間者（adversary-in-the-middle）攻撃から保護されなければならない。 [OSPS-BR-03.02]
    プロジェクトによって配布される成果物は、完全性と真正性を保証するチャネルを通じて配布されるべきです。ダウンロードにHTTPSを使用すること、署名付きリリースを使用すること、信頼できるパッケージマネージャーを通じて配布することは、いずれも中間者攻撃から保護するための許容できる方法です。

    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


    バッジには十分です！

    プロジェクトは、シークレットや認証情報などの暗号化されていない機密データが、バージョン管理システムに意図せず保存されることを防止しなければなりません。 [OSPS-BR-07.01]
    機密情報を含む可能性のあるファイルを除外するために、.gitignoreまたは同等のものを設定してください。プリコミットフックおよび自動スキャンツールを使用して、コミットに機密データが含まれることを検出および防止してください。

    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


    バッジには十分です！

    プロジェクトがリリースを行った場合、プロジェクトドキュメントには、すべての基本機能に対するユーザーガイドを含まなければなりません。 [OSPS-DO-01.01]
    プロジェクトのすべての基本機能について、インストール、設定、およびプロジェクトの機能の使用方法を説明するユーザーガイドまたはドキュメントを作成してください。既知の危険な行為または破壊的な行為が利用可能な場合は、非常に目立つ警告を含めてください。

    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


    バッジには十分です！

    プロジェクトがリリースを行った場合、プロジェクトドキュメントには、欠陥報告のためのガイドを含まなければなりません。 [OSPS-DO-02.01]
    プロジェクトでは、バージョン管理システムのデフォルトの課題追跡ツールを使用することをお勧めします。外部ソースが使用される場合は、プロジェクトドキュメントと貢献ガイドで報告システムの使用方法を明確かつ目立つように説明してください。プロジェクトドキュメントでは、欠陥がどのようにトリアージおよび解決されるかについての期待値を設定することもお勧めします。

    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


    バッジには十分です！

    プロジェクトは、提案された変更や利用上の障害についての公開討論のための1つ以上のメカニズムを持たなければならない。 [OSPS-GV-02.01]
    メーリングリスト、インスタントメッセージング、または課題追跡ツールなど、プロジェクト内の公開討論のための1つ以上のメカニズムを確立し、オープンなコミュニケーションとフィードバックを促進してください。

    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


    バッジには十分です！

    プロジェクトのドキュメントには、貢献プロセスの説明を含めなければならない、または一般からの貢献を受け付けていないことを明確に記載しなければならない。 [OSPS-GV-03.01]
    変更の提出手順やプロジェクトメンテナーとのやり取りを含む、貢献プロセスの概要を示すCONTRIBUTING.mdまたはCONTRIBUTING/ディレクトリを作成します。

    .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


    バッジには十分です！

    ソースコードのライセンスは、OSIのオープンソース定義またはFSFのフリーソフトウェア定義を満たさなければならない。 [OSPS-LE-02.01]
    OSI（Open Source Initiative）によって承認されたライセンス、またはFSF（Free Software Foundation）によって承認されたフリーライセンスを含むLICENSEファイルをプロジェクトのリポジトリに追加します。そのようなライセンスの例としては、MIT、BSD 2-clause、BSD 3-clause revised、Apache 2.0、Lesser GNU General Public License（LGPL）、およびGNU General Public License（GPL）が含まれます。特許などの他の障害がない場合、パブリックドメインへのリリースはこの管理を満たします。

    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


    バッジには十分です！

    リリースされたソフトウェア資産のライセンスは、OSIのオープンソース定義またはFSFのフリーソフトウェア定義を満たさなければならない。 [OSPS-LE-02.02]
    リリースされたソフトウェア資産に異なるライセンスが含まれている場合は、OSI（Open Source Initiative）によって承認されたライセンス、またはFSF（Free Software Foundation）によって承認されたフリーライセンスであることを確認してください。そのようなライセンスの例としては、MIT、BSD 2-clause、BSD 3-clause revised、Apache 2.0、Lesser GNU General Public License（LGPL）、およびGNU General Public License（GPL）が含まれます。リリースされたソフトウェア資産のライセンスはソースコードとは異なる場合があることに注意してください。

    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


    バッジには十分です！

    ソースコードのライセンスは、対応するリポジトリのLICENSEファイル、COPYINGファイル、LICENSES/ディレクトリ、またはLICENSE/ディレクトリで管理されなければならない。 [OSPS-LE-03.01]
    ライセンス条項の可視性と明確性を確保するため、プロジェクトのソースコードライセンスをプロジェクトのLICENSEファイル、COPYINGファイル、LICENSES/ディレクトリ、またはLICENSE/ディレクトリに含めてください。ファイル名には拡張子を付けてもかまいません。プロジェクトが複数のリポジトリを持つ場合は、各リポジトリにライセンスファイルが含まれていることを確認してください。

    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


    バッジには十分です！

    リリースされたソフトウェア資産のライセンスは、リリースされたソースコードに含めるか、対応するリリース資産と共にLICENSEファイル、COPYINGファイル、またはLICENSE/ディレクトリに含めなければならない。 [OSPS-LE-03.02]
    ライセンス条件に関する可視性と明確性を提供するために、プロジェクトのリリースされたソフトウェア資産のライセンスを、リリースされたソースコードに、または対応するリリース資産と一緒にあるLICENSEファイル、COPYINGファイル、またはLICENSE/ディレクトリに含めます。ファイル名には拡張子を付けることができます。プロジェクトに複数のリポジトリがある場合は、各リポジトリにライセンスファイルが含まれていることを確認してください。

    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


    バッジには十分です！

    プロジェクトのソースコードリポジトリは、静的なURLで公開され、読み取り可能でなければならない。 [OSPS-QA-01.01]
    GitHub、GitLab、Bitbucketなどの一般的なVCSを使用します。リポジトリが公開読み取り可能であることを確認してください。主要なソースを明確にする可視性の高いドキュメントがない限り、リポジトリの複製またはミラーリングを避けてください。リポジトリURLに影響を与える可能性のある頻繁なリポジトリの変更を避けてください。リポジトリが公開されていることを確認してください。

    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


    バッジには十分です！

    バージョン管理システムには、行われたすべての変更、誰が変更を行ったか、いつ変更が行われたかの公開読み取り可能な記録が含まれている必要があります。 [OSPS-QA-01.02]
    GitHub、GitLab、Bitbucketなどの一般的なVCSを使用して、公開読み取り可能なコミット履歴を維持します。コミットの作成者が不明瞭になるような方法でコミットをスカッシュまたは書き換えることは避けてください。

    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


    バッジには十分です！

    パッケージ管理システムがサポートしている場合、ソースコードリポジトリには、直接の言語依存関係を説明する依存関係リストが含まれている必要があります。 [OSPS-QA-02.01]
    これは、package.json、Gemfile、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


    バッジには十分です！

    複数のリポジトリを持つプロジェクトは、プロジェクトの一部であるコードベースの一覧を文書化しなければならない。 [OSPS-QA-04.01]
    プロジェクトによって生成され、リリースにコンパイルされる追加のサブプロジェクトコードリポジトリを文書化します。このドキュメントには、それぞれのコードベースのステータスと意図を含める必要があります。

    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


    バッジには不十分です。

    バージョン管理システムには、生成された実行可能な成果物を含めてはなりません（MUST NOT）。 [OSPS-QA-05.01]
    プロジェクトのバージョン管理システムで生成された実行可能アーティファクトを削除します。生成された実行可能アーティファクトがテストなどのプロセスで重要と思われるシナリオでは、代わりにビルド時に生成するか、別に保存して、明確に文書化されたパイプライン ステップ中に取得する必要があることが推奨されます。

    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


    バッジには不十分です。

    バージョン管理システムには、レビュー不可能なバイナリ成果物を含めてはなりません（MUST NOT）。 [OSPS-QA-05.02]
    プロジェクトのバージョン管理システムにレビュー不可能なバイナリアーティファクトを追加しないでください。これには、実行可能なアプリケーションバイナリ、ライブラリファイル、および同様のアーティファクトが含まれます。これには、グラフィック画像、音声や音楽ファイル、および通常バイナリ形式で保存されるコンテンツなどのアセットは含まれません。

    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


    バッジには十分です！

    プロジェクトの文書には、セキュリティ連絡先を含めなければなりません（MUST）。 [OSPS-VM-02.01]
    プロジェクトのセキュリティ連絡先を含むsecurity.md（または同様の名前の）ファイルを作成してください。

    .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



ツールやAIシステムを使って、https://www.bestpractices.dev/ja/projects/14187/choose/edit?osps_ac_01_01_status=Met&osps_ac_01_01_justification=GitHub+enforcedのような簡単なURLで変更を提案できます。その方法については、自動化提案システムをご覧ください。 このデータは、Community Data License Agreement – Permissive, Version 2.0 (CDLA-Permissive-2.0)のもとで利用可能です。これは、データ受領者が、データ受領者がこの契約のテキストを共有データとともに利用可能にする限り、変更の有無にかかわらずデータを共有できることを意味します。Progressive RobotおよびOpenSSFベストプラクティスバッジのコントリビューターにクレジットを表示してください。

プロジェクト バッジ登録の所有者： Progressive Robot.
エントリの作成日時 2026-08-21 05:37:27 UTC、 最終更新日 2026-09-12 02:50:23 UTC 最後に2026-08-21 17:17:16 UTCにバッジ合格を達成しました。