LinuxTV

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

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

        

 Grundlagen 13/13

  • Identifizierung

    The LinuxTV community develops and maintains the Linux Kernel Media Subsystems and several userspace libraries and applications.

    The Linux Kernel Media Subsystems provide support for devices like webcams, streaming capture and output, analog TV, digital TV, AM/FM radio, Sofware Digital Radio (SDR), remote controllers and encoders/decoders for compressed video formats. It offers native support for a large number of drivers for commonly available PCI cards and USB devices, but the subsystems are also targeted towards Linux based set-top-boxes and embedded devices like mobile phones.

    The main goal is to develop the Linux Kernel media subsystem.

    We also develop a series of userspace applications, tools and libraries: v4l-utils, ZBar, Kaffeine, XawTv, TVtime, Camorama, EDID decode, Digital TV tables. While several applications are used primarely by end users, for the developers of the project, their primary goal is to be able to test the Kernel development and to provide userspace libraries to enhance the media subsystem support.

    Welche Programmiersprache wird verwendet, um das Projekt umzusetzen?
  • Grundlegende Informationen auf der Projektwebseite


    Die Projekt-Website MUSS prägnant beschreiben, was die Software tut (welches Problem löst sie?). [description_good]

    Project goals is clearly at the main page; each git tree we host have their own short descriptions. We maintain a Wiki page with all project details.



    Die Projekt-Website MUSS Informationen darüber enthalten, wie Feedback erhalten und gegeben werden kann (als Fehlerberichte oder Verbesserungsvorschläge), und wie man zur Softwareentwicklung beitragen kann. [interact]

    The wiki pages have a developer's section explaining it: https://linuxtv.org/wiki/index.php/Developer_section There are also ReST documentation at the Kernel tree with the Linux Kernel documentation, with applies to all the Kernel development, including the media subsystem.



    Die Informationen darüber, wie jemand beitragen kann, MÜSSEN den Prozess erklären (z.B. wie werden Pull-Requests verwendet?) (URL erforderlich) [contribution]

    The contribution process is explained at https://linuxtv.org/wiki/index.php/Developer_section This project doesn't use GitHub. Instead, discussions, patches and pull requests goes via a mailing list (linux-media@vger.kernel.org), for all trees we host (both kernelspace and userspace).



    Die Informationen darüber, wie jemand beitragen können, SOLLTEN die Anforderungen für akzeptable Beiträge (z. B. einen Hinweis auf jeden erforderlichen Programmierstandard) enthalten. (URL erforderlich) [contribution_requirements]

    We adopt Kernel coding style: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/SubmittingPatches That's also described at the Wiki.


  • FLOSS-Lizenz

    Unter welcher Lizenz/welchen Lizenzen ist das Projekt veröffentlicht?



    Die vom Projekt entwickelte Software MUSS als FLOSS lizensiert veröffentlicht sein. [floss_license]

    GPL-2.0-only The GPL-2.0-only license is approved by the Open Source Initiative (OSI).



    Es wird EMPFHOLEN, dass alle erforderlichen Lizenz(en) für die vom Projekt entwickelte Software von der Open Source Initiative (OSI) anerkannt werden. [floss_license_osi]

    The main license we use is GPL-2.0-only for the Linux Kernel. Userspace libraries and tools developed by the project are under LGPL and GPL. Some documentation are under GFDL with no invariant sections. Both GPL and LGPL are approved OSS licenses. The GPL-2.0-only license is approved by the Open Source Initiative (OSI).



    Das Projekt MUSS die Lizenz(en) seiner Erzeugnisse an einem üblichen Ort in ihrem Quell-Repository veröffentlichen. (URL erforderlich) [license_location]

    At libraries/tools, license is at COPYING files; at the Linux Kernel, the COPYING file points to the location of the SPDX licenses that apply: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/COPYING.


  • Dokumentation


    Das Projekt MUSS eine grundlegende Dokumentation für die vom Projekt entwickelte Software liefern. [documentation_basics]

    There is a comprehensive set of documentation at: https://linuxtv.org/docs.php



    Das Projekt MUSS Referenzdokumentationen enthalten, die externe Schnittstellen (beides, Eingabe und Ausgabe) der vom Projekt entwickelten Software beschreiben. [documentation_interface]

    There is a comprehensive set of documentation at: https://linuxtv.org/docs.php


  • Andere


    Die Projekt-Seiten (Website, Repository und Download-URLs) MÜSSEN HTTPS mit TLS unterstützen. [sites_https]

    Given only https: URLs.



    Das Projekt MUSS einen oder mehrere Mechanismen zur Diskussion (einschließlich der vorgeschlagenen Änderungen und Issues) haben, die durchsuchbar sind, bei denen Nachrichten und Themen durch URL adressiert werden, neue Personen an einigen der Diskussionen teilnehmen können und keine lokale Installation von proprietärer Software erfordern. [discussion]

    Most discussions happen at the open public mailing list (linux-media@vger.kernel.org). We also maintain #v4l and #linuxtv channels at irc.freenode.net.



    Das Projekt SOLLTE Dokumentationen in englischer Sprache zur Verfügung stellen und in der Lage sein, Fehlerberichte und Kommentare zum Code in Englisch zu akzeptieren. [english]

    English is the preferred language, used on our channels.



    The project MUST be maintained. [maintained]


(Erweitert) Welche anderen Benutzer haben zusätzliche Rechte zum Bearbeiten dieses Badge-Antrags? Derzeit: []



  • Öffentliches Versionskontroll-Source-Repository


    Das Projekt MUSS ein versiongesteuertes Quell-Repository haben, das öffentlich lesbar ist und eine URL hat. [repo_public]

    We use Git for all sub-projects.



    Das Quell-Repository des Projekts MUSS verfolgen, welche Änderungen vorgenommen wurden, wer die Änderungen vorgenommen hat und wann die Änderungen vorgenommen wurden. [repo_track]

    We use Git for all sub-projects.



    Um eine kollaborative Überprüfung zu ermöglichen, MUSS das Quell-Repository des Projekts Zwischenversionen für die Überprüfung zwischen Releases enthalten. Es DARF NICHT nur endgültige Veröffentlichungen enthalten. [repo_interim]

    Development is continuous using git. Patches contain incremental changes.



    Es ist EMPFOHLEN, dass eine gemeinsame genutzte Versionskontrollsoftware (z.B. git oder mercurial) für das Source-Repository des Projekts verwendet wird. [repo_distributed]

    We use Git for all sub-projects.


  • Einzigartige Versionsnummerierung


    Die für Endbenutzer vorgesehenen Projektergebnisse MÜSSEN eine eindeutige Versionskennung für jede Freigabe haben. [version_unique]

    We use formal release versions.



    Es ist EMPFHOLEN, dass ein Semantic Versioning (SemVer) oder Calendar Versioning (CalVer) Versionsnummerierungsformat für Releases verwendet wird. Es ist EMPFHOLEN, dass Anwender des CalVer Formates auch die Micro Ebene mit angeben. [version_semver]

    Most of the trees we use use SemVer. Linux Kernel doesn't use, neither does XawTv, due to historical reasons.



    Es wird erwartet, dass Projekte jedes Release innerhalb ihres Versionskontrollsystems identifizieren. Zum Beispiel wird erwartet, dass die Projekte, die git verwenden, jedes Release mit git-Tags identifizieren. [version_tags]

    We have tags for every release stored at the git repository.


  • Versionshinweise


    Das Projekt MUSS zu jedem Update Releasenotes enthalten, die eine lesbare Zusammenfassung der wichtigsten Änderungen der Version sind, damit Benutzer/innen sehen können, ob sie aktualisieren sollten und was die Auswirkungen des Updades sind. Die Releasenotes DÜRFEN NICHT die Rohausgabe eines Versionskontrollprotokolls sein (z. B. die "git log"-Befehlsergebnisse sind keine Releasenotes). Für Projekte, deren Ergebnisse nicht für die Wiederverwendung an mehreren Standorten bestimmt sind (z. B. die Software für eine einzelne Website oder Dienstleistung) und eine kontinuierliche Lieferung verwenden, können Sie "N/A" auswählen. (URL erforderlich) [release_notes]

    Kernel community maintain release notes on separate sites, like lwn.net and kernel-newbies: https://kernelnewbies.org/LinuxVersions

    On other sub-projects, we maintain a ChangeLog file summarizing the changes.



    Die Releasenotes MÜSSEN jede öffentlich bekannte Laufzeit-Sicherheitslücke mit einer CVE-Zuweisung oder Ähnlichem kennzeichnen, die in der aktuellen veröffentlichten Version behoben sind. Dieses Kriterium darf als nicht anwendbar (N/A) markiert werden, wenn Benutzer typischerweise nicht selbst die Software aktualisieren. Diese Kirterium trifft nur auf die Projektergebnisse zu, nicht auf Abhängikeiten. Wenn keine Releasenotes vorhanden sind oder keine öffentlich bekannten Sicherheitslücken bekannt sind, wählen Sie (N/A). [release_notes_vulns]

    Kernel CVE are propely documented. For other sub-projects, we never got a CVE assignment.


  • Bug-Report-Prozess


    Das Projekt muss einen Prozess für Benutzer enthalten, um Fehlerberichte zu senden (z. B. mit einem Issue-Tracker oder eine Mailing-Liste). (URL erforderlich) [report_process]

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

    For the Kernel, we use: https://bugzilla.kernel.org. Other sub-projects use GitHub; Kaffeine uses http://bugs.kde.org/.



    Das Projekt MUSS eine Mehrheit der in den letzten 2-12 Monaten eingereichten Fehlerberichte berücksichtigen; Die Antwort muss keine Korrektur enthalten. [report_responses]

    We answer to bug reports via mailing list.



    Das Projekt SOLLTE auf eine Mehrheit (>50%) der Verbesserungsvorschläge in den letzten 2-12 Monaten (einschließlich) reagieren. [enhancement_responses]

    We accept enhancements in the form of patches submitted by interested parties. As this is related to hardware, and the number of media hardware is pretty big, enhancement development require developers to have the specific hardware in hands. We are not able to acquire all hardware we would need for hardware-specific development.



    Das Projekt MUSS ein öffentlich zugängliches Archiv für Berichte und Antworten für die spätere Suche haben. (URL erforderlich) [report_archive]

    There are several mirrors for the mailing lists. The main one is at: https://lore.kernel.org/linux-media/ we also maintain logs for the IRC channel discussions.


  • Anfälligkeits-Prozessbericht


    Das Projekt MUSS den Prozess für die Meldung von Schwachstellen auf der Projektseite veröffentlichen. (URL erforderlich) [vulnerability_report_process]

    The only vulnerabilities we ever got are related to the Kernel. There's a documented process about reporting security issues to the Linux Kernel: https://www.kernel.org/doc/html/latest/admin-guide/security-bugs.html



    Falls das Projekt einen Kanal zur Übertragung von Schwachstellen besitzt, dann MUSS diese Informationsübertragung privat ablaufen. (URL erforderlich) [vulnerability_report_private]

    The only vulnerabilities we ever got are related to the Kernel. There's a documented process about reporting security issues to the Linux Kernel: https://www.kernel.org/doc/html/latest/admin-guide/security-bugs.html



    Das Projekts MUSS mindestens binnen 14 Tagen, auf jeden in den letzten 6 Monaten erhaltenen Anfälligkeitsbericht, reagieren. [vulnerability_report_response]

    Most of the time, we don't receive any vulnerability to the media subsystem. Last year, we got only one CVE and one private report at the beginning of 2018. Once we received the reports, they were promptly solved.


  • Produktivsystem


    Falls die vom Projekt entwickelte Software vor Benutzung kompiliert werden muss, MUSS das Projekt ein funktionierendes Buildsystem bereitstellen, das den Quellcode automatisch in Software übersetzt. [build]

    Kernel just uses standard Makefiles; other projects use cmake or autotools.



    Es ist EMPFHOLEN, dass gewöhnliche Werkzeuge zum Kompilieren von Software benutzt wird. [build_common_tools]

    Kernel just uses standard Makefiles; other projects use cmake or autotools.



    Das Projekt SOLLTE allein mit FLOSS-Werkzeugen gebaut werden können. [build_floss_tools]

    Everything is buildable with standard FLOSS tools like GNU c and glibc. No need to use proprietary build tools.


  • Automatisierte Test-Suite


    Das Projekt MUSS mindestens eine automatisierte Test-Suite verwenden, die öffentlich als FLOSS veröffentlicht wird (diese Test-Suite kann als separates FLOSS-Projekt gepflegt werden). Das Project MUSS verständlich zeigen oder dokumentieren, wie die Test-Suite ausgeführt wird (z. B. durch ein Continuous Integration (CI) Script oder als Dokumentation in Dateien, wie z. B. BUILD.md, README.md oder CONTRIBUTING.md). [test]

    The Linux Kernel has several CI tools. One of them is at: https://kernelci.org/ We also have apps to check the compliance with hardware drivers with media APIs. We're in the process of adding CI for other sub-projects.



    Eine Test-Suite SOLLTE in einer üblichen Weise für diese Programmiersprache aufrufbar sein. [test_invocation]

    As most of the stuff is hardware-dependent, there's no way to implement unit tests. So, we designed a test suite to check if the Kernel drivers are properly implementing the media APIs. The main tool is v4l2-compliance. We also provide a set of other tools in order to test the hardware.



    Es wird erwartet, dass die Test-Suite die meisten (oder idealerweise alle) Code-Zweige, Eingabefelder und Funktionalitäten abdeckt. [test_most]

    As most of the stuff is hardware-dependent, there's no way to implement unit tests. So, we designed a test suite to check if the Kernel drivers are properly implementing the media APIs. The main tool is v4l2-compliance. We also provide a set of other tools in order to test the hardware.



    Es wird erwartet, dass das Projekt eine kontinuierliche Integration durchführt (wo neuer oder geänderter Code häufig in ein zentrales Code-Repository integriert wird und automatisierte Tests auf diesen Ergebnissen durchgeführt werden). [test_continuous_integration]

    The Linux Kernel has several CI tools. One of them is at: https://kernelci.org/ We also have apps to check the compliance with hardware drivers with media APIs. We're in the process of adding CI for other sub-projects.


  • Neue Funktionalitätsüberprüfung


    Das Projekt MUSS allgemeine Grundregeln (formal oder nicht) haben, die als wesentliche neue Funktionalität der Software des Projektes hinzugefügt werden. Tests dieser Funktionalität sollten zu einer automatisierten Test-Suite hinzugefügt werden. [test_policy]

    We follow Linux Kernel policies.



    Das Projekt MUSS nachweisen, dass die test_policy für das Hinzufügen von Tests in den jüngsten großen Änderungen an der Projektsoftware eingehalten wurde. [tests_are_added]

    New drivers are required to pass at the compliance tools. The results of the tests should be submitted together with the patchsets adding the drivers.



    Es wird erwartet, dass diese Richtlinien zum Hinzufügen von Tests (siehe test_policy ) in den Anweisungen für Änderungsvorschläge dokumentiert werden. [tests_documented_added]

    We follow Linux Kernel policies.


  • Warnhinweise


    Das Projekt MUSS einen oder mehrere Compiler-Warn-Flags, einen "sicheren" Sprachmodus oder ein separates "Linter" -Tool verwenden, um nach qualitativen Fehlern im Code oder gängigen einfachen Fehlern zu suchen, wenn es mindestens ein FLOSS-Tool gibt, das dieses Kriterium implementieren kann in der gewählten sprache [warnings]

    We have low tolerance to warnings at the project. Besides compiler warnings, we also test the Kernel multimedia subsystem with Coverity, Sparse and Smatch static code analyzers.



    Das Projekt MUSS auf Warnungen reagieren. [warnings_fixed]

    Our goal is to have zero warnings when the media subsystem is built with W=1 (with enables lots of additional warnings over the usual Kernel standard).



    Es wird erwartet, dass Projekte Warnungen in der Software, die durch das Projekt produziert wird, sorgfältig berücksichtigen. [warnings_strict]

    We follow the Kernel policies. On distros, usually all warnings produce errors. At the Linux Kernel, this is an optional build feature.


  • Wissen über sichere Entwicklungspraktiken


    Das Projekt MUSS mindestens einen primären Entwickler haben, der weiß, wie man sichere Software entwerfen kann. (Siehe "Details" für spezifische Anforderungen.) [know_secure_design]

    The project main maintainer has CISSP certification (https://www.isc2.org/Certifications/CISSP).



    Mindestens einer der primären Entwickler des Projekts MUSS über weitläufige Arten von Fehlern, die zu Schwachstellen in dieser Art von Software führen, Bescheid wissen sowie mindestens eine Methode, um jede von ihnen zu beseitigen oder zu mildern. [know_common_errors]

    The project main maintainer has CISSP certification (https://www.isc2.org/Certifications/CISSP).


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

    Die vom Projekt entwickelte Software MUSS standardmäßig nur kryptografische Protokolle und Algorithmen verwenden, die öffentlich sind und von Experten überprüft wurden (falls kryptographische Protokolle und Algorithmen verwendet werden). [crypto_published]

    We don't implement cryptography at the project. The website are https only.



    Wenn die Software, die durch das Projekt produziert wird, eine Anwendung oder Bibliothek ist, und ihr Hauptzweck nicht die Kryptographie ist, dann SOLLTE sie lediglich Software einbinden, die speziell für kryptographische Funktionen entworfen ist; Sie SOLLTE NICHT eine eigene Implementierung vornehmen. [crypto_call]

    We don't implement cryptography at the project.



    Alle Funktionalitäten in der vom Projekt entwickelten Software, die von Kryptographie abhängigen, MÜSSEN mit FLOSS implementiert werden. [crypto_floss]

    We don't implement cryptography at the project. The DVB API supports access to DVB CI hardware modules (with are meant to implement cryptography), but the implementation is out of the scope of the project, as we just enable access to the hardware cryptographic functions.



    Die Sicherheitsmechanismen innerhalb der vom Projekt entwickelten Software, MÜSSEN Standard-Keylängen verwenden, die die NIST-Mindestanforderungen bis zum Jahr 2030 erfüllen (wie im Jahr 2012 festgelegt). Es MUSS möglich sein, die Software so zu konfigurieren, dass kürzere Keylängen vollständig deaktiviert werden können. [crypto_keylength]

    We don't implement cryptography at the project.



    Die Standard-Sicherheitsmechanismen innerhalb der vom Projekt entwickelten Software DÜRFEN NICHT von defekten kryptographischen Algorithmen abhängen (z.B. MD4, MD5, Single DES, RC4, Dual_EC_DRBG) oder Chiffre-Modi verwenden, die dem Kontext unangemessen sind, außer sie sind notwendig, um kompatible Protokolle bereitzustellen (wenn das Protokoll in der neusten Version in der Zielumgebung zum Einsatz kommt, die Zielumgebung solch ein Protokoll erfordert und das Zielsystem keine sicherere Alternative anbietet). Die Dokumentation MUSS auf jegliche Sicherheitsrisiken hinweisen und bekannte Vorsichtsmaßnahmen beschreiben, sollten unsichere Protokolle unumgäglich sein. [crypto_working]

    We don't implement cryptography at the project.



    Die Standard-Sicherheitsmechanismen innerhalb der vom Projekt entwickelten Software SOLLTEN NICHT nicht von kryptographischen Algorithmen oder Modi mit bekannten schweren Schwächen abhängen (z.B. SHA-1-Kryptographie-Hash-Algorithmus oder CBC-Modus in SSH). [crypto_weaknesses]

    We don't implement cryptography at the project.



    Die Sicherheitsmechanismen innerhalb der vom Projekt entwickelten Software SOLLTEN Perfect Forward Secrecy für wichtige Vereinbarungsprotokolle implementieren, so dass ein Sitzungsschlüssel, der aus einer Reihe von Langzeitschlüsseln abgeleitet wird, nicht beeinträchtigt werden kann, wenn einer der Langzeitschlüssel in der Zukunft kompromittiert wird. [crypto_pfs]

    We don't implement cryptography at the project.



    Wenn die vom Projekt erzeugte Software Passwörter für die Authentifizierung von externen Benutzern speichert, 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). Siehe auch OWASP Password Storage Cheat Sheet). [crypto_password_storage]

    Only Camorama sub-project may allow the user to optionally store passwords, but this is done via standard Glib authentication mechanism. Nothing is stored directly by it.



    Die Sicherheitsmechanismen innerhalb der vom Projekt entwickelten Software MÜSSEN alle kryptographischen Schlüssel und Nonces mit einem kryptographisch sicheren Zufallszahlengenerator erzeugen und DÜRFEN NICHT mit Generatoren arbeiten, die kryptographisch unsicher sind. [crypto_random]

    We don't implement cryptography at the project nor depend on random number generator.


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


    Das Projekt MUSS einen Auslieferungsmechanismus verwenden, der den MITM-Angriffen entgegenwirkt. Die Verwendung von https oder ssh + scp ist akzeptabel. [delivery_mitm]

    Only camorama may use URLs to store camera images on a remote place. The mechanism supports https and scp.



    Ein kryptographischer Hash (z.B. sha1sum) DARF NICHT über http abgerufen und ohne Überprüfung einer kryptographischen Signatur verwendet werden. [delivery_unsigned]

    We don't implement cryptography at the project. The website we use is https only.


  • Öffentlich bekannte Schwachstellen wurden behoben


    Es DARF KEINE ungepatchte Schwachstelle von mittlerer oder höherer Schwere enthalten sein, die seit mehr als 60 Tagen öffentlich bekannt ist. [vulnerabilities_fixed_60_days]

    There's no known unpatch vulnerabilities.



    Projekte SOLLTEN alle kritischen Schwachstellen schnell beheben, nachdem sie gemeldet wurden. [vulnerabilities_critical_fixed]

    We speed up fixes for critical vulnerabilities.


  • Andere Sicherheitsissues


    Die öffentlichen Repositorys DÜRFEN NICHT gültige private Zugriffsdaten enthalten (z. B. ein funktionierendes Passwort oder einen privaten Schlüssel), die den öffentlichen Zugriff einschränken sollen. [no_leaked_credentials]

    We do our best efforts to keep private data confidential. We also have a privacy policy implemented: https://linuxtv.org/wiki/index.php/LinuxTVWiki:Privacy_policy


  • Statische Codeanalyse


    Mindestens ein Tool zur Analyse statischer Codes (über Compiler-Warnungen und "sichere" Sprachmodi hinaus) MUSS vor der Veröffentlichung auf jede vorgeschlagene größere Produktionsversion der Software angewendet werden, wenn mindestens ein FLOSS-Tool dieses Kriterium in der ausgewählten Sprache implementiert. [static_analysis]

    Coverity, sparse, smatch.



    Es wird davon ausgegangen, dass mindestens eines der statischen Analysewerkzeuge, die für das statische Analysekriterium verwendet wurde, Regeln oder Ansätze einschließt, um nach häufigen Schwachstellen in der analysierten Sprache oder Umgebung zu suchen. [static_analysis_common_vulnerabilities]

    The tools we use check for common vulnerabilities.



    Alle mittel- und höhergradig ausnutzbaren Schwachstellen, die mit statischer Codeanalyse entdeckt wurden, MÜSSEN nach der Entdeckung rechtzeitig behoben werden. [static_analysis_fixed]

    Our goal is to have zero warnings from static code analyzers and compiler warnings (except for false-positive ones).



    Es wird EMPFOHLEN, dass eine statische Quellcode-Analyse bei jedem Commit oder zumindest täglich ausgeführt wird. [static_analysis_often]

    We run sparse and smatch for every single commit applied to the tree.


  • Dynamische Codeanalyse


    Es ist EMPFHOLEN, dass mindestens ein dynamisches Analyse-Tool auf jede vorgeschlagene größere Veröffentlichung der Software vor seiner Freigabe angewendet wird. [dynamic_analysis]

    https://01.org/lkp/documentation/0-day-test-service runs lots of these tools on all trees before release.



    Es ist EMPFHOLEN, dass die vom Projekt entwickelte Software, falls sie Software von einer Speicher-unsicheren Sprache (z. B. C oder C ++) enthält, regelmäßig mindestens ein dynamisches Werkzeug (z.B. ein Fuzzer oder ein Web-Anwendungs-Scanner) in Kombination mit einem Mechanismus zur Erkennung von Speichersicherheitsproblemen wie Puffer-Overwrites verwendet. Wenn das Projekt keine Software entwickelt, die in einer Speicher-unsicheren Sprache geschrieben ist, wählen Sie "nicht anwendbar" (N/A). [dynamic_analysis_unsafe]

    We don't run directly any fuzzer, but there are a group of Kernel developers doing that and doing periodic reports to our channels.



    Es ist EMPFHOLEN, dass das Projekt eine Konfigurations benutzt, die zumindest etwas dynamischen Analyse nutzt (wie z.B. testing oder fuzzing), welche Assertions erlauben. In vielen Fällen sollten diese Assertions nicht in Production Builds aktiviert sein. [dynamic_analysis_enable_assertions]

    Look at all of the wonderful BUG_ON() calls in the kernel (hint, you really don't want those to ever trigger, but they are there...) Outside the Kernel, errors are properly handled by the library and tools, reporting runtime errors or using assert() calls.



    Alle mittel- und höhergradig ausnutzbaren Schwachstellen, die mit dynamischer Codeanalyse entdeckt werden, MÜSSEN zügig behoben werden, nachdem sie bestätigt wurden. [dynamic_analysis_fixed]

    We actively monitor reports from Kernel fuzzer projects and address them.



Die Daten sind unter der Creative Commons Attribution 3.0-Lizenz oder Nachfolder (CC-BY-3.0+) verfügbar, bereitgestellt von der Open Source Security Foundation 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 Mauro Carvalho Chehab und die OpenSSF Best Practices Badge Mitwirkenden an.

Projekt-Badge-Eintrag im Besitz von: Mauro Carvalho Chehab.
Eintrag erstellt: 2019-02-27 12:44:33 UTC, zuletzt aktualisiert: 2019-02-28 00:30:38 UTC. Letztes erreichtes Badge: 2019-02-27 15:18:02 UTC.

Zurück