Crypto++

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 3806 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 1/5 ●

  • Identifizierung

    Free C++ class library of cryptographic schemes

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

    The project's key players and their roles are detailed in several places. In fact four different key members were selected from different regions of the world to ensure continuity. In particular https://www.cryptopp.com/wiki/Release_Process and https://www.cryptopp.com/wiki/Release_Signing. We should probably create a PDF with the relevant information in one place.


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

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

  • Andere


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

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

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


    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]

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

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

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

    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.

    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]

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

    'make test' and 'make check' work for me. It follows the GNU Coding Standards.

    Warnung: URL erforderlich, aber keine URL gefunden.


    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]

    Linux and OS X builds using Travis CI: https://github.com/weidai11/cryptopp/blob/master/.travis.yml. FreeBSD builds using Cirrus CI: https://github.com/weidai11/cryptopp/blob/master/.cirrus.yml. Android and iOS builds using Travis CI: https://github.com/weidai11/cryptopp/blob/master/.travis.yml. Windows builds using AppVeyor: https://github.com/weidai11/cryptopp/blob/master/.appveyor.yml.


    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]

    The library does not provide protocols like SSH or TLS.


    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]

    The library does not provide protocols like SSH or 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".


  • Andere Sicherheitsissues


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

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

    The project uses hardened toolchain settings when available, like -fexceptions, -fplugin=annobin, -fstack-clash-protection, -fstack-protector-strong (or -fstack-protector), -grecord-gcc-switches, -mcet -fcf-protection, -Werror=format-security, -Werror=implicit-function-declaration, -fPIC and -pie for ASLR, -Wa,--noexecstack, -Wl,-z,relro, -Wl,-z,now and -Wl,-z,defs.

    Warnung: URL erforderlich, aber keine URL gefunden.


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

    The project uses Valgrind and Sanitizers to test for runtime violations. Valgrind detects memory and thread problems. Santiziers include Asan, Msan and UBsan.

    The projects self tests also "fuzz" certain interfaces attempting to crash the test suite. The fuzzing occurs under Valgrind, Asan and Msan.


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

    Debug builds of the project includes asserts to aide the developer in finding mistakes.

    Release builds are built with -DNDEBUG and will NEVER asset. The library will validate the parameters and/or state and throw an exception on failure. Anywhere there is an 'if' statement to validate state includes an assert. Anywhere there is an assert to validate state includes an 'if' statement that throws. They are matched set like bookends.

    The Crypto++ library never asserts in production for five reasons. First, it is the application's authors decision to crash their app. The library does not make policy decisions for the application author.

    Second, some platforms, like Apple iOS, forbid applications from crashing because it degrades the UI experience. In this case, the App Store has set the policy for the application author. The library will not cause an author's app to be rejected from an App Store.

    Third, the library handles sensitive information like private keys, shared secrets and passwords. When an assert fires a core file could be written that includes the sensitive information. That means the sensitive information has been egressed outside the application's security boundary. Folks with access to the mobile device, desktop computer or a computer paired/sync'd with the mobile device will be able to recover the secrets from the filesystem.

    Fourth, the core file, if present, may be shipped to an Error Reporting Service. Now Apple, Google, Fedora, Red Hat, Ubuntu or Microsoft have the user's private keys, shared secrets and passwords. Then the information is then passed onto the developer who has the user's private keys, shared secrets and passwords, too.

    Fifth, asserts destroy most of Confidentiality-Availability-Integrity (CIA). When an assert crashes a program, it (1) may preserve data Integrity at the expense of (2) Confidentiality of the data and (3) Availability of the program or server. If an author wishes to preserve Integrity, he/she/it merely needs to return false in the offending function or call exit(1) without the loss of Confidentiality or Availability.



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

Projekt-Badge-Eintrag im Besitz von: Jeffrey Walton.
Eintrag erstellt: 2020-03-25 18:25:43 UTC, zuletzt aktualisiert: 2020-03-26 03:01:39 UTC. Letztes erreichtes Badge: 2020-03-25 19:57:57 UTC.

Zurück