hMailServer

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

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

Мы с удовольствием предоставляем информацию на нескольких языках, однако, если есть какой-либо конфликт или несоответствие между переводами, английская версия является авторитетной.
Если это ваш проект, пожалуйста, покажите свой значок на странице проекта! Статус значка выглядит следующим образом: Уровень значка для проекта 14949 - gold Вот как вставить его:
Вы можете показать свой статус значка, вставив его в файл с разметкой Markdown:
[![OpenSSF Best Practices](https://www.bestpractices.dev/projects/14949/badge)](https://www.bestpractices.dev/projects/14949)
- или HTML:
<a href="https://www.bestpractices.dev/projects/14949"><img src="https://www.bestpractices.dev/projects/14949/badge"></a>


Это критерии уровня Silver. Вы также можете просмотреть критерии уровня Passing или Gold.

Baseline Series: Базовый уровень 1 Базовый Уровень 2 Базовый Уровень 3

        

 Основы 17/17 ●

  • Общая

    Обратите внимание, что другие проекты могут использовать то же имя.

    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.

  • Предварительные требования


    Проект ОБЯЗАН получить значок уровня Passing. [achieve_passing]

  • Основная информация на веб-сайте проекта


    В информацию о том, как внести вклад, НЕОБХОДИМО включить требования к приемлемым взносам (например, ссылку на любой требуемый стандарт кодирования). (Требуется URL) [contribution_requirements]

    CONTRIBUTING.md and the merge request template state what an acceptable contribution needs: one logical change from the current master, a warning-free build (/WX, -warnaserror), a regression test for new behaviour, parameterised SQL only, the coding style and licence header, and a Signed-off-by (DCO) on every commit from an outside contributor. The Code of Conduct also applies. https://gitlab.com/Progressiverobot/hmailserver/-/blob/master/CONTRIBUTING.md


  • Надзор за проектом


    Проекту СЛЕДУЕТ иметь юридический механизм, через который все авторы содержательных взносов в ПО проекта подтверждают, что они имеют законное право на внесение этих взносов. Самый распространенный и легко реализуемый подход для этого заключается в использовании Developer Certificate of Origin (DCO), при котором пользователи добавляют строку "signed-off-by" в свои коммиты, а проект ссылается на веб-сайт DCO. Но этот механизм МОЖЕТ быть реализован и в качестве Лицензионного соглашения с участниками (Contributor License Agreement, CLA) или другого правового механизма. (Требуется URL) [dco]
    DCO является рекомендуемым механизмом, потому что его легко реализовать и отслеживать в исходном коде, а git напрямую поддерживает функцию "signed-off" при помощи "commit -s". Для большей эффективности лучше всего, если проектная документация объясняет, что означает "signed-off" для этого проекта. CLA - это юридическое соглашение, которое определяет условия, на которых произведения умственного труда были лицензированы для организации или проекта. Соглашение о назначении участника (contributor assignment agreement, CAA) является юридическим соглашением, которое передает права на произведения умственного труда другой стороне; проекты не обязаны иметь CAA, поскольку CAA увеличивает риск того, что потенциальные участники не будут вносить свой вклад, особенно если получатель является коммерческой организацией. Лицензии CLA от Apache Software Foundation (лицензия отдельного участника и корпоративное соглашение CLA) являются примерами CLA для проектов, считающих, что риски от такого рода CLA для проекта меньше, чем их преимущества.

    CONTRIBUTING.md's Sign-off section links the Developer Certificate of Origin, says what the Signed-off-by trailer means, and requires it (git commit -s) on every commit of a merge request from outside the project; the maintainers' own commits are exempt, and there is no CLA. The sign-off job in .gitlab-ci.yml checks those merge requests; none has arrived yet, so it has not run. https://gitlab.com/Progressiverobot/hmailserver/-/blob/master/CONTRIBUTING.md#sign-off



    Проект ОБЯЗАН четко определить и задокументировать модель управления проектом (способ принятия решений, включая ключевые роли). (Требуется URL) [governance]
    Требуется устоявшийся задокументированный способ принятия решений и разрешения споров. В небольших проектах это может быть просто вплоть до «владелец и лидер проекта принимает все окончательные решения». Существуют различные модели управления, включая благосклонное диктаторство и формальную меритократию; более подробно см. Governance models. В проектах успешно используются как централизованные подходы (например, с одним ведущим), так и децентрализованные (например, с групповыми ведущими). Не нужно указывать в сведениях об управлении возможность форка проекта, поскольку это всегда возможно для проектов СПО.

    GOVERNANCE.md documents the model: two maintainers (Christopher Holloway and Zain Ul Abidin), stewarded by Progressive Robot Ltd, who decide in the open on the issue tracker. When they disagree, both positions are written on the issue and Christopher Holloway decides, giving his reason. The document also covers roles, how to become a maintainer, critical assets and continuity. https://gitlab.com/Progressiverobot/hmailserver/-/blob/master/GOVERNANCE.md



    Проект ОБЯЗАН определить правила поведения и разместить эти правила в стандартном месте. (Требуется URL) [code_of_conduct]
    Проекты могут повысить цивилизованность их сообщества и установить ожидания относительно приемлемого поведения, приняв правила поведения. Это может помочь избежать проблем до их возникновения и сделать проект более привлекательным местом, поощряющим участие. Правила должны быть сосредоточены только на поведении в сообществе или на рабочем месте проекта. Примерами правил поведения являются правила конфликтов на проекте ядра Linux, Contributor Covenant Code of Conduct, Кодекс поведения Debian, Ubuntu Code of Conduct, Правила поведения проекта Fedora, GNOME Code Of Conduct, KDE Community Code of Conduct">, Python Community Code of Conduct, The Ruby Community Conduct Guideline и The Rust Code of Conduct.

    The project adopts the Contributor Covenant 2.1, in the standard location CODE_OF_CONDUCT.md at the repository root and linked from CONTRIBUTING.md. It applies to the GitLab project and says how to report privately (a confidential issue, or the Service Desk address). https://gitlab.com/Progressiverobot/hmailserver/-/blob/master/CODE_OF_CONDUCT.md



    Проект ОБЯЗАН четко определять и публично документировать ключевые роли в проекте и их обязанности, включая любые задачи, которые должны выполнять эти роли. Должно быть ясно, кто имеет какую роль(и), хотя это может быть и не задокументировано соответствующим образом. (Требуется URL) [roles_responsibilities]
    Документация для управления , а также роли и обязанности могут быть в одном месте.

    GOVERNANCE.md defines the roles and their duties: Maintainer (accepting changes, releasing per RELEASE.md, security response per SECURITY.md, direction, infrastructure), Contributor and Reporter. A table says who holds which duty: Christopher Holloway (Progressiverobot on GitLab) holds all of them, and Zain Ul Abidin shares accepting changes and direction. https://gitlab.com/Progressiverobot/hmailserver/-/blob/master/GOVERNANCE.md



    Проект ОБЯЗАН быть в состоянии продолжать работу с минимальным прерыванием, если какой-либо человек окажется недееспособен или убит. В частности, проект ОБЯЗАН быть в состоянии создавать и закрывать вопросы в трекере, принимать предложенные изменения и выпускать версии программного обеспечения через неделю после подтверждения того, что данный человек недееспособен или убит. Это МОЖЕТ быть реализовано через обеспечение кого-то ещё необходимыми ключами, паролами и законными правами для продолжения проекта. Лица, которые запускают проект СПО, МОГУТ сделать это, оставив ключи в сейфе и завещание, передающее все необходимые юридические права (например, для имен DNS). (Требуется URL) [access_continuity]

    GOVERNANCE.md (Critical assets, Continuity) lists the credentials whose loss would stop the project - project ownership, the release and code-signing path, and the build and test environment recipes - and says the owner keeps them in a managed arrangement that a trusted person can reach on confirmed unavailability, with the legal authority to use them, so issues, changes and releases can continue within days. The second maintainer is a Developer member of the GitLab project and can triage and close issues; RELEASE.md documents every release step. https://gitlab.com/Progressiverobot/hmailserver/-/blob/master/GOVERNANCE.md#continuity



    Проекту СЛЕДУЕТ поддерживать «коэффициент автобуса» 2 или более. (Требуется URL) [bus_factor]
    «Коэффициент автобуса» (или «коэффициент грузовика») - это минимальное количество участников проекта, которые должны внезапно исчезнуть из проекта («попасть под автобус»), чтобы проект заглох из-за отсутствия квалифицированного или компетентного персонала. Инструмент truck-factor может оценить это для проектов на GitHub. Для получения дополнительной информации см. статью Cosentino et al. Assessing the Bus Factor of Git Repositories.

    GOVERNANCE.md names two maintainers but says the record of knowing the codebase is still one person's. In the past year all but one human commit on master are Christopher Holloway's; the second maintainer, Zain Ul Abidin (a Developer on GitLab), has one. Only the owner's account can push master or create release tags. https://gitlab.com/Progressiverobot/hmailserver/-/blob/master/GOVERNANCE.md#continuity


  • Документация


    Проект ОБЯЗАН иметь задокументированный долгосрочный план (roadmap), описывающий, что проект намеревается, а что не намеревается делать, по крайней мере на ближайший год. (Требуется URL) [documentation_roadmap]
    Проект может не достичь того, что описано в долгосрочном плане, и это нормально. Цель дорожной карты - помочь потенциальным пользователям и участникам понять намеченное направление проекта. Подробности не требуются.

    Roadmap.md records what the project intends to do and deliberately will not do, with a status and reason for each item, and Roadmap2.md plans the current programme of work. Roadmap items are also tracked as issues with the roadmap label. https://gitlab.com/Progressiverobot/hmailserver/-/blob/master/Roadmap.md



    Проект ОБЯЗАН включать документацию по архитектуре (также называемой высокоуровневым дизайном) ПО, создаваемого проектом. Выберите «неприменимо» (N/A), если проект не создает программное обеспечение. (Требуется URL) [documentation_architecture]
    Архитектура ПО объясняет фундаментальную структуру программы, то есть основные компоненты программы, отношения между ними и ключевые свойства этих компонентов и отношений.

    ARCHITECTURE.md documents the high-level design: the repository's shape, the server's components (COM API as the management seam, Common, SMTP, IMAP/POP3, SQL persistence with parameterised queries), the tools, the tests, and the constraints between them. https://gitlab.com/Progressiverobot/hmailserver/-/blob/master/ARCHITECTURE.md



    Проект ОБЯЗАН документировать то, что пользователь может и чего он не должен ожидать с точки зрения безопасности от ПО, создаваемого проектом (его «требования безопасности»). (Требуется URL) [documentation_security]
    Это требования безопасности, выполнение которых ожидается от ПО.

    SECURITY.md states what users can and cannot expect: the supported versions, the classes of issue treated as vulnerabilities, an explicit out-of-scope list (administrator-level access, deliberately unencrypted listeners, unsubstantiated scanner output), and how to verify a release. ASSURANCE-CASE.md argues why the security requirements are met. https://gitlab.com/Progressiverobot/hmailserver/-/blob/master/SECURITY.md



    Проект ОБЯЗАН предоставить руководство для быстрого начала работы для новых пользователей, чтобы помочь им быстро что-то сделать, используя ПО, создаваемое проект. (Требуется URL) [documentation_quick_start]
    Идея состоит в том, чтобы показать пользователям, как начать работу и и добиться, чтобы ПО что-то вообще сделало. Потенциальным пользователям это критически важно для начала работы.

    The README's Installing section and the wiki's Installing-hMailServer and Your-First-Domain-and-Mailbox pages take a new user from the single installer (or the .deb/.rpm) to a working domain and mailbox. The Control Deck's first-hour checklist can also create a sample domain to try things on. https://gitlab.com/Progressiverobot/hmailserver/-/wikis/Your-First-Domain-and-Mailbox



    Проект ОБЯЗАН прилагать усилия к тому, чтобы документация соответствовала текущей версии результатов проекта (включая ПО, создаваемое проектом). НЕОБХОДИМО исправлять любые известные дефекты документации, приводящие к ее непоследовательности. Если документация в целом актуальна, но ошибочно включает в себя некоторые более старые данные, которые больше не верны, просто рассматривайте это как дефект, отслеживайте и исправляйте, как обычно. [documentation_current]
    Документация МОЖЕТ включать информацию о различиях или изменениях между версиями программного обеспечения и/или ссылку на более старые версии документации. Смысл этого критерия заключается в том, что прилагаются усилия для обеспечения согласованности документации, а не в том, чтобы документация была идеальной.

    The documentation is revised with the code, and known defects in it are filed as GitLab issues with the documentation label (for example #15, documents that still name 6.3.3 as the latest release). Before 6.3.4, its CHANGELOG section was checked against the code and thirteen statements were corrected: https://gitlab.com/Progressiverobot/hmailserver/-/commit/40c7d3e0c



    НЕОБХОДИМО размещать ссылку на любые свои достижения, включая этот значок передовой практики, на главной странице проекта и/или веб-сайте в течение 48 часов после открытого признания достижения. (Требуется URL) [documentation_achievements]
    Достижением считается любой набор внешних критериев, над выполнением которых проект специально работал, включая некоторые значки. Эта информация не обязательно должна находиться на главной странице веб-сайта проекта. Проект с использованием GitHub может помещать достижения на главную страницу хранилища кода, добавляя их в файл README.

    The README opens with the OpenSSF Best Practices badge, hyperlinked to the project's entry on bestpractices.dev. It still points at the old entry (14187), so it must be changed to this entry's number when this entry reaches passing. https://gitlab.com/Progressiverobot/hmailserver/-/blob/master/README.md


  • Общедоступность и интернационализация


    Проекту (как на сайтах проекта, так и в результатах работы проекта) СЛЕДУЕТ придерживаться передовой практики общедоступности, чтобы люди с ограниченными возможностями могли участвовать в проекте и использовать результаты проекта, где это имеет смысл. [accessibility_best_practices]
    Для веб-приложений см. Руководство по обеспечению доступности веб-контента (WCAG) 2.0 и его поддерживающий документ Understanding WCAG 2.0; см. также W3C accessibility information. Для приложений с графическим интерфейсом рассмотрите использование соответствующих вашему окружению рекомендаций по обеспечению доступности (таких как GNOME, KDE, XFCE, Android, iOS, Mac и Windows (на русском)). Некоторые приложения с текстовым интерфейсом пользователя (например, программы на ncurses) могут сделать некоторые вещи, чтобы сделать себя более доступными (например, параметр `force-arrow-cursor` в `alpine`). Большинство приложений командной строки довольно общедоступны как они есть. Этот критерий часто неприменим, например, для библиотек программ. Вот несколько примеров действий или проблем, которые следует учитывать:
    • Должны предоставляться текстовые альтернативы для любого нетекстового контента, так чтобы его можно изменить на другие необходимые формы, например крупная печать, шрифт Брайля, озвучка текста, символы или упрощенный язык (Understanding WCAG 2.0 guideline 1.1)
    • Цвет не должен использоваться в качестве единственного визуального средства передачи информации, указания на действие, запрос реакции пользователя или выделения визуальных элементов. (WCAG 2.0 guideline 1.4.1)
    • Визуальное представление текста и изображений текста должно иметь контрастность не менее 4,5:1, за исключением большого текста, случайного текста и логотипов (WCAG 2.0 guideline 1.4.3)
    • Все функциональные возможности должны быть доступны с клавиатуры (WCAG guideline 2.1)
    • GUI или веб-проект ДОЛЖНЫ тестировать, по крайней мере, одно средство чтения экрана на целевой платформе(ах) (например, NVDA, Jaws или WindowEyes в Windows; VoiceOver на Mac и iOS; Orca на Linux/BSD; TalkBack на Android). Программы с текстовым интерфейсом пользователя МОГУТ по возможности сокращать переписывание текста на экране, чтобы предотвратить лишнее чтение средствами чтения экрана.

    The Control Panel gives every control an accessible name and never carries a status by colour alone (hmailserver/docs/ControlPanelDesign.md); AccessibleNamesTests in ControlPanel.Tests checks the naming. The webmail is built to be used with a screen reader (landmarks, a skip link, focus that follows navigation; README). The project's documents are Markdown rendered by GitLab. https://gitlab.com/Progressiverobot/hmailserver/-/tree/master/hmailserver/source/Tools/ControlPanel.Tests



    Проекту СЛЕДУЕТ интернационализировать создаваемое ПО, чтобы обеспечить легкую локализацию под культуру, регион или язык целевой аудитории. Выберите «неприменимо» (N/A), если интернационализация (i18n) не применяется (например, ПО не генерирует текст, предназначенный для конечных пользователей, и не сортирует текст, читаемый человеком), [internationalization]
    Локализация "относится к адаптации продукта, приложения или содержимого документа для соответствия языковым, культурным и другим требованиям конкретного целевого рынка (языковому стандарту)". Интернационализация - это «проектирование и разработка продукта, приложения или содержимого документа, которые позволяют легкую локализацию под целевые аудитории, различающиеся по культуре, региону или языку». (См. «Локализация по сравнению с интернационализацией» на веб-сайте W3C.) Чтобы ПО соответствовало этому критерию, достаточно лишь интернационализации. Не требуется локализация для другого конкретного языка, так как после того, как программное обеспечение было интернационализировано, другие могут работать над локализацией.

    User-facing text is served through language layers. The server has Languages.cpp and the COM Languages API, with per-language files that the installer's section_languages.iss offers. The Control Panel has resource files for 17 languages besides English (Resources/Strings.<lang>.resx). The self-service portal has 23 language files (Server/Common/Util/PortalLanguages). https://gitlab.com/Progressiverobot/hmailserver/-/blob/master/hmailserver/source/Server/Common/Util/Languages.cpp


  • Другое


    Если на сайтах проекта (веб-сайт, хранилище и URL-адреса загрузки) хранятся пароли для аутентификации внешних пользователей, НЕОБХОДИМО хранить пароли как итерированные хеши с отдельной "солью" для каждого пользователя с использованием алгоритма (итерированного) растяжения ключа (например, Argon2id, Bcrypt, Scrypt или PBKDF2). Выберите «неприменимо» (N/A), если сайты проекта не хранят пароли для этой цели. [sites_password_security]
    Примечание: использование GitHub автоматически выполняет этот критерий. Этот критерий применяется только к паролям, используемым для аутентификации внешних пользователей на сайтах проекта (т.н. входящей аутентификации). Если сайты проекта должны подключаться к другим сайтам (т.н. исходящая аутентификация), им может потребоваться хранить аутентифицирующие данные (пароли, ключи) для этой цели как-то иначе (поскольку хранение контрольной суммы для этой цели бесполезно). В данном случае критерий crypto_password_storage применяется к сайтам проекта, по аналогии с критерием sites_https.

    The repository, issue tracker and downloads are on GitLab, which stores users' passwords as salted bcrypt hashes. The project forum, https://www.hmailserver.co.uk/, runs NodeBB and has local accounts; NodeBB stores each password as a bcrypt hash with a per-user salt and a work factor.


 Управление изменениями 1/1 ●

  • Предыдущие версии


    Проект ОБЯЗАН поддерживать наиболее часто используемые старые версии продукта или предоставлять возможность простого перехода на более новые версии (upgrade path). Если переход затруднен, проект ОБЯЗАН задокументировать порядок обновления (например, изменившиеся интерфейсы и подробные предлагаемые шаги для обновления). [maintenance_or_update]

    An upgrade path is provided from every earlier hMailServer version. Installing over an existing deployment keeps the configuration and the mail, and the database upgrade chain is continuous: hmailserver/source/DBScripts, applied by the installer and by DBUpdater. SECURITY.md states that the 6.3 line is supported and that the answer for older versions is this in-place upgrade. https://gitlab.com/Progressiverobot/hmailserver/-/blob/master/SECURITY.md


 Отчеты о проблемах 3/3 ●

  • Процесс сообщения об ошибках


    Проект ОБЯЗАН использовать трекер вопросов (issue tracker) для отслеживания отдельных вопросов. [report_tracker]

    GitLab issues is the project's issue tracker, with labels for area, type and workflow state: https://gitlab.com/Progressiverobot/hmailserver/-/issues


  • Процесс отчета об уязвимостях


    Проект ОБЯЗАН отмечать автора(-ов) всех отчетов об уязвимостях, разрешенных за последние 12 месяцев, за исключением авторов, которые просят об анонимности. Выберите «неприменимо» (N/A), если в течение последних 12 месяцев не было обнаружено никаких уязвимостей. (Требуется URL) [vulnerability_report_credit]

    The vulnerabilities resolved in the last 12 months (among them the REST settings routes in 6.3.3, the COM access checks in 6.2.10 and the JScript escaping flaw in 6.3.4) were all found by the project's own review or analysis, and none came from an outside report, so no reporter is uncredited; SECURITY.md commits to crediting reporters in the release notes unless they ask not to be named. https://gitlab.com/Progressiverobot/hmailserver/-/blob/master/CHANGELOG.md



    Проект ОБЯЗАН иметь документированный процесс реагирования на отчеты об уязвимостях. (Требуется URL) [vulnerability_response_process]
    Этот критерий тесно связан с критерием vulnerability_report_process, который требует документированного способа для сообщения об уязвимостях. Он также связан с vulnerability_report_response, который требует ответа на отчеты об уязвимостях в течение определенного периода времени.

    SECURITY.md documents the response: private report by confidential issue or Service Desk email, acknowledgement within 5 working days, assessment within 10, a fix with a regression test within 90 days, coordinated disclosure at 90 days, credit in the release notes, and a CVE ID requested through GitLab, which is a CNA. https://gitlab.com/Progressiverobot/hmailserver/-/blob/master/SECURITY.md


 Качество 19/19 ●

  • Стандарты кодирования


    Проект ОБЯЗАН задать определенные правила стиля кодирования для основных языков, которые он использует, и требовать его соблюдения от предлагаемого кода. (Требуется URL) [coding_standards]
    В большинстве случаев это делается путем ссылки на некоторые существующие руководства по стилю, возможно, с перечислением различий. Эти руководства по стилю могут включать в себя способы повышения удобочитаемости и способы снижения вероятности дефектов (включая уязвимости). Многие языки программирования имеют один или несколько широко используемых руководств по стилю. Примеры руководств по стилю включают Руководство по стилю Google и Стандарты кодирования SEI CERT.

    CONTRIBUTING.md (Code style and licence headers) sets the rules contributions must follow. .editorconfig requires spaces with three to an indent in C++ and C#, a final newline and no trailing whitespace. C++ builds at warning level 3 with /WX, and dotnet format formats C#. SQL is parameterised only, a new setting goes in the database, and every source file carries the licence header. https://gitlab.com/Progressiverobot/hmailserver/-/blob/master/CONTRIBUTING.md#code-style-and-licence-headers



    Проект ОБЯЗАН автоматически применять свой выбранный стиль(и) кодирования, если есть хотя бы один инструмент на СПО, который может сделать это на выбранном языке (языках). [coding_standards_enforced]
    Это МОЖЕТ быть реализовано при помощи инструмента(ов) статического анализа и/или путем пропускания кода через средства переформатирования. Во многих случаях конфигурация инструмента включена в репозиторий проекта (так как разные проекты могут выбирать разные конфигурации). Проекты МОГУТ (и, как правило, будут) допускать исключения стиля; там, где происходят исключения, они ОБЯЗАНЫ быть редки и документированы в соответствующих местах кода, чтобы эти исключения можно было пересматривать и инструменты могли автоматически обрабатывать их в будущем. Примеры таких инструментов включают ESLint (JavaScript) и Rubocop (Ruby).

    The style is declared in .editorconfig, and the editorconfig job of .gitlab-ci.yml runs editorconfig-checker (FLOSS) over every text file, with a negative control. No GitLab pipeline has run that job yet. Until 18 September 2026, GitHub's style workflow ran the same check on every push. https://gitlab.com/Progressiverobot/hmailserver/-/blob/master/.gitlab-ci.yml


  • Рабочая система сборки


    Системы сборки для нативных двоичных файлов ОБЯЗАНЫ учитывать соответствующие переменные (среды) для компилятора и компоновщика, переданные им (например, CC, CFLAGS, CXX, CXXFLAGS и LDFLAGS) и передавать их на вызовы компилятора и компоновщика. Система сборки МОЖЕТ расширять их дополнительными флагами; НЕДОПУСТИМО просто заменять предоставленные значения своими. Выберите «неприменимо» (N/A), если нативные двоичные файлы не создаются. [build_standard_variables]
    Должно быть легко включить специальные функции сборки, такие как Address Sanitizer (ASAN), или выполнить рекомендации по упрочнению от дистрибутивов (например, путем простого включения флагов компилятора для этого).

    The Linux build is CMake, which takes CC, CXX, CFLAGS, CXXFLAGS and LDFLAGS from the environment and passes them to the compiler and linker. CMakeLists.txt only appends its own options (add_compile_options) and never replaces CMAKE_C_FLAGS or CMAKE_CXX_FLAGS; build/ci/linux-build.sh chooses the compiler through CC and CXX. The Windows MSBuild build has no such variables and takes Configuration, Platform and PlatformToolset instead. https://gitlab.com/Progressiverobot/hmailserver/-/blob/master/hmailserver/source/Server/CMakeLists.txt



    В системах сборки и установки СЛЕДУЕТ сохранять отладочную информацию, если передаваемые флаги требуют этого (например, не используется «install -s»). Выберите «неприменимо» (N/A), если системы сборки или установки нет (например, для типичных библиотек JavaScript), . [build_preserve_debug]
    Например, установка CFLAGS (C) или CXXFLAGS (C++) должна создавать соответствующую информацию для отладки, если эти языки используются, и ее не следует удалять во время установки. Отладочная информация необходима для поддержки и анализа, а также полезна для того, чтобы определить наличие упрочняющих функций в скомпилированных двоичных файлах.

    The Windows projects set DebugInformationFormat ProgramDatabase and GenerateDebugInformation true, so every Release build writes a .pdb beside the binary. The CMake build honours CMAKE_BUILD_TYPE (Debug, RelWithDebInfo) and -g in CXXFLAGS, and cmake --install does not strip. The .deb and .rpm that CPack makes are stripped (CPACK_STRIP_FILES). https://gitlab.com/Progressiverobot/hmailserver/-/blob/master/hmailserver/source/Server/hMailServer/hMailServer.vcxproj



    НЕДОПУСТИМО, чтобы система сборки ПО, создаваемого проектом, рекурсивно собирала подкаталоги, если в подкаталогах есть кросс-зависимости. Выберите «неприменимо» (N/A), если системы сборки или установки нет (например, типичные библиотеки JavaScript). [build_non_recursive]
    Информация о внутренних зависимостях системы сборки проекта должна быть точной, в противном случае изменения в проекте могут быть включены в сборку неправильно. Неправильные сборки могут привести к дефектам (включая уязвимости). Общей ошибкой в ​​больших системах сборки является использование «рекурсивной сборки» или «рекурсивного make», то есть иерархии подкаталогов, содержащих исходные файлы, где каждый подкаталог собирается независимо. Если только каждый из подкаталогов не является полностью независимым, это ошибка, потому что информация о зависимостях неверна.

    No build is recursive. On Windows, one MSBuild solution (hMailServer.sln) resolves build order from the project references. On Linux, one CMakeLists.txt with no add_subdirectory builds the core library, the server and its test programs from a single dependency graph. https://gitlab.com/Progressiverobot/hmailserver/-/blob/master/hmailserver/source/Server/CMakeLists.txt



    Проект ОБЯЗАН быть в состоянии повторить процесс генерации информации из исходных файлов и получить такой же результат с точностью до бита. Выберите «неприменимо» (N/A), если в проекте не используется сборка (например, языки сценариев, в которых исходный код используется непосредственно вместо компиляции), . [build_repeatable]
    Пользователи GCC и clang могут найти полезной опцию -frandom-seed; в некоторых случаях это может быть разрешено путем задания определенного порядка сортировки. Дополнительные предложения можно найти на сайте Reproducible builds.

    The Windows server compiles and links with /Brepro, /d1trimfile and /pdbaltpath, with OPENSSL_NO_FILENAMES defined. Two clean Release builds of the same tree on one machine gave a byte-identical hMailServer.exe (first on 22 August 2026, recorded in Roadmap.md), and RELEASE.md step 8 requires that check for every release. The Linux build uses -ffile-prefix-map and SOURCE_DATE_EPOCH. https://gitlab.com/Progressiverobot/hmailserver/-/blob/master/RELEASE.md


  • Система установки


    Проект ОБЯЗАН предоставлять возможность легко установить и удалить ПО, создаваемое проектом, с использованием общепринятых способов. [installation_common]
    Примеры включают использование менеджера пакетов (на уровне системы или языка), «make install/uninstall» (с поддержкой DESTDIR), контейнер в стандартном формате или образ виртуальной машины в стандартном формате. Процесс установки и удаления (например, его упаковка) МОЖЕТ быть реализован третьей стороной, при условии что он построен на СПО.

    On Windows, one Inno Setup installer (hMailServer-x.y.z-x64.exe) installs, upgrades in place and uninstalls from Apps and Features, and supports unattended install. On Linux, a .deb and an .rpm install and remove with the system package manager. The installer smoke test (install, upgrade, uninstall) is run by hand on a throwaway Windows Server 2025 VM, first on 25 September 2026, not in CI. https://gitlab.com/Progressiverobot/hmailserver/-/blob/master/README.md#installing



    В системе установки для конечных пользователей НЕОБХОДИМО учитывать стандартные соглашения при выборе места, в которое собранные артефакты записываются при установке. Например, если она устанавливает файлы в системе POSIX, НЕОБХОДИМО учитывать переменную окружения DESTDIR. Если установочной системы или стандартного соглашения нет, выберите «неприменимо» (N/A). [installation_standard_variables]

    The Windows installer defaults to Program Files and honours Inno Setup's standard /DIR= switch (documented in the README's Unattended install table). The Linux install is CMake's install() with GNUInstallDirs, so it honours DESTDIR, and the .deb and .rpm are built through it. https://gitlab.com/Progressiverobot/hmailserver/-/blob/master/README.md#unattended-install



    Проект ОБЯЗАН предоставить возможность потенциальным разработчикам быстро установить все результаты проекта и поддерживать среду, необходимую для внесения изменений, включая тесты и тестовое окружение. Проект ОБЯЗАН использовать для этого общепринятые соглашения. [installation_development_quick]
    Это МОЖЕТ быть реализовано при помощи сгенерированного контейнера или установочных сценариев. Внешние зависимости обычно устанавливаются путем вызова системных и/или языковых пакетов, как описано в критерии external_dependencies.

    CONTRIBUTING.md lists every prerequisite with its pinned version and one command per component: scripts that download and build the external libraries with checked hashes, build.ps1, build-tools.ps1, build-tests.ps1, and the CMake/Ninja commands with the Debian/Ubuntu package list for Linux. The CI image build/ci/linux.Dockerfile is a ready-made Linux build and test environment. https://gitlab.com/Progressiverobot/hmailserver/-/blob/master/CONTRIBUTING.md#prerequisites


  • Компоненты, поддерживаемые извне


    Проект ОБЯЗАН перечислять внешние зависимости в машинночитаемом виде. (Требуется URL) [external_dependencies]
    Обычно это делается при помощи инструкций для диспетчера пакетов и/или системы сборки. Обратите внимание, что это помогает реализовать критерий installation_development_quick.

    Dependencies are listed in machine-readable form: the .NET projects' committed NuGet lock files (packages.lock.json), the native libraries' pinned versions in the project files, and every vendored or fetched binary with its version, origin and SHA-256 in hmailserver/docs/third-party-binaries.json. SPDX and CycloneDX SBOMs were attached to the releases up to 6.3.3. https://gitlab.com/Progressiverobot/hmailserver/-/blob/master/hmailserver/docs/third-party-binaries.json



    Проекты ОБЯЗАНЫ следить за своими внешними зависимостями или периодически проверять их (включая копии, сделанные для удобства) на предмет известных уязвимостей, а также исправлять уязвимости, которые могут быть использованы, или проверять невозможность их использования. [dependency_monitoring]
    Это можно сделать с помощью средств анализа происхождения/зависимостей, например Dependency-Check от OWASP, Nexus Auditor от Sonatype, Protex от Black Duck , Protecode от Synopsys и Bundler-аудит (для Ruby). Некоторые менеджеры пакетов включают в себя соответствующие механизмы. Допустимо оставлять уязвимость, если ее невозможно использовать, но такой анализ труден, и временами проще просто обновить или исправить эту часть кода.

    The dependency-scan job in .gitlab-ci.yml (Trivy over the lock files and the CI image, OSV over the vendored libraries) was run by hand on the project's runner on 25 September 2026. What it found (zlib 1.3.1's CVE-2026-27171, and a 7-Zip 19.00 that OSV cannot match) was fixed the same day by moving to zlib 1.3.2 and 7-Zip 26.03; a finding that does not affect the project is dismissed with its reason in the VEX document. The job has not yet run in a GitLab pipeline; Renovate (renovate.json) waits for the owner's token and schedule, and Dependabot ran on GitHub until 18 September 2026. https://gitlab.com/Progressiverobot/hmailserver/-/blob/master/hmailserver/docs/ContinuousIntegration.md#security-scanning



    Проект ОБЯЗАН:
    1. позволять легко идентифицировать и обновлять повторно используемые компоненты, поддерживаемые извне; или
    2. использовать стандартные компоненты, предоставляемые системой или языком программирования.
    В этом случае, если уязвимость обнаружена в повторно используемом компоненте, будет легко обновить этот компонент. [updateable_reused_components]
    Типичным способом выполнить этот критерий является использование предоставляемых операционной системой и языком программирования систем управления пакетами. Многие свободные программы распространяются с «подсобными библиотеками», которые являются локальными копиями стандартных библиотек (возможно, форков библиотек). Само по себе это нормально. Однако, если программа *должна* использовать эти локальные копии/форки, то обновление «стандартных» библиотек через системное обновление безопасности оставит эти дополнительные копии по-прежнему уязвимыми. Это особенно актуально для облачных систем; если провайдер облака обновляет свои «стандартные» библиотеки, но программа их не собирается использовать, обновления фактически не помогут. См., например, "Chromium: Why it isn't in Fedora yet as a proper package" от Тома Каллавея.

    Reused components are named and pinned where they can be updated: the .NET packages in committed NuGet lock files restored with --locked-mode, OpenSSL, Boost and libpq by version and source hash in the libraries/ build scripts, and every third-party binary by SHA-256 in hmailserver/docs/third-party-binaries.json, inventoried in ThirdPartyBinaries.md. Renovate (renovate.json) is configured to propose updates but waits for the owner's token and schedule. https://gitlab.com/Progressiverobot/hmailserver/-/blob/master/hmailserver/docs/ThirdPartyBinaries.md



    Проекту СЛЕДУЕТ избегать использования нерекомендуемых (deprecated) или устаревших (obsolete) функций и API в тех случаях, когда альтернативы на СПО доступны в используемом наборе технологий («стек технологий» проекта) и для подавляющего большинства пользователей, поддерживаемых проектом (т.е. так чтобы пользователи могли быстро воспользоваться этой альтернативой). [interfaces_current]

    The fork is built on current interfaces: Visual Studio 2026 (toolset v145), OpenSSL 4.0.x, Boost 1.92 and .NET 10 for the Control Panel and tools. The README's technology table records these versions, along with the plan to move OpenSSL to the next LTS. Deprecated protocol behaviour is kept only where a mail server must interoperate, and then behind a setting. https://gitlab.com/Progressiverobot/hmailserver/-/blob/master/README.md


  • Набор автотестов


    НЕОБХОДИМО применять автоматический набор тестов к каждому коммиту в общий репозиторий по крайней мере для одной ветки. Этот набор тестов ОБЯЗАН создавать отчет об успешном или неудачном тестировании. [automated_integration_testing]
    Это требование можно рассматривать как подмножество test_continuous_integration, но сосредоточенное только на тестировании, без требования непрерывной интеграции.

    Every code change reaches master only after the maintainer's full regression gate has passed on the tree that lands: the whole Windows regression suite (NUnit), split across two machines, and the whole Linux suite, each reporting the tests that passed and failed (CONTRIBUTING.md, Merge requests); documentation-only commits may follow a gated tree. GitHub Actions ran the automated suites on every push until 18 September 2026; the GitLab CI that replaces them is defined in .gitlab-ci.yml but has not yet run a full pipeline. https://gitlab.com/Progressiverobot/hmailserver/-/blob/master/hmailserver/docs/ContinuousIntegration.md



    Проект ОБЯЗАН добавить регрессионные тесты к автоматизированному набору тестов по крайней мере на 50% ошибок, исправленных в течение последних шести месяцев. [regression_tests_added50]

    A bug is fixed with a regression test that fails against the build before the fix, as SECURITY.md and SUPPORT.md state. Examples: the 6.3.4 JScript escaping fix is pinned in RegressionTests/API/Events.cs, and the CVE-2023-51764 smuggling rule in SMTP/BareLineFeedEndOfData.cs. The automated NUnit suite has 495 C# files. Every change lands only after the maintainer runs the whole Windows suite, split across two machines, and the whole Linux suite. https://gitlab.com/Progressiverobot/hmailserver/-/tree/master/hmailserver/test/RegressionTests



    Проект ОБЯЗАН иметь автоматические тестовые пакеты на СПО, которые обеспечивают покрытие не менее 80% инструкций кода, если есть хотя бы один инструмент на СПО, который может измерять этот критерий на выбранном языке. [test_statement_coverage80]
    Для измерения тестового покрытия существует множество средств на СПО, включая gcov/lcov, Blanket.js, Istanbul и JCov. Обратите внимание, что соответствие этому критерию не является гарантией того, что тестовый пакет является исчерпывающим; вместо этого, несоответствие этому критерию является сильным индикатором плохого набора тестов.

    The native server's coverage was measured once, on 15 September 2026: 73.48% of its lines (67,790 of 92,260 under hmailserver/source/Server) over the whole Windows regression suite, with OpenCppCoverage 0.9.9. That is below 80%. https://gitlab.com/Progressiverobot/hmailserver/-/blob/master/ASSURANCE-CASE.md


  • Тестирование новых функций


    Проект ОБЯЗАН иметь формальную задокументированную политику о том, что при добавлении существенной новой функциональности НЕОБХОДИМО добавлять тесты для новой функциональности в набор автоматических тестов. [test_policy_mandated]

    The policy is written in CONTRIBUTING.md: 'Add or update regression tests for a change of behaviour', and 'A fix ships with a test that fails against the build before it'; the merge-request template's checklist repeats it for new behaviour. https://gitlab.com/Progressiverobot/hmailserver/-/blob/master/CONTRIBUTING.md#merge-requests



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

    The instructions for change proposals, CONTRIBUTING.md's 'Merge requests' section, say to add or update regression tests for a change of behaviour, and the merge-request template's checklist asks that new behaviour be covered by a regression test. https://gitlab.com/Progressiverobot/hmailserver/-/blob/master/CONTRIBUTING.md#merge-requests


  • Флаги предупреждений


    Проекты ОБЯЗАНЫ быть максимально строгими с предупреждениями в ПО, создаваемом проектом, где это целесообразно. [warnings_strict]
    Некоторые предупреждения не могут быть эффективно задействованы в некоторых проектах. Что необходимо в этом критерии - это доказательства того, что проект стремится включать флаги предупреждений там, где это возможно, чтобы ошибки обнаруживались на ранней стадии.

    The Windows build holds the server's own code to MSVC /W3 with /WX (vendored zlib alone is compiled at /W1), and the .NET projects are built with -warnaserror; moving a codebase of this age to /W4 would need mass suppression, and the Linux build adds no warning flags of its own. Beyond compiler warnings, cppcheck and clang-tidy (bugprone, cert, clang-analyzer and concurrency checks) were run over the sources on 25 September 2026 and their findings committed as a baseline, against which the CI job reports any new finding (allow_failure until the baseline is triaged). https://gitlab.com/Progressiverobot/hmailserver/-/blob/master/CONTRIBUTING.md#code-style-and-licence-headers


 Безопасность 13/13 ●

  • Знание безопасной разработки


    Проект ОБЯЗАН реализовывать принципы безопасного дизайна (из критерия «know_secure_design»), где это применимо. Выберите «неприменимо» (N/A), если проект не создает программное обеспечение. [implement_secure_design]
    Например, результаты проекта должны иметь отказоустойчивые значения по умолчанию (доступ по умолчанию должен быть запрещен, а установка проектов по умолчанию должна быть в защищенной конфигурации). Также должно использоваться полное отграничение (любой доступ, который может быть ограничен, должен проверяться на достаточность прав доступа и не иметь обходных путей). Обратите внимание, что в некоторых случаях принципы будут противоречить друг другу, и в этом случае необходимо делать выбор (например, многочисленность механизмов может усложнять дизайн, противореча принципу экономичности/простоты механизма).

    The server fails safe: a new installation is given a certificate, STARTTLS on every listener and TLS required for authentication from other hosts before it first listens. TLS peers are verified by default, and unsafe password-hash schemes are refused. Mediation is complete: all management goes through one API seam (COM, with REST on top), and SQL is parameterised by rule. https://gitlab.com/Progressiverobot/hmailserver/-/blob/master/hmailserver/docs/SecureDefaults.md


  • Основы правильного использования криптографии

    Обратите внимание, что некоторое ПО не нуждается в использовании криптографических механизмов.

    В ПО, создаваемом проектом, НЕДОПУСТИМО делать механизмы безопасности по умолчанию зависимыми от криптографических алгоритмов или режимов с известными серьезными слабостями (например, криптографический алгоритм хеширования SHA-1 или режим CBC в SSH). [crypto_weaknesses]
    Проблемы, связанные с режимом CBC в SSH, обсуждаются в описании уязвимости CERT: SSH CBC.

    The defaults do not depend on seriously weak algorithms. The default cipher list excludes DES, 3DES, MD5, export and null ciphers and lists ECDHE with AES-GCM first; TLS 1.3 is AEAD only; and the AEAD-ONLY preset removes the remaining CBC and SHA-1 HMAC suites. DKIM signs with SHA-256 by default and treats rsa-sha1 signatures as failing (RFC 8301) unless DkimAcceptSha1 is set. Passwords are hashed with PBKDF2 by default. https://gitlab.com/Progressiverobot/hmailserver/-/blob/master/hmailserver/source/Server/Common/AntiSpam/DKIM/DKIM.cpp



    Проекту СЛЕДУЕТ поддерживать несколько криптографических алгоритмов, чтобы пользователи могли быстро переключиться, если один из них поврежден. Общие симметричные ключевые алгоритмы включают AES, Twofish и Serpent. Общие алгоритмы контрольных сумм (хешей) включают SHA-2 (SHA-224, SHA-256, SHA-384 и SHA-512) и SHA-3. [crypto_algorithm_agility]

    Algorithms are settings, not constants. Password hashing is PBKDF2 (the default), Argon2id or scrypt through PreferredHashAlgorithm, with a minimum accepted scheme. The TLS 1.2 cipher list (SslCipherList, with an AEAD-ONLY preset), the TLS 1.3 suites (TlsCipherSuites13) and the key-exchange groups (TlsKeyExchangeGroups) are all configurable, and DKIM signs with RSA-SHA256 or Ed25519. https://gitlab.com/Progressiverobot/hmailserver/-/blob/master/hmailserver/source/Server/Common/Application/IniFileSettings.cpp



    Проект ОБЯЗАН поддерживать хранение данных для аутентификации (например, паролей и динамических токенов) и закрытых криптографических ключей в файлах, отдельных от остальной информации (например, файлов конфигурации, баз данных и журналов) и позволять пользователям их обновление и замену без перекомпиляции кода. Выберите «неприменимо» (N/A), если проект никогда не работает с данными аутентификации и закрытыми криптографическими ключами. [crypto_credential_agility]

    TLS certificates and private keys, and DKIM private keys, are separate PEM files referenced by path from the configuration, and can be replaced without recompiling. Account passwords are stored only as hashes; credentials the server uses to sign in elsewhere (route relays, external accounts) are settings in the database, protected at rest, and changed without recompiling. No credential is compiled into the program. https://gitlab.com/Progressiverobot/hmailserver/-/blob/master/hmailserver/source/Server/Common/TCPIP/SslContextInitializer.cpp



    В ПО, создаваемом проектом, СЛЕДУЕТ поддерживать безопасные протоколы для всех сетевых коммуникаций, такие как SSHv2 или новее, TLS1.2 или новее (HTTPS), IPsec, SFTP и SNMPv3. По умолчанию СЛЕДУЕТ отключать небезопасные протоколы, такие как FTP, HTTP, telnet, SSLv3 или более ранние версии, и SSHv1, и разрешать их только в том случае, если пользователь явным образом это задаёт. Если программное обеспечение, созданное проектом, не поддерживает сетевые коммуникации, выберите «неприменимо» (N/A). [crypto_used_network]

    SMTP, IMAP and POP3 support STARTTLS and implicit TLS. A new installation gets a certificate, offers STARTTLS on 25, 587, 110 and 143, and requires TLS for authentication from the Internet (SecureDefaults.md); a database that is upgraded or attached keeps its previous settings. The REST API (bound to 127.0.0.1) and the web-services listeners are off by default. The SNMP agent is off by default and speaks SNMPv3 authPriv, with v2c a separate opt-in. Outbound delivery supports DANE, MTA-STS and per-domain TLS policy. https://gitlab.com/Progressiverobot/hmailserver/-/blob/master/hmailserver/docs/SecureDefaults.md



    Если ПО, создаваемое проектом, поддерживает или использует TLS, ему СЛЕДУЕТ поддерживать как минимум версию TLS 1.2. Примечание: предшественник TLS называется SSL. Если программное обеспечение не использует TLS, выберите «неприменимо» (N/A). [crypto_tls12]

    TLS 1.2 and 1.3 are the versions a new database enables (SslVersions 24). SSLv2 and SSLv3 cannot be enabled, and TLS 1.0 and 1.1 only by an explicit setting. The regression suite runs TLS 1.2 and 1.3 handshakes (RegressionTests/SSL/SslTlsVersionTests.cs). https://gitlab.com/Progressiverobot/hmailserver/-/blob/master/hmailserver/source/Server/Common/TCPIP/SslContextInitializer.cpp



    В ПО, создаваемом проектом, НЕОБХОДИМО выполнять проверку сертификата TLS по умолчанию при использовании TLS, в том числе в подресурсах. Если программное обеспечение не использует TLS, выберите «неприменимо» (N/A). [crypto_certificate_verification]
    Обратите внимание, что неправильная проверка сертификата TLS является распространенной ошибкой. Для дальнейших сведений см. "The Most Dangerous Code in the World: Validating SSL Certificates in Non-Browser Software" Мартина Георгиева и др. и "Do you trust this application?" Майкла Катанзаро.

    Outbound TLS verifies certificates by default: a new database sets VerifyRemoteSslCertificate to 1. TCPConnection.cpp then sets verify_peer and verify_fail_if_no_peer_cert and installs a callback that checks the chain and the expected host name, with DANE-EE matching where TLSA records apply and MTA-STS forcing verification. Inbound client-certificate verification can be set per port. https://gitlab.com/Progressiverobot/hmailserver/-/blob/master/hmailserver/source/Server/Common/TCPIP/TCPConnection.cpp



    В ПО, создаваемом проектом, НЕОБХОДИМО, если поддерживается TLS, выполнять проверку сертификата TLS по умолчанию при использовании TLS, в том числе в подресурсах. Если программное обеспечение не использует TLS, выберите «неприменимо» (N/A). [crypto_verification_private]

    The verify mode and callback are set on the socket before the handshake, and a failed verification fails the handshake. So the server, as a client, sends SMTP AUTH credentials or any other private data only over a connection that has already been verified. https://gitlab.com/Progressiverobot/hmailserver/-/blob/master/hmailserver/source/Server/Common/TCPIP/TCPConnection.cpp


  • Безопасный выпуск


    Проект ОБЯЗАН криптографически подписывать выпуски результатов проекта, предназначенные для широкого использования, и ОБЯЗАН иметь задокументированный процесс, объясняющий пользователям, как они могут получить общедоступные ключи подписи и проверить подпись(и) выпусков. НЕДОПУСТИМО размещать закрытый ключ для этих подписей на сайте(сайтах), используемом для прямого распространения ПО для общественности. Выберите «неприменимо» (N/A), если выпуски не предназначены для широкого использования. [signed_releases]
    Результаты проекта включают как исходный код, так и любые сгенерированные результаты, если это применимо (например, исполняемые файлы, пакеты и контейнеры). Сгенерированные результаты МОГУТ быть подписаны отдельно от исходного кода. Подписывание МОЖЕТ быть реализовано как подписанные теги git (с использованием криптографических цифровых подписей). Проекты МОГУТ предоставлять генерируемые результаты отдельно от таких инструментов, как git, но в этих случаях отдельные результаты ОБЯЗАНЫ быть отдельно подписаны.

    Every release published on GitLab is signed, and SECURITY.md documents how to get the public keys and verify each signature: https://gitlab.com/Progressiverobot/hmailserver/-/blob/master/SECURITY.md#verifying-a-release. Release tags are SSH-signed with the key listed in the repository's allowed_signers file (also on the maintainer's GitLab account). Every asset of the releases from 6.2.19 to 6.3.3 carries a keyless Sigstore bundle recorded in the public Rekor log. The Windows installer is Authenticode-signed (Progressive Robot Ltd) since 6.3.1. From 6.3.4, the release's SHA256SUMS file, which lists the hash of every asset, is signed with the same SSH key (ssh-keygen -Y sign, verified with ssh-keygen -Y verify against allowed_signers). No private key is on a distribution site: Sigstore signing is keyless, the tag key stays on the maintainer's own machine, and the Authenticode key is held in Azure Artifact Signing.



    ЖЕЛАТЕЛЬНО, чтобы в системе контроля версий каждый важный тег версии (тег, который является частью основного выпуска, минорной версии или исправляет общедоступные уязвимости) подписывался криптографической подписью и поддавался проверке, как описано в критерииsigned_releases. [version_tags_signed]

    Every release tag from v6.2.23-alpha2 on is an annotated tag signed with a maintainer's SSH key, and each verifies with git verify-tag against the allow list in the repository (.github/allowed_signers on master today, .gitlab/allowed_signers once the next batch lands); SECURITY.md's 'Verifying a release' gives the command. https://gitlab.com/Progressiverobot/hmailserver/-/blob/master/SECURITY.md#verifying-a-release


  • Другие вопросы безопасности


    В результатах проекта НЕОБХОДИМО проверять любой ввод из потенциально ненадежных источников, чтобы убедиться, что они действительны (*белый список*), и отклонять недействительный ввод, если вообще есть какие-либо ограничения на данные. [input_validation]
    Обратите внимание, что сравнения ввода со списком «плохих форматов» (также известным как *черный список*) обычно недостаточно, потому что злоумышленники часто могут обойти черный список. В частности, числа преобразуются во внутренние форматы, а затем проверяются, находятся ли они между их минимальным и максимальным (включительно), а текстовые строки проверяются, чтобы убедиться, что они являются допустимыми текстовыми шаблонами (например, действительный UTF-8, длина, синтаксис и т. д.). От некоторых данных может требоваться, чтобы они были «хоть чем-нибудь» (например, загрузчик файлов), но такое обычно случается редко.

    Untrusted protocol input is checked at the boundary: SMTP, IMAP and POP3 commands are parsed against their grammar and anything else is refused. A bare LF before the end-of-data dot is refused (the SMTP smuggling rule, CVE-2023-51764), pinned by SMTP/BareLineFeedEndOfData.cs. SQL is parameterised by rule, and the MIME parser is fuzzed (fuzz/). https://gitlab.com/Progressiverobot/hmailserver/-/tree/master/fuzz



    В ПО, создаваемом проектом, СЛЕДУЕТ использовать механизмы упрочнения безопасности (hardening), чтобы дефекты программного обеспечения с меньшей вероятностью приводили к уязвимостям в безопасности. [hardening]
    Механизмы упрочнения могут включать HTTP-заголовки, такие как Content Security Policy (CSP), флаги компилятора для противостояния атакам (например, -fstack-protector) или флаги компилятора, устраняющие неопределенное поведение. Для наших целей политика наименьших привилегий не считается механизмом упрочнения (использовать наименьшие достаточные привилегии важно, но этому посвящён отдельный критерий).

    The Windows server is built with the MSVC hardening defaults left on (/GS, DEP, ASLR) and with Control Flow Guard (/guard:cf) in every configuration of hMailServer.vcxproj. The web pages it serves send Content-Security-Policy and X-Frame-Options: DENY, and unsafe password-hash schemes are refused for new secrets. https://gitlab.com/Progressiverobot/hmailserver/-/blob/master/hmailserver/source/Server/hMailServer/hMailServer.vcxproj



    Проект ОБЯЗАН предоставить обоснование того, что требования безопасности соблюдаются проектом. В обоснование НЕОБХОДИМО включить: описание модели угроз, четкое указание границ доверия, доказательство того, что использовались принципы безопасного дизайна, и доказательство того, что слабости в безопасности реализации нейтрализованы. (Требуется URL) [assurance_case]
    Обоснованием является «документальное подтверждение, которое дает убедительное и корректное доказательство того, что указанный набор критических заявлений относительно свойств системы адекватно оправдан для данного приложения в данной среде» (перевод выдержки из "Software Assurance Using Structured Assurance Case Models", Thomas Rhodes et al, NIST Interagency Report 7608). Границы доверия - это границы, на которых меняется уровень доверия к данным или выполнению кода, например границы сервера в типичном веб-приложении. В обосновании обычно перечисляются принципы безопасного проектирования (такие как Saltzer and Schroeer) и общие слабости безопасности в реализации (такие как OWASP Top 10 или CWE/SANS Top 25), и показывается, как противодействовать каждой из них. Полезным примером может служить обоснование для BadgeApp. Этот критерий связан с documentation_security, documentation_architecture и implement_secure_design.

    ASSURANCE-CASE.md states the security requirements as seven claims (C1-C7). It covers the threat model (actors A1-A6, assets, attack surfaces) and the trust boundaries B1-B6 with a diagram, argues that secure design principles are applied, maps the countermeasures for common weaknesses to CWE classes (injection, memory corruption, smuggling, credential storage, randomness, certificate validation, resource exhaustion, supply chain), and gives evidence per claim and the residual risks. https://gitlab.com/Progressiverobot/hmailserver/-/blob/master/ASSURANCE-CASE.md


 Анализ 2/2 ●

  • Статический анализ кода


    Проект ОБЯЗАН использовать хотя бы один инструмент статического анализа с правилами или подходами для поиска распространенных уязвимостей в анализируемом языке или окружении, если есть хотя бы один инструмент на СПО, который может реализовать этот критерий на выбранном языке. [static_analysis_common_vulnerabilities]
    Инструменты статического анализа, специально предназначенные для поиска распространенных уязвимостей, с большей вероятностью найдут их. Тем не менее, использование любых статических инструментов обычно помогает найти какие-то проблемы, поэтому мы предлагаем, но не требуем этого для получения базового значка.

    clang-tidy runs the cert-, bugprone- and clang-analyzer-* check families (build/ci/clang-tidy.yaml), which look for common C and C++ weaknesses such as memory errors, unchecked conversions and unsafe functions, and Semgrep runs its open rule packs for C#, Python, JavaScript and shell, which include security rules. Until 18 September 2026 CodeQL's security queries also ran on GitHub. https://gitlab.com/Progressiverobot/hmailserver/-/blob/master/build/ci/clang-tidy.yaml


  • Динамический анализ кода


    Если ПО, создаваемое проектом, включает ПО, написанное с использованием небезопасного языка (например, C или C++), тогда проект ОБЯЗАН регулярно использовать хотя бы один динамический инструмент (например, фаззер или сканер веб-приложения) в сочетании с механизмом для обнаружения проблем безопасности памяти, таких как перезапись буфера. Выберите «неприменимо» (N/A), если проект не создает ПО, написанное на небезопасном языке. [dynamic_analysis_unsafe]
    Примерами механизмов обнаружения проблем безопасности памяти являются Address Sanitizer (ASAN) (доступен в GCC и LLVM), Memory Sanitizer и valgrind. Другие потенциально используемые инструменты включают Thread Sanitizer и Undefined Behavior Sanitizer. Достаточно широкое использование утверждений (assertions) тоже может быть приемлемо.

    The C++ MIME parser is fuzzed with libFuzzer under AddressSanitizer before every minor release (RELEASE.md step 8c; fuzz/, docs/Fuzzing.md). Before each release, the whole regression suite also runs on the assertion build, with a crash oracle that fails a test on any swallowed access violation. The nightly fuzz job (linux-fuzz) and an ASan/UBSan job over snmp-tests (linux-sanitize) are defined in .gitlab-ci.yml but have not yet run on GitLab; nightly fuzzing ran on GitHub until 18 September 2026. https://gitlab.com/Progressiverobot/hmailserver/-/blob/master/hmailserver/docs/Fuzzing.md



Вы можете использовать инструменты и системы ИИ для предложения изменений через простой 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.