hMailServer

Проекты, которые следуют приведенным ниже лучшим практикам, могут добровольно и самостоятельно оценить себя и продемонстрировать, что они получили значок Open Source Security Foundation (OpenSSF).

Не существует набора практик, гарантирующего, что у программного обеспечения никогда не будет недостатков или уязвимостей; даже формальные методы могут не помочь, если спецификации или допущения ошибочны. Также не существует какой-либо практики, которая могла бы гарантировать, что проект будет поддерживать здоровое и хорошо функционирующее сообщество разработчиков. Однако следующие хорошие правила могут помочь улучшить результаты проектов. Например, некоторые правила описывают ревью несколькими участниками перед выпуском, что может помочь найти технические уязвимости, которые было бы сложно найти другим способом, и помочь построить доверие и желание дальнейшего взаимодействия между разработчиками из разных компаний. Чтобы получить значок, нужно выполнить все критерии с ключевыми словами "НЕОБХОДИМО"/"ОБЯЗАН"/"НЕДОПУСТИМО", все критерии со словом "СЛЕДУЕТ" либо должны удовлетворяться, либо должно быть приведено обоснование их невыполнения, и все критерии со словом "ЖЕЛАТЕЛЬНО" могут быть удовлетворены ИЛИ неудовлетворены (желательно, чтобы они были хотя бы рассмотрены). Если вы хотите ввести общий комментарий вместо объяснения, почему текущая ситуация приемлема, начните текст с '//' и пробела. Приветствуется обратная связь через сайт на GitHub в виде issues или pull requests. Существует также список рассылки для общих вопросов.

Мы с удовольствием предоставляем информацию на нескольких языках, однако, если есть какой-либо конфликт или несоответствие между переводами, английская версия является авторитетной.
Если это ваш проект, пожалуйста, отобразите статус вашего базового значка на странице проекта! Статус базового значка выглядит так: Базовый уровень значка для проекта 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».
    Common Platform Enumeration (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-коммита.

    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]
    Ожидаемая личность может быть в форме идентификаторов ключей, используемых для подписи, эмитента и личности из сертификата 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


    Недостаточно для значка.

    Когда проект выпустил релиз, все скомпилированные выпущенные программные активы ДОЛЖНЫ поставляться со списком компонентов программного обеспечения (Software Bill of Materials). [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


    Достаточно для значка!

    Документация проекта ОБЯЗАНА четко описывать, когда и как выполняются тесты. [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



Вы можете использовать инструменты и системы ИИ для предложения изменений через простой URL, например https://www.bestpractices.dev/ru/projects/14949/choose/edit?osps_ac_01_01_status=Met&osps_ac_01_01_justification=GitHub+enforced. Смотрите нашу систему автоматизированных предложений о том, как это сделать. Эти данные доступны по лицензии Community Data License Agreement – Permissive, Version 2.0 (CDLA-Permissive-2.0). Это означает, что получатель данных может распространять данные с изменениями или без них, при условии, что получатель данных предоставляет текст данного соглашения вместе с распространяемыми данными. Пожалуйста, укажите в качестве источника christopher holloway и участников OpenSSF Best Practices badge.

Владелец анкеты на значок проекта: christopher holloway.
2026-09-26 05:28:20 UTC, последнее изменение сделано 2026-09-26 06:16:51 UTC. Последний раз условия для получения значка были выполнены 2026-09-26 05:45:21 UTC.