hMailServer

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

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

私たちは多言語で情報を提供していますが、翻訳版に矛盾や意味の不一致がある場合は、英語版を正式な記述とします。
これがあなたのプロジェクトである場合は、プロジェクトページにベースラインバッジステータスを表示してください！ベースラインバッジステータスは次のようになります： プロジェクト14949のベースラインバッジレベルはin_progressです ベースラインバッジを埋め込む方法は次のとおりです：
ベースラインバッジステータスを表示するには、マークダウンファイルに以下を埋め込みます：
[![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)」。一重引用符または二重引用符を含めないでください。
    複数の言語がある場合は、コンマを区切り（スペースを入れてもよい）としてリストし、使用頻度の高いものから順に並べます。使用言語が多くある場合は、少なくとも最初の3つの最も多く使われるものをリストアップしてください。言語がない場合（例：ドキュメントだけ、またはテスト専用のプロジェクトの場合）、1文字 " - "を使用します。言語ごとにある大文字・小文字の慣用を踏襲してください（例：「JavaScript」）。
    Common Platform Enumeration（CPE）は、情報技術（IT）システム、ソフトウェア、およびパッケージのための構造化された命名体系です。脆弱性を報告する際に、多くのシステムやデータベースで使用されています。

    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


    バッジには十分です！

    プロジェクトがリリースを作成した場合、プロジェクトのドキュメントには、ソフトウェアリリースを作成した人またはプロセスの期待されるIDを検証するための手順が含まれている必要があります。 [OSPS-DO-03.02]
    期待されるIDは、署名に使用される鍵ID、sigstore証明書からの発行者とID、または他の類似の形式である可能性があります。可能であれば、このドキュメントをビルドおよびリリースパイプラインと同じ場所に保存しないようにして、単一の侵害によってソフトウェアとその整合性を検証するためのドキュメントの両方が侵害されることを避けてください。

    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


    バッジには十分です！

    プロジェクトの文書には、機密リソースへの昇格された権限を付与する前に、コード共同作業者がレビューされるというポリシーを含めなければなりません（MUST）。 [OSPS-GV-04.01]
    マージ承認やシークレットへのアクセスなど、機密リソースへのエスカレートされた権限を付与される前に、コード共同作業者がレビューおよび承認される必要があるという実行可能なポリシーをプロジェクトのドキュメントに公開してください。審査には、既知の信頼できる組織との貢献者の関連性を確認するなど、正当化可能なIDの系統を確立することが推奨されます。

    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 Baseline要件に従うことに加えて、これにはセキュリティレビューを要求すること、脆弱性がないこと、および既知のセキュリティ問題がないことを確認することが含まれる場合があります。

    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


    バッジには十分です！

    プロジェクトの文書は、テストがいつ、どのように実行されるかを明確に文書化しなければなりません（MUST）。 [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


    バッジには十分です！

    プロジェクトの文書には、プロジェクトが作成したソフトウェアへのすべての主要な変更が、自動テスト スイート内の該当機能のテストを追加または更新すべきであるというポリシーを含めなければなりません（MUST）。 [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


    バッジには不十分です。

    プライマリブランチにコミットが行われる場合、プロジェクトのバージョン管理システムは、マージする前に、作者以外の少なくとも1人の人間による変更の承認を要求しなければなりません（MUST）。 [OSPS-QA-07.01]
    プロジェクトのバージョン管理システムを構成し、リリースまたはプライマリブランチにマージする前に、作者以外の少なくとも1人の人間による変更の承認を要求します。これは、プルリクエストがマージされる前に、少なくとも1人の他のコラボレーターによってレビューおよび承認されることを要求することで実現できます。

    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


    バッジには十分です！

    プロジェクトがリリースを行った場合、プロジェクトは、システム内の重要なコードパス、関数、および相互作用に対する攻撃を理解して防御するために、脅威モデリングと攻撃面分析を実行しなければなりません（MUST）。 [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文書で説明され、悪用不可能性の詳細を伴って脆弱性レポートを補完しなければなりません（MUST）。 [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の検出結果の修正に関するしきい値を定義するポリシーを含めなければなりません（MUST）。 [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違反に対処するポリシーを含めなければなりません（MUST）。 [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


    バッジには不十分です。

    プロジェクトのコードベースへのすべての変更は、悪意のある依存関係および依存関係内の既知の脆弱性に関する文書化されたポリシーに照らして自動的に評価され、悪用不可能であると宣言され抑制されている場合を除き、違反があった場合はブロックされなければなりません（MUST）。 [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の検出結果の修正に関するしきい値を定義するポリシーを含めなければなりません（MUST）。 [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


    バッジには不十分です。

    プロジェクトのコードベースへのすべての変更は、セキュリティ上の弱点に関する文書化されたポリシーに照らして自動的に評価され、悪用不可能であると宣言され抑制されている場合を除き、違反があった場合はブロックされなければなりません（MUST）。 [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システムを使って、https://www.bestpractices.dev/ja/projects/14949/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)のもとで利用可能です。これは、データ受領者が、データ受領者がこの契約のテキストを共有データとともに利用可能にする限り、変更の有無にかかわらずデータを共有できることを意味します。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にバッジ合格を達成しました。