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>


これらはベースラインレベル2の基準です。 これらは基準バージョン 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）システム、ソフトウェア、およびパッケージのための構造化された命名体系です。脆弱性を報告する際に、多くのシステムやデータベースで使用されています。

 管理策 18/19 ●

  • 管理策


    バッジには十分です！

    CI/CDタスクが権限を指定せずに実行される場合、CI/CDシステムはパイプラインで付与される最低限の権限をタスクの権限としてデフォルトで設定しなければなりません。 [OSPS-AC-04.01]
    プロジェクトの設定を構成して、デフォルトで新しいパイプラインに利用可能な最低限の権限を割り当て、特定のタスクに必要な場合にのみ追加の権限を付与します。

    The repository's GitHub Actions default workflow token permission is read-only (verified via API: gh api repos/Progressiverobot/hmailserver/actions/permissions/workflow returns default_workflow_permissions=read), so any CI/CD task with no permissions specified receives a read-only GITHUB_TOKEN — the lowest default. In addition, all 10 workflows on master declare an explicit top-level permissions block: nine are read-only or empty (contents: read; contents: read + actions: read; read-all; {}), and upstream-watch.yml adds issues: write at workflow level, needed by its single job to file upstream-tracking issues. Other write scopes are granted per job only where required: id-token: write and contents: write in sign-release.yml's signing job (keyless cosign signing and asset upload), security-events: write for CodeQL and Scorecard SARIF upload (Scorecard also id-token: write), contents: write in the SBOM job to attach release assets, and pull-requests: write in dependency-review. See https://github.com/Progressiverobot/hmailserver/tree/master/.github/workflows


    バッジには十分です！

    公式リリースが作成される場合、そのリリースには一意のバージョン識別子を割り当てなければなりません。 [OSPS-BR-02.01]
    プロジェクトによって生成される各リリースに、一貫した命名規則または番号付けスキームに従って一意のバージョン識別子を割り当てます。例には、SemVer、CalVer、またはgit commit idが含まれます。

    Every release is assigned a unique SemVer-style tag: v6.2.2 through v6.2.21 for stable releases, with pre-releases distinguished by suffix (v6.2.22-pre1..pre6, v6.2.23-alpha1). 25+ releases enumerated via the GitHub API each carry a distinct tag_name, and an active 'Protect release tags' ruleset protects the tags after publication. See https://github.com/Progressiverobot/hmailserver/releases


    バッジには十分です！

    公式リリースが作成される場合、そのリリースには機能的およびセキュリティの変更の記述的なログを含めなければなりません。 [OSPS-BR-04.01]
    すべてのリリースに記述的な変更ログを含めるようにしてください。変更ログが人間が読めるものであり、コミットメッセージだけでなく、セキュリティへの影響や異なるユースケースとの関連性についての説明などの詳細を含めることが推奨されます。機械可読性を確保するために、「## Changelog」などのmarkdownヘッダーの下にコンテンツを配置してください。

    Each GitHub Release carries thorough, human-written notes describing functional and security modifications. v6.2.21's body is ~11.8 KB; v6.2.23-alpha1's notes describe new features, breaking changes (database schema 6022->6025), security-relevant fixes (a path silently losing mail, a COM vtable compatibility break, an installer hang), and upgrade cautions with backup instructions. Release notes name CVEs where relevant (e.g. the CVE-2023-51764 SMTP-smuggling rule). The notes are not placed under a literal '## Changelog' header, which the criterion recommends but does not require. See https://github.com/Progressiverobot/hmailserver/releases


    バッジには十分です！

    ビルドとリリースのパイプラインが依存関係を取り込む場合、利用可能な場合は標準化されたツールを使用しなければなりません。 [OSPS-BR-05.01]
    エコシステム用の一般的なツール（パッケージマネージャーや依存関係管理ツールなど）を使用して、ビルド時に依存関係を取り込みます。これには、必要な依存関係を指定するための依存関係ファイル、ロックファイル、またはマニフェストを使用し、ビルドシステムによって取り込まれることが含まれます。

    .NET dependencies are ingested with standard tooling: CI runs 'dotnet restore' (NuGet) on ControlPanel.csproj and the Tools solution (ci.yml), and Dependabot manages the nuget and github-actions ecosystems weekly (.github/dependabot.yml); GitHub Actions are pinned by commit SHA. The native C++ dependencies (OpenSSL, Boost, libpq) have no ecosystem package manager in this project's MSVC flow — they are built from pinned source versions per documented steps under %hMailServerLibs% — and every binary committed to the tree is SHA-256-inventoried in hmailserver/docs/third-party-binaries.json, enforced by the verify-binary-provenance workflow. See https://github.com/Progressiverobot/hmailserver/blob/master/.github/dependabot.yml


    バッジには十分です！

    公式リリースが作成される場合、そのリリースには署名するか、各アセットの暗号ハッシュを含む署名付きマニフェストで説明しなければなりません。 [OSPS-BR-06.01]
    ビルド時にすべてのリリースされたソフトウェア アセットを、GPGまたはPGP署名、Sigstore署名、SLSAプロベナンス、またはSLSA VSAなどの暗号署名または証明で署名します。署名付きマニフェストまたはメタデータファイルに各アセットの暗号ハッシュを含めます。

    Since v6.2.19, every release asset is signed at release time with Sigstore cosign (keyless): sign-release.yml runs 'cosign sign-blob --bundle' over each release asset, verifies each bundle with 'cosign verify-blob' pinning the signing workflow identity before upload, and attaches a .cosign.bundle per asset. The latest stable release v6.2.21 and latest prerelease v6.2.23-alpha1 each ship the installer plus SPDX and CycloneDX SBOMs, each asset with its own .cosign.bundle. User-facing verification commands are documented in the workflow header. Releases prior to v6.2.19 predate the signing process and are unsigned. See https://github.com/Progressiverobot/hmailserver/blob/master/.github/workflows/sign-release.yml


    バッジには十分です！

    プロジェクトがリリースを行った場合、プロジェクトのドキュメントには、プロジェクトが依存関係をどのように選択、取得、および追跡するかについての説明を含めなければなりません。 [OSPS-DO-06.01]
    この情報をソースコードリポジトリ、プロジェクトウェブサイト、またはその他のチャネルなどの公開表示可能なリソース上で、プロジェクトの技術および設計ドキュメントと一緒に公開することが推奨されます。

    Dependency handling is documented publicly: README's third-party libraries section explains how OpenSSL 4.0.x, Boost 1.91 and PostgreSQL 18 libpq are obtained and built at pinned versions under %hMailServerLibs%; .github/dependabot.yml states the tracking policy (NuGet and GitHub Actions updated weekly via Dependabot; native C++ libs tracked manually since Dependabot has no C++ ecosystem); and hmailserver/docs/ThirdPartyBinaries.md records, for each of the 40 committed binaries, what it is, where it came from, why it is present and whether it should be, with SHA-256s in third-party-binaries.json enforced by CI. SBOMs ship with each release. See https://github.com/Progressiverobot/hmailserver/blob/master/hmailserver/docs/ThirdPartyBinaries.md


    バッジには十分です！

    プロジェクトのドキュメントには、必要なライブラリ、フレームワーク、SDK、および依存関係を含む、ソフトウェアのビルド方法に関する手順が含まれていなければなりません。 [OSPS-DO-07.01]
    この情報は、CONTRIBUTING.mdや他の開発者タスクドキュメントなど、プロジェクトの貢献者ドキュメントと一緒に公開することが推奨されます。これはまた、Makefileターゲットや他の自動化スクリプトを使用して文書化することもできます。

    README.md has a contents-linked 'Building hMailServer' section covering prerequisites (Visual Studio 2026 / v145 toolset with the required workloads, Inno Setup 6, Perl, Python), step-by-step instructions for building the external libraries (OpenSSL via nmake, PostgreSQL libpq via meson, Boost via b2) under %hMailServerLibs%, and building the server, tools and installer via the build*.ps1 scripts or MSBuild, including a warning about build events on machines running a production instance. .github/CONTRIBUTING.md summarizes the same and points back to the README. See https://github.com/Progressiverobot/hmailserver/blob/master/README.md#building-hmailserver


    バッジには十分です！

    プロジェクトの文書には、機密リソースへのアクセス権を持つプロジェクト メンバーの一覧を含めなければなりません（MUST）。 [OSPS-GV-01.01]
    プロジェクトのソースコードリポジトリ内のmembers.md、governance.md、maintainers.md、または同様のファイルなどのアーティファクトを通じて、プロジェクト参加者とその役割を文書化します。これは、メンテナのリストに名前またはアカウントハンドルを含めるだけの簡単なものでも、プロジェクトのガバナンスに応じてより複雑なものでも構いません。

    The project has exactly one member with access to sensitive resources, and he is documented by name and handle on master: README states the fork 'is maintained by Christopher Holloway / Progressive Robot Ltd'; .github/CODEOWNERS lists @chrisholloway5 as owner of every path, explicitly enumerating the sensitive ones (CI workflows, release/signing files, committed third-party binaries, TLS/crypto code); SECURITY.md states it is a single-maintainer project. PR #40's GOVERNANCE.md will restate this as a formal member list once merged. See https://github.com/Progressiverobot/hmailserver/blob/master/.github/CODEOWNERS


    バッジには十分です！

    プロジェクトの文書には、プロジェクト メンバーの役割と責任の説明を含めなければなりません（MUST）。 [OSPS-GV-01.02]
    プロジェクトのソースコードリポジトリ内のmembers.md、governance.md、maintainers.md、または同様のファイルなどのアーティファクトを通じて、プロジェクト参加者とその役割を文書化します。

    GOVERNANCE.md documents the project roles and their responsibilities: the Maintainer role (accepting changes, releasing per RELEASE.md, security response per SECURITY.md, direction via Roadmap.md, custody of critical credentials), the Contributor role (expectations set by CONTRIBUTING.md), and the Reporter role (SUPPORT.md / SECURITY.md paths). Who currently holds each role is stated by name. See https://github.com/Progressiverobot/hmailserver/blob/master/GOVERNANCE.md


    バッジには十分です！

    プロジェクトの文書には、受け入れ可能な貢献の要件を含む、コード貢献者向けのガイドを含めなければなりません（MUST）。 [OSPS-GV-03.02]
    プロジェクトドキュメントのCONTRIBUTING.mdまたはCONTRIBUTING/の内容を拡張して、コーディング標準、テスト要件、コードコントリビューターのための提出ガイドラインを含む、受け入れ可能な貢献の要件を概説します。このガイドがコントリビューターと承認者の両方にとって信頼できる情報源であることが推奨されます。

    .github/CONTRIBUTING.md on master sets requirements for acceptable contributions: coding standards (code must build warning-free under /WX; parameterised SQL exclusively, never manually built SQL strings; new optional server features follow the INI-settings pattern), testing requirements (all changes must keep the regression suite green; add or update regression tests for behavior changes), submission guidelines (branch from master, one logical change per PR), architectural guidance on the BO/Persistence/COM layering, and licensing terms (contributions licensed under AGPLv3). See https://github.com/Progressiverobot/hmailserver/blob/master/.github/CONTRIBUTING.md


    バッジには十分です！

    バージョン管理システムは、すべてのコード貢献者に対し、コミットのたびに、関連する貢献を行う法的権限があることを表明するよう要求しなければなりません（MUST）。 [OSPS-LE-01.01]
    プロジェクトのリポジトリにDCOを含め、コードコントリビューターが、すべてのコミットで関連する貢献を行うことが法的に認められていると主張することを要求します。ステータスチェックを使用して、主張が行われたことを確認します。CLAもこの要件を満たします。GitHubなどの一部のバージョン管理システムでは、これがプラットフォームの利用規約に含まれている場合があります。

    There is no DCO status check or CLA. The repository is hosted on GitHub, and this criterion's guidance explicitly accepts the platform's terms of service: GitHub's Terms of Service (section D) require every user, on every contribution, to represent that they have the right to post the content, and license inbound contributions under the repository's license. All contributions arrive through GitHub (a sole maintainer plus Dependabot). CONTRIBUTING.md additionally states 'By contributing you agree that your contributions are licensed under the AGPLv3'. See https://github.com/Progressiverobot/hmailserver/blob/master/.github/CONTRIBUTING.md


    バッジには不十分です。

    プライマリブランチにコミットが行われる場合、コミットの自動ステータスチェックは、合格するか手動でバイパスされる必要があります。 [OSPS-QA-03.01]
    プロジェクトのバージョン管理システムを設定して、すべての自動ステータスチェックが合格するか、コミットがプライマリブランチにマージされる前に手動確認を要求するようにします。オプションのステータスチェックは、承認者がバイパスしたくなるような合格または不合格の要件として設定しないことが推奨されます。

    master has no branch protection (GitHub API returns 404 'Branch not protected') and no branch ruleset applies to it (rules/branches/master returns an empty list; the only active ruleset protects release tags). CI, CodeQL and dependency-review workflows run on pushes and PRs, but nothing requires their status checks to pass before a commit lands: the sole maintainer pushes directly to master as the normal workflow, so a failing check cannot block a change. Adding required status checks on master would close this gap. See https://github.com/Progressiverobot/hmailserver/blob/master/.github/workflows/ci.yml


    バッジには十分です！

    コミットが受け入れられる前に、プロジェクトのCI/CDパイプラインは、変更が期待を満たすことを確認するために少なくとも1つの自動テストスイートを実行する必要があります。 [OSPS-QA-06.01]
    自動テストは、プライマリブランチへのすべてのマージの前に実行される必要があります。テストスイートはCI/CDパイプラインで実行され、結果はすべてのコントリビューターに表示される必要があります。テストスイートは一貫した環境で実行され、コントリビューターがローカルでテストを実行できるような方法で実行される必要があります。テストスイートの例には、ユニットテスト、統合テスト、エンドツーエンドテストが含まれます。

    The CI workflow (.github/workflows/ci.yml) triggers on every push and pull request to master and runs an automated test suite: 'dotnet test' on ControlPanel.Tests with cobertura coverage, plus a generated-code drift check and -warnaserror builds. Results are publicly visible in the Actions tab, and contributors can run the same tests locally (dotnet test; build/build-tests.ps1 and build/run-tests.ps1 are documented in CONTRIBUTING.md). Pull requests are tested before merge; every commit reaching master is tested by the same pipeline. See https://github.com/Progressiverobot/hmailserver/blob/master/.github/workflows/ci.yml


    バッジには十分です！

    プロジェクトがリリースを行った場合、プロジェクトドキュメントは、システム内のすべてのアクションとアクターを示す設計ドキュメントを含む必要があります。 [OSPS-SA-01.01]
    プロジェクトドキュメントに、アクションとアクターを説明する設計を含めます。アクターには、システム内の別のセグメントに影響を与えることができるサブシステムまたはエンティティが含まれます。これが新機能や破壊的変更のために更新されることを確認してください。

    ARCHITECTURE.md at the repo root is a maintained 218-line design document describing the system's components and how they interact: the C++ server modules (SMTP/IMAP/POP3, delivery queue, anti-spam/anti-virus, persistence layering BO->Persistence->SQL with caches over four database backends), the COM/IDispatch API as the management seam used by the Control Panel, the test suite and third-party scripts, the optional listeners (REST, metrics, web services, ManageSieve) with their threading and TLS behavior, the scheduler, and external actors such as ClamAV, SpamAssassin, DNS and the databases. It records interaction constraints and is kept current. See https://github.com/Progressiverobot/hmailserver/blob/master/ARCHITECTURE.md


    バッジには十分です！

    プロジェクトがリリースを行った場合、プロジェクトドキュメントは、リリースされたソフトウェアアセットのすべての外部ソフトウェアインターフェースの説明を含む必要があります。 [OSPS-SA-02.01]
    リリースされたソフトウェアアセットのすべてのソフトウェアインターフェース（API）を文書化し、ユーザーがソフトウェアとどのように対話できるか、どのようなデータが期待または生成されるかを説明します。これが新機能や破壊的変更のために更新されることを確認してください。

    README.md documents all external interfaces of the released software: SMTP, IMAP and POP3 with per-extension RFC citations; SASL mechanisms (SCRAM-SHA-256/-PLUS); Sieve plus the ManageSieve (RFC 5804) listener with its command set; the REST administration API with its complete endpoint list (/api/v1/status, domains, accounts, queue, apikeys, tlsa) and authentication model (administrator password or scoped API keys); the Prometheus /metrics endpoint with metric names and the /livez, /readyz, /healthz probes; OTLP trace/metrics/logs endpoints; the COM/IDispatch API; and the hMailServer.ini configuration surface. ARCHITECTURE.md describes the COM API's role as the management seam. See https://github.com/Progressiverobot/hmailserver/blob/master/README.md


    バッジには十分です！

    プロジェクトがリリースを行った場合、プロジェクトは、ソフトウェア内で発生する可能性のある最も可能性が高く、影響の大きい潜在的なセキュリティ問題を理解するためにセキュリティ評価を実行する必要があります。 [OSPS-SA-03.01]
    セキュリティ評価を実行することで、プロジェクトメンバーと下流の消費者の両方に、プロジェクトがソフトウェア内で発生する可能性のある問題を理解していることを知らせます。どのような脅威が実現する可能性があるかを理解することは、プロジェクトがリスクを管理および対処するのに役立ちます。この情報は、プロジェクトのセキュリティの能力と実践を示すために、下流の消費者にとって有用です。これが新機能や破壊的変更のために更新されることを確認してください。

    ASSURANCE-CASE.md is the project's documented security assessment: a threat model with actors and principal attack surfaces, trust boundaries B1-B6, security claims C1-C7 argued with evidence, CWE-mapped analysis of how common implementation weaknesses are countered, and a residual-risk list. It is supported by continuous tooling on master: CodeQL on every push and pull request, OpenSSF Scorecard, and a libFuzzer harness suite under fuzz/. See https://github.com/Progressiverobot/hmailserver/blob/master/ASSURANCE-CASE.md


    バッジには十分です！

    プロジェクトの文書には、明確な対応期限を伴う、協調的な脆弱性開示（CVD）のポリシーを含めなければなりません（MUST）。 [OSPS-VM-01.01]
    ディレクトリのルートにSECURITY.mdファイルを作成し、プロジェクトの協調的脆弱性開示のポリシーを概説します。脆弱性を報告する方法を含めます。プロジェクトが報告された問題にどのように対応および対処するかについての期待を設定します。

    SECURITY.md (in .github/, shown on the repo's Security tab) is a full coordinated vulnerability disclosure policy with explicit timeframes: acknowledgement within 5 working days, initial assessment (reproduction or request for more information) within 10 working days, and a fix for a confirmed vulnerability within 90 days of acknowledgement. It commits to coordinated disclosure on a 90-day timetable (advisory published when the fix ships or at 90 days, whichever is first), asks reporters to flag earlier disclosure intentions, states the credit policy, and defines in-scope and out-of-scope report classes. Verified on master. See https://github.com/Progressiverobot/hmailserver/blob/master/.github/SECURITY.md


    バッジには十分です！

    プロジェクトの文書は、プロジェクト内のセキュリティ連絡先に直接、非公開で脆弱性を報告する手段を提供しなければなりません（MUST）。 [OSPS-VM-03.01]
    セキュリティ研究者がプロジェクトに非公開で脆弱性を報告する手段を提供します。これは、専用の電子メールアドレス、ウェブフォーム、VCS専用ツール、セキュリティ連絡先の電子メールアドレス、またはその他の方法である可能性があります。

    Private vulnerability reporting is enabled on the repository (verified via the GitHub API), and SECURITY.md directs reporters to the private channel with a direct link to https://github.com/Progressiverobot/hmailserver/security/advisories/new, explicitly instructs against public issues, discussions, PRs or forum posts for security problems, and provides a fallback: a reporter who cannot use GitHub Security Advisories may open an issue containing no technical detail asking for a private channel, and the maintainer will open an advisory and invite them. Reports go directly to the maintainer, who is the security contact. See https://github.com/Progressiverobot/hmailserver/blob/master/.github/SECURITY.md


    バッジには十分です！

    プロジェクトの文書は、発見された脆弱性に関するデータを公開しなければなりません（MUST）。 [OSPS-VM-04.01]
    CVEエントリ、ブログ投稿、またはその他のメディアなど、予測可能な公開チャネルで既知の脆弱性に関する情報を提供します。可能な限り、この情報には、影響を受けるバージョン、消費者が脆弱かどうかを判断する方法、および緩和または修復の手順が含まれる必要があります。

    The project publishes vulnerability data through GitHub Security Advisories and release notes. SECURITY.md commits that once a fix is available it ships as a new build and the advisory is published with a CVE requested through GitHub, on a 90-day coordinated-disclosure timetable. To date no vulnerability has been discovered in this fork, so the public advisory list is empty (verified via the GitHub API: zero published advisories, none withheld); where upstream CVEs are relevant the release notes name them explicitly (e.g. CVE-2023-51764 SMTP smuggling, whose mitigation is enforced and pinned by a regression test). 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にバッジ合格を達成しました。