GNU make

Projekte, die den nachfolgenden Best Practices folgen, können sich freiwillig selbst zertifizieren und zeigen, dass sie einen Core-Infrastruktur-Initiative (CII) 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 "#" 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: Badgelevel für Projekt 249 ist passing Hier ist, wie man es einbetten:
Sie können Ihren Badgestatus anzeigen, indem Sie folgendes in Ihre Markdown-Datei einbetten:
[![CII Best Practices](https://bestpractices.coreinfrastructure.org/projects/249/badge)](https://bestpractices.coreinfrastructure.org/projects/249)
oder indem Sie folgendes in Ihr HTML einbetten:
<a href="https://bestpractices.coreinfrastructure.org/projects/249"><img src="https://bestpractices.coreinfrastructure.org/projects/249/badge"></a>


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



 Grundlagen 0/5

  • Identifizierung

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

    The make utility updates files that are derived from other files. A typical case is the generation of executables and other non-source files of a program from the program's source files.

  • Prerequisites


    Nicht genug für ein Badge.

    The project MUST achieve a silver level badge. [achieve_silver]

  • Projektüberwachung


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

    Das Projekt MUSS einen "Busfaktor" von 2 oder mehr haben. (URL erforderlich) [bus_factor]
    A "bus factor" (aka "truck factor") is the minimum number of project members that have to suddenly disappear from a project ("hit by a bus") before the project stalls due to lack of knowledgeable or competent personnel. The truck-factor tool can estimate this for projects on GitHub. For more information, see Assessing the Bus Factor of Git Repositories by Cosentino et al.


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

    Das Projekt muss mindestens zwei bedeutende, nicht assoziierte Mitwirkende haben. (URL erforderlich) [contributors_unassociated]
    Contributors are associated if they are paid to work by the same organization (as an employee or contractor) and the organization stands to benefit from the project's results. Financial grants do not count as being from the same organization if they pass through other organizations (e.g., science grants paid to different organizations from a common government or NGO source do not cause contributors to be associated). Someone is a significant contributor if they have made non-trivial contributions to the project in the past year. Examples of good indicators of a significant contributor are: written at least 1,000 lines of code, contributed 50 commits, or contributed at least 20 pages of documentation.

  • Andere


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

    The project MUST include a license statement in each source file. This MAY be done by including the following inside a comment near the beginning of each file: SPDX-License-Identifier: [SPDX license expression for project]. [license_per_file]
    This MAY also be done by including a statement in natural language identifying the license. The project MAY also include a stable URL pointing to the license text, or the full license text. Note that the criterion license_location requires the project license be in a standard location. See this SPDX tutorial for more information about SPDX license expressions. Note the relationship with copyright_per_file, whose content would typically precede the license information.

 Verbesserungs/Nacharbeits -Kontrolle 0/4

  • Öffentliches Versionskontroll Source Repository


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

    Das Source-Repository des Projekts MUSS eine gemeinsame genutzte Versionskontrollsoftware (z. B. git oder mercurial) verwenden. [repo_distributed]
    Git is not specifically required and projects can use centralized version control software (such as subversion) with justification.

    Warnung: Erfordert eine längere Begründung.



    Unbekannte erforderliche Informationen, nicht 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]
    This identification is typically done by marking selected issues in an issue tracker with one or more tags the project uses for the purpose, e.g., up-for-grabs, first-timers-only, "Small fix", microtask, or IdealFirstBug. These new tasks need not involve adding functionality; they can be improving documentation, adding test cases, or anything else that aids the project and helps the contributor understand more about the project.


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

    The project MUST require two-factor authentication (2FA) for developers for changing a central repository or accessing sensitive data (such as private vulnerability reports). This 2FA mechanism MAY use mechanisms without cryptographic mechanisms such as SMS, though that is not recommended. [require_2FA]


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

    The project's two-factor authentication (2FA) SHOULD use cryptographic mechanisms to prevent impersonation. Short Message Service (SMS) based 2FA, by itself, does NOT meet this criterion, since it is not encrypted. [secure_2FA]
    A 2FA mechanism that meets this criterion would be a Time-based One-Time Password (TOTP) application that automatically generates an authentication code that changes after a certain period of time. Note that GitHub supports TOTP.

 Qualität 0/7

  • Programmierstil


    Unbekannte erforderliche Informationen, nicht 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]
    Siehe auch two_person_review und contribution_requirements.


    Unbekannte erforderliche Informationen, nicht 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]

  • Produktivsystem


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

    The project MUST have a reproducible build. If no building occurs (e.g., scripting languages where the source code is used directly instead of being compiled), select "not applicable" (N/A). (URL erforderlich) [build_reproducible]
    Eine reproduzierbares Build bedeutet, dass mehrere Parteien den Prozess der Generierung von Informationen aus Quelldateien unabhängig voneinander wiederholen und genau das gleiche Bit-für-Bit-Ergebnis erhalten können. In manchen Fällen kann dies dadurch gelöst werden, dass man eine Sortierreihenfolge erzwingt. JavaScript-Entwickler können erwägen npm shrinkwrap und webpack OccurenceOrderPlugin zu verwenden. GCC und clang Benutzer könnten die Option -frandom-seed nützlich finden. Die Buildumgebung (einschließlich des Toolsets) kann oft für externe Teilnehmer definiert werden, indem der kryptografische Hash eines bestimmten Containers oder einer virtuellen Maschine angegeben wird, die sie für das Kompilieren verwenden können. Das Reproducible Builds Projekt hat eine Dokumentation, wie dies erreicht werden kann.

  • Automatisierte Test-Suite


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

    Eine Test-Suite MUSS in einer standardisierten Weise für diese Programmiersprache anrufbar sein. (URL erforderlich) [test_invocation]
    Zum Beispiel, "make check", "mvn test", oder "rake test".

    Warnung: URL erforderlich, aber keine URL gefunden.



    Nicht genug für ein Badge.

    The project MUST implement continuous integration, where new or changed code is frequently integrated into a central code repository and automated tests are run on the result. (URL erforderlich) [test_continuous_integration]
    In den meisten Fällen bedeutet dies, dass jeder Entwickler, der Vollzeit auf dem Projekt arbeitet, mindestens täglich integriert.


    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.

    The project MUST have FLOSS automated test suite(s) that provide at least 80% branch coverage if there is at least one FLOSS tool that can measure this criterion in the selected language. [test_branch_coverage80]

 Sicherheit 2/5

  • Verwende grundlegend gute kryptographische Praktiken

    Beachte, dass einige Software keine kryptographischen Mechanismen verwenden muss.

    Genug für ein Badge!

    The software produced by the project MUST support secure protocols for all of its network communications, such as SSHv2 or later, TLS1.2 or later (HTTPS), IPsec, SFTP, and SNMPv3. Insecure protocols such as FTP, HTTP, telnet, SSLv3 or earlier, and SSHv1 MUST be disabled by default, and only enabled if the user specifically configures it. If the software produced by the project does not support network comunications, select "not applicable" (N/A). [crypto_used_network]


    Genug für ein Badge!

    The software produced by the project MUST, if it supports or uses TLS, support at least TLS version 1.2. Note that the predecessor of TLS was called SSL. If the software does not use TLS, select "not applicable" (N/A). [crypto_tls12]

  • Gesicherte Zustellung gegen Man-in-the-Middle (MITM) Angriffe


    Nicht genug für ein Badge.

    The project website, repository (if accessible via the web), and download site (if separate) MUST include key hardening headers with nonpermissive values. (URL erforderlich) [hardened_site]
    Note that GitHub is known to meet this. Sites such as https://securityheaders.io/ can quickly check this. The key hardening headers are: Content Security Policy (CSP), HTTP Strict Transport Security (HSTS), X-Content-Type-Options (as "nosniff"), X-Frame-Options, and X-XSS-Protection.

    X-Content-Type-Options was not set to "nosniff".


  • Andere Sicherheitsissues


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

    The project MUST have performed a security review within the last 5 years. This review MUST consider the security requirements and security boundary. [security_review]
    This MAY be done by the project members and/or an independent evaluation. This evaluation MAY be supported by static and dynamic analysis tools, but there also must be human review to identify problems (particularly in design) that tools cannot detect.


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

    Hardening mechanisms MUST be used in the software produced by the project so that software defects are less likely to result in security vulnerabilities. (URL erforderlich) [hardening]
    Hardening mechanisms may include HTTP headers like Content Security Policy (CSP), compiler flags to mitigate attacks (such as -fstack-protector), or compiler flags to eliminate undefined behavior. For our purposes least privilege is not considered a hardening mechanism (least privilege is important, but separate).

 Analyse 1/2

  • Dynamische Codeanalyse


    Nicht genug für ein Badge.

    The project MUST apply at least one dynamic analysis tool to any proposed major production release of the software produced by the project before its release. [dynamic_analysis]
    Ein dynamisches Analyse-Tool untersucht die Software, indem es sie mit bestimmten Eingaben ausführt. Beispielsweise DARF das Projekt ein Fuzzing-Tool verwenden (z.B. American Fuzzy Lop) oder einen Web Application Scanner (z.B. OWASP ZAP oder w3af). In einigen Fällen ist das OSS-Fuzz Projekt bereit, Fuzz-Tests auf Ihr Projekt anzuwenden. Für die Zwecke dieses Kriteriums muss das dynamische Analyse-Tool die Eingaben in irgendeiner Weise variieren, um nach verschiedenen Arten von Problemen zu suchen oder eine automatisierte Test-Suite mit mindestens 80% Abdeckung. Die Wikipedia-Seite zur dynamischen Analysen und die OWASP Seite auf Fuzzing nennen einige dynamische Analyse-Tools. Das Analyse-Tool(s) DARF für der Suche nach Sicherheitslücken eingesetzt werden, aber das ist nicht erforderlich.

    No dynamic analysis tool found.



    Gerade genug für ein Badge.

    The project SHOULD include many run-time assertions in the software it produces and check those assertions during dynamic analysis. [dynamic_analysis_enable_assertions]

    No dynamic analysis tool found.



Die Daten sind unter der Creative Commons Attribution 3.0-Lizenz (CC-BY-3.0) verfügbar, bereitgestellt von der Core Infrastructure Initiative unter den Nutzungsbedingungen. Es ist allen erlaubt, die Daten zu teilen und anzupassen, müssen aber einen angemessene Hinweis auf den Urheber geben. Bitte geben Sie als Urheber Paul Smith und die CII Best Practices Badge Mitwirkenden an.

Projekt Badge Eintrag im Besitz von: Paul Smith.
Eintrag erstellt auf 2016-07-16 15:17:58 UTC, zuletzt aktualisiert auf 2017-02-08 14:28:59 UTC. Letztes erreichtes Badge auf 2017-02-08 14:28:59 UTC.

Zurück