hMailServer

Los proyectos que siguen las mejores prácticas a continuación pueden autocertificarse voluntariamente y demostrar que han obtenido una insignia de mejores prácticas de Open Source Security Foundation (OpenSSF).

No existe un conjunto de prácticas que pueda garantizar que el software nunca tendrá defectos o vulnerabilidades; incluso los métodos formales pueden fallar si las especificaciones o suposiciones son incorrectas. Tampoco existe ningún conjunto de prácticas que pueda garantizar que un proyecto mantenga una comunidad de desarrollo saludable y que funcione bien. Sin embargo, seguir las mejores prácticas puede ayudar a mejorar los resultados de los proyectos. Por ejemplo, algunas prácticas permiten la revisión por parte de múltiples personas antes del lanzamiento, lo que puede ayudar a encontrar vulnerabilidades técnicas que de otro modo serían difíciles de encontrar y ayudar a generar confianza y un deseo repetido de interacción entre desarrolladores de diferentes compañías. Para obtener una insignia, se deben cumplir todos los criterios DEBE y NO DEBE, se deben cumplir, así como todos los criterios DEBERÍAN deben cumplirse o ser justificados, y todos los criterios SUGERIDOS se pueden cumplir o incumplir (queremos que se consideren al menos). Si desea añadir texto como justificación mediante un comentario genérico, en lugar de ser un razonamiento de que la situación es aceptable, comience el bloque de texto con '//' seguido de un espacio. Los comentarios son bienvenidos a través del sitio de GitHub mediante "issues" o "pull requests". También hay una lista de correo electrónico para el tema principal.

Con mucho gusto proporcionaríamos la información en varios idiomas, sin embargo, si hay algún conflicto o inconsistencia entre las traducciones, la versión en inglés es la versión autorizada.
Si este es su proyecto, por favor muestre el estado de su insignia base en la página de su proyecto. El estado de la insignia base se ve así: El nivel de insignia base para el proyecto 14187 es in_progress Aquí se explica cómo insertar la insignia base:
Puede mostrar el estado de su insignia base insertando esto en su archivo markdown:
[![OpenSSF Baseline](https://www.bestpractices.dev/projects/14187/baseline)](https://www.bestpractices.dev/projects/14187)
o insertando esto en su HTML:
<a href="https://www.bestpractices.dev/projects/14187"><img src="https://www.bestpractices.dev/projects/14187/baseline"></a>


Estos son los criterios de Nivel Base 1. Estos son los criterios de la versión v2026.08.28.

Baseline Series: Nivel Base 1 Nivel Base 2 Nivel Base 3

        

 Fundamentos

  • General

    Tenga en cuenta que otros proyectos pueden usar el mismo nombre.

    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.

    Por favor use formato de expresión de licencia SPDX; los ejemplos incluyen "Apache-2.0", "BSD-2-Clause", "BSD-3-Clause", "GPL-2.0+", "LGPL-3.0+", "MIT" y "(BSD-2-Clause OR Ruby)". No incluya comillas simples o comillas dobles.
    Si hay más de un lenguaje, enumérelos como valores separados por comas (los espacios son opcionales) y ordénelos de más a menos usado. Si hay una lista larga, por favor enumere al menos los tres primeros más comunes. Si no hay lenguaje (por ejemplo, este es un proyecto solo de documentación o solo de pruebas), use el carácter único "-". Por favor use una capitalización convencional para cada lenguaje, por ejemplo, "JavaScript".
    La Common Platform Enumeration (CPE) es un esquema de nomenclatura estructurado para sistemas de tecnología de la información, software y paquetes. Se utiliza en varios sistemas y bases de datos al reportar vulnerabilidades.

 Controles 22/24 ●

  • Controles


    ¡Suficiente para una insignia!

    Cuando un usuario intenta leer o modificar un recurso sensible en el repositorio autorizado del proyecto, el sistema DEBE requerir que el usuario complete un proceso de autenticación multifactor. [OSPS-AC-01.01]
    Aplique la autenticación multifactor para el sistema de control de versiones del proyecto, requiriendo que los colaboradores proporcionen una segunda forma de autenticación al acceder a datos sensibles o modificar la configuración del repositorio. Las claves de acceso (passkeys) son aceptables para este control.

    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


    ¡Suficiente para una insignia!

    Cuando se agrega un nuevo colaborador, el sistema de control de versiones DEBE requerir asignación manual de permisos, o restringir los permisos del colaborador a los privilegios más bajos disponibles por defecto. [OSPS-AC-02.01]
    La mayoría de los sistemas de control de versiones públicos están configurados de esta manera. Asegúrese de que el sistema de control de versiones del proyecto siempre asigne los permisos más bajos disponibles a los colaboradores por defecto cuando se agreguen, otorgando permisos adicionales solo cuando sea necesario.

    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


    ¡Suficiente para una insignia!

    Cuando se intenta un commit directo en la rama principal del proyecto, un mecanismo de aplicación DEBE evitar que se aplique el cambio. [OSPS-AC-03.01]
    Si el VCS está centralizado, establezca protección de rama en la rama principal en el VCS del proyecto. Alternativamente, use un enfoque descentralizado, como el del kernel de Linux, donde los cambios se proponen primero en otro repositorio, y fusionar cambios en el repositorio principal requiere un acto separado específico.

    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


    ¡Suficiente para una insignia!

    Cuando se intenta eliminar la rama principal del proyecto, el sistema de control de versiones DEBE tratar esto como una actividad sensible y requerir confirmación explícita de la intención. [OSPS-AC-03.02]
    Establezca protección de rama en la rama principal en el sistema de control de versiones del proyecto para evitar la eliminación.

    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


    ¡Suficiente para una insignia!

    Cuando un pipeline de CI/CD opera con metadatos no confiables, esos parámetros DEBEN sanearse y validarse antes de usarse en el pipeline. [OSPS-BR-01.01]
    Los flujos de CI/CD deben sanear (entre comillas, escapar o salir en valores esperados) todas las entradas de metadatos que correspondan a fuentes no confiables. Esto incluye datos como nombres de ramas, mensajes de confirmación, etiquetas, títulos de solicitudes de incorporación e información del autor.

    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


    ¡Suficiente para una insignia!

    Cuando un flujo de CI/CD opera sobre instantáneas de código no confiable, DEBE impedir el acceso a credenciales y activos privilegiados de CI/CD. [OSPS-BR-01.03]
    Los flujos de CI/CD deben aislar las instantáneas de código no confiable de las credenciales y activos privilegiados. En particular, los proyectos deben tener cuidado de garantizar que los flujos de trabajo que compilan o ejecutan código antes de su revisión por un colaborador no tengan acceso a las credenciales de 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


    ¡Suficiente para una insignia!

    Cuando el proyecto lista un URI como un canal oficial del proyecto, ese URI DEBE ser entregado exclusivamente usando canales cifrados. [OSPS-BR-03.01]
    Configure los sitios web y sistemas de control de versiones del proyecto para usar canales cifrados como SSH o HTTPS para la transmisión de datos. Asegúrese de que todas las herramientas y dominios referenciados en la documentación del proyecto solo puedan accederse a través de canales cifrados.

    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


    ¡Suficiente para una insignia!

    Cuando el proyecto indique una URI como canal de distribución oficial, ese canal DEBE estar protegido contra ataques de adversario en el medio (adversary-in-the-middle) mediante canales criptográficamente autenticados. [OSPS-BR-03.02]
    Los artefactos distribuidos por el proyecto deben distribuirse a través de canales que garanticen la integridad y la autenticidad. El uso de HTTPS para las descargas, versiones firmadas o distribución a través de gestores de paquetes confiables son métodos aceptables para proteger contra ataques de adversario en el medio.

    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


    ¡Suficiente para una insignia!

    El proyecto DEBE prevenir el almacenamiento no intencionado de datos sensibles no cifrados, como secretos y credenciales, en el sistema de control de versiones. [OSPS-BR-07.01]
    Configure .gitignore o equivalente para excluir archivos que puedan contener información sensible. Use hooks de pre-commit y herramientas de escaneo automatizado para detectar y prevenir la inclusión de datos sensibles en los commits.

    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


    ¡Suficiente para una insignia!

    Cuando el proyecto haya realizado un lanzamiento, la documentación del proyecto DEBE incluir guías de usuario para toda la funcionalidad básica. [OSPS-DO-01.01]
    Cree guías de usuario o documentación para toda la funcionalidad básica del proyecto, explicando cómo instalar, configurar y usar las características del proyecto. Si hay acciones peligrosas o destructivas disponibles, incluya advertencias altamente visibles.

    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


    ¡Suficiente para una insignia!

    Cuando el proyecto haya realizado un lanzamiento, la documentación del proyecto DEBE incluir una guía para reportar defectos. [OSPS-DO-02.01]
    Se recomienda que los proyectos utilicen el gestor de incidencias predeterminado de su VCS. Si se utiliza una fuente externa, asegúrese de que la documentación del proyecto y la guía de contribución expliquen claramente y de manera visible cómo usar el sistema de reporte. Se recomienda que la documentación del proyecto también establezca expectativas sobre cómo se clasificarán y resolverán los defectos.

    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


    ¡Suficiente para una insignia!

    El proyecto DEBE contar con uno o más mecanismos para realizar discusiones públicas sobre los cambios propuestos y los obstáculos de uso. [OSPS-GV-02.01]
    Establezca uno o más mecanismos para discusiones públicas dentro del proyecto, como listas de correo, mensajería instantánea o gestores de incidencias, para facilitar la comunicación abierta y la retroalimentación.

    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


    ¡Suficiente para una insignia!

    La documentación del proyecto DEBE incluir una explicación del proceso de contribución, o indicar claramente que no se aceptan contribuciones públicas [OSPS-GV-03.01]
    Cree un archivo CONTRIBUTING.md o un directorio CONTRIBUTING/ para delinear el proceso de contribución, incluyendo los pasos para enviar cambios e interactuar con los mantenedores del proyecto.

    .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


    ¡Suficiente para una insignia!

    La licencia del código fuente DEBE cumplir con la Definición de Código Abierto de la OSI o la Definición de Software Libre de la FSF. [OSPS-LE-02.01]
    Agregue un archivo LICENSE al repositorio del proyecto con una licencia que sea una licencia aprobada por la Open Source Initiative (OSI), o una licencia libre aprobada por la Free Software Foundation (FSF). Ejemplos de tales licencias incluyen MIT, BSD 2-clause, BSD 3-clause revised, Apache 2.0, Lesser GNU General Public License (LGPL), y la GNU General Public License (GPL). Liberar al dominio público cumple con este control si no hay otros gravámenes como patentes.

    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


    ¡Suficiente para una insignia!

    La licencia de los activos de software publicados DEBE cumplir con la Definición de Código Abierto de la OSI o la Definición de Software Libre de la FSF. [OSPS-LE-02.02]
    Si se incluye una licencia diferente con los activos de software lanzados, asegúrese de que sea una licencia aprobada por la Open Source Initiative (OSI), o una licencia libre aprobada por la Free Software Foundation (FSF). Ejemplos de tales licencias incluyen MIT, BSD 2-clause, BSD 3-clause revised, Apache 2.0, Lesser GNU General Public License (LGPL), y la GNU General Public License (GPL). Tenga en cuenta que la licencia para los activos de software lanzados puede ser diferente a la del código fuente.

    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


    ¡Suficiente para una insignia!

    La licencia del código fuente DEBE mantenerse en el archivo LICENSE, el archivo COPYING, el directorio LICENSES/ o el directorio LICENSE/ del repositorio correspondiente. [OSPS-LE-03.01]
    Incluya la licencia del código fuente del proyecto en el archivo LICENSE, el archivo COPYING, el directorio LICENSES/ o el directorio LICENSE/ del proyecto para proporcionar visibilidad y claridad sobre los términos de la licencia. El nombre del archivo PUEDE tener una extensión. Si el proyecto tiene varios repositorios, asegúrese de que cada repositorio incluya el archivo de licencia.

    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


    ¡Suficiente para una insignia!

    La licencia de los activos de software publicados DEBE incluirse en el código fuente publicado, o en un archivo LICENSE, un archivo COPYING o un directorio LICENSE/ junto a los activos de la versión correspondiente. [OSPS-LE-03.02]
    Incluya la licencia de los activos de software lanzados del proyecto en el código fuente lanzado, o en un archivo LICENSE, archivo COPYING o directorio LICENSE/ junto con los activos de lanzamiento correspondientes para proporcionar visibilidad y claridad sobre los términos de licencia. El nombre de archivo PUEDE tener una extensión. Si el proyecto tiene múltiples repositorios, asegúrese de que cada repositorio incluya el archivo de licencia.

    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


    ¡Suficiente para una insignia!

    El repositorio de código fuente del proyecto DEBE ser legible públicamente en una URL estática. [OSPS-QA-01.01]
    Use un VCS común como GitHub, GitLab o Bitbucket. Asegúrese de que el repositorio sea legible públicamente. Evite la duplicación o creación de mirrors de repositorios a menos que la documentación altamente visible aclare la fuente principal. Evite cambios frecuentes en el repositorio que impactarían la URL del repositorio. Asegúrese de que el repositorio sea público.

    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


    ¡Suficiente para una insignia!

    El sistema de control de versiones DEBE contener un registro legible públicamente de todos los cambios realizados, quién los realizó y cuándo se realizaron los cambios. [OSPS-QA-01.02]
    Use un VCS común como GitHub, GitLab o Bitbucket para mantener un historial de commits legible públicamente. Evite aplastar o reescribir commits de una manera que oscurecería al autor de cualquier commit.

    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


    ¡Suficiente para una insignia!

    Cuando el sistema de gestión de paquetes lo admita, el repositorio de código fuente DEBE contener una lista de dependencias que contabilice las dependencias directas del lenguaje. [OSPS-QA-02.01]
    Esto puede tomar la forma de un gestor de paquetes o un archivo de dependencias del lenguaje que enumere todas las dependencias directas como package.json, Gemfile o 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


    ¡Suficiente para una insignia!

    Los proyectos con múltiples repositorios DEBEN documentar una lista de bases de código que forman parte del proyecto. [OSPS-QA-04.01]
    Documente cualquier repositorio de código de subproyecto adicional producido por el proyecto y compilado en un lanzamiento. Esta documentación debe incluir el estado e intención de la respectiva base de código.

    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


    No es suficiente para una insignia.

    El sistema de control de versiones NO DEBE contener artefactos ejecutables generados. [OSPS-QA-05.01]
    Elimine los artefactos ejecutables generados en el sistema de control de versiones del proyecto. Se recomienda que cualquier escenario donde un artefacto ejecutable generado parezca crítico para un proceso como las pruebas, en su lugar debería generarse en el momento de la compilación o almacenarse por separado y obtenerse durante un paso de pipeline específico y bien documentado.

    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


    No es suficiente para una insignia.

    El sistema de control de versiones NO DEBE contener artefactos binarios que no se puedan revisar. [OSPS-QA-05.02]
    No agregue ningún artefacto binario no revisable al sistema de control de versiones del proyecto. Esto incluye binarios de aplicaciones ejecutables, archivos de biblioteca y artefactos similares. No incluye activos como imágenes gráficas, archivos de sonido o música y contenido similar que típicamente se almacena en formato binario.

    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


    ¡Suficiente para una insignia!

    La documentación del proyecto DEBE contener los contactos de seguridad. [OSPS-VM-02.01]
    Cree un archivo security.md (o con nombre similar) que contenga contactos de seguridad para el proyecto.

    .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



Puede utilizar herramientas y sistemas de IA para proponer cambios a través de una URL simple, como https://www.bestpractices.dev/es/projects/14187/choose/edit?osps_ac_01_01_status=Met&osps_ac_01_01_justification=GitHub+enforced. Consulte nuestro sistema de propuestas de automatización para saber cómo hacerlo. Estos datos están disponibles bajo el Acuerdo de Licencia de Datos de la Comunidad – Permisivo, Versión 2.0 (CDLA-Permissive-2.0). Esto significa que un Destinatario de Datos puede compartir los Datos, con o sin modificaciones, siempre que el Destinatario de Datos ponga a disposición el texto de este acuerdo con los Datos compartidos. Por favor, acredite a Progressive Robot y a los colaboradores de la insignia de Mejores Prácticas de OpenSSF.

Entrada de insignia del proyecto propiedad de: Progressive Robot.
Entrada creada el 2026-08-21 05:37:27 UTC, última actualización el 2026-09-12 02:50:23 UTC. Última obtención de la insignia de nivel básico el 2026-08-21 17:17:16 UTC.