hMailServer

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

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

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

 Элементы управления 22/24 ●

  • Элементы управления


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

    Когда пользователь пытается прочитать или изменить чувствительный ресурс в авторитетном репозитории проекта, система ДОЛЖНА требовать от пользователя прохождения процесса многофакторной аутентификации. [OSPS-AC-01.01]
    Обеспечьте многофакторную аутентификацию для системы контроля версий проекта, требуя от соавторов предоставления второй формы аутентификации при доступе к конфиденциальным данным или изменении настроек репозитория. Для этой меры приемлемы passkeys (ключи доступа).

    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]
    Если VCS централизована, установите защиту ветки на основную ветку в VCS проекта. В качестве альтернативы используйте децентрализованный подход, как в ядре 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 или эквивалент для исключения файлов, которые могут содержать конфиденциальную информацию. Используйте pre-commit хуки и автоматизированные инструменты сканирования для обнаружения и предотвращения включения конфиденциальных данных в коммиты.

    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


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

    Проект ОБЯЗАН иметь один или несколько механизмов для публичного обсуждения предлагаемых изменений и препятствий использования. [OSPS-GV-02.01]
    Создайте один или несколько механизмов для публичных обсуждений в рамках проекта, таких как списки рассылки, мгновенные сообщения или трекеры задач, чтобы облегчить открытое общение и обратную связь.

    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]
    Добавьте файл LICENSE в репозиторий проекта с лицензией, которая является одобренной лицензией Open Source Initiative (OSI), или свободной лицензией, одобренной Фондом свободного программного обеспечения (FSF). Примеры таких лицензий включают 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]
    Если с выпущенными программными активами включена другая лицензия, убедитесь, что это одобренная лицензия Open Source Initiative (OSI) или свободная лицензия, одобренная Free Software Foundation (FSF). Примеры таких лицензий включают 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]
    Используйте общую систему контроля версий (VCS), такую как GitHub, GitLab или Bitbucket. Убедитесь, что репозиторий доступен для публичного чтения. Избегайте дублирования или зеркалирования репозиториев, если только хорошо видимая документация не разъясняет первичный источник. Избегайте частых изменений репозитория, которые могут повлиять на 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]
    Используйте общую VCS, такую как GitHub, GitLab или Bitbucket, для поддержания публично доступной истории коммитов. Избегайте сжатия или перезаписи коммитов таким образом, чтобы это скрывало автора любых коммитов.

    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


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

    Система управления версиями НЕ ДОЛЖНА содержать сгенерированные исполняемые артефакты. [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


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

    Система управления версиями НЕ ДОЛЖНА содержать нерецензируемые двоичные артефакты. [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


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

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



Вы можете использовать инструменты и системы ИИ для предложения изменений через простой URL, например https://www.bestpractices.dev/ru/projects/14187/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). Это означает, что получатель данных может распространять данные с изменениями или без них, при условии, что получатель данных предоставляет текст данного соглашения вместе с распространяемыми данными. Пожалуйста, укажите в качестве источника Progressive Robot и участников OpenSSF Best Practices badge.

Владелец анкеты на значок проекта: Progressive Robot.
2026-08-21 05:37:27 UTC, последнее изменение сделано 2026-09-12 02:50:23 UTC. Последний раз условия для получения значка были выполнены 2026-08-21 17:17:16 UTC.