hMailServer

Les projets qui suivent les meilleures pratiques ci-dessous peuvent s'auto-certifier et montrer qu'ils ont obtenu le badge de la Open Source Security Foundation (OpenSSF).

Il n'existe aucun ensemble de pratiques qui garantissent que ce logiciel n'aura jamais de défauts ou de vulnérabilités ; même les méthodes formelles peuvent échouer si les spécifications ou les hypothèses sont fausses. Il n'y a pas non plus de pratiques qui peuvent garantir qu'un projet permettra de maintenir une communauté de développement saine et qui fonctionne bien. Toutefois, suivre les meilleures pratiques peut contribuer à améliorer les résultats des projets. Par exemple, certaines pratiques permettent la revue par plusieurs personnes avant publication, ce qui peut aider à trouver des vulnérabilités techniques difficiles à trouver autrement et à renforcer la confiance et un désir d'interaction répétée entre les développeurs de différentes entreprises. Pour gagner un badge, tous les critères DOIT et NE DOIT PAS doivent être satisfaits, tous les critères DEVRAIT doivent être satisfaits OU non satisfaits avec justification, et tous les critères PROPOSÉ doivent être satisfaits OU non satisfaits (nous voulons au moins qu'ils soient considérés). Si vous voulez entrer un texte de justification pour un commentaire générique, au lieu d'une raison justifiant que la situation est acceptable, commencez le bloc de texte avec '//' suivi d'un espace. Les commentaires sont les bienvenus via le site GitHub en tant que problèmes ou pull requests. Il existe également une liste de diffusion pour discussion générale.

Nous fournissons volontiers l'information dans plusieurs langues, cependant, s'il existe un conflit ou une contradiction entre les traductions, la version anglaise est la version qui fait autorité.
Si c'est votre projet, veuillez afficher votre statut de badge de référence sur la page de votre projet ! Le statut du badge de référence ressemble à ceci : Le niveau du badge de référence pour le projet 14949 est in_progress Voici comment intégrer le badge de référence :
Vous pouvez afficher votre statut de badge de référence en incorporant ceci dans votre fichier markdown :
[![OpenSSF Baseline](https://www.bestpractices.dev/projects/14949/baseline)](https://www.bestpractices.dev/projects/14949)
ou en incorporant ceci dans votre HTML :
<a href="https://www.bestpractices.dev/projects/14949"><img src="https://www.bestpractices.dev/projects/14949/baseline"></a>


Voici les critères du niveau de référence 3. Il s'agit des critères version v2026.08.28.

Baseline Series: Niveau de référence 1 Niveau de référence 2 Niveau de référence 3

        

 Notions de base

  • Général

    Notez que d'autres projets peuvent utiliser le même nom.

    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.

    Utilisez un format d'expression de licence SPDX ; des exemples sont « Apache-2.0 », « BSD-2-Clause », « BSD-3-Clause », « GPL-2.0+ », « LGPL-3.0+ », « MIT » et « (BSD-2-Clause OU Ruby) ». Ne pas inclure des guillemets simples ou doubles.
    S'il y a plus d'un langage, listez-les en tant que valeurs séparées par des virgules (espaces facultatifs) et triez-les du plus au moins utilisé. S'il y a une longue liste, veuillez lister au moins les trois premiers. S'il n'y a pas de langage (par exemple, il s'agit d'un projet uniquement de documentation ou de test), utilisez le caractère unique « - ». Utilisez une capitalisation conventionnelle pour chaque langage, par exemple « JavaScript ».
    La plate-forme commune d'énumération (CPE) est un schéma de dénomination structuré pour les systèmes, les logiciels et les paquetages des technologies de l'information. Il est utilisé dans un certain nombre de systèmes et de bases de données pour signaler des vulnérabilités.

    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.

 Contrôles 17/21 ●

  • Contrôles


    Assez pour un badge !

    Lorsqu'une tâche se voit attribuer des permissions dans un pipeline CI/CD, le code source ou la configuration DOIT attribuer uniquement les privilèges minimaux nécessaires pour l'activité correspondante. [OSPS-AC-04.02]
    Configurez les pipelines CI/CD du projet pour attribuer les permissions les plus basses disponibles aux utilisateurs et services par défaut, en élevant les permissions seulement lorsque nécessaire pour des tâches spécifiques. Dans certains systèmes de gestion de version, cela peut être possible au niveau de l'organisation ou du dépôt. Sinon, définissez les permissions au niveau supérieur du pipeline.

    The CI file on master grants no job an ID token or a secret. The release jobs in the next batch are the only ones that ask for an ID token: release-authenticode for audience api://AzureADTokenExchange, and release-sign for audience sigstore. Both run only for a protected v* tag, and the build/ci/repo-hygiene.py check fails any job that asks for id_tokens or secrets and can run for a merge request. See https://gitlab.com/Progressiverobot/hmailserver/-/blob/master/.gitlab-ci.yml


    Assez pour un badge !

    Les pipelines CI/CD qui acceptent des entrées de collaborateurs de confiance DOIVENT assainir et valider ces entrées avant de les utiliser dans le pipeline. [OSPS-BR-01.04]
    Les pipelines CI/CD doivent assainir (mettre entre guillemets, échapper ou quitter pour les valeurs attendues) toutes les entrées des collaborateurs lors des exécutions explicites de workflows. Bien que les collaborateurs soient généralement de confiance, les entrées manuelles dans un workflow ne peuvent pas être revues et pourraient être détournées par une prise de contrôle de compte ou une menace interne.

    GitLab pipelines here accept no collaborator input. The project's minimum role for pipeline variables is 'no one allowed', so nobody can pass variables when starting a pipeline, and .gitlab-ci.yml defines no spec:inputs. The manual jobs take no parameters, and what a schedule sets is only compared in rules. The GitHub workflow that interpolated a dispatch input (installer-smoke.yml) no longer runs and is removed in the next batch. See https://gitlab.com/Progressiverobot/hmailserver/-/blob/master/.gitlab-ci.yml


    Assez pour un badge !

    Lorsqu'une version officielle est créée, tous les actifs de cette version DOIVENT être clairement associés à l'identifiant de version ou un autre identifiant unique pour l'actif. [OSPS-BR-02.02]
    Attribuez un identifiant de version unique à chaque actif logiciel produit par le projet, en suivant une convention de nommage ou un schéma de numérotation cohérent. Les exemples incluent SemVer, CalVer, ou l'id de commit git.

    Each release's files are in the package registry under the version, e.g. /packages/generic/hmailserver/6.3.3/, and are linked from the release with that tag. The installer and the packages also carry the version in their file names (hMailServer-6.3.3-x64.exe, hmailserver_6.3.3_amd64.deb). See https://gitlab.com/Progressiverobot/hmailserver/-/releases/v6.3.3


    Assez pour un badge !

    Le projet DOIT définir une politique pour gérer les secrets et informations d'identification utilisés par le projet. La politique devrait inclure des directives pour stocker, accéder et faire tourner les secrets et informations d'identification. [OSPS-BR-07.02]
    Documentez comment les secrets et informations d'identification sont gérés et utilisés dans le projet. Cela devrait inclure des détails sur la façon dont les secrets sont stockés (par exemple, en utilisant un outil de gestion de secrets), comment l'accès est contrôlé, et comment les secrets sont renouvelés ou mis à jour. Assurez-vous que les informations sensibles ne sont pas codées en dur dans le code source ou stockées dans les systèmes de gestion de version.

    SECURITY.md, 'Secrets and credentials', is the policy. No token, password or signing key is committed, and the test keys are throwaway fixtures. Release-asset signing is keyless (Sigstore), and the tag-signing keys' public halves are in allowed_signers. A secret is rotated when a maintainer leaves, when its pipeline changes hands, on any suspicion of exposure, and before it expires. GOVERNANCE.md says only Christopher Holloway holds the credentials under 'Critical assets'. See https://gitlab.com/Progressiverobot/hmailserver/-/blob/master/SECURITY.md


    Assez pour un badge !

    Lorsque le projet a fait une version, la documentation du projet DOIT contenir des instructions pour vérifier l'intégrité et l'authenticité des actifs de la version. [OSPS-DO-03.01]
    Les instructions dans le projet devraient contenir des informations sur la technologie utilisée, les commandes à exécuter et la sortie attendue. Lorsque cela est possible, évitez de stocker cette documentation au même endroit que le pipeline de construction et de publication pour éviter qu'une seule violation ne compromette à la fois le logiciel et la documentation pour vérifier l'intégrité du logiciel.

    SECURITY.md, "Verifying a release", gives the commands. git verify-tag against the committed allowed signers file checks the tag. cosign verify-blob, with the bundle, certificate identity and OIDC issuer, checks each asset of the releases up to 6.3.3. Get-AuthenticodeSignature checks the Windows installer from 6.3.1. It also names the tool each check uses. See https://gitlab.com/Progressiverobot/hmailserver/-/blob/master/SECURITY.md#verifying-a-release


    Assez pour un badge !

    Lorsque le projet a fait une version, la documentation du projet DOIT contenir des instructions pour vérifier l'identité attendue de la personne ou du processus créant la version logicielle. [OSPS-DO-03.02]
    L'identité attendue peut être sous la forme d'identifiants de clés utilisés pour signer, d'émetteur et d'identité d'un certificat sigstore, ou d'autres formes similaires. Lorsque cela est possible, évitez de stocker cette documentation au même endroit que le pipeline de construction et de publication pour éviter qu'une seule violation ne compromette à la fois le logiciel et la documentation pour vérifier l'intégrité du logiciel.

    SECURITY.md, 'Verifying a release', says release tags verify against the committed allowed_signers file, which holds one key, christopher.j.holloway@outlook.com's (.github/ on master, .gitlab/ from the next batch). Assets up to 6.3.3 must carry the Sigstore identity ^https://github.com/Progressiverobot/hmailserver/ with the issuer https://token.actions.githubusercontent.com. The next batch adds the GitLab identity and the issuer https://gitlab.com for releases from 6.3.5. See https://gitlab.com/Progressiverobot/hmailserver/-/blob/master/SECURITY.md#verifying-a-release


    Assez pour un badge !

    Quand le projet a publié une version, la documentation du projet DOIT inclure une déclaration descriptive sur la portée et la durée du support pour chaque version. [OSPS-DO-04.01]
    Afin de communiquer la portée et la durée du support pour les actifs logiciels publiés par le projet, le projet devrait avoir un fichier SUPPORT.md, une section « Support » dans SECURITY.md, ou toute autre documentation expliquant le cycle de vie du support, y compris la durée prévue du support pour chaque version, les types de support fournis (par exemple, corrections de bugs, mises à jour de sécurité), et toutes politiques ou procédures pertinentes pour obtenir du support.

    SECURITY.md's "Supported versions" names the supported line (6.3.x) and says a fix ships in the next release, with no back-ports because there are no maintenance branches. SUPPORT.md describes the support offered: issues, the forum, what to expect, and no guaranteed response time. See https://gitlab.com/Progressiverobot/hmailserver/-/blob/master/SECURITY.md#supported-versions


    Assez pour un badge !

    Quand le projet a publié une version, la documentation du projet DOIT fournir une déclaration descriptive sur le moment où les versions ne recevront plus de mises à jour de sécurité. [OSPS-DO-05.01]
    Afin de communiquer la portée et la durée du support pour les corrections de sécurité, le projet devrait avoir un fichier SUPPORT.md ou autre documentation expliquant la politique du projet pour les mises à jour de sécurité.

    SECURITY.md says only the 6.3 line receives security fixes and everything older than 6.3 does not. A fix ships in the next 6.3 release and is not back-ported, so a release stops receiving security updates once a newer one is published. See https://gitlab.com/Progressiverobot/hmailserver/-/blob/master/SECURITY.md#supported-versions


    Assez pour un badge !

    La documentation du projet DOIT comporter une politique selon laquelle les collaborateurs de code sont examinés avant l'octroi de permissions élevées sur des ressources sensibles. [OSPS-GV-04.01]
    Publiez une politique applicable dans la documentation du projet qui exige que les collaborateurs de code soient examinés et approuvés avant de se voir accorder des permissions élevées aux ressources sensibles, telles que l'approbation de fusion ou l'accès aux secrets. Il est recommandé que l'examen comprenne l'établissement d'une lignée d'identité justifiable, comme la confirmation de l'association du contributeur avec une organisation de confiance connue.

    GOVERNANCE.md, 'Becoming a maintainer', sets the rule for escalated access: a sustained record of correct, tested changes and willingness to take on the release and security duties, decided by the maintainers. It records openly that the second maintainer was appointed from within Progressive Robot Ltd before building that record. Only Progressiverobot, the project's one member above Developer, can grant a GitLab role. See https://gitlab.com/Progressiverobot/hmailserver/-/blob/master/GOVERNANCE.md#becoming-a-maintainer


    Pas assez pour un badge.

    Quand le projet a publié une version, tous les actifs logiciels compilés publiés DOIVENT être livrés avec une nomenclature logicielle. [OSPS-QA-02.02]
    Il est recommandé de générer automatiquement les SBOM au moment de la compilation en utilisant un outil dont la précision a été vérifiée. Cela permet aux utilisateurs d'ingérer ces données de manière standardisée aux côtés d'autres projets dans leur environnement.

    Every release from v6.2.3 on carries SPDX and CycloneDX SBOMs (hmailserver.spdx.json, hmailserver.cyclonedx.json) beside its installer and packages, but five earlier releases still listed (v6.0.0-B1, v6.0.0, v6.1.0, v6.2.1, v6.2.2) carry an installer with no SBOM. https://gitlab.com/Progressiverobot/hmailserver/-/releases


    Assez pour un badge !

    Quand le projet a publié une version comprenant plusieurs dépôts de code source, tous les sous-projets DOIVENT appliquer des exigences de sécurité aussi strictes ou plus strictes que la base de code principale. [OSPS-QA-04.02]
    Tous les dépôts de code de sous-projets supplémentaires produits par le projet et compilés dans une version doivent appliquer des exigences de sécurité selon le statut et l'objectif de la base de code respective. En plus de suivre les exigences Baseline OSPS correspondantes, cela peut inclure l'exigence d'un examen de sécurité, garantir qu'il est exempt de vulnérabilités et garantir qu'il est exempt de problèmes de sécurité connus.

    Releases are built from one repository alone: the server, the .NET tools, the web front ends and the vendored third-party code (inventoried in hmailserver/docs/third-party-binaries.json) all live there, so there are no subproject repositories to hold to the primary codebase's requirements. https://gitlab.com/Progressiverobot/hmailserver


    Assez pour un badge !

    La documentation du projet DOIT clairement documenter quand et comment les tests sont exécutés. [OSPS-QA-06.02]
    Ajoutez une section à la documentation de contribution qui explique comment exécuter les tests localement et comment exécuter les tests dans le pipeline CI/CD. La documentation devrait expliquer ce que les tests testent et comment interpréter les résultats.

    CONTRIBUTING.md's Testing section says how to run the Windows regression suite (the bench, build/preflight-tests.ps1, build/run-tests.ps1) and the Linux suite (dotnet test with the HMTEST_* settings), what they exercise and how to read the result; 'The checkers' and hmailserver/docs/ContinuousIntegration.md say which checks and suites each GitLab CI job runs, where, and for which refs. RELEASE.md requires the full suite, zero failures, on the exact binary that ships. https://gitlab.com/Progressiverobot/hmailserver/-/blob/master/CONTRIBUTING.md#testing


    Assez pour un badge !

    La documentation du projet DOIT inclure une politique selon laquelle tous les changements majeurs apportés au logiciel produit par le projet devraient ajouter ou mettre à jour des tests de la fonctionnalité dans une suite de tests automatisée. [OSPS-QA-06.03]
    Ajoutez une section à la documentation de contribution qui explique la politique d'ajout ou de mise à jour des tests. La politique devrait expliquer ce qui constitue un changement majeur et quels tests doivent être ajoutés ou mis à jour.

    CONTRIBUTING.md makes it policy: 'Add or update regression tests for a change of behaviour' (Merge requests), and 'A fix ships with a test that fails against the build before it' (Writing a test); RELEASE.md requires a negative-control test for every defect fix. https://gitlab.com/Progressiverobot/hmailserver/-/blob/master/CONTRIBUTING.md#merge-requests


    Pas assez pour un badge.

    Quand un commit est effectué vers la branche principale, le système de contrôle de version du projet DOIT exiger au moins une approbation humaine non auteur des changements avant la fusion. [OSPS-QA-07.01]
    Configurez le système de contrôle de version du projet pour exiger au moins une approbation humaine non auteur des changements avant la fusion dans la branche de publication ou principale. Cela peut être réalisé en exigeant qu'une pull request soit examinée et approuvée par au moins un autre collaborateur avant qu'elle puisse être fusionnée.

    No approval rule is configured on GitLab, so nothing requires a non-author human approval before a change reaches master; CONTRIBUTING.md says so. One active maintainer lands changes, each checked by adversarial review passes run by AI agents, fixture gates and the full regression gate before it lands, which is not two-person review. https://gitlab.com/Progressiverobot/hmailserver/-/blob/master/CONTRIBUTING.md#merge-requests


    Assez pour un badge !

    Quand le projet a publié une version, le projet DOIT effectuer une modélisation des menaces et une analyse de la surface d'attaque pour comprendre et se protéger contre les attaques sur les chemins de code critiques, les fonctions et les interactions au sein du système. [OSPS-SA-03.02]
    La modélisation des menaces est une activité où le projet examine la base de code, les processus et l'infrastructure associés, les interfaces, les composants clés et « pense comme un pirate » et réfléchit à la manière dont le système pourrait être cassé ou compromis. Chaque menace identifiée est répertoriée afin que le projet puisse ensuite réfléchir à la manière d'éviter ou de combler de manière proactive toute lacune ou vulnérabilité qui pourrait survenir. Assurez-vous que cela est mis à jour pour les nouvelles fonctionnalités ou les changements majeurs.

    Sections 3 and 4 of ASSURANCE-CASE.md are the threat model and attack-surface analysis: actors A1-A6 with their assumed capabilities, the assets, the principal attack surfaces (protocol parsers, MIME parsing, TLS, the scanner and DNS paths, persistence, and the REST, metrics and web-services listeners) and trust boundaries B1-B6 with the check made at each. https://gitlab.com/Progressiverobot/hmailserver/-/blob/master/ASSURANCE-CASE.md#3-threat-model


    Assez pour un badge !

    Toute vulnérabilité présente dans les composants logiciels mais n'affectant pas le projet DOIT être prise en compte dans un document VEX, en complétant le rapport de vulnérabilité avec des détails sur la non-exploitabilité. [OSPS-VM-04.02]
    Établissez un flux VEX communiquant le statut d'exploitabilité des vulnérabilités connues, y compris les détails d'évaluation ou toute mesure d'atténuation en place empêchant l'exécution du code vulnérable.

    The project keeps an OpenVEX document, .github/hmailserver.openvex.json (moving to .gitlab/ with the next batch), with a not_affected statement and its justification for every advisory dismissed as not affecting the project: five today, for zlib and Boost advisories found by the dependency-scan OSV query. SECURITY.md requires a statement for each such dismissal, and the dependency-scan job honours the document. https://gitlab.com/Progressiverobot/hmailserver/-/blob/master/.github/hmailserver.openvex.json


    Assez pour un badge !

    La documentation du projet DOIT inclure une politique qui définit un seuil pour la remédiation des résultats d'analyse de composition logicielle (SCA) liés aux vulnérabilités et aux licences. [OSPS-VM-05.01]
    Documentez une politique dans le projet qui définit un seuil pour la résolution des résultats SCA liés aux vulnérabilités et aux licences. Incluez le processus pour identifier, prioriser et résoudre ces résultats.

    SECURITY.md's Vulnerability management policy sets the SCA thresholds: a high or critical advisory in a dependency is fixed, or the dependency replaced, before the next release and within 14 days; moderate within 30 days; low within 90 days or with the next refresh; a licence incompatible with AGPL-3.0-or-later is treated as high. It says how findings are found (the dependency-scan job's Trivy and OSV queries, Renovate) and how a not-affected one is recorded in the VEX document. https://gitlab.com/Progressiverobot/hmailserver/-/blob/master/SECURITY.md#dependencies-software-composition-analysis


    Assez pour un badge !

    La documentation du projet DOIT inclure une politique pour traiter les violations SCA avant toute publication. [OSPS-VM-05.02]
    Documentez une politique dans le projet pour traiter les résultats applicables de l'analyse de composition du logiciel avant toute publication, et ajoutez des vérifications de statut qui vérifient la conformité avec cette politique avant la publication.

    SECURITY.md: a release is not cut while a known high or critical advisory against a shipped dependency is open; the dependency-scan report of the release's commit is read first, and every component it marks UNKNOWN is checked by hand against the release's SBOM. That check is made by hand: the dependency-scan job is defined in .gitlab-ci.yml, not blocking, and has not yet run on GitLab. https://gitlab.com/Progressiverobot/hmailserver/-/blob/master/SECURITY.md#dependencies-software-composition-analysis


    Pas assez pour un badge.

    Tous les changements apportés à la base de code du projet DOIVENT être automatiquement évalués par rapport à une politique documentée concernant les dépendances malveillantes et les vulnérabilités connues dans les dépendances, puis bloqués en cas de violation, sauf lorsqu'ils sont déclarés et supprimés comme non exploitables. [OSPS-VM-05.03]
    Créez une vérification de statut dans le système de contrôle de version du projet qui exécute un outil d'analyse de composition du logiciel sur toutes les modifications apportées à la base de code. Exigez que la vérification de statut réussisse avant que les modifications puissent être fusionnées.

    Not every change is evaluated and blocked. The dependency-scan job (Trivy and OSV, honouring the VEX document) is defined for master, batch* and v* pipelines on the project's runner only, is allow_failure, and has not yet run on GitLab; merge requests do not reach it, and Renovate waits for the owner's token and schedule. GitHub's blocking dependency review ran until 18 September 2026. https://gitlab.com/Progressiverobot/hmailserver/-/blob/master/hmailserver/docs/ContinuousIntegration.md


    Assez pour un badge !

    La documentation du projet DOIT inclure une politique qui définit un seuil pour la remédiation des résultats d'analyse statique de sécurité (SAST). [OSPS-VM-06.01]
    Documentez une politique dans le projet qui définit un seuil pour la résolution des résultats des tests de sécurité des applications statiques (SAST). Incluez le processus pour identifier, prioriser et résoudre ces résultats.

    SECURITY.md's Vulnerability management policy sets the SAST threshold: an error-level finding, or a high or critical security finding, is fixed before merge; medium within 30 days; low or note-level with the next change to that file or dismissed with a written reason; no release with an open error-level finding. It names the tools (cppcheck, clang-tidy and Semgrep in CI, MSVC /analyze by hand) and how suppressions are recorded. https://gitlab.com/Progressiverobot/hmailserver/-/blob/master/SECURITY.md#source-code-static-analysis


    Pas assez pour un badge.

    Tous les changements apportés à la base de code du projet DOIVENT être automatiquement évalués par rapport à une politique documentée concernant les faiblesses de sécurité et bloqués en cas de violation, sauf lorsqu'ils sont déclarés et supprimés comme non exploitables. [OSPS-VM-06.02]
    Créez une vérification de statut dans le système de contrôle de version du projet qui exécute un outil de test de sécurité des applications statiques (SAST) sur toutes les modifications apportées à la base de code. Exigez que la vérification de statut réussisse avant que les modifications puissent être fusionnées.

    SAST does not yet block changes. The static-analysis (cppcheck, clang-tidy) and semgrep jobs are defined for master, batch* and v* pipelines only, are allow_failure against committed baselines until triaged, do not read the Windows-only sources, and have not yet run on GitLab; GitLab SAST and secret detection come with the next batch. CodeQL ran on GitHub until 18 September 2026. https://gitlab.com/Progressiverobot/hmailserver/-/blob/master/hmailserver/docs/ContinuousIntegration.md#security-scanning



Vous pouvez utiliser des outils et des systèmes d'IA pour proposer des modifications via une URL simple, par exemple https://www.bestpractices.dev/fr/projects/14949/choose/edit?osps_ac_01_01_status=Met&osps_ac_01_01_justification=GitHub+enforced. Consultez notre système de propositions d'automatisation pour savoir comment procéder. Ces données sont disponibles sous la licence Community Data License Agreement – Permissive, Version 2.0 (CDLA-Permissive-2.0). Cela signifie qu'un destinataire de données peut partager les données, avec ou sans modifications, à condition que le destinataire de données rende disponible le texte de cet accord avec les données partagées. Veuillez créditer christopher holloway et les contributeurs du badge des meilleures pratiques de la OpenSSF.

Soumission du badge du projet appartenant à : christopher holloway.
Soumission créée le 2026-09-26 05:28:20 UTC, dernière mise à jour le 2026-09-26 06:16:51 UTC. Le dernier badge obtenu l'a été le 2026-09-26 05:45:21 UTC.