BRL-CAD

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)). 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 66 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/66/badge)](https://bestpractices.coreinfrastructure.org/projects/66)
oder indem Sie folgendes in Ihr HTML einbetten:
<a href="https://bestpractices.coreinfrastructure.org/projects/66"><img src="https://bestpractices.coreinfrastructure.org/projects/66/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.

    BRL-CAD is an open source solid modeling system with interactive 3D geometry editing, high-performance ray tracing for rendering, hybrid representation geometry conversion, and processing for geometric analysis.

  • 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. [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. [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 1/4

  • Öffentliches Versionskontroll Source Repository


    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.

    BRL-CAD uses both centralized and decentralized development, intentionally using centralized (SVN on Sourceforge) for primary development where we have strict validation and verification (V&V) requirements and a desire for enforced developer interaction inherent with the centralized model. We used decentralized (GIT on GitHub) for all our other work including website infrastructure, model management, and experimental projects.



    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. [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 2/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


    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.

    Reproducible builds are not currently supported as timestamps are intentionally embedded into all libraries and (by extension) all binaries.


  • Automatisierte Test-Suite


    Genug für ein Badge!

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


    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. [test_continuous_integration]
    In den meisten Fällen bedeutet dies, dass jeder Entwickler, der Vollzeit auf dem Projekt arbeitet, mindestens täglich integriert.

    BuildBot is used for CI. The "distcheck-full" target in BRL-CAD's build system are run on BRL-CAD's central (SVN) code repository.



    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 3/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]

    There is un unencrypted network communication with an encrypted equivalent.



    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]

    There is no SSL / TLS communication in BRL-CAD.


  • 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.

    SourceForge supports X-Content-Type-Options nosniff. GitHub supports multiple. Project website and download site support none.


  • 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.


    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. [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).

    BRL-CAD extensively uses compiler flags (including -fstack-protector) and static analysis tools (Coverity) to minimize or eliminate undefined behavior. BRL-CAD has extensive testing strategies in place to detect security issues and unexpected behavior.


 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.

    Dynamic analysis is not currently part of BRL-CAD's release repertoire, but several tools are used periodically and have been used in the past including gcov, valgrind, dmalloc, and purify.



    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]

    Dynamic analysis is not currently part of BRL-CAD's release repertoire, but several tools are used periodically and have been used in the past including gcov, valgrind, dmalloc, and purify.



This data is available under the Creative Commons Attribution version 3.0 license (CC-BY-3.0) per the Core Infrastructure Initiative terms of use. All are free to share and adapt the data, but must give appropriate credit. Please credit Christopher Sean Morrison and the CII Best Practices badge contributors.

Projekt Badge Eintrag im Besitz von: Christopher Sean Morrison.
Eintrag erstellt auf 2016-02-16 19:22:11 UTC, zuletzt aktualisiert auf 2016-08-26 22:10:07 UTC. Letztes erreichtes Badge auf 2016-08-22 03:14:40 UTC.

Zurück