ruview-home-sensing

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 indiquer votre statut de badge sur votre page de projet ! Le statut du badge ressemble à ceci : Le niveau de badge pour le projet 15634 est in_progress Voici comment l'intégrer :
Vous pouvez afficher votre statut de badge en incorporant ceci dans votre fichier markdown :
[![OpenSSF Best Practices](https://www.bestpractices.dev/projects/15634/badge)](https://www.bestpractices.dev/projects/15634)
ou en incorporant ceci dans votre HTML :
<a href="https://www.bestpractices.dev/projects/15634"><img src="https://www.bestpractices.dev/projects/15634/badge"></a>


Ce sont les critères du niveau Basique. Vous pouvez également afficher les critères des niveaux Argent ou Or.

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

        

 Notions de base 12/13 ●

 Contrôle des modifications 9/9 ●

  • Dépôt source public sous contrôle de version


    Assez pour un badge !

    Le projet DOIT avoir un dépôt source sous contrôle de version qui est publiquement lisible et possède une URL. [repo_public]
    L'URL PEUT être identique à l'URL du projet. Le projet PEUT utiliser des branches privées (non publiques) dans des cas spécifiques alors que la modification n'est pas diffusée publiquement (par exemple, pour la correction d'une vulnérabilité avant qu'elle ne soit révélée au public).

    The software source is publicly readable in the default main branch after PR 1 merged at commit 3afc395637abd854f7300e96d62512af7975ab0b. The tagged initial prerelease remains separately available. Evidence: https://github.com/ha-homelab/ruview-home-sensing/tree/3afc395637abd854f7300e96d62512af7975ab0b ; https://github.com/ha-homelab/ruview-home-sensing/pull/1 ; https://github.com/ha-homelab/ruview-home-sensing/releases/tag/v0.4.0-rc.1


    Assez pour un badge !

    Le dépôt source du projet DOIT suivre les changements apportés, qui a effectué les changements et quand les changements ont été effectués. [repo_track]

    The public Git repository records the source changes and review commits. This assessment uses only its public change record. Evidence: https://github.com/ha-homelab/ruview-home-sensing/commits/d71f09cdc6948fb131c247ae51a2ada1af27a942 ; https://github.com/ha-homelab/ruview-home-sensing/pull/1/commits


    Assez pour un badge !

    Pour permettre une analyse collaborative, le dépôt source du projet DOIT inclure des versions provisoires pour examen entre versions officielles ; Il NE DOIT PAS inclure que les dernières versions. [repo_interim]
    Les projets PEUVENT choisir d'omettre des versions intermédiaires spécifiques dans leurs dépôts source publics (par exemple, celles qui corrigent des vulnérabilités de sécurité non publiques spécifiques, ne peuvent jamais être rendues publiques ou incluent des éléments qui ne peuvent être légalement publiés et ne sont pas dans la version finale).

    Interim source revisions are publicly available as Git commits and pull requests. The initial public source PR has merged, and its resulting main-branch commit is publicly readable. Evidence: https://github.com/ha-homelab/ruview-home-sensing/commits/3afc395637abd854f7300e96d62512af7975ab0b ; https://github.com/ha-homelab/ruview-home-sensing/tree/3afc395637abd854f7300e96d62512af7975ab0b ; https://github.com/ha-homelab/ruview-home-sensing/pull/1


    Assez pour un badge !

    Il est PROPOSÉ qu'un logiciel reconnu de contrôle de version distribué soit utilisé (par exemple, git) pour le dépôt source du projet. [repo_distributed]
    Git n'est pas spécifiquement requis et les projets peuvent utiliser un logiciel de contrôle de version centralisé (comme subversion) avec justification.

    The project uses a public Git repository, a distributed version-control system. Evidence: https://github.com/ha-homelab/ruview-home-sensing/tree/d71f09cdc6948fb131c247ae51a2ada1af27a942


  • Numérotation unique de la version


    Assez pour un badge !

    Les résultats du projet DOIVENT avoir un identifiant de version unique pour chaque version destinée à être utilisée par les utilisateurs. [version_unique]
    Cela PEUT être satisfait de diverses façons, y compris les identifiants de commit (comme git commit id ou mercure changeset id) ou un numéro de version (y compris les numéros de version qui utilisent la version sémantique ou les systèmes basés sur la date comme YYYYMMDD).

    The initial prerelease v0.4.0-rc.1 has a unique Git tag resolving to commit d71f09cdc6948fb131c247ae51a2ada1af27a942. The version file uses 0.4.0-rc.1 and Python metadata uses the corresponding 0.4.0rc1 spelling. The published source archive manifest identifies its exact source commit. Evidence: https://github.com/ha-homelab/ruview-home-sensing/releases/tag/v0.4.0-rc.1 ; https://github.com/ha-homelab/ruview-home-sensing/blob/d71f09cdc6948fb131c247ae51a2ada1af27a942/version ; https://github.com/ha-homelab/ruview-home-sensing/blob/d71f09cdc6948fb131c247ae51a2ada1af27a942/pyproject.toml


    Assez pour un badge !

    Il est PROPOSÉ d'utiliser le format de numérotation de version appelé Versionage Sémantique (SemVer) ou Versionage Calendaire (CalVer). Il est PROPOSÉ que ceux qui utilisent CalVer incluent une valeur de niveau micro. [version_semver]
    Les projets devraient généralement préférer le format attendu par leurs utilisateurs, par exemple, parce que c'est le format normal utilisé par leur écosystème. De nombreux écosystèmes préfèrent SemVer, et SemVer est généralement préféré pour les interfaces de programmation d'applications (API) et les kits de développement logiciel (SDK). CalVer a tendance à être utilisé par des projets de grande envergure, ayant un nombre inhabituellement élevé de dépendances développées indépendamment, ayant une portée en constante évolution ou étant sensibles au temps. Il est PROPOSÉ que ceux qui utilisent CalVer incluent une valeur de niveau micro, car l'inclusion d'un niveau micro prend en charge les branches maintenues simultanément chaque fois que cela devient nécessaire. D'autres formats de numérotation de version peuvent être utilisés, y compris les ID de commit git ou les ID de jeu de modifications mercurial, à condition qu'ils identifient de manière unique les versions. Cependant, certaines alternatives (telles que les ID de commit git) peuvent poser des problèmes en tant qu'identificateurs de version, car les utilisateurs peuvent ne pas être en mesure de déterminer facilement s'ils sont à jour. Le format de l'ID de version peut être sans importance pour l'identification des versions logicielles si tous les destinataires n'exécutent que la dernière version (par exemple, il s'agit du code d'un site Web ou d'un service Internet unique qui est constamment mis à jour par livraison continue).

    The source version follows the SemVer prerelease form 0.4.0-rc.1. Python packaging uses its ecosystem-compatible 0.4.0rc1 representation. Evidence: https://github.com/ha-homelab/ruview-home-sensing/blob/d71f09cdc6948fb131c247ae51a2ada1af27a942/version ; https://github.com/ha-homelab/ruview-home-sensing/blob/d71f09cdc6948fb131c247ae51a2ada1af27a942/pyproject.toml


    Assez pour un badge !

    Il est PROPOSÉ que les projets identifient chaque version dans leur système de contrôle de version. Par exemple, il est PROPOSÉ que ceux qui utilisent git identifient chaque version à l'aide des tags de git. [version_tags]

    The published initial prerelease v0.4.0-rc.1 is identified by the Git tag of the same name, which resolves to source commit d71f09cdc6948fb131c247ae51a2ada1af27a942. The prerelease tag remains immutable and distinct from the later main-branch merge; no stable release is claimed. Evidence: https://github.com/ha-homelab/ruview-home-sensing/releases/tag/v0.4.0-rc.1 ; https://github.com/ha-homelab/ruview-home-sensing/tree/v0.4.0-rc.1


  • Notes de version


    Assez pour un badge !

    Le projet DOIT fournir, avec chaque distribution, des notes de version qui sont un résumé lisible par les humains des changements majeurs dans cette version afin d'aider les utilisateurs à déterminer s'ils doivent se mettre à niveau et quel sera l'impact de la mise à niveau. Les notes de version NE DOIVENT PAS être la sortie brute d'un journal de contrôle de version (par exemple, les résultats de la commande « git log » ne sont pas des notes de version). Les projets dont les résultats ne sont pas destinés à être réutilisés dans plusieurs emplacements (tels que le logiciel pour un site Web ou un service unique) ET qui utilisent la livraison continue PEUVENT sélectionner « N/A ». (URL requise) [release_notes]
    Les notes de version PEUVENT être mises en œuvre de différentes façons. De nombreux projets les fournissent dans un fichier nommé « NEWS », « CHANGELOG » ou « ChangeLog », éventuellement avec des extensions telles que « .txt », « .md » ou « .html ». Historiquement, le terme « journal des modifications » signifiait un enregistrement de chaque changement, mais pour répondre à ces critères, il faut un résumé lisible par un humain. Les notes de version PEUVENT être fournies à la place par des mécanismes de système de contrôle de version tels que le GitHub Releases workflow.

    The sole published release, v0.4.0-rc.1, includes human-readable notes explaining the initial software components, separate bridge dependency, the source archive and wheel, compatibility and installation-policy requirements, security fixes, and experimental limitations. The notes link the exact source and validation run and explicitly do not claim stable promotion, deployment, a Passing badge or physical-device qualification. Evidence: https://github.com/ha-homelab/ruview-home-sensing/releases/tag/v0.4.0-rc.1 ; https://github.com/ha-homelab/ruview-home-sensing/blob/d71f09cdc6948fb131c247ae51a2ada1af27a942/docs/distribution.md


    Assez pour un badge !

    Les notes de version DOIVENT identifier toutes les vulnérabilités connues du public corrigées dans cette version qui avaient déjà une affectation CVE ou similaire lors de la création de la version. Ce critère peut être marqué comme non applicable (N/A) si les utilisateurs ne peuvent pas en général mettre à jour le logiciel eux-mêmes (par exemple, comme c'est souvent le cas pour les mises à jour du noyau). Ce critère s'applique uniquement aux résultats du projet, pas à ses dépendances. S'il n'y a pas de notes de version ou qu'il n'y a pas eu de vulnérabilité publiquement connue, choisissez N/A. [release_notes_vulns]
    Ce critère aide les utilisateurs à déterminer si une mise à jour donnée corrigera une vulnérabilité connue publiquement, pour aider les utilisateurs à prendre une décision éclairée concernant la mise à jour. Si les utilisateurs ne peuvent généralement pas mettre à jour le logiciel eux-mêmes sur leur ordinateur, mais doivent à la place dépendre d'un ou plusieurs intermédiaires pour effectuer la mise à niveau (comme c'est souvent le cas pour un noyau et un logiciel de bas niveau associé à un noyau), le projet peut choisir « non applicable » (N/A) à la place, car ces informations supplémentaires ne seront pas utiles à ces utilisateurs. De même, un projet peut choisir N/A si tous les destinataires n'exécutent que la dernière version (par exemple, il s'agit du code d'un site Web ou d'un service Internet unique qui est constamment mis à jour par livraison continue). Ce critère s'applique uniquement aux résultats du projet, pas à ses dépendances. Énumérer les vulnérabilités de toutes les dépendances transitives d'un projet devient ingérable à mesure que les dépendances augmentent et varient, et n'est pas nécessaire car les outils qui examinent et suivent les dépendances peuvent le faire de manière plus évolutive.

    No qualifying publicly known project-runtime vulnerability with a CVE or equivalent assignment has been identified for this initial prerelease. Its notes nevertheless describe the project security fixes. CVE-2026-59890 / GHSA-h35f-9h28-mq5c, also discussed in the notes, concerns the external setuptools build dependency and is outside this criterion's project-results scope. Reassess when a release fixes a qualifying assigned project vulnerability. Evidence: https://github.com/ha-homelab/ruview-home-sensing/releases/tag/v0.4.0-rc.1 ; https://github.com/ha-homelab/ruview-home-sensing/security/advisories


 Compte-rendu 8/8 ●

  • Procédure de signalement des bogues


    Assez pour un badge !

    Le projet DOIT fournir un processus permettant aux utilisateurs de soumettre des signalements de bogue (par exemple, en utilisant un suivi des problèmes ou une liste de diffusion). (URL requise) [report_process]

    CONTRIBUTING asks reporters to open an issue with observed behavior, expected results and a minimal fictional reproduction. The public repository has an enabled issue tracker. Evidence: https://github.com/ha-homelab/ruview-home-sensing/blob/d71f09cdc6948fb131c247ae51a2ada1af27a942/CONTRIBUTING.md ; https://github.com/ha-homelab/ruview-home-sensing/issues


    Assez pour un badge !

    Le projet DEVRAIT utiliser un suivi des problèmes pour le suivi des problèmes individuels. [report_tracker]

    The project uses an enabled public GitHub issue tracker for individual reports. Evidence: https://github.com/ha-homelab/ruview-home-sensing/issues


    Assez pour un badge !

    Le projet DOIT confirmer une majorité des signalements de bogues soumis au cours des 2 à 12 derniers mois (inclus) ; la réponse ne doit pas nécessairement inclure une correction. [report_responses]

    The maintainer reports no qualifying external bug reports during the assessment period. The newly created public tracker currently contains no bug issues. This is a no-report assessment, not an invented response record. Evidence: https://github.com/ha-homelab/ruview-home-sensing/issues


    Assez pour un badge !

    Le projet DEVRAIT répondre à une majorité (>50%) des demandes d'amélioration au cours des 2 à 12 derniers mois (inclus). [enhancement_responses]
    La réponse PEUT être « non » ou une discussion sur ses mérites. Le but est simplement qu'il y ait une réponse à certaines demandes, ce qui indique que le projet est toujours en vie. Aux fins de ce critère, les projets ne doivent pas compter les fausses demandes (par exemple, provenant de spammeurs ou de systèmes automatisés). Si un projet ne fait plus d'améliorations, sélectionnez « non satisfait » et incluez l'URL qui rend cette situation claire pour les utilisateurs. Si un projet tend à être submergé par le nombre de demandes d'amélioration, sélectionnez « non satisfait » et expliquez.

    The maintainer reports no qualifying external enhancement requests during the assessment period. The newly created public tracker currently contains no enhancement issues. Evidence: https://github.com/ha-homelab/ruview-home-sensing/issues


    Assez pour un badge !

    Le projet DOIT avoir une archive publique pour les signalements et les réponses pour une recherche ultérieure. (URL requise) [report_archive]

    GitHub provides a public searchable archive of open and closed issues and their responses; the initial pull-request discussion is also publicly retained. Evidence: https://github.com/ha-homelab/ruview-home-sensing/issues?q=is%3Aissue ; https://github.com/ha-homelab/ruview-home-sensing/pull/1


  • Processus de signalement de vulnérabilité


    Assez pour un badge !

    Le projet DOIT publier le processus de signalement des vulnérabilités sur le site du projet. (URL requise) [vulnerability_report_process]
    Les projets hébergés sur GitHub DEVRAIENT envisager d'activer le signalement privé d'une vulnérabilité de sécurité . Les projets sur GitLab DEVRAIENT envisager d'utiliser sa capacité à signaler une vulnérabilité en privé . Les projets PEUVENT identifier une adresse postale sur https://PROJECTSITE/security, souvent sous la forme security@example.org. Ce processus de rapport de vulnérabilité PEUT être le même que son processus de rapport de bogue. Les rapports de vulnérabilité PEUVENT toujours être publics, mais de nombreux projets ont un mécanisme de rapport de vulnérabilité privé.

    SECURITY explains the confidential reporting route, requested reproduction information and handling boundaries. GitHub private vulnerability reporting is enabled for this repository. Evidence: https://github.com/ha-homelab/ruview-home-sensing/blob/d71f09cdc6948fb131c247ae51a2ada1af27a942/SECURITY.md ; https://github.com/ha-homelab/ruview-home-sensing/security/advisories/new


    Assez pour un badge !

    Si les signalements de vulnérabilités privés sont pris en charge, le projet DOIT inclure la façon d'envoyer l'information de manière confidentielle. (URL requise) [vulnerability_report_private]
    Des exemples incluent un signalement de défaut privé envoyé sur le Web en utilisant HTTPS (TLS) ou un courrier électronique chiffré à l'aide d'OpenPGP. Si les signalements de vulnérabilités sont toujours publics (donc il n'y a jamais de signalements de vulnérabilités privés), choisissez « non applicable » (N/A).

    The enabled GitHub private vulnerability-reporting form is the documented confidential intake. Reporters are told not to publish credentials or sensitive reproduction data in a public issue. Evidence: https://github.com/ha-homelab/ruview-home-sensing/blob/d71f09cdc6948fb131c247ae51a2ada1af27a942/SECURITY.md ; https://github.com/ha-homelab/ruview-home-sensing/security/advisories/new


    Assez pour un badge !

    Le temps de réponse initial du projet pour tout signalement de vulnérabilité reçu au cours des 6 derniers mois DOIT être inférieur ou égal à 14 jours. [vulnerability_report_response]
    S'il n'y a pas eu de vulnérabilité signalée au cours des 6 derniers mois, choisissez « non applicable » (N/A).

    The maintainer reports no vulnerability reports in the preceding six months. This no-report applicability assessment does not assert a demonstrated response-time record. Evidence: https://github.com/ha-homelab/ruview-home-sensing/blob/d71f09cdc6948fb131c247ae51a2ada1af27a942/SECURITY.md


 Qualité 8/13 ●

 Sécurité 5/16 ●

 Analyse 8/8 ●


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/15634/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 alvit et les contributeurs du badge des meilleures pratiques de la OpenSSF.

Soumission du badge du projet appartenant à : alvit.
Soumission créée le 2026-10-17 23:08:53 UTC, dernière mise à jour le 2026-10-18 00:10:48 UTC.