haggle

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 13582 ist silver 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/13582/badge)](https://www.bestpractices.dev/projects/13582)
oder indem Sie Folgendes in Ihr HTML einbetten:
<a href="https://www.bestpractices.dev/projects/13582"><img src="https://www.bestpractices.dev/projects/13582/badge"></a>


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

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

        

 Grundlagen 17/17 ●

  • Allgemein

    Hinweis: Andere Projekte können den selben Namen benutzen.

    AGL Australia smart meter -> Home Assistant Energy dashboard (Claude-generated custom integration)

    Bitte verwenden Sie das SPDX-License-Expression-Format; Beispiele sind "Apache-2.0", "BSD-2-Clause", "BSD-3-Clause", "GPL-2.0+", "LGPL-3.0+", "MIT" und "(BSD-2-Clause OR Ruby)". Geben sie nicht die einfachen oder doppelten Anführungszeichen mit an.
    Wenn es mehr als eine Programmiersprache gibt, listen Sie sie als kommagetrennte Werte (Leerzeichen sind optional) auf und sortieren Sie sie von am häufigsten zum am wenigsten verwendeten. Wenn es eine lange Liste gibt, bitte mindestens die ersten drei häufigsten auflisten. Wenn es keine Programmiersprache gibt (z. B. ist dies nur ein Dokumentations- oder Testprojekt), verwenden Sie das einzelne Zeichen "-". Bitte verwenden Sie eine herkömmliche Großschreibung für jede Sprache, z.B. "JavaScript".
    Das Common Platform Enumeration (CPE) ist ein strukturiertes Namensschema für IT-Systeme, Software und Pakete. Es wird in diversen Systemen und Datenbanken bei der Meldung von Schwachstellen verwendet.

  • Voraussetzungen


    Genug für ein Badge!

    Das Projekt MUSS ein bestimmtes Level erreichen. [achieve_passing]

  • Grundlegende Informationen auf der Projektwebseite


    Genug für ein Badge!

    Die Informationen darüber, wie man mitwirken kann, MÜSSEN die Anforderungen für akzeptable Beiträge (z.B. einen Hinweis auf einen erforderlichen Codierungsstandard) enthalten. (URL erforderlich) [contribution_requirements]

    CONTRIBUTING.md (https://github.com/NaanyaBiz/haggle/blob/main/CONTRIBUTING.md) states the requirements for acceptable contributions: the mandatory dev loop (ruff lint/format, strict mypy, pytest, pre-commit) that CI re-runs and rejects failures on, enforced Conventional Commits with provenance trailers, a required PR checklist, and anonymisation rules for API fixtures. The referenced AGENTS.md carries the full coding-standard detail ("What NOT to Do", endpoint procedure).


  • Projektüberwachung


    Gerade genug für ein Badge.

    Das Projekt SOLLTE einen rechtlichen Mechanismus haben, wo alle Entwickler von nicht-trivialen Beiträgen versichern, dass sie rechtlich ermächtigt sind, diese Beiträge zu machen. Der häufigste und leicht umsetzbare Ansatz, ist die Verwendung eines Developer Certificate of Origin (DCO) , wo Benutzer "signed-off-by" in ihren Commits und die Projektlinks zur DCO-Website hinzufügen. Allerdings DARF dies als Contributor License Agreement (CLA) oder als ein anderer rechtlicher Mechanismus implementiert werden. (URL erforderlich) [dco]
    Die DCO ist der empfohlene Mechanismus, weil er einfach zu implementieren ist, im Quellcode verfolgt wird und git direkt eine "signed-off" Funktion mit "commit -s" unterstützt. Um am effektivsten zu sein, ist es am besten, wenn die Projektdokumentation erklärt, was "signed-off" für dieses Projekt bedeutet. Eine CLA ist eine rechtliche Vereinbarung, die die Bedingungen definiert, unter denen intellektuelle Werke an eine Organisation oder ein Projekt lizenziert wurden. Ein Contributor Assignment Agreement (CAA) ist eine gesetzliche Vereinbarung, die die Rechte an einer intellektuellen Arbeit an eine andere Person überträgt; Projekte müssen keine CAAs haben, da CAA das Risiko erhöht, dass potenzielle Mitwirkende nicht dazu beitragen werden, vor allem, wenn der Empfänger eine gewinnorientierte Organisation ist. Die Apache Software Foundation CLAs (die individuelle Contributor-Lizenz und die Corporate CLA) sind Beispiele für CLAs, für Projekte, die bestimmt haben, dass die Risiken dieser CLAs für das Projekt geringen sind als ihre Vorteile.

    CONTRIBUTING.md contains an inbound=outbound licensing statement ("By contributing, you agree your work is licensed under the project's Apache-2.0 license") but no mechanism by which contributors assert they are legally authorized to make their contributions - there is no DCO sign-off requirement, no link to the Developer Certificate of Origin, and no CLA; commit history does not carry Signed-off-by trailers.


    Genug für ein Badge!

    Das Projekt MUSS eindeutig sein Projekt-Governance-Modell (die Art, wie es Entscheidungen fällt, einschließlich der wichtigsten Rollen) definieren und dokumentieren. (URL erforderlich) [governance]
    Es muss einen gut dokumentierten, etablierten Weg geben, Entscheidungen zu treffen und Streitigkeiten zu lösen. In kleinen Projekten kann dies so einfach sein wie, "der Projektinhaber und -Leiter trifft alle endgültigen Entscheidungen". Es gibt verschiedene Führungs-Modelle, darunter wohlwollender Diktator und formale Meritokratie; Für weitere Details siehe Governance-Modelle . Sowohl zentralisierte (z.B. Single-Maintainer) als auch dezentrale (z.B. Gruppen-Maintainer) Ansätze wurden erfolgreich in Projekten verwendet. Die Governance-Informationen müssen nicht die Möglichkeit einer Projektspaltung dokumentieren, da dies für FLOSS-Projekte immer möglich ist.

    The governance model is documented plainly as single-maintainer: CONTRIBUTING.md (https://github.com/NaanyaBiz/haggle/blob/main/CONTRIBUTING.md) states the single-maintainer model and the issue-first contribution process, .github/CODEOWNERS routes every change to the maintainer (* @naanyabiz), and SECURITY.md's risk-acceptance register states the key role explicitly: "the same person authors, triages, and accepts every exception in this project - self-acceptance is the operating model of a single-maintainer repository" (https://github.com/NaanyaBiz/haggle/blob/main/SECURITY.md). AGENTS.md's "Human-approved boundary" section documents that every merge, tag, and release requires the maintainer's live decision.


    Genug für ein Badge!

    Das Projekt MUSS einen Code of Conduct etablieren und an einem üblichen Ort veröffentlichen. (URL erforderlich) [code_of_conduct]
    Projekte können das Miteinander ihrer Gemeinschaft verbessern und Erwartungen in Bezug auf akzeptables Verhalten setzen, indem sie einen Verhaltenskodex verfassen. Dies kann helfen, Probleme zu vermeiden, bevor sie auftreten, und das Projekt zu einem einladenderen Ort zu machen. Dies sollte sich nur auf das Verhalten innerhalb der Gemeinschaft/ am Arbeitsplatz des Projekts konzentrieren. Beispielhafte Verhaltenskodizes sind der Linux Kernel Code of Conduct, der Contributor Covenant Code of Conduct, der Debian Code of Conduct, der Ubuntu Code of Conduct, der Fedora Code of Conduct, der GNOME Code Of Conduct, der KDE Community Code of Conduct, der Python Community Code of Conduct, die Ruby Community Conduct Guideline und der Rust Code of Conduct.

    The project has adopted the Contributor Covenant 2.1 as its code of conduct, posted at the standard location https://github.com/NaanyaBiz/haggle/blob/main/CODE_OF_CONDUCT.md. It states scope and enforcement and includes a private reporting contact (security@naanya.biz) with a 5-business-day acknowledgement commitment.


    Genug für ein Badge!

    Das Projekt MUSS klar und deutlich die Rollen- auf Aufgabenverteilung dokumentieren, inklusive einzelnen Tätigkeiten, die von den Rollenträgern ausgeführt werden müssen. Es MUSS eindeutig sein wer welche Rolle hat, auch wenn es in anderer Form dokumentiert ist. (URL erforderlich) [roles_responsibilities]
    Die Dokumentation für Governance und Rollen und Verantwortlichkeiten können an einem Ort sein.

    The project publicly documents its role structure: .github/CODEOWNERS assigns ownership of everything to @naanyabiz, SECURITY.md states plainly that the same person authors, triages, releases, and accepts every exception ("self-acceptance is the operating model of a single-maintainer repository"), and AGENTS.md section Provenance enumerates every AI tool operating on the repo with its role and scope plus the human-approved boundary (merging, tagging, and releasing always require the maintainer). The committed conformance map (https://github.com/NaanyaBiz/haggle/blob/main/docs/compliance/conformance.md) records under CO-1 that all role functions collapse into the named owner, so it is unambiguous who holds which role.


    Genug für ein Badge!

    Das Projekt MUSS in der Lage sein, mit minimaler Unterbrechung fortzufahren, wenn eine beliebige Person nicht in der Lage ist oder stirbt. Insbesondere MUSS das Projekt in der Lage sein, Probleme zu lösen, vorgeschlagene Änderungen zu akzeptieren und Versionen der Software freizugeben, innerhalb einer Woche nach der Bestätigung, dass eine Person nicht mehr in der Lage ist oder gestorben ist. Dies DARF sichergestellt werden, indem man jemandem anderes notwendige Schlüssel, Passwörter und gesetzliche Rechte gibt, um das Projekt fortzusetzen. Einzelpersonen, die ein FLOSS-Projekt ausführen, DÜRFEN dies durch die Bereitstellung von Schlüsseln in einer Lockbox und einer Willenserklärung zur Bereitstellung von erforderlichen gesetzlichen Rechten (z. B. für DNS-Namen). (URL erforderlich) [access_continuity]

    The project documents a continuity and succession plan in SECURITY.md (section "Continuity and succession"): on the maintainer's death or permanent departure, ownership of the GitHub account/repository and the ed25519 release-signing key passes to next of kin per the maintainer's will, and a digital-legacy arrangement grants next of kin identity access to operate, wind down, or transfer the project. Risk-acceptance RA-04 records the residual (estate-administration latency; the living-incapacity gap). https://github.com/NaanyaBiz/haggle/blob/main/SECURITY.md


    Gerade genug für ein Badge.

    Das Projekt SOLLTE einen Bus-Faktor von 2 oder mehr haben. (URL erforderlich) [bus_factor]
    Ein "bus factor" (aka "LKW-Faktor") ist die minimale Anzahl von Projektmitgliedern, die plötzlich aus einem Projekt ("hit by a bus") verschwinden müssen, bevor das Projekt aufgrund fehlender kompetenter Mitarbeiter stockt. Das Truck-Factor-Tool kann dies für Projekte auf GitHub schätzen. Weitere Informationen finden Sie unter Bewertung des Busfaktors von Git-Repositories von Cosentino et al.

    The project has a bus factor of 1: a single maintainer authors, reviews, and releases everything. This is recorded openly as risk-acceptance RA-04 in SECURITY.md (https://github.com/NaanyaBiz/haggle/blob/main/SECURITY.md), with the public Apache-2.0 licence, AGENTS.md as a succession document, and attested releases as the compensating controls.


  • Dokumentation


    Genug für ein Badge!

    Das Projekt MUSS eine dokumentierte Roadmap, für mindestens das nächste Jahr haben, die beschreibt, was das Projekt beabsichtigt zu tun und nicht zu tun. (URL erforderlich) [documentation_roadmap]
    Das Projekt könnte die Roadmap nicht umsetzen, das ist ok; Der Zweck der Roadmap ist es, potenziellen Nutzern/innen und Entwicklern/innen zu helfen, die beabsichtigte Richtung des Projekts zu verstehen. Sie muss nicht detailliert sein.

    ROADMAP.md documents the project's direction for roughly the next 12 months and its explicit non-goals (single-retailer AGL only; electricity and solar feed-in only; read-only Energy-dashboard import; no telemetry, device control, or portal scraping). https://github.com/NaanyaBiz/haggle/blob/main/ROADMAP.md


    Genug für ein Badge!

    Das Projekt MUSS in der Dokumentation die Architektur (alias High-Level-Design) der vom Projekt entwickelten Software bereitstellen. Wenn das Projekt keine Software produziert, wählen Sie "nicht anwendbar" (N/A). (URL erforderlich) [documentation_architecture]
    Eine Softwarearchitektur erläutert die grundlegenden Strukturen eines Programms, d.h. die Hauptkomponenten des Programms, die Beziehungen zwischen ihnen und die Schlüsseleigenschaften dieser Komponenten und Beziehungen.

    docs/threat-model.md section 1 "System description" (https://github.com/NaanyaBiz/haggle/blob/main/docs/threat-model.md) documents the high-level design, including a core data-flow diagram (browser -> config flow -> AGL Auth0 -> coordinator/parser -> HA recorder -> diagnostics) and the trust boundaries between components. AGENTS.md's "Repo Map" (https://github.com/NaanyaBiz/haggle/blob/main/AGENTS.md) describes every major component (config_flow, coordinator, sensor, diagnostics, agl client/parser/pinning) with its role and relationships, and the "Energy Dashboard Contract" section documents the key statistics-interface properties.


    Genug für ein Badge!

    Das Projekt MUSS dokumentieren, was der/die Benutzer/in in Bezug auf die Sicherheit der Projektsoftware (seine "Sicherheitsanforderungen") erwarten kann und nicht erwarten kann. (URL erforderlich) [documentation_security]
    Dies sind Sicherheitsanforderungen, die die Software erfüllen soll.

    https://github.com/NaanyaBiz/haggle/blob/main/SECURITY.md documents what users can and cannot expect: the data handled and impact assessment, token storage (including the explicit statement that the OAuth refresh token is plaintext at rest on the HA host, with host-FDE guidance), warn-only TLS SPKI pin-mismatch behaviour, supported versions, and what is in/out of scope. The full per-boundary security requirements, data classification, and resilience targets are in the committed threat model, https://github.com/NaanyaBiz/haggle/blob/main/docs/threat-model.md (sections 2, 3 and 8).


    Genug für ein Badge!

    Das Projekt MUSS eine "Quickstart"-Anleitung für neue Benutzer/innen haben, um ihnen zu helfen, schnell mit der Software umgehen zu können. (URL erforderlich) [documentation_quick_start]
    Die Idee ist, den Benutzern/innen zu zeigen, wie man anfängt und was die Software überhaupt macht. Dies ist entscheidend für potenzielle Benutzer/innen, um loszulegen.

    The README's Install section (https://github.com/NaanyaBiz/haggle/blob/main/README.md) is a five-step quick start taking a new user from HACS install to a working configured integration, including the browser-based AGL login step, and is followed by an Energy-dashboard section telling users exactly which statistics to add; a full setup guide lives at docs/energy-dashboard.md.


    Genug für ein Badge!

    Das Projekt MUSS sich bemühen, die Dokumentation mit der aktuellen Version der Projektergebnisse (einschließlich der vom Projekt produzierten Software) stehts zu aktualisieren. Jegliche bekannte Dokumentationsfehler, die es inkonsistent machen, MÜSSEN behoben werden. Wenn die Dokumentation in der Regel aktuell ist, aber fälschlicherweise einige ältere Informationen enthält, die nicht mehr wahr sind, behandeln Sie diese als Störung, dann verfolgen und beheben Sie diese wie üblich. [documentation_current]
    Die Dokumentation DARF Informationen über Unterschiede oder Änderungen zwischen Versionen der Software und/oder Links zu älteren Versionen der Dokumentation enthalten. Die Absicht dieses Kriteriums ist nicht, dass die Dokumentation perfekt sein muss, vielmehr soll Arbeit investiert, um die Dokumentation konsistent zu halten

    Documentation currency is enforced per-PR: AGENTS.md's "Documentation Checklist - Required on Every PR" mandates updating the CHANGELOG, repo map, API facts, and security docs with every code change (https://github.com/NaanyaBiz/haggle/blob/main/AGENTS.md). Known documentation defects are corrected when found - SECURITY.md's storage section explicitly retracts an earlier incorrect claim that HAOS encrypts data at rest, and a README version-rot defect was fixed by policy (no hardcoded version strings; a shields.io release badge instead).


    Genug für ein Badge!

    Die Projekt-Repository-Titelseite und / oder Website MUSS alle Errungenschaften, die erreicht wurden, einschließlich dieses Best Practices Abzeichens, innerhalb von 48 Stunden nach der öffentlichen Anerkennung ausweisen und verlinken. (URL erforderlich) [documentation_achievements]
    Eine Errungenschaft ist jegliche Form von externen Kriterien, auf die das Projekt speziell hingearbeitet hat, um diese zu erreichen, einschließlich einiger Abzeichen. Diese Informationen müssen nicht auf der ersten Seite der Website des Projekts einzusehen sein. Ein Projekt, das GitHub verwendet, kann Errungenschaften auf der Repository-Vorderseite setzen, indem man sie der README-Datei hinzufügt.

    The repository front page README (https://github.com/NaanyaBiz/haggle/blob/main/README.md) displays hyperlinked achievement badges at the top: the OpenSSF Best Practices badge (project 13582, linking to bestpractices.dev), the OpenSSF Scorecard badge (linking to the scorecard.dev viewer), and the latest-release badge. The Best Practices badge was added the same day the passing badge was earned (2026-07-12, PR #172).


  • Zugänglichkeit und Internationalisierung


    Genug für ein Badge!

    Das Projekt (beide Projektwebsite und Projektergebnisse) SOLLTE den bewährten Praktiken der Erreichbarkeit folgen, damit Personen mit Behinderungen noch an dem Projekt teilnehmen und die Projektergebnisse nutzen können, wo es vernünftig ist. [accessibility_best_practices]
    Für Webanwendungen siehe Web Content Accessibility Guidelines (WCAG 2.0) und dessen unterstützendes Dokument Understanding WCAG 2.0; Siehe auch W3C accessibility information. Für GUI-Anwendungen sollten Sie die umweltbezogenen Barrierefreiheitsrichtlinien verwenden (z.B. Gnome, KDE, XFCE, Android, iOS , Mac und Windows). Einige TUI-Anwendungen (z.B. `ncurses`-Programme) können bestimmte Dinge ausführen, um sich selbst zugänglicher zu machen (z.B. `alpine`'s `force-arrow-cursor`-Einstellung). Die meisten Kommandozeilen-Anwendungen sind ziemlich unzugänglich. Dieses Kriterium ist oft N/A, z.B. für Programmbibliotheken. Hier sind einige Beispiele, welche Maßnahmen zu ergreifen oder Fragen zu berücksichtigen sind:
    • Stellen Sie Text Alternativen für alle Nicht-Text-Inhalte zur Verfügung, so dass dieser in andere Formen umgewandelt werden kann, wie z.B. Großdruck, Blindenschrift, Sprache, Symbole oder einfachere Sprache ( WCAG 2.0-guideline 1.1)
    • Farbe ist nicht das einzige Mittel um Informationen zu übermitteln, die eine Aktion anzeigen, zu einer Eingabe auffordern oder visuelle Elemente unterscheiden. (WCAG 2.0 guideline 1.4.1)
    • Die visuelle Darstellung von Text und Textbildern hat einen Kontrast Verhältnis von mindestens 4,5:1, außer für großen Text, nebensächlichen Text, und Logos(WCAG 2.0 guideline 1.4.3)
    • Machen Sie alle Funktionalitäten von einer Tastatur aus erreichbar (WCAG guideline 2.1)
    • Ein GUI oder ein webbasiertes Projekt SOLLTE mit mindestens einen Screen-Reader auf der Zielplattform(en) testen (z.B. NVDA, Jaws oder WindowEyes auf Windows; VoiceOver auf Mac & iOS; Orca auf Linux/BSD; TalkBack auf Android). TUI-Programme DÜRFEN die Übermalung reduzieren, um eine redundante Lesung durch Screenreader zu verhindern.

    The project ships no user interface of its own: it is a headless Home Assistant integration whose config flow, sensors, and Energy-dashboard statistics are all rendered by Home Assistant's standard frontend (the integration contributes only strings.json/translations, no HTML/JS/frontend assets), and accessibility of that UI is owned upstream by Home Assistant. Project documentation is plain Markdown rendered by GitHub.


    Genug für ein Badge!

    Die Projektsoftware SOLLTE internationalisiert werden, um eine einfachen Zugang für die Kultur, Region oder Sprache der Zielgruppe zu ermöglichen. Wenn die Internationalisierung (i18n) nicht andzuwenden ist (z. B. die Software keine für Endbenutzer beabsichtigte Texte erzeugt und keinen menschlich lesbaren Text sortiert), wählen Sie "nicht anwendbar" (N/A). [internationalization]
    Lokalisierung "bezieht sich auf die Anpassung eines Produkt-, Applikations- oder Dokumentinhalts, um die Sprache, kulturelle und andere Anforderungen eines bestimmten Zielmarktes zu erfüllen." Internationalisierung ist die "Gestaltung und Entwicklung eines Produkt-, Applikations- oder Dokumentinhaltes, die eine einfache Lokalisierung für Zielgruppen ermöglicht, die in Kultur, Region oder Sprache variieren." (Siehe W3Cs "Lokalisierung vs. Internationalisierung" .) Software erfüllt dieses Kriterium einfach dadurch, dass sie internationalisiert ist. Es ist keine Lokalisierung für eine andere Sprache erforderlich, denn sobald Software internationalisiert wurde, ist es möglich für andere, an der Lokalisierung zu arbeiten.

    User-facing text is externalized through Home Assistant's standard translation framework: custom_components/haggle/strings.json (https://github.com/NaanyaBiz/haggle/blob/main/custom_components/haggle/strings.json) holds all config-flow, error, and entity strings, mirrored in translations/en.json - localizing to another language is a matter of adding a translations/<lang>.json file. Only English is currently provided.


  • Andere


    Genug für ein Badge!

    Wenn die Projektseiten (Website, Repository und Download-URLs) Passwörter für die Authentifizierung von externen Benutzern speichern, müssen die Passwörter als iterierte Hashes mit einem per-User-Salt unter Verwendung eines Key-Stretching (iterierten) Algorithmus (z. B. Argon2id, Bcrypt, Scrypt, or PBKDF2). Wenn die Projektseiten hierfür keine Passwörter speichern, wählen Sie "nicht anwendbar" (N/A) aus. [sites_password_security]
    Beachten Sie, dass die Verwendung von GitHub dieses Kriterium erfüllt. Dieses Kriterium gilt nur für Passwörter, die für die Authentifizierung von externen Benutzern in die Projektseiten verwendet werden (inbound authentication). Wenn sich die Projektseiten auf anderen Seiten anmelden müssen (outbound authentication), müssen sie eventuell Authorization-Tokens für diesen Zweck anders speichern (da das Speichern eines Hashes nutzlos wäre). Dies gilt für das Kriterium crypto_password_storage zu den Projektseiten, ähnlich wie sites_https.

    All project sites (repository, issue tracker, releases, security advisories) are hosted on GitHub, which handles external-user authentication and stores passwords per this criterion; the project operates no site of its own that stores passwords.


 Verbesserungs-/Nacharbeits-Kontrolle 1/1 ●

  • Vorherige Versionen


    Genug für ein Badge!

    Das Projekt MUSS die am häufigsten verwendeten älteren Versionen des Produkts beibehalten oder einen Upgrade-Pfad zu neueren Versionen bieten. Wenn der Upgrade-Pfad schwierig durchzuführen ist, muss das Projekt dokumentieren, wie das Upgrade durchgeführt werden kann (z. B. die Interfaces, die sich geändert haben, detaillierte Anleitung für die Aktualisierung des Upgrades). [maintenance_or_update]

    SECURITY.md section Supported Versions states the latest tagged release on main is the only supported version, with upgrades surfaced to users automatically via HACS. The README's "Rollback / downgrade" section (https://github.com/NaanyaBiz/haggle/blob/main/README.md) documents that any prior release can be reinstalled via HACS, that config entries are downgrade-safe and statistics survive in both directions, and docs/releasing.md requires a recorded manual downgrade test with each stable release.


 Berichterstattung 3/3 ●

  • Bug-Report-Prozess


    Genug für ein Badge!

    Das Projekt MUSS ein Issue-Tracking-System zur Verwaltung einzelner Issues verwenden. [report_tracker]

    The project tracks individual issues on the GitHub issue tracker at https://github.com/NaanyaBiz/haggle/issues, declared machine-readably in the integration manifest ("issue_tracker" in https://github.com/NaanyaBiz/haggle/blob/main/custom_components/haggle/manifest.json) and in pyproject.toml project URLs. CONTRIBUTING.md requires an issue-first workflow and AGENTS.md defines a triaged label taxonomy (P1-P3 priority, sev:high/med/low, escaped) consumed by the release flow and quarterly delivery metrics.


  • Anfälligkeits-Prozessbericht


    Genug für ein Badge!

    Das Projekt MUSS die Reporter/in von allen in den letzten 12 Monaten bekanntgegebenen Schwachstellenberichte aufführen, mit Ausnahme der Reporter, die Anonymität erbeten. Wurde in den letzten 12 Monaten keine Schwachstelle festgestellt, wählen Sie "nicht anwendbar" (N/A). (URL erforderlich) [vulnerability_report_credit]

    No vulnerability reports have been received or resolved in the last 12 months (the project is only a few months old); SECURITY.md's "Hall of Fame" section explicitly reads "(none yet - be the first.)". SECURITY.md commits to crediting reporters in release notes and the Hall of Fame unless anonymity is requested (https://github.com/NaanyaBiz/haggle/blob/main/SECURITY.md). The one CVE fix in CHANGELOG (idna, dev-only lockfile) came via automated Dependabot monitoring, not an external report to this project.


    Genug für ein Badge!

    Das Projekt MUSS den Prozess für die Meldung von Schwachstellen auf der Projektseite veröffentlichen. (URL erforderlich) [vulnerability_response_process]
    Dies steht im Zusammenhang mit vulnerability_report_process, welcher erfordert, dass es eine dokumentierte Möglichkeit gibt, Schwachstellen zu melden. Es bezieht sich auch auf vulnerability_report_response, welcher eine Antwort auf Schwachstellenberichte innerhalb eines bestimmten Zeitrahmens erfordert.

    https://github.com/NaanyaBiz/haggle/blob/main/SECURITY.md documents the full response process: private reporting via GitHub Private Security Advisories or security@naanya.biz, acknowledgement within 5 business days, graduated response targets by severity (critical 72 h / high 7 days / moderate-low 30 days), a self-escalation forcing function honest about the single-maintainer bound, a coordinated-disclosure window (14 days), and the known-vulnerable-release procedure (GHSA advisory, superseding release, HACS delisting).


 Qualität 19/19 ●

  • Programmierstil


    Genug für ein Badge!

    Das Projekt MUSS die spezifischen Codierungsstilrichtlinien für die primären Programmierprachen, die es verwendet, einhalten, und erfordern, dass die Beiträge die Bedingungen generell erfüllen. (URL erforderlich) [coding_standards]
    In den meisten Fällen erfolgt dies durch Verweis auf einige vorhandene Stilrichtlinien, möglicherweise Auflistung Unterschiede. Diese Stilrichtlinien können Möglichkeiten zur Verbesserung der Lesbarkeit und zur Verringerung der Wahrscheinlichkeit von Mängeln (einschließlich Schwachstellen) enthalten. Viele Programmiersprachen haben eine oder mehrere weit verbreitete Stilrichtlinien. Beispiele für Style Guides sind Google-Style-Guides und SEI CERT Coding Standards .

    CONTRIBUTING.md requires contributions to pass the documented dev loop - ruff check, ruff format, and strict mypy - before pushing (https://github.com/NaanyaBiz/haggle/blob/main/CONTRIBUTING.md). The specific style configuration is committed in pyproject.toml ([tool.ruff] with 17 rule families, line-length 88, isort ordering; [tool.mypy] strict = true) (https://github.com/NaanyaBiz/haggle/blob/main/pyproject.toml), and .github/workflows/ci.yml enforces ruff check, ruff format --check, and mypy as part of a required PR status check.


    Genug für ein Badge!

    Das Projekt MUSS automatisch dafür sorgen, dass die ausgewählten Stilrichtlinien eingehalten werden, wenn mindestens ein FLOSS-Tool vorhanden ist, welches das in der gewählten Programmiersprache tun kann. [coding_standards_enforced]
    Dies kann mit Hilfe von statischen Analysewerkzeugen und/oder durch das Durchlaufen des Codes durch Code-Umformatierer erreicht werden. In vielen Fällen ist die Werkzeugkonfiguration im Projekt-Repository enthalten (da verschiedene Projekte unterschiedliche Konfigurationen wählen können). Projekte DÜRFEN Stil Ausnahmen erlauben (und werden es in der Regel); Wo Ausnahmen getroffen werden, MÜSSEN sie selten sein und MÜSSEN dokumentiert werden an der Stelle im Code, wo sie auftreten, so dass diese Ausnahmen überprüft werden können und so dass Werkzeuge sie automatisch in der Zukunft bearbeiten können. Beispiele für solche Werkzeuge sind ESLint (JavaScript), Rubocop (Ruby) und devtools check (R).

    Coding style is enforced automatically by FLOSS tools: ruff lint, ruff format --check, and mypy run on every push and pull request in CI (https://github.com/NaanyaBiz/haggle/blob/main/.github/workflows/ci.yml, steps at lines 41-48), and the containing 'Test (Python 3.14)' job is one of eight required status checks under the zero-bypass protect-main ruleset, so a style violation blocks merge. The selected style is committed in pyproject.toml ([tool.ruff]) and also enforced locally via pre-commit hooks.


  • Produktivsystem


    Genug für ein Badge!

    Build-Systeme für native Binärdateien MÜSSEN die relevanten Compiler- und Linker- (Umgebungs-) Variablen, die an sie übergeben werden (z.B. CC, CFLAGS, CXX, CXXFLAGS und LDFLAGS), respektieren und an Compiler- und Linker-Aufrufe weiterleiten. Ein Build-System DARF sie mit zusätzlichen Flags erweitern; Es DARF NICHT einfach die mitgelieferten Werte ersetzen. Wenn keine nativen Binärdateien erzeugt werden, wählen Sie "nicht anwendbar" (N/A). [build_standard_variables]
    Es sollte einfach sein, spezielle Build-Features wie Address Sanitizer (ASAN) zu aktivieren, oder verteilte und bewährte Best Practices einzuhalten (z.B. durch einfaches Einschalten von Compiler-Flags).

    The project is a pure-Python Home Assistant custom integration: manifest.json declares "requirements": [] and the hatchling build backend produces no native binaries, so no compiler or linker is ever invoked and CC/CFLAGS-style variables have no referent.


    Genug für ein Badge!

    Das Build- und Installationssystem SOLLTE Debugging-Informationen beibehalten, wenn sie in den entsprechenden Flags angefordert werden (z. B. "install -s" wird nicht verwendet). Wenn kein Build- oder Installationssystem vorhanden ist (z. B. typische JavaScript-Bibliotheken), wählen Sie "nicht anwendbar" (N / A). [build_preserve_debug]
    Z. B., die Festlegung von CFLAGS (C) oder CXXFLAGS (C ++) sollte die relevanten Debugging-Informationen erstellen, wenn diese Sprachen verwendet werden, und sie sollten während der Installation nicht ignoriert werden. Debugging-Informationen werden für Unterstützung und Analyse benötigt und sind auch nützlich, um das Vorhandensein von Härtungsmerkmalen in den kompilierten Binärdateien zu messen.

    The release build (https://github.com/NaanyaBiz/haggle/blob/main/.github/workflows/release.yml, "Build release artifact" step) zips the unmodified Python source of custom_components/haggle, excluding only pycache/.pyc; HACS installs that zip as-is. Nothing is stripped, minified, or compiled, so full source-level debugging information (readable source, tracebacks with line numbers) is always preserved in what users install.


    Genug für ein Badge!

    Das Build-System für die Software, die durch das Projekt erzeugt wird, DARF NICHT rekursive Unterverzeichnisse aufbauen, wenn es Querverweise in den Unterverzeichnissen gibt. Wenn kein Build- oder Installationssystem vorhanden ist (z.B. typische JavaScript-Bibliotheken), wählen Sie "nicht anwendbar" (N / A). [build_non_recursive]
    Die interne Abhängigkeitsinformationen des Build-Systems des Projektes müssen präzise sein, andernfalls können Änderungen an dem Projekt nicht korrekt erfolgen. Falsche Builds können zu Defekten (einschließlich Schwachstellen) führen. Ein häufiger Fehler bei großen Build-Systemen ist die Verwendung eines "rekursiven Builds" oder "rekursiven Make", d.h. einer Hierarchie von Unterverzeichnissen, die Quelldateien enthalten, wobei jedes Unterverzeichnis unabhängig aufgebaut ist. Es sei denn, jedes Unterverzeichnis ist völlig unabhängig, was ist ein Fehler ist, da die Abhängigkeitsinformationen nicht korrekt sind.

    The only build step is a single, flat packaging step in the release workflow: release.yml zips the contents of custom_components/haggle/ into haggle.zip in one command, then generates SBOMs and attestations from that artifact (https://github.com/NaanyaBiz/haggle/blob/main/.github/workflows/release.yml). There are no subdirectory builds, no Makefile recursion, and no cross-directory build dependencies; the integration is pure Python with zero compiled components.


    Genug für ein Badge!

    Das Projekt MUSS in der Lage sein, den Prozess der Generierung von Informationen aus Quelldateien zu wiederholen und genau das gleiche Bit-für-Bit-Ergebnis zu erhalten. Wenn kein Build auftritt (z. B. Skriptsprachen, in denen der Quellcode direkt verwendet wird, anstatt kompiliert zu werden), wählen Sie "nicht anwendbar" (N / A). [build_repeatable]
    GCC- und Clang-Benutzer finden die Option -frandom-seed womöglich nützlich; In manchen Fällen kann dies dadurch gelöst werden, dass man eine Sortierreihenfolge erzwingt. Weitere Vorschläge finden Sie auf der reproducible Build Seite.

    Not applicable: haggle is a pure-Python Home Assistant custom integration whose source is used directly - HACS extracts the release archive and Home Assistant imports the .py files unchanged, so there is no compilation or build step to reproduce bit-for-bit. The criterion explicitly permits N/A where source is used directly rather than compiled.


  • Installationssystem


    Genug für ein Badge!

    Das Projekt MUSS eine Möglichkeit zur einfachen Installation und Deinstallation der Software haben, unter Benutzung einer häufig verwendeten Methode. [installation_common]
    Beispiele hierfür sind die Verwendung eines Paketmanagers (auf dem System- oder Sprachniveaus), "make install/uninstall" (unterstützt DESTDIR), einem Container im Standardformat oder ein virtuelles Maschinenbild im Standardformat. Der Installations- und Deinstallationsvorgang (z.B. seine Verpackung) DARF von einem/einer Dritten implementiert werden, solange es FLOSS ist.

    The integration is distributed via HACS (the Home Assistant community package manager) and is in the HACS default store; README section Install documents the install (HACS -> search Haggle -> Download -> restart) and section Removing documents uninstall via HA's Settings -> Devices & Services, including a best-effort revocation of the stored OAuth grant on removal (https://github.com/NaanyaBiz/haggle/blob/main/README.md). hacs.json configures the attested zip_release asset that HACS installs.


    Genug für ein Badge!

    Das Installationssystem für den/die Endbenutzer/in MUSS Standardkonventionen zur Auswahl des Zielortes, in dem gebildete Artefakte zur Installationszeit geschrieben werden, folgen. Zum Beispiel, wenn es Dateien auf einem POSIX-System installiert, muss es die DESTDIR-Umgebungsvariable verwenden. Wenn es kein Installationssystem oder keine Standardkonvention gibt, wählen Sie "nicht anwendbar" (N/A). [installation_standard_variables]

    The installation system is HACS, which installs the integration into Home Assistant's standard custom_components/ location inside the user-chosen HA configuration directory - the platform's standard convention for install location (install and rollback steps documented at https://github.com/NaanyaBiz/haggle/blob/main/README.md#install). Nothing is compiled, so no DESTDIR-style build-time relocation applies to this artifact type; the install location follows the ecosystem convention exactly.


    Genug für ein Badge!

    Das Projekt MUSS einen Weg für potenzielle Entwickler bereithalten, um schnell alle erforderlich Projektergebnisse und Support-Umgebungen zu installieren, um Änderungen vornehmen zu können, einschließlich der Tests und Test-Umgebung. Dies MUSS mit einer gängigen Methode durchgeführt werden können. [installation_development_quick]
    Dies DARF mit einem generierten Container- und/oder Installationsskript(en) implementiert werden. Externe Abhängigkeiten würden typischerweise durch das Aufrufen von System- und/oder Sprachpaketmanager(n), als external_dependencies, installiert.

    CONTRIBUTING.md section Dev loop (https://github.com/NaanyaBiz/haggle/blob/main/CONTRIBUTING.md) documents a one-command setup - uv sync installs the complete dev and test environment from the hash-pinned uv.lock - followed by uv run pytest / ruff / mypy / pre-commit, matching what CI runs. A committed .devcontainer/devcontainer.json additionally provides a ready-made containerized dev environment with uv preinstalled.


  • Externe gepflegte Komponenten


    Genug für ein Badge!

    Das Projekt MUSS externe Abhängigkeiten in computerlesbarer Form auflisten. (URL erforderlich) [external_dependencies]
    Dies geschieht in der Regel mit den Konventionen des Paketmanagers und / oder des Buildsystems. Dies hilft auch installation_development_quick zu erfüllen.

    Runtime dependencies are declared machine-readably in https://github.com/NaanyaBiz/haggle/blob/main/custom_components/haggle/manifest.json ("requirements": [] - the integration deliberately ships zero packages; everything it imports is vendored and pinned by Home Assistant core, as documented in SECURITY.md's supply-chain section). Development/test dependencies are declared in https://github.com/NaanyaBiz/haggle/blob/main/pyproject.toml and hash-pinned in uv.lock; Dependabot processes both the pip and github-actions ecosystems weekly.


    Genug für ein Badge!

    Projekte MÜSSEN ihre externen Abhängigkeiten (einschließlich Bequemlichkeitskopien) überwachen oder regelmäßig überprüfen, um bekannte Schwachstellen zu erkennen und ausnutzbare Schwachstellen zu beheben oder sie als unausweichlich zu verifizieren. [dependency_monitoring]
    Dies kann mit einem Ursprungsanalysator / Abhängigkeitsüberprüfungswerkzeug / Softwarezusammensetzungsanalysator wie OWASPs Dependency-Check, Sonatypes Nexus Auditor, Synopsys' Black Duck Software Composition Analysis, und Bundler-Audit (für Ruby) erreicht werden. Einige Paketmanager beinhalten Mechanismen, um dies zu tun. Es ist akzeptabel, wenn die Anfälligkeit der Komponenten nicht ausgenutzt werden kann, aber diese Analyse ist schwierig und es ist manchmal einfacher, den Part einfach zu aktualisieren oder zu reparieren.

    Dependabot runs weekly on both the pip lockfile and github-actions ecosystems (https://github.com/NaanyaBiz/haggle/blob/main/.github/dependabot.yml), and every PR is gated by a required "Dependency review" check (actions/dependency-review-action, fail-on-severity: moderate, vulnerability-check: true) in ci.yml. SECURITY.md documents the triage ladder for alerts (critical 72 h / high 7 d / rest 30 d) and the exploitability analysis: manifest.json ships zero runtime requirements, so lockfile CVEs are dev/CI-only and are triaged on that recorded basis.


    Genug für ein Badge!

    Das Projekt MUSS entweder:
    1. Es einfach machen, wiederverwendbare extern gepflegte Komponenten zu identifizieren und zu aktualisieren;oder
    2. Die Standardkomponenten des Systems oder der Programmiersprache verwenden.
    Dann, wenn eine Schwachstelle in einer wiederverwendeten Komponente gefunden wird, wird es einfach sein diese Komponente zu aktualisieren. [updateable_reused_components]
    Ein typischer Weg, um dieses Kriterium zu erfüllen, ist die Verwendung von System- und Programmiersprachen-Paketverwaltungssystemen. Viele FLOSS-Programme werden mit "Convenience-Bibliotheken" ausgestattet, die lokale Kopien der Standardbibliotheken (ggf. geforkt) enthalten. Prinzipiell ist das gut. Wenn jedoch das Programm diese lokalen (geforkten) Kopien verwenden *muss*, dann wird die Aktualisierung der "Standard"-Bibliotheken, als Sicherheitsupdate, diese zusätzlichen Kopien immer noch verwundbar lassen. Dies ist vor allem ein Problem für Cloud-basierte Systeme; Wenn der Cloud-Provider seine "Standard"-Bibliotheken aktualisiert, aber das Programm sie nicht verwendt, dann helfen die Updates nicht wirklich. Siehe z.B. "Chromium: Why it isn't in Fedora yet as a proper package" von Tom Callaway .

    The shipped integration reuses only components vendored and version-pinned by Home Assistant core - https://github.com/NaanyaBiz/haggle/blob/main/custom_components/haggle/manifest.json declares "requirements": [] - so users receive standard platform-provided components. Development dependencies are enumerated in pyproject.toml and hash-locked per artifact in uv.lock, and https://github.com/NaanyaBiz/haggle/blob/main/.github/dependabot.yml runs weekly grouped update PRs for both the pip and github-actions ecosystems.


    Genug für ein Badge!

    Das Projekt SOLLTE vermeiden veraltete oder obsolete Funktionen und APIs zu verwenden, für die FLOSS-Alternativen in der eingesetzten Technologie verfügbar sind (ihr "Technologie-Stack") und eine Supermajorität der Benutzer, die das Projekt unterstützt (so dass die Benutzer den Zugriff auf die Alternative haben ). [interfaces_current]

    Ruff's pyupgrade (UP), flake8-async (ASYNC), and bugbear (B) rule families are enabled in pyproject.toml and gate every PR, flagging obsolete Python idioms and deprecated patterns (https://github.com/NaanyaBiz/haggle/blob/main/pyproject.toml); pytest runs with filterwarnings = "error" so deprecation warnings from the project's own code fail the suite (upstream homeassistant DeprecationWarnings are the only scoped exception). A weekly compat workflow additionally runs the full suite against the latest Home Assistant releases including betas to catch upcoming upstream deprecations early (https://github.com/NaanyaBiz/haggle/blob/main/.github/workflows/compat.yml).


  • Automatisierte Test-Suite


    Genug für ein Badge!

    Eine automatisierte Test-Suite MUSS bei jedem Check-In auf ein gemeinsames Repository für mindestens einen Zweig angewendet werden. Diese Test-Suite muss einen Bericht über Erfolg oder Misserfolg des Testes produzieren. [automated_integration_testing]
    Diese Anforderung kann als Teilmenge von test_continuous_integration angesehen werden, konzentriert sich aber nur auf das Testen, ohne eine kontinuierliche Integration zu fordern.

    The full automated test suite (pytest, with a combined line+branch coverage floor of 89% enforced via --cov-fail-under) runs on every push to main and every pull request via https://github.com/NaanyaBiz/haggle/blob/main/.github/workflows/ci.yml, producing a success/failure report as a GitHub check run on each commit; the check is required for merge by the protect-main ruleset.


    Genug für ein Badge!

    Das Projekt MUSS Regressionstests zu einer automatisierten Test-Suite hinzufügen für mindestens 50% der, in den letzten sechs Monaten, gefixten Bugs. [regression_tests_added50]

    The committed test strategy (https://github.com/NaanyaBiz/haggle/blob/main/docs/testing.md) requires that every escaped defect gets a named, pinned regression test and lists the existing pins (e.g. test_uses_outer_consumption_quantity_not_inner_values, test_baseline_looked_up_at_earliest_fetched_hour, test_band_reachback_baseline_after_long_absence). Verified in git history: 14 of the 16 integration-code bug-fix commits in the last six months (~87%) included automated-test additions or changes in the same commit, well above the 50% threshold.


    Genug für ein Badge!

    Das Projekt MUSS automatisierte FLOSS-Test-Suite(s) haben, die mindestens 80% Aussage Berichterstattung haben, wenn es mindestens ein FLOSS-Tool gibt, das dieses Kriterium in der ausgewählten Sprache erfüllen kann. [test_statement_coverage80]
    Viele FLOSS-Tools stehen zur Verfügung, um die Test-Coverage zu beurteilen, einschließlich gcov/lcov, Blanket.js, Istanbul, JCov, und covr (R). Beachten Sie, dass das Erfüllen dieses Kriteriums keine Garantie dafür ist, dass die Test-Suite gründlich ist, hingegen ist das Verfehlen dieses Kriteriums ein starker Indikator für eine schlechte Test-Suite.

    The FLOSS test suite (pytest + coverage.py, ~254 tests including recorder-backed integration tests) is gated in CI at a combined line+branch coverage floor of 89% via --cov-fail-under=89 in https://github.com/NaanyaBiz/haggle/blob/main/.github/workflows/ci.yml, part of the required "Test (Python 3.14)" status check enforced by the zero-bypass protect-main ruleset. Current statement (line) coverage is 91.6% (local coverage.xml line-rate 0.9162; https://github.com/NaanyaBiz/haggle/blob/main/docs/testing.md records 90.0% combined at floor-setting time and defines the floor as an upward-only ratchet).


  • Neue Funktionalitätsüberprüfung


    Genug für ein Badge!

    Das Projekt MUSS eine formale schriftliche Richtlinie dazu haben, wie wichtige neue Funktionalität hinzugefügt werden. Tests für die neue Funktionalität MÜSSEN zu einer automatisierten Test-Suite hinzugefügt werden. [test_policy_mandated]

    docs/testing.md (https://github.com/NaanyaBiz/haggle/blob/main/docs/testing.md) is the formal written test policy: its "Required depth per change type" section mandates automated tests for every functional change class (new endpoint => new fixture + parser tests; coordinator/statistics change => harness-integration tests, with real-recorder tests for sum-chain changes; every escaped defect => a named pinned regression test), enforced by the required CI check with a ratcheting coverage floor (--cov-fail-under=89). CONTRIBUTING.md and AGENTS.md's "Adding a New Endpoint" procedure repeat the tests-required rule for contributors.


    Genug für ein Badge!

    Das Projekt MUSS in seinen dokumentierten Anweisungen für Änderungsvorschläge die Richtlinien enthalten, die Tests für große neue Funktionalität hinzugefügt werden sollen. [tests_documented_added]
    Allerdings ist auch eine informelle Regel akzeptabel, solange die Tests in der Praxis hinzugefügt werden.

    https://github.com/NaanyaBiz/haggle/blob/main/CONTRIBUTING.md requires new-endpoint contributions to "Add an anonymised fixture, parser, client method, and tests", and https://github.com/NaanyaBiz/haggle/blob/main/docs/testing.md section "Required depth per change type" mandates the specific test layer for every class of change (new endpoint => new fixture + parser tests; cumulative-sum changes => recorder-backed tests in test_recorder_statistics.py; escaped defects => a named pinned regression test), enforced by CI's ratcheting 89% coverage floor.


  • Warnhinweise


    Genug für ein Badge!

    Projekte MÜSSEN praktischerweise sehr streng mit Warnungen in der Projektsoftware sein. [warnings_strict]
    Bei manchen Projekten können einige Warnungen effektiv nicht aktiviert werden. Was benötigt wird, ist ein Beleg dafür, dass das Projekt danach strebt, Warnungen zu aktivieren, wo es möglich ist, so dass Fehler frühzeitig erkannt werden.

    Warnings are maximally strict and enforced in CI: mypy runs with strict = true plus warn_unreachable, warn_unused_ignores, and warn_redundant_casts; ruff enables 17 rule families including security (flake8-bandit), pylint, bugbear, and a max-complexity 12 gate; and pytest converts warnings to errors (filterwarnings = "error" with narrowly scoped upstream exceptions) - all configured in pyproject.toml (https://github.com/NaanyaBiz/haggle/blob/main/pyproject.toml) and run as part of the required "Test (Python 3.14)" PR check in .github/workflows/ci.yml.


 Sicherheit 13/13 ●

  • Wissen über sichere Entwicklungspraktiken


    Genug für ein Badge!

    Das Projekt MUSS sichere Designprinzipien (von "know_secure_design"), soweit anwendbar, umsetzen. Wenn das Projekt keine Software produziert, wählen Sie "nicht anwendbar" (N/A). [implement_secure_design]
    Beispielsweise sollten die Projektergebnisse fehlersichere Vorgaben haben (Zugriffsentscheidungen sollten standardmäßig verweigert werden und die Installation von Projekten sollte standardmäßig sicher sein). Die Projektergebnisse sollten auch eine vollständige Vermittlung haben (jeder Zugang, der begrenzt werden kann, muss auf Autorität überprüft werden und nicht umgangen werden können). Beachten Sie, dass in einigen Fällen Prinzipien in Konflikt geraten, in welchen eine Entscheidung getroffen werden muss (z.B. viele Mechanismen können die Dinge komplexer machen, gegen die "Wirtschaftlichkeit des Mechanismus" verstoßen / halten Sie es einfach).

    Secure design principles are applied and documented per trust boundary in the committed threat model (https://github.com/NaanyaBiz/haggle/blob/main/docs/threat-model.md section 3): all untrusted AGL JSON passes allowlist parsing with numeric clamping to finite non-negative values (complete mediation / input validation, fuzz-enforced); least privilege governs OAuth scopes (read-only, with a documented re-assessment tripwire on any write scope) and CI tokens (read-only default, job-scoped writes); fail-safe defaults appear as fail-closed release gates (tag ancestry + signature verification) and a fail-closed secret-scanner self-test; secret exposure is minimised (memory-only 15-minute access token, rotate-on-use refresh token, hash-only fallback unique_id).


  • Verwende grundlegend gute kryptographische Praktiken

    Beachten Sie, dass einige Software keine kryptographischen Mechanismen verwenden muss. Wenn Ihr Project Software erstellt das (1) kryptographische funktionen einbindet, aktiviert, oder ermöglicht und (2) aus den USA heraus an nicht US-Bürger verteilt wird, dann könnten sie rechtlich zu weiterne Schritten gezwungen sein. Meistens beinhaltet dies lediglich das Senden einer E-Mail. Für mehr Informationen, siehe den Abschnitt zu Encryption in Understanding Open Source Technology & US Export Controls.

    Genug für ein Badge!

    Die Standard-Sicherheitsmechanismen innerhalb der Projektsoftware DÜRFEN NICHT von kryptographischen Algorithmen oder Modi mit bekannten schweren Mängeln abhängen (z.B. der SHA-1-Kryptographie-Hash-Algorithmus oder der CBC-Modus in SSH). [crypto_weaknesses]
    Sorgen über den CBC-Modus in SSH werden in CERT: SSH CBC vulnerability erläutert.

    All cryptographic mechanisms in the integration use SHA-256 or stronger: the OAuth PKCE challenge is S256 (config_flow.py), TLS pins are SHA-256 SPKI hashes (https://github.com/NaanyaBiz/haggle/blob/main/custom_components/haggle/agl/pinning.py), diagnostics anonymisation is HMAC-SHA256 (diagnostics.py), and the fallback unique_id is a SHA-256 digest. A search of the integration code finds no MD5 or SHA-1 usage; TLS itself is provided by the host Python/aiohttp stack with modern defaults.


    Genug für ein Badge!

    Das Projekt SOLLTE mehrere kryptographische Algorithmen unterstützen, so dass Benutzer schnell wechseln können, wenn eines defekt ist. Verbreitete symmetrische Schlüsselalgorithmen umfassen AES, Twofish und Serpent. Verbreitete kryptographische Hash-Algorithmus-Alternativen umfassen SHA-2 (einschließlich SHA-224, SHA-256, SHA-384 UND SHA-512) und SHA-3. [crypto_algorithm_agility]

    All transport cryptography is delegated to the platform TLS stack (Python ssl/OpenSSL via aiohttp), which negotiates among multiple cipher suites and inherits new/updated algorithms from platform updates - the project hard-codes no protocol cryptography. The only project-level primitive is SHA-256, used for the Trust-On-First-Use SPKI pin comparison (https://github.com/NaanyaBiz/haggle/blob/main/custom_components/haggle/agl/pinning.py) and a fallback hashed unique_id; the pin check is deliberately warn-only (SECURITY.md), so a break in that hash degrades a defence-in-depth signal without blocking traffic, and the algorithm is swappable in a single helper.


    Genug für ein Badge!

    Das Projekt MUSS die Speicherung von Anmeldeinformationen (z.B. Passwörter und dynamische Token) und private kryptografische Schlüssel in Dateien, die von anderen Informationen getrennt sind (z.B. Konfigurationsdateien, Datenbanken und Protokolle), unterstützen und den Benutzern erlauben, sie ohne Code-Neukompilierung zu aktualisieren und zu ersetzen . Wenn das Projekt keine Anmeldeinformationen und private kryptographische Schlüssel verarbeitet, wählen Sie "nicht anwendbar" (N/A). [crypto_credential_agility]

    The only credential the project processes is the user's own AGL OAuth refresh token, which is stored in Home Assistant's config-entry store (.storage/core.config_entries) - a data file entirely separate from the integration code - alongside the TOFU TLS pin hashes; SECURITY.md section Storage documents this (https://github.com/NaanyaBiz/haggle/blob/main/SECURITY.md). Credentials are replaced at any time via the standard HA Reconfigure/reauth flow with no code change (pure Python, nothing is compiled), and no credentials or keys are embedded in the source (enforced by the layered gitleaks scanning).


    Genug für ein Badge!

    Die vom Projekt produzierte Software SOLLTE sichere Protokolle für alle Netzwerkkommunikationen unterstützen , wie SSHv2 oder höher, TLS1.2 oder höher (HTTPS), IPsec, SFTP und SNMPv3. Unsichere Protokolle wie FTP, HTTP, Telnet, SSLv3 oder früher, und SSHv1 SOLLTEN standardmäßig deaktiviert werden und nur aktiviert werden, wenn der/die Benutzer/in es speziell konfiguriert. Wenn die vom Projekt produzierte Software keine Netzwerkkommunikation verwendet, wählen Sie "nicht anwendbar" (N/A). [crypto_used_network]

    All network communication is HTTPS: the only outbound endpoints are https://secure.agl.com.au and https://api.platform.agl.com.au, defined in https://github.com/NaanyaBiz/haggle/blob/main/custom_components/haggle/const.py, with no plaintext-protocol code path. TLS is additionally hardened with Trust-On-First-Use SPKI pinning of both hosts (custom_components/haggle/agl/pinning.py; documented in SECURITY.md section Trust-On-First-Use TLS pinning).


    Genug für ein Badge!

    Wenn die Software, die durch das Projekt produziert wird, TLS unterstützt oder verwendet, SOLLTE sie mindestens TLS Version 1.2 verwenden. Beachten Sie, dass der Vorgänger von TLS SSL genannt wurde. Wenn die Software TLS nicht verwendet, wählen Sie "nicht anwendbar" (N/A). [crypto_tls12]

    All upstream communication is HTTPS-only to secure.agl.com.au and api.platform.agl.com.au (const.py) via aiohttp on Python >=3.14, whose default TLS context negotiates a minimum of TLS 1.2 and supports TLS 1.3; no code in the repository lowers the TLS minimum or constructs a weakened SSL context. On top of transport TLS, both hosts are Trust-On-First-Use SPKI-pinned, with mismatches surfaced to the user (https://github.com/NaanyaBiz/haggle/blob/main/custom_components/haggle/agl/pinning.py).


    Genug für ein Badge!

    Die Software, die vom Projekt produziert wird, muss, wenn es TLS unterstützt, die TLS-Zertifikatsüberprüfung standardmäßig bei der Verwendung von TLS, einschließlich auf Subresources, durchführen. Wenn die Software TLS nicht verwendet, wählen Sie "nicht anwendbar" (N/A). [crypto_certificate_verification]
    Beachten Sie, dass eine falsche TLS-Zertifikatsüberprüfung ein häufiger Fehler ist. Weitere Informationen finden Sie unter "The Most Dangerous Code in the World: Validating SSL Certificates in Non-Browser Software" von Martin Georgiev et al. und "Do you trust this application?" von Michael Catanzaro.

    All upstream communication is HTTPS via aiohttp, whose default TLS certificate verification is never disabled anywhere in the shipped code (no ssl=False, verify overrides, or CERT_NONE exist in custom_components/), and the integration additionally layers Trust-On-First-Use SPKI pinning of both AGL endpoints on top of standard verification (https://github.com/NaanyaBiz/haggle/blob/main/custom_components/haggle/agl/pinning.py; behaviour documented in SECURITY.md, 'Trust-On-First-Use TLS pinning').


    Genug für ein Badge!

    Die Software, die vom Projekt produziert wird, MUSS, wenn sie TLS unterstützt, eine Zertifikatsüberprüfung durchführen, bevor HTTP-Header mit privaten Informationen (wie z.B. sichere Cookies) versendet werden. Wenn die Software TLS nicht verwendet, wählen Sie "nicht anwendbar" (N/A). [crypto_verification_private]

    All upstream endpoints are HTTPS (const.py: secure.agl.com.au, api.platform.agl.com.au) and every request goes through aiohttp with default certificate and hostname verification - no ssl=False, CERT_NONE, or check_hostname override exists anywhere in the tree - so verification completes during the TLS handshake before any HTTP headers carrying bearer tokens are sent. On top of WebPKI verification, a Trust-On-First-Use SHA-256 SPKI pin is checked on every new connection (https://github.com/NaanyaBiz/haggle/blob/main/custom_components/haggle/agl/pinning.py); the pin layer is warn-only by documented design, but standard certificate verification always applies.


  • Sicheres Release


    Genug für ein Badge!

    Das Projekt MUSS kryptographisch unterschriebene Releases der Projektergebnisse aufzeichnen, die für weit verbreitete Verwendung gedacht sind, und es MUSS ein dokumentierter Prozess sein, der den Benutzern/innen erklärt, wie sie die öffentlichen Signaturschlüssel erhalten und die Signatur(en) überprüfen können. Der private Schlüssel für diese Signatur(en) MUSS NICHT auf der Seite(n) verwendet werden, die öffentlich zugänglich sind. Wenn Releases nicht für eine weit verbreitete Verwendung bestimmt sind, wählen Sie "nicht anwendbar" (N/A). [signed_releases]
    Die Projektergebnisse umfassen sowohl Quellcode als auch alle erzeugten Ergebnisse, falls zutreffend (z. B. ausführbare Dateien, Pakete und Container). Generierte Ergebnisse können separat vom Quellcode signiert werden. Diese DÜRFEN als signierte git-Tags (mit kryptographischen digitalen Signaturen) implementiert werden. Projekte DÜRFEN generierte Ergebnisse getrennt von Werkzeugen wie git behandeln, aber in diesen Fällen MÜSSEN die separaten Ergebnisse separat unterzeichnet werden.

    Releases are cryptographically signed twice over: release tags are ed25519-SSH-signed by the maintainer's offline key and the release workflow refuses fail-closed any tag whose signature does not verify against the committed public key file https://github.com/NaanyaBiz/haggle/blob/main/.github/allowed_signers (https://github.com/NaanyaBiz/haggle/blob/main/.github/workflows/release.yml, "Verify tag signature"); the installed artifact haggle.zip is Sigstore-attested via actions/attest-build-provenance with the .sigstore bundles and attested SPDX/CycloneDX SBOMs attached to every GitHub Release. The user verification process is documented in https://github.com/NaanyaBiz/haggle/blob/main/SECURITY.md (gh attestation verify haggle.zip --repo NaanyaBiz/haggle). No private key is on any distribution site - the tag key is held offline and Sigstore signing is keyless (ephemeral OIDC). Historical honesty: releases <= v0.4.0-beta.4 predate attestation and pre-2026-07-13 tags render Unverified, recorded as accepted risk RA-10; all releases from 2026-07 onward are signed and attested.


    Genug für ein Badge!

    Es wird empfohlen, dass in dem Versionskontrollsystem jeder wichtige Versions-Tag (ein Tag, der Teil eines Hauptrelease, eines kleineren Release, oder eines Fixes, öffentlich gemeldeten Schwachstellen, ist) kryptographisch signiert und verifizierbar ist, wie in Signed_releases. [version_tags_signed]

    Release tags are cryptographically signed: each v* tag is SSH-signed (ed25519) with the maintainer's release identity, whose public key is committed at .github/allowed_signers (https://github.com/NaanyaBiz/haggle/blob/main/.github/allowed_signers), and release.yml refuses fail-closed to build any tag whose signature does not verify against that file. I verified the latest tag (v0.4.0-beta.6) locally with git tag -v against the committed allowed_signers. Tags cut before 2026-07-13 predate the registered signing identity and are recorded as a historical exception (SECURITY.md RA-10).


  • Andere Sicherheitsissues


    Genug für ein Badge!

    Die Projektergebnisse MÜSSEN alle Eingaben aus potenziell nicht vertrauenswürdigen Quellen überprüfen, um sicherzustellen, dass sie gültig sind (eine *Allowliste*) und ungültige Eingaben ablehnen, wenn überhaupt Einschränkungen für die Daten vorliegen. [input_validation]
    Beachten Sie, dass der Vergleich der Eingabe mit einer Liste von "schlechten Formaten" (aka einer *Denylist*) normalerweise nicht ausreicht, weil Angreifer oft um eine Denyliste herumarbeiten können. Insbesondere werden Zahlen in interne Formate konvertiert und dann überprüft, ob sie zwischen ihrem Minimum und Maximum (inklusive) liegen und Textstrings werden überprüft, um sicherzustellen, dass sie gültige Textmuster haben (z.B. gültige UTF-8, Länge, Syntax, etc.). Einige Daten müssen möglicherweise "irgendetwas" (z. B. ein Datei-Uploader) sein, aber das ist typischerweise selten der Fall.

    The untrusted input surface - AGL API JSON (attacker-influenceable, since TLS pin mismatch is warn-only by design) - is processed by allowlist-style parsers in https://github.com/NaanyaBiz/haggle/blob/main/custom_components/haggle/agl/parser.py that are total over arbitrary JSON: only named fields are extracted (open-schema dict passthrough is prohibited in AGENTS.md), interval types are checked against a known set, and every numeric is clamped to a non-negative finite float via _safe_float before it can reach recorder statistics. The property is enforced by the atheris fuzz harness (tests/fuzz/fuzz_parser.py, a required PR check via fuzz.yml) and TestParserTotality in tests/test_parser.py.


    Genug für ein Badge!

    Härtungsmechanismen SOLLTEN in der Software, die das Project entwickelt, verwendet werden, so dass Softwarefehler weniger wahrscheinlich zu Sicherheitslücken führen. [hardening]
    Härtungsmechanismen können HTTP-Header enthalten wie Content Security Policy (CSP), oder Compiler-Flags (z.B. -fstack-protector), um Angriffe zu mildern, oder Compiler-Flags, um undefiniertes Verhalten zu eliminieren. Für unsere Zwecke wird das Prinzip des kleinsten Privilegs nicht als Verhärtungsmechanismus betrachtet (trotzdem ist es wichtig, aber an anderer Stelle).

    Multiple hardening layers make defects less likely to become vulnerabilities: both AGL endpoints are SPKI-pinned (TOFU) yet their JSON is still treated as attacker-influenceable - parsing is allowlist-style (no open-schema passthrough), numeric values are clamped through _safe_float so inf/NaN/negatives can never reach the recorder (https://github.com/NaanyaBiz/haggle/blob/main/custom_components/haggle/agl/parser.py), and the parser boundary is fuzz-tested with atheris on every PR plus a weekly deep run (https://github.com/NaanyaBiz/haggle/blob/main/.github/workflows/fuzz.yml). Ruff's flake8-bandit security rules gate CI, diagnostics pass a scrub layer backed by leak tests, and upstream error bodies are stripped before exceptions propagate (docs/threat-model.md sections 2-3).


    Genug für ein Badge!

    Das Projekt MUSS einen "Assurance Case" bereithalten, der rechtfertigt, wie die Sicherheitsanforderungen erfüllt werden. Der Assurance Case muss Folgendes beinhalten: eine Beschreibung des Bedrohungsmodells, eine eindeutige Identifizierung von Vertrauensgrenzen, eine Beschreibung wie sichere Designprinzipien angewendet wurden, und eine Beschreibung wie die üblichen Implementierungssicherheitsschwächen beseitige wurden. (URL erforderlich) [assurance_case]
    Ein "Assurance Case" ist ein dokumentierter Beweis, der ein überzeugendes und gültiges Argument enthällt, dass ein bestimmter Satz kritischer Ansprüche bezüglich der Eigenschaften eines Systems für eine gegebene Anwendung in einer gegebenen Umgebung hinreichend erfüllt ist ("Software Assurance Using Structured Assurance Case Models", Thomas Rhodes et al., NIST Interagency Report 7608 ). Vertrauensgrenzen sind Grenzen, in denen Daten oder Ausführung ihr Vertrauensniveau ändern, z.B. die Grenzen eines Servers in einer typischen Webanwendung. Es ist üblich, sichere Designprinzipien (wie Saltzer und Schroeer) und gemeinsame Implementierungssicherheitsschwächen (wie die OWASP Top 10 oder CWE/SANS Top 25) aufzurufen und zu zeigen, wie diesen entgegengewirkt wird. Die BadgeApp Assurance Case kann ein nützliches Beispiel sein. Dies bezieht sich auf documentation_security, documentation_architecture und implement_secure_design.

    The committed living threat model is the assurance case: it describes the system and threat model (an 18-threat STRIDE register, each threat tracked to a disposition with cited evidence), identifies five trust boundaries and the controls at each (https://github.com/NaanyaBiz/haggle/blob/main/docs/threat-model.md sections 1-5), and argues how secure design principles are applied and common implementation weaknesses countered (allowlist parsing, numeric clamping, fuzz-enforced parser totality, secret redaction backed by leak tests, plus CodeQL SAST and atheris fuzzing as required merge gates - https://github.com/NaanyaBiz/haggle/blob/main/SECURITY.md, 'Gating Policy'). The statement-level conformance map extends the argument control-by-control against the committed secure-SDLC standard (https://github.com/NaanyaBiz/haggle/blob/main/docs/compliance/conformance.md).


 Analyse 2/2 ●

  • Statische Codeanalyse


    Genug für ein Badge!

    Das Projekt MUSS mindestens ein statisches Analyse-Tool mit Regeln oder Ansätzen verwenden, um nach bekannten Schwachstellen in der analysierten Sprache oder Umgebung zu suchen, wenn es mindestens ein FLOSS-Tool gibt, das dieses Kriterium in der ausgewählten Sprache implementieren kann. [static_analysis_common_vulnerabilities]
    Statische Analysetools, die speziell dafür entwickelt wurden, nach Schwachstellen zu suchen, finden diese eher. Das heißt, dass die Verwendung von statischen Tools in der Regel helfen wird einige Probleme zu finden. Wir schlagen dies vor, aber erwarten es für das "passing" -Level-Badge nicht.

    CodeQL Python analysis runs weekly and on every PR (https://github.com/NaanyaBiz/haggle/blob/main/.github/workflows/codeql.yml) and is one of the eight required status checks enforced by the zero-bypass protect-main ruleset. CI additionally runs ruff with the flake8-bandit security rule set ("S") enabled in pyproject.toml on every PR, so two FLOSS vulnerability-oriented static analyzers gate every change.


  • Dynamische Codeanalyse


    Genug für ein Badge!

    Wenn die Projektsoftware Software mit einer speicherunsicheren Sprache (z.B. C oder C ++) enthält, MUSS mindestens ein dynamisches Werkzeug (z.B. ein Fuzzer oder ein Web-Applikationsscanner) routinemäßig in Kombination mit einem Mechanismus verwendet werden, welche Speichersicherheitsproblemen wie Puffer-Cach Überschreibe erkennen. Wenn das Projekt keine Software verwendet, die in einer speicherunsicheren Sprache geschrieben ist, wählen Sie "nicht anwendbar" (N/A). [dynamic_analysis_unsafe]
    Beispiele für Mechanismen zur Erkennung von Arbeitsspeicher Sicherheitsproblemen sind Adresse Sanitizer (ASAN) (verfügbar in GCC und LLVM), Memory Sanitizer und valgrind. Andere möglicherweise verwendete Werkzeuge sind Thread Sanitizer und Undefined Behavior Sanitizer. Weit verbreitete Assertions würden auch funktionieren.

    The shipped software is written entirely in Python, a memory-safe managed language; the tree contains no C/C++/assembly and the integration declares zero compiled runtime requirements (manifest.json "requirements": []), so no memory-unsafe code exists to instrument. (Dynamic hostile-input testing runs regardless: atheris fuzzing of the parser trust boundary on every PR plus weekly deep runs, https://github.com/NaanyaBiz/haggle/blob/main/.github/workflows/fuzz.yml.)



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 NaanyaBiz und die OpenSSF Best Practices Badge-Mitwirkenden als Urheber.

Projekt-Badge-Eintrag im Besitz von: NaanyaBiz.
Eintrag erstellt: 2026-07-12 09:21:52 UTC, zuletzt aktualisiert: 2026-07-14 20:21:06 UTC. Letztes erreichtes Badge: 2026-07-12 09:34:54 UTC.