ruview-home-sensing

Projekte, die den nachfolgenden Best Practices folgen, können sich freiwillig selbst zertifizieren und zeigen, dass sie einen Core-Infrastruktur-Initiative-/OpenSSF-Badge erhalten haben.

Es gibt keine Auswahl an Praktiken, die garantieren können, dass Software niemals Fehler oder Schwachstellen hat. Selbst formale Methoden können fehlschlagen, wenn die Spezifikationen oder Annahmen falsch sind. Auch gibt es keine Auswahl an Praktiken, die garantieren können, dass ein Projekt eine gesunde und gut funktionierende Entwicklungsgemeinschaft erhalten wird. Allerdings können Best Practices dabei helfen, die Ergebnisse von Projekten zu verbessern. Zum Beispiel ermöglichen einige Praktiken die Mehrpersonen-Überprüfung vor der Freigabe, die sowohl helfen können ansonsten schwer zu findende technische Schwachstellen zu finden und gleichzeitig dazu beitragen Vertrauen und den Wunsch nach wiederholter Zusammenarbeit zwischen Entwicklern verschiedener Unternehmen zu schaffen. Um ein Badge zu verdienen, müssen alle MÜSSEN und MÜSSEN NICHT Kriterien erfüllt sein, alle SOLLTEN Kriterien müssen erfüllt sein oder eine Rechtfertigung enthalten, und alle EMPFHOLEN Kriterien müssen erfüllt sein oder nicht (wir wollen sie zumindest berücksichtigt wissen). Wenn lediglich ein allgemeiner Kommentar angebeben werden soll, keine direkte Begründung, dann ist das erlaubt, wenn der Text mit "//" und einem Leerzeichen beginnt. Feedback ist willkommen auf derGitHub-Website als Issue oder Pull-Request. Es gibt auch eine E-Mail-Liste für allgemeine Diskussionen.

Wir stellen Ihnen gerne die Informationen in mehreren Sprachen zur Verfügung, allerdings ist die englische Version maßgeblich, insbesondere wenn es Konflikte oder Inkonsistenzen zwischen den Übersetzungen gibt.
Wenn dies Ihr Projekt ist, zeigen Sie bitte Ihren Badge-Status auf Ihrer Projektseite! Der Badge-Status sieht so aus: Badge-Level für Projekt 15634 ist in_progress So können Sie ihn einbetten:
Sie können Ihren Badge-Status anzeigen, indem Sie Folgendes in Ihre Markdown-Datei einbetten:
[![OpenSSF Best Practices](https://www.bestpractices.dev/projects/15634/badge)](https://www.bestpractices.dev/projects/15634)
oder indem Sie Folgendes in Ihr HTML einbetten:
<a href="https://www.bestpractices.dev/projects/15634"><img src="https://www.bestpractices.dev/projects/15634/badge"></a>


Dies sind die Kriterien das Level Passing. Sie können auch die Kriterien für die Level Silber oder Gold sehen.

Baseline Series: Baseline Niveau 1 Baseline Niveau 2 Baseline Niveau 3

        

 Grundlagen 12/13 ●

 Verbesserungs-/Nacharbeits-Kontrolle 9/9 ●

  • Öffentliches Versionskontroll-Source-Repository


    Genug für ein Badge!

    Das Projekt MUSS ein versiongesteuertes Quell-Repository haben, das öffentlich lesbar ist und eine URL hat. [repo_public]
    Die URL KANN die gleiche wie die Projekt-URL sein. Das Projekt KANN in bestimmten Fällen private (nichtöffentliche) Zweige verwenden, während die Änderung nicht öffentlich freigegeben wird (z. B. für die Behebung einer Sicherheitslücke, bevor sie veröffentlicht wird).

    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


    Genug für ein Badge!

    Das Quell-Repository des Projekts MUSS verfolgen, welche Änderungen vorgenommen wurden, wer die Änderungen vorgenommen hat und wann die Änderungen vorgenommen wurden. [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


    Genug für ein Badge!

    Um eine kollaborative Überprüfung zu ermöglichen, MUSS das Quell-Repository des Projekts Zwischenversionen für die Überprüfung zwischen Releases enthalten. Es DARF NICHT nur endgültige Veröffentlichungen enthalten. [repo_interim]
    Projekte DÜRFEN sich entscheiden, bestimmte Zwischenversionen aus ihren öffentlichen Quell-Repositories auszulassen (z.B. diejenigen, die bestimmte nicht-öffentliche Sicherheitslücken beheben, niemals öffentlich freigegeben werden können, oder Material enthalten, das nicht legal veröffentlicht werden kann und nicht in der endgültigen Version enthalten ist).

    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


    Genug für ein Badge!

    Es ist EMPFOHLEN, dass eine gemeinsame genutzte Versionskontrollsoftware (z.B. git oder mercurial) für das Source-Repository des Projekts verwendet wird. [repo_distributed]
    Git ist nicht speziell gefordert und Projekte können andere zentralisierte Versionskontrollsoftware (wie z. B. Subversion) mit Rechtfertigung verwenden.

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


  • Einzigartige Versionsnummerierung


    Genug für ein Badge!

    Die für Endbenutzer vorgesehenen Projektergebnisse MÜSSEN eine eindeutige Versionskennung für jede Freigabe haben. [version_unique]
    Dies DARF durch einer Vielzahl von Möglichkeiten, einschließlich einer Commit-IDs (wie z. B. gits Commit-ID oder mercurials Changeset-ID) oder eine Versionsnummer, (einschließlich Versionsnummern, die semantische oder datumsbasierte Systeme wie YYYYMMDD verwenden) erfüllt werden.

    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


    Genug für ein Badge!

    Es ist EMPFHOLEN, dass ein Semantic Versioning (SemVer) oder Calendar Versioning (CalVer) Versionsnummerierungsformat für Releases verwendet wird. Es ist EMPFHOLEN, dass Anwender des CalVer Formates auch die Micro Ebene mit angeben. [version_semver]
    Andere Versionsnummerierungsschemata, wie z. B. Commit-IDs (wie z. B. gits Commit-ID oder mercurials Changeset-ID) oder datumsbasierte Schemata wie YYYYMMDD, DÜRFEN als Versionsnummern verwendet werden, da sie eindeutig sind. Einige Alternativen können zu Problemen führen, denn die Benutzer können nicht leicht feststellen, ob sie aktuell sind. SemVer kann weniger hilfreich sein, um Software-Releases zu identifizieren, wenn alle Empfänger nur die neueste Version ausführen (z.B. ist es der Code für eine einzelne Website oder Internet-Service, der ständig durch kontinuierliche Updates aktualisiert wird).

    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


    Genug für ein Badge!

    Es wird erwartet, dass Projekte jedes Release innerhalb ihres Versionskontrollsystems identifizieren. Zum Beispiel wird erwartet, dass die Projekte, die git verwenden, jedes Release mit git-Tags identifizieren. [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


  • Versionshinweise


    Genug für ein Badge!

    Das Projekt MUSS zu jedem Update Releasenotes enthalten, die eine lesbare Zusammenfassung der wichtigsten Änderungen der Version sind, damit Benutzer/innen sehen können, ob sie aktualisieren sollten und was die Auswirkungen des Updades sind. Die Releasenotes DÜRFEN NICHT die Rohausgabe eines Versionskontrollprotokolls sein (z. B. die "git log"-Befehlsergebnisse sind keine Releasenotes). Für Projekte, deren Ergebnisse nicht für die Wiederverwendung an mehreren Standorten bestimmt sind (z. B. die Software für eine einzelne Website oder Dienstleistung) und eine kontinuierliche Lieferung verwenden, können Sie "N/A" auswählen. (URL erforderlich) [release_notes]
    Die Releasenotes DÜRFEN auf vielfältige Weise implementiert werden. Viele Projekte bieten sie in einer Datei namens "NEWS", "CHANGELOG" oder "ChangeLog", optional mit Erweiterungen wie ".txt", ".md" oder ".html" an. Historisch bedeutete der Begriff "Change Log" ein Protokoll, in dem jede Änderung festgehalten wird, aber um diese Kriterien zu erfüllen, benötigt es eine menschlich lesbare Zusammenfassung. Die Releasenotes können stattdessen von Versionskontrollsystemmechanismen wie dem GitHub Release Workflow zur Verfügung gestellt werden.

    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


    Genug für ein Badge!

    Die Releasenotes MÜSSEN jede öffentlich bekannte Laufzeit-Sicherheitslücke mit einer CVE-Zuweisung oder Ähnlichem kennzeichnen, die in der aktuellen veröffentlichten Version behoben sind. Dieses Kriterium darf als nicht anwendbar (N/A) markiert werden, wenn Benutzer typischerweise nicht selbst die Software aktualisieren. Diese Kirterium trifft nur auf die Projektergebnisse zu, nicht auf Abhängikeiten. Wenn keine Releasenotes vorhanden sind oder keine öffentlich bekannten Sicherheitslücken bekannt sind, wählen Sie (N/A). [release_notes_vulns]
    Dieses Kiterium hilft Benutzer zu verstehen ob ein Update eine bestimmte öffentlich bekannte Sicherheitslücke schließt, und zu entscheiden ob das Update eingespielt wird oder nicht. Wenn Benutzer die Software normalerweise nicht selbst auf ihren Computern aktualisieren können, sondern stattdessen auf eine/n Mittelsfrau/mann angewiesen sind, um das Upgrade durchzuführen (wie es bei einem Kernel und einer Low-Level-Software häufig der Fall ist), wählen Sie stattdessen "nicht anwendbar" (N/A), da diese zusätzliche Information für den Benutzer nicht hilfreich ist. Ein Projekt kann auch N/A auswählen wenn alle Empfänger nur die neuste Version benutzen (z. B. wenn der Code für eine einzelne Webseite oder Internetdienst ist der continuierlich mittels Contious Delivery geupdated wird). Diese Kriterium betrifft nur die Projektergenbisse, nicht seine Abhängigkeiten. Alle Sicherheitslücken für alle Abhängigkeiten eines Projektes aufzulisten ist unhandlich weil Abhängikeiten sich regelmäßig ändern könen; außerdem ist es unnötig weil Tools die sich auf die Analyse von Abhängikeiten spezialisieren das viel skalierbarer hin bekommen.

    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


 Berichterstattung 8/8 ●

  • Bug-Report-Prozess


    Genug für ein Badge!

    Das Projekt muss einen Prozess für Benutzer enthalten, um Fehlerberichte zu senden (z. B. mit einem Issue-Tracker oder eine Mailing-Liste). (URL erforderlich) [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


    Genug für ein Badge!

    Das Projekt SOLLTE einen Issue-Tracker für die Nachverfolgung einzelner Issues verwenden. [report_tracker]

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


    Genug für ein Badge!

    Das Projekt MUSS eine Mehrheit der in den letzten 2-12 Monaten eingereichten Fehlerberichte berücksichtigen; Die Antwort muss keine Korrektur enthalten. [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


    Genug für ein Badge!

    Das Projekt SOLLTE auf eine Mehrheit (>50%) der Verbesserungsvorschläge in den letzten 2-12 Monaten (einschließlich) reagieren. [enhancement_responses]
    Die Antwort DARF "nein" oder eine Diskussion über ihre Vorzüge sein. Das Ziel ist einfach, dass es einige Antworten auf einige Anfragen gibt, was darauf hinweist, dass das Projekt noch am Leben ist. Für die Zwecke dieses Kriteriums müssen die Projekte keine falschen Anfragen (z.B. von Spammern oder automatisierten Systemen) zählen. Wenn ein Projekt keine weiteren Verbesserungen vornimmt, wählen Sie bitte "Unerfüllt" und geben Sie die URL ein, die diesen Zustand den Benutzern klar macht. Wenn ein Projekt von der Anzahl der Verbesserungsvorschläge überwältigt wird, wählen Sie bitte "Unerfüllt" und erklären Sie die Situation.

    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


    Genug für ein Badge!

    Das Projekt MUSS ein öffentlich zugängliches Archiv für Berichte und Antworten für die spätere Suche haben. (URL erforderlich) [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


  • Anfälligkeits-Prozessbericht


    Genug für ein Badge!

    Das Projekt MUSS den Prozess für die Meldung von Schwachstellen auf der Projektseite veröffentlichen. (URL erforderlich) [vulnerability_report_process]
    z.B., eine klar benannte Mailing-Adresse auf https://PROJECTSITE/security, oft in der Form security@example.org. Dies KANN die gleiche sein wie die für den Fehlerberichtsprozess. Informationen über Schwachstellen können immer öffentlich sein, aber viele Projekte verfügen über einen privaten Schwachstellen-Berichtsmechanismus.

    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


    Genug für ein Badge!

    Falls das Projekt einen Kanal zur Übertragung von Schwachstellen besitzt, dann MUSS diese Informationsübertragung privat ablaufen. (URL erforderlich) [vulnerability_report_private]
    Beispiele hierfür sind ein privater Defektbericht, der im Internet über HTTPS (TLS) oder eine mit OpenPGP verschlüsselte E-Mail verschickt wird. Wenn die Informationsübertragung von Schwachstellen immer öffentlich sind (also gibt es niemals private Informationsübertragung von Schwachstellen), wählen Sie "nicht anwendbar" (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


    Genug für ein Badge!

    Das Projekts MUSS mindestens binnen 14 Tagen, auf jeden in den letzten 6 Monaten erhaltenen Anfälligkeitsbericht, reagieren. [vulnerability_report_response]
    Wenn in den letzten 6 Monaten keine Schwachstellen gemeldet wurden, wählen Sie "nicht anwendbar" (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ät 8/13 ●

 Sicherheit 5/16 ●

 Analyse 8/8 ●


Sie können Tools und KI-Systeme nutzen, um Änderungen über eine einfache URL vorzuschlagen, z. B. https://www.bestpractices.dev/de/projects/15634/choose/edit?osps_ac_01_01_status=Met&osps_ac_01_01_justification=GitHub+enforced. Wie das geht, erfahren Sie in unserem Automatisierungsvorschlagssystem. Diese Daten sind unter der Community Data License Agreement – Permissive, Version 2.0 (CDLA-Permissive-2.0) verfügbar. Dies bedeutet, dass ein Datenempfänger die Daten mit oder ohne Änderungen weitergeben darf, solange der Datenempfänger den Text dieser Vereinbarung mit den weitergegebenen Daten zur Verfügung stellt. Bitte nennen Sie alvit und die OpenSSF Best Practices Badge-Mitwirkenden als Urheber.

Projekt-Badge-Eintrag im Besitz von: alvit.
Eintrag erstellt: 2026-10-17 23:08:53 UTC, zuletzt aktualisiert: 2026-10-18 00:10:48 UTC.