tpm2-tss

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 2332 ist passing 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

    This repository hosts source code implementing the Trusted Computing Group's (TCG) TPM2 Software Stack (TSS). This stack consists of the following layers from top to bottom:

    • Feature API (FAPI) as described in the TCG Feature API (FAPI) Specification along with TCG TSS 2.0 JSON Data Types and Policy Language Specification This API is designed to be very high-level API, intended to make programming with the TPM as simple as possible. The API functions are exposed through a single library: libtss2-fapi.
    • Enhanced System API (ESAPI) as described in the TCG TSS 2.0 Enhanced System API (ESAPI) Specification This API is a 1-to-1 mapping of the TPM2 commands documented in Part 3 of the TPM2 specification. Additionally there are asynchronous versions of each command. In addition to SAPI, the ESAPI performs tracking of meta data for TPM object and automatic calculation of session based authorization and encryption values. Both the synchronous and asynchronous API are exposed through a single library: libtss2-esys.
    • System API (SAPI) as described in the TCG TSS 2.0 System Level API (SAPI) Specification This API is a 1-to-1 mapping of the TPM2 commands documented in Part 3 of the TPM2 specification. Additionally there are asynchronous versions of each command. These asynchronous variants may be useful for integration into event-driven programming environments. Both the synchronous and asynchronous API are exposed through a single library: libtss2-sys.
    • Marshaling/Unmarshaling (MU) as described in the TCG TSS 2.0 Marshaling/Unmarshaling API Specification This API provides a set of marshaling and unmarshaling functions for all data types define by the TPM library specification. The Marshaling/Unmarshaling API is exposed through a library called libtss2-mu.
    • TPM Command Transmission Interface (TCTI) as described in the TCG TSS 2.0 TPM Command Transmission Interface (TCTI) API Specification. This API provides a standard interface to transmit / receive TPM command / response buffers. It is expected that any number of libraries implementing the TCTI API will be implemented as a way to abstract various platform specific IPC mechanisms. Currently this repository provides several TCTI implementations: libtss2-tcti-device, libtss2-tcti-tbs (for Windows), libtss2-tcti-swtpm and libtss2-tcti-mssim. The former should be used for direct access to the TPM through the Linux kernel driver. The latter implements the protocol exposed by the Microsoft software TPM2 simulator.
    • The TCG TSS 2.0 Overview and Common Structures Specification forms the basis for all implementations in this project. NOTE: We deviate from this specification by increasing the value of TPM2_NUM_PCR_BANKS from 3 to 16 to ensure compatibility with TPM2 implementations that have enabled a larger than typical number of PCR banks. This larger value for TPM2_NUM_PCR_BANKS is expected to be included in a future revision of the specification.
    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]

    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]

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

    Non-trivial contribution file in repository: https://github.com/tpm2-software/tpm2-tss/blob/master/CONTRIBUTING.md.



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

    The BSD-2-Clause 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 BSD-2-Clause 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]

    Non-trivial license location file in repository: https://github.com/tpm2-software/tpm2-tss/blob/master/LICENSE.


  • Dokumentation


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

    https://github.com/tpm2-software/tpm2-tss/blob/master/README.md - for General Overview https://github.com/tpm2-software/tpm2-tss/tree/master/doc - for General Documentation https://github.com/tpm2-software/tpm2-tss/tree/master/man - man pages for the some of the components Full Doxygen Documentation for ESAPI/FAPI layer - https://tpm2-tss.readthedocs.io/en/latest/



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

    https://github.com/tpm2-software/tpm2-tss/tree/master/man - man pages for the some of the components

    Full Doxygen Documentation for ESAPI/FAPI layer - https://tpm2-tss.readthedocs.io/en/latest/


  • Andere


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

    Given only https: URLs - feature by Github



    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]

    GitHub supports discussions on issues and pull requests. Also a searchable Mailing List https://lists.01.org/hyperkitty/list/tpm2@lists.01.org/



    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]

    All documentation and communication is done in English. https://github.com/tpm2-software/tpm2-tss/blob/master/README.md



    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]

    Repository on GitHub, which provides public git repositories with URLs.



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

    Repository on GitHub, which uses git. git can track the changes, who made them, and when they were made.



    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]

    The complete development is done on github - every interim version, every change, every commit can be found on the repository.



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

    Repository on GitHub, which uses git. git is distributed.


  • Einzigartige Versionsnummerierung


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

    Semantic versioning scheme is used and the release process is documented in https://github.com/tpm2-software/tpm2-tss/blob/master/RELEASE.md



    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]

    Semantic versioning scheme is used and the release process is documented in https://github.com/tpm2-software/tpm2-tss/blob/master/RELEASE.md



    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]

    Every release is tagged with a signed tag. Even release candidates are marked with a signed tag. https://github.com/tpm2-software/tpm2-tss/blob/master/RELEASE.md


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

    Non-trivial release notes file in repository: https://github.com/tpm2-software/tpm2-tss/blob/master/CHANGELOG.md. They are also included on the Release Page https://github.com/tpm2-software/tpm2-tss/releases



    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]

    Currently there are no known CVE entries - nevertheless, security relevant fixes are marked as such.


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

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

    Yes - Issues: 27 open, 656 fixed/closed - https://github.com/tpm2-software/tpm2-tss/issues / Pull Requests: 1 open, 1239 closed - https://github.com/tpm2-software/tpm2-tss/pulls



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

    Yes - Issues: 27 open, 656 fixed/closed - https://github.com/tpm2-software/tpm2-tss/issues / Pull Requests: 1 open, 1239 closed - https://github.com/tpm2-software/tpm2-tss/pulls



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

    Yes - Issues: 27 open, 656 fixed/closed - https://github.com/tpm2-software/tpm2-tss/issues / Pull Requests: 1 open, 1239 closed - https://github.com/tpm2-software/tpm2-tss/pulls Public Mailing List Archive: https://lists.01.org/hyperkitty/list/tpm2@lists.01.org/


  • Anfälligkeits-Prozessbericht


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

    https://github.com/tpm2-software/tpm2-tss/blob/master/CONTRIBUTING.md - although brief, it is stated how to report security bugs.



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

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

    Yes - handled via Intel's Security Response Team, fixed and coordinated


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

    Each commit is automatically compiled using travis CI and AppVeyor. Each pull request is also automatically compiled travis CI and AppVeyor. https://travis-ci.org/tpm2-software/tpm2-tss and https://ci.appveyor.com/project/tpm2-software/tpm2-tss



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

    The build step of the software is based on the ubiquitous 'autotools' - known as "./configure && make && sudo make install" The software can also be built via a dockerfile.



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

    It relies on autotools for building. Other software/libraries are also covered by floss licenses.


  • 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 tests are checked in under https://github.com/tpm2-software/tpm2-tss/tree/master/test and are perfomed on each commit using travis-ci. https://travis-ci.org/tpm2-software/tpm2-tss



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

    invocation via simple standard 'make check'



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

    Code Coverage by automated testsuite (via travis-ci) is automatically reported to coveralls and is at about 85+% https://coveralls.io/github/tpm2-software/tpm2-tss?branch=master



    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 tests are checked in under https://github.com/tpm2-software/tpm2-tss/tree/master/test and are perfomed on each commit using travis-ci. https://travis-ci.org/tpm2-software/tpm2-tss


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

    https://github.com/tpm2-software/tpm2-tss/blob/master/CONTRIBUTING.md This is also part of the review cycle and has been enforced multple times. But could be made clearer - TODO



    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]

    General Code Coverage is always improved and must be kept above 80%. New tests are also mentioned in the release notes.



    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]

    Part of the review cycle - but could be made clearer - TODO.


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

    A lot of the most common secure compile flags are enabled in configure per default. https://github.com/tpm2-software/tpm2-tss/blob/master/configure.ac#L192

    Also the code is compiled using gcc and clang to enable more warning coverage. In addition to that static code analysis is done via coverity and scan-build (via clang).



    Das Projekt MUSS auf Warnungen reagieren. [warnings_fixed]

    All compiler warnings are treated as errors ("-Werror"). https://github.com/tpm2-software/tpm2-tss/blob/master/configure.ac#L196

    Static Code Analyzer Warnings are adressed / reviewed on a regular basis https://scan.coverity.com/projects/tpm2-tss



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

    A lot of the most common secure compile flags are enabled in configure per default. https://github.com/tpm2-software/tpm2-tss/blob/master/configure.ac#L192

    Also the code is compiled using gcc and clang to enable more warning coverage. In addition to that static code analysis is done via coverity and scan-build (via clang).


  • 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 design of the specification of the software is performed within a Working Group within the Trusted Computing Group. Software development in the context of the TCG is always related to security and secure software. The maintainers have several years of experience in developing secure software.



    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 design of the specification of the software is performed within a Working Group within the Trusted Computing Group. Software development in the context of the TCG is always related to security and secure software. The maintainers have several years of experience in developing secure software.


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

    The design of the specification of the software is performed within a Working Group within the Trusted Computing Group. Software development in the context of the TCG is always related to security and secure software. The cryptography depends on public cryptographic protocols and algorithms like TLS, sha, aes, rsa....



    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]

    It uses openssl or mbedtls as crypto-backends. It does not implement its own crypto.



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

    It uses openssl or mbedtls as crypto-backends - both are FLOSS.



    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]

    The TPM specification currently still allows the usage of these algorithms/keysizes even if better algorithms are available, so we must support them.

    However a new configure flag --disable-weakcrypto was introduced which prevents the usage of these algorithms as much as possible.



    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]

    tpm2-tss does not support any of these. Only SM3 may be an issue in the future here. Re-assessment will be done regularly - TODO.



    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]

    The TPM specification currently still allows the usage of these algorithms, even if better algorithms are available, so we must support them.

    However a new configure flag --disable-weakcrypto was introduced which prevents the usage of these algorithms as much as possible.



    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]

    tpm2-tss does not establish cryptographic sessions that qualify for perfect forward secrecy. The Auth-Sessions to the TPM would be prone to this issue, but those are bound to the hardware specification and the private keys are held inside SmartCards-like ICs aka TPMs. Nothing we can do here.



    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]

    tpm2-tss does not store passwords.



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

    Each release is performed with signed tags as described in https://github.com/tpm2-software/tpm2-tss/blob/master/RELEASE.md Apart from that the software can also be downloaded via https or via the git protocol.



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

    Each release is performed with signed tags as described in https://github.com/tpm2-software/tpm2-tss/blob/master/RELEASE.md The signature verification is performed by github on the release page and the signature of the release packages can be retrieved via https.


  • Ö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]

    No publicly known vulnerabilities open.



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

    No publicly known vulnerabilities open.


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

    No leaks.


  • 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 Scan and scan-build from clang/llvm.



    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]

    Covered by coverity.



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

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

    Coverity is run before a release - https://github.com/tpm2-software/tpm2-tss/blob/master/RELEASE.md Scan-build is run on a per commit basis.


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

    Currently not implemented - code coverage is above 80% using the automatic testsuite.



    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]

    Currently not implemented - code coverage is above 80% using the automatic testsuite including some boundary checks.

    Valgrind can be easily used with make check-valgrind



    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]

    Currently not implemented - code coverage is above 80% using the automatic testsuite



    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]

    Currently not implemented



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 Peter Huewe und die OpenSSF Best Practices Badge Mitwirkenden an.

Projekt-Badge-Eintrag im Besitz von: Peter Huewe.
Eintrag erstellt: 2018-11-08 16:22:22 UTC, zuletzt aktualisiert: 2020-11-24 13:31:51 UTC. Letztes erreichtes Badge: 2019-04-01 19:29:20 UTC.

Zurück