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 14949 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/14949/baseline)](https://www.bestpractices.dev/projects/14949)
o insertando esto en su HTML:
<a href="https://www.bestpractices.dev/projects/14949"><img src="https://www.bestpractices.dev/projects/14949/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 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.

    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.

    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.

 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.

    Only the Owner account, Progressiverobot, can change project settings, CI/CD variables, protected branches and tags, or push master and v* tags, and it signs in with two-factor authentication. The two other members, zainulabidin1990 and chrisholloway5 (Developer), can read confidential issues, where security reports arrive, and also sign in with two-factor authentication. The project is in a personal namespace, so GitLab has no setting that enforces this for them. See https://gitlab.com/Progressiverobot/hmailserver/-/project_members


    ¡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.

    GitLab never grants project access by itself: a member is added only by an Owner or Maintainer inviting them with an explicitly chosen role, and access requests are turned off for this project. Today there are three members: Progressiverobot (Owner) and zainulabidin1990 and chrisholloway5 (Developer). See https://gitlab.com/Progressiverobot/hmailserver/-/project_members


    No es 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.

    master is a protected branch: force pushes are refused and only the Maintainer role or above may push or merge. Only the Owner account, Progressiverobot, holds that role, so every other account is refused a direct commit. But the maintainer lands changes by pushing master directly (a fast-forward after the full regression gate), and nothing prevents a direct commit from that account. See https://gitlab.com/Progressiverobot/hmailserver/-/blob/master/CONTRIBUTING.md#merge-requests


    ¡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 default branch, and GitLab refuses to delete the default branch. master is also protected: a git push cannot delete it, and only the Maintainer role or above can unprotect it, which only the Owner account holds. See https://gitlab.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.

    The only CI job that handles metadata from outside the project is sign-off, which runs on a merge request from a fork. It reads commit authors, subjects and trailers into quoted shell variables, compares them as data and only prints them. Branch and tag names are compared in rules: and passed to scripts only as environment variables, never written into a command (SECURITY.md, "Branch and tag names in the pipelines"). See https://gitlab.com/Progressiverobot/hmailserver/-/blob/master/.gitlab-ci.yml


    ¡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.

    The project's two runners, linix and bench150, are registered ref_protected and locked, and do not run untagged jobs. The jobs that use them run only for protected refs (master, batch*, v*), never for a merge request. A merge request from a fork runs its pipeline in the fork, or on GitLab's shared runners when a maintainer runs it here, and either way sees no protected variable. No job on master declares an ID token; in the next batch only the release jobs for protected v* tags do. See https://gitlab.com/Progressiverobot/hmailserver/-/blob/master/hmailserver/docs/ContinuousIntegration.md


    ¡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.

    The project's channels are HTTPS only: the GitLab project, issues, wiki and releases, the update feed https://updates.progressiverobot.com and https://www.progressiverobot.com. The forums SUPPORT.md names are also HTTPS only: https://www.hmailserver.com/forum/ on master, and https://www.hmailserver.co.uk/ from the next batch. Each of those four sites redirects plain HTTP to HTTPS (checked 26 September 2026), and Git is served over HTTPS and SSH only. See https://gitlab.com/Progressiverobot/hmailserver/-/blob/master/SUPPORT.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.

    Releases are distributed only over HTTPS, from GitLab's release pages and package registry (https://gitlab.com/Progressiverobot/hmailserver/-/releases) and the HTTPS update feed. Assets are also signed: Sigstore bundles for every asset up to 6.3.3, and Authenticode on the Windows installer from 6.3.1.


    No es 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.

    The repository holds no credential, but nothing on GitLab stops one from being committed today. GitLab's secret push protection needs Ultimate, and .gitignore excludes build output and logs but no secret-file patterns. A secret_detection job (GitLab's template, failing on any finding not listed in .gitleaksignore) comes in the next batch and has not run on GitLab yet. On 26 September 2026 a scan of the whole history with that job's image found no real secret. See https://gitlab.com/Progressiverobot/hmailserver/-/blob/master/SECURITY.md


    ¡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.

    README.md covers installation (Windows installer, Linux packages, unattended install), administration (Control Panel, REST API), and building, with a configuration reference. The 104 documents under hmailserver/docs cover operation, upgrade, migration and security, and the GitLab wiki (https://gitlab.com/Progressiverobot/hmailserver/-/wikis/home) has 63 pages of user guides. See https://gitlab.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.

    SUPPORT.md explains how to report a defect: a GitLab issue with the Bug template, and what to include (the log, the ERROR log, version, platform, database). It says what to expect and sends security problems to SECURITY.md. CONTRIBUTING.md, 'Reporting, asking and proposing', repeats the routes. See https://gitlab.com/Progressiverobot/hmailserver/-/blob/master/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.

    The GitLab issue tracker is public. Proposed changes and questions are discussed there, and a Question template adds the question label. Merge requests are open to forks. SUPPORT.md also points usage questions to the hMailServer forum. See https://gitlab.com/Progressiverobot/hmailserver/-/work_items


    ¡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.

    CONTRIBUTING.md explains the contribution process: how to report, ask and propose, then build, test, sign off, and open a merge request from a fork against master. It also explains how the maintainer reviews and lands the change. See https://gitlab.com/Progressiverobot/hmailserver/-/blob/master/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 is licensed AGPL-3.0-or-later, which is OSI-approved and FSF-free. The full text is in LICENSE, the source headers carry SPDX-License-Identifier: AGPL-3.0-or-later, and GitLab detects the licence. See https://gitlab.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.

    The released assets are the same AGPL-3.0-or-later software. The Windows installer shows the AGPL text at install time (LicenseFile=license.rtf, hmailserver/installation/License.rtf), and the .rpm declares License: AGPL-3.0-or-later. No other licence is applied to releases. See https://gitlab.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 licence text is in the LICENSE file at the root of the project's only repository. See https://gitlab.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.

    Each GitLab release includes the source archives of its tag, which contain the root LICENSE (AGPL-3.0-or-later), and the Windows installer shows the licence text during setup. See https://gitlab.com/Progressiverobot/hmailserver/-/releases


    ¡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 source code is publicly readable at the static URL https://gitlab.com/Progressiverobot/hmailserver (a public GitLab project, default branch master), the project's home since 22 September 2026, as the first lines of README.md say. The former GitHub copy has been unavailable since 18 September 2026. https://gitlab.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 git history on GitLab is publicly readable and records the author, committer and date of every commit: master's 1,425 commits are the whole history carried over from GitHub plus every commit since, kept linear by fast-forward, and force-push is refused on the protected master branch. https://gitlab.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.

    Every .NET project with a PackageReference has a committed NuGet lock file (packages.lock.json), and three legacy test tools list theirs in packages.config; the Python tooling's requirements are pinned with hashes (build/requirements-dev.txt). The C++ server has no package manager: OpenSSL, Boost and libpq are pinned by version and source-archive hash in the libraries/build-*.ps1 scripts, and every binary build input is listed in hmailserver/docs/third-party-binaries.json (checked by SHA-256, by version for the MSVC runtime, and for presence for two of Windows' own type libraries). https://gitlab.com/Progressiverobot/hmailserver/-/blob/master/hmailserver/docs/ThirdPartyBinaries.md


    ¡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.

    hMailServer is a single-repository project: the C++ server, the .NET tools, the Control Deck and webmail, the tests, fuzz harnesses, installer, packaging and documentation are all built into releases from https://gitlab.com/Progressiverobot/hmailserver alone. The wiki belongs to the same GitLab project and is compiled into nothing.


    ¡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.

    No generated executable is in version control. The one there was, the COM interop wrapper Interop.hMailServer.dll, has been generated at build time by build/generate-com-wrapper.ps1 since 11 September 2026. None of master's 6,983 tracked files has a PE, ELF or Mach-O header (checked 26 September 2026); the CI's Binary-Artifacts check (build/ci/repo-hygiene.py) tests the same. https://gitlab.com/Progressiverobot/hmailserver/-/blob/master/hmailserver/source/Tools/Interop/README.md


    ¡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.

    Since 11 September 2026 the repository holds no executable or library binary: the forty third-party DLLs, MSIs and EXEs were removed, and the build fetches or gathers each one it still needs, checked against hmailserver/docs/third-party-binaries.json (SHA-256 for the fetched ones, version for the MSVC runtime, presence for two of Windows' own type libraries). What remains binary is images (icons, the Fat Cow icon archive, installer bitmaps), licence texts (RTF) and test fixtures (PST files, certificates, OpenPGP samples, fuzz regression inputs). https://gitlab.com/Progressiverobot/hmailserver/-/blob/master/hmailserver/docs/ThirdPartyBinaries.md


    ¡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.

    SECURITY.md at the repository root gives the security contacts: a confidential GitLab issue (Security template) or email to the project's Service Desk address, contact-project+progressiverobot-hmailserver-86730559-issue-@incoming.gitlab.com, both reaching the maintainers, whom GOVERNANCE.md names. https://gitlab.com/Progressiverobot/hmailserver/-/blob/master/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/14949/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 christopher holloway y a los colaboradores de la insignia de Mejores Prácticas de OpenSSF.

Entrada de insignia del proyecto propiedad de: christopher holloway.
Entrada creada el 2026-09-26 05:28:20 UTC, última actualización el 2026-09-26 06:16:51 UTC. Última obtención de la insignia de nivel básico el 2026-09-26 05:45:21 UTC.