BIND 9

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.

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 299 ist passing So können Sie ihn einbetten:

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

        

 Grundlagen 3/5 ●

  • Identifizierung

    BIND is open source software that implements the Domain Name System (DNS) protocols for the Internet.

  • Voraussetzungen


    Nicht genug für ein Badge.

    Das Projekt MUSS ein Silber-Siegel erreichen. [achieve_silver]

  • Projektüberwachung


    Genug für ein Badge!

    Das Projekt MUSS einen "Busfaktor" von 2 oder mehr haben. (URL erforderlich) [bus_factor]

    https://gitlab.isc.org/isc-projects/bind9/graphs/master We have a team of active committers. The gitlab graph actually understates contributors because we have fewer authorized committers.


    Unbekannte erforderliche Informationen, nicht genug für ein Badge.

    Das Projekt MUSS mindestens zwei unabhängige bedeutende Entwickler haben. (URL erforderlich) [contributors_unassociated]

  • Andere


    Genug für ein Badge!

    Das Projekt MUSS eine Lizenzerklärung in jeder Quelldatei enthalten. Dies DARF als Kommentar relativ am Anfangs jeder Datei einfügt sein: SPDX-License-Identifier: [SPDX license expression for project]. [license_per_file]

    we have this header in each file: - Copyright (C) Internet Systems Consortium, Inc. ("ISC") - - This Source Code Form is subject to the terms of the Mozilla Public - License, v. 2.0. If a copy of the MPL was not distributed with this - file, you can obtain one at https://mozilla.org/MPL/2.0/. - - See the COPYRIGHT file distributed with this work for additional - information regarding copyright ownership. -->

    and this at the top level of our repo https://gitlab.isc.org/isc-projects/bind9/-/blob/main/LICENSE

    and of course, it is also mentioned in the readme...


  • Öffentliches Versionskontroll-Source-Repository


    Genug für ein Badge!

    Das Source-Repository des Projekts MUSS eine geläufige, verteilte Versionskontrollsoftware (z. B. git oder mercurial) verwenden. [repo_distributed]

    We use a privately hosted instance of the open source Gitlab.


    Genug für ein Badge!

    Das Projekt MUSS eindeutig kleine Aufgaben identifizieren, die von neuen oder gelegentlichen Mitwirkenden durchgeführt werden können. (URL erforderlich) [small_tasks]

    We have a number of such items identified by the label "patches welcome" https://gitlab.isc.org/isc-projects/bind9/-/issues/?sort=created_date&state=opened&label_name%5B%5D=Patches%20Welcome&first_page_size=20


    Genug für ein Badge!

    Das Projekt MUSS eine Zwei-Faktor-Authentifizierung (2FA) für Entwickler haben, um ein zentrales Repository zu wechseln oder auf sensible Daten zugreifen zu können (z. B. private Schwachstellen-Berichte). Dieser 2FA-Mechanismus DARF Mechanismen ohne kryptographische Mechanismen wie SMS verwenden, obwohl dies nicht empfohlen wird. [require_2FA]

    We require 2FA for developers, maintainers and owners. https://gitlab.isc.org/isc-projects/bind9/-/project_members


    Genug für ein Badge!

    Die Zwei-Faktor-Authentifizierung des Projekts (2FA) SOLLTE Kryptographie-Mechanismen verwenden, um Identitätswechsel zu verhindern. Short-Message-Service-/SMS-basierte 2FAs allein erfüllen dieses Kriterium nicht, da sie nicht verschlüsselt sind. [secure_2FA]

    We use TOTP: https://docs.gitlab.com/ee/user/profile/account/two_factor_authentication.html


  • Programmierstil


    Genug für ein Badge!

    Das Projekt MUSS seine Code-Review-Anforderungen dokumentieren, einschließlich, wie Code-Überprüfung durchgeführt wird, was überprüft werden muss und was erforderlich ist, um akzeptabel zu sein. (URL erforderlich) [code_review_standards]

    https://gitlab.isc.org/isc-projects/bind9/-/blob/main/doc/dev/dev.md#reviews This is also explained and linked in the Contributing document https://gitlab.isc.org/isc-projects/bind9/-/blob/main/CONTRIBUTING.md

    Our code review process includes a list of things to check. In brief, the developer creates a branch for the work to be committed. When the work is ready, he/she creates a merge request marked with the label 'review' and unassigns themselves to the issue. Someone else on the team takes the issue and reviews the code, providing comments via Gitlab, and then they remove the review label and reassign back to the original author. The original author then addresses the comments, which could include explaining why they did something, or - most often - by modifying the code or documentation.


    Genug für ein Badge!

    Das Projekt MUSS mindestens 50% aller vorgeschlagenen Änderungen vor dem Release durch eine andere Person als den Autor überprüfen, um festzustellen, ob es sich um eine sinnvolle Änderung handelt und frei von bekannten Problemen ist, die gegen die Freigabe der Änderung sprechen würden [two_person_review]

    https://gitlab.isc.org/isc-projects/bind9/-/blob/main/doc/dev/dev.md#reviews This is also explained and linked in the Contributing document https://gitlab.isc.org/isc-projects/bind9/-/blob/main/CONTRIBUTING.md

    Our code review process includes a list of things to check. In brief, the developer creates a branch for the work to be committed. When the work is ready, he/she creates a merge request marked with the label 'review' and unassigns themselves to the issue. Someone else on the team takes the issue and reviews the code, providing comments via Gitlab, and then they remove the review label and reassign back to the original author. The original author then addresses the comments, which could include explaining why they did something, or - most often - by modifying the code or documentation.


  • Produktivsystem


    Genug für ein Badge!

    Das Projekt MUSS ein reproducible Build haben. Wenn kein Building erforderlich ist (z. B. Skriptsprachen, in denen der Quellcode direkt verwendet wird, anstatt kompiliert zu werden), wählen Sie "nicht anwendbar" (N/A). (URL erforderlich) [build_reproducible]

    BIND is packaged in several operating systems that do provide reproducible builds (Debian, Arch Linux, SUSE, etc). https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/bind9.html


  • Automatisierte Test-Suite


    Genug für ein Badge!

    Eine Test-Suite MUSS in einer standardisierten Weise für diese Programmiersprache anrufbar sein. (URL erforderlich) [test_invocation]

    https://gitlab.isc.org/isc-projects/bind9/-/blob/main/doc/dev/dev.md#testing Our tests can be executed using "make check".


    Genug für ein Badge!

    Das Projekt MUSS eine kontinuierliche Integration implementieren, bei der neue oder geänderte Codes häufig in ein zentrales Code-Repository integriert werden und automatisierte Tests auf dem Ergebnis durchgeführt werden. (URL erforderlich) [test_continuous_integration]

    We use continuous integration running in our Gitlab instance. https://gitlab.isc.org/isc-projects/bind9/-/pipelines


    Unbekannte erforderliche Informationen, nicht genug für ein Badge.

    Das Projekt MUSS automatisierte FLOSS-Test-Suite(n) einsetzen, die mindestens 90% der Befehle abdecken, wenn es mindestens ein FLOSS-Tool gibt, das dieses Kriterium in der ausgewählten Programmiersprache messen kann. [test_statement_coverage90]

    Unbekannte erforderliche Informationen, nicht genug für ein Badge.

    Das Projekt MUSS automatisierte FLOSS-Test-Suite(s) mit mindestens 80% Zweig-Abdeckung haben, wenn es mindestens ein FLOSS-Tool gibt, das dieses Kriterium in der ausgewählten Sprache messen kann. [test_branch_coverage80]

  • 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 vom Projekt produzierte Software MUSS 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 MÜSSEN 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]

    We support several encrypted DNS protocols, including DNS over TLS (aka DOT).


    Genug für ein Badge!

    Die Projektsoftware MUSS, wenn sie TLS unterstützt oder verwendet, mindestens TLS Version 1.2 unterstützen. 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]

    We support TLS. https://bind9.readthedocs.io/en/latest/reference.html#namedconf-statement-tls


  • Gesicherte Zustellung gegen Man-in-the-Middle-/MITM-Angriffe


    Nicht genug für ein Badge.

    Die Projekt-Website, das Repository (wenn über das Internet zugänglich) und die heruntergelandenen Seiten (falls separat) MÜSSEN Key-Hardening-Headers mit nichtpermeablen Werten enthalten. (URL erforderlich) [hardened_site]

    X-Content-Type-Options was not set to "nosniff". // One or more of the required security hardening headers is missing.


  • Andere Sicherheitsissues


    Genug für ein Badge!

    Das Projekt MUSS innerhalb der letzten 5 Jahre eine Sicherheitsüberprüfung durchgeführt haben. Diese Überprüfung muss die Sicherheitsanforderungen und die Sicherheitsgrenze berücksichtigen. [security_review]

    We had an external audit performed by x.41-DE in 2023: https://www.isc.org/blogs/2024-bind-audit/


    Genug für ein Badge!

    Härtungsmechanismen müssen in der Projektsoftware verwendet werden, so dass Softwarefehler weniger wahrscheinlich zu Sicherheitslücken führen. (URL erforderlich) [hardening]

    we do enable hardening in C complier:

    https://gitlab.isc.org/isc-projects/bind9/-/blob/main/configure.ac?ref_type=heads#L143

    See https://www.redhat.com/en/blog/enhance-application-security-fortifysource for what this does.


  • Dynamische Codeanalyse


    Genug für ein Badge!

    Das Projekt MUSS mindestens ein dynamisches Analyse-Tool auf jeden kommenden Hauptproduktionsrelease der Software, die durch das Projekt vor seiner Freigabe produziert wird, anwenden. [dynamic_analysis]

    we have implemented AFL fuzzing


    Genug für ein Badge!

    Das Projekt SOLLTE viele Laufzeit-Assertionen in der Projektsoftware enthalten und diese Assertionen während der dynamischen Analyse überprüfen. [dynamic_analysis_enable_assertions]

    It is often suggested that we have TOO MANY run-time asssertions....



This data is available under the Community Data License Agreement – Permissive, Version 2.0 (CDLA-Permissive-2.0). This means that a Data Recipient may share the Data, with or without modifications, so long as the Data Recipient makes available the text of this agreement with the shared Data. Please credit Vicky Risk and the OpenSSF Best Practices badge contributors.

Projekt-Badge-Eintrag im Besitz von: Vicky Risk.
Eintrag erstellt: 2016-08-15 17:41:15 UTC, zuletzt aktualisiert: 2025-02-12 17:43:44 UTC. Letztes verlorenes Badge: 2023-07-11 15:31:20 UTC. Letztes erreichtes Badge: 2023-07-11 15:34:03 UTC.

Zurück