libjxl

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 7845 ist silver 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 5/5 ●

  • Identifizierung

    JPEG XL image format reference implementation, including a library for encoding and decoding JPEG XL images as well as command line tools (cjxl, djxl, jxlinfo) and various related tools (e.g. perceptual metrics, color conversion and benchmarking tools).

  • Voraussetzungen


    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]

    Hard to assess with the truck-factor tool since initial development was private and all commits were authored by "jpegxl-bot". But there are at least 4 project maintainers who are sufficiently knowledgeable and competent, so the bus factor is 4 or more. As can be seen on https://github.com/libjxl/libjxl/graphs/contributors, there are at least 6 project members who have made significant contributions over a long time span in the past and are still recently active.


    Genug für ein Badge!

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

    Significant contributors include: - Jon Sneyers (Cloudinary) - Moritz Firsching, Luca Versari, Evgenii Kliuchnikov, Jyrki Alakuijala, Sami Boukortt, Zoltan Szabadka, Jan Wassenberg (Google) See https://github.com/libjxl/libjxl/graphs/contributors


  • Andere


    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]

    All source files start with the following:

    // Copyright (c) the JPEG XL Project Authors. All rights reserved. // // Use of this source code is governed by a BSD-style // license that can be found in the LICENSE 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.


    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]

    The 'good first issue' label is used for this. https://github.com/libjxl/libjxl/issues?q=is%3Aopen+is%3Aissue+label%3A%22good+first+issue%22


    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]

    2FA is required for everyone in the libjxl github organization.


    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]

    TOTP is used for 2FA, not SMS.


  • Programmierstil


    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]

    This is documented in https://github.com/libjxl/libjxl/blob/main/CONTRIBUTING.md


    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]

    All pull requests require review/approval by at least one person other than the author, and this is enforced. For more significant proposed modifications, typically at least two reviews by a person other than the author are done, although this is not enforced.


  • Produktivsystem


    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]

    Building for various platforms is done as part of the CI, see e.g. https://github.com/libjxl/libjxl/actions/workflows/release.yaml


  • Automatisierte Test-Suite


    Genug für ein Badge!

    Eine Test-Suite MUSS in einer standardisierten Weise für diese Programmiersprache anrufbar sein. (URL erforderlich) [test_invocation]

    The gtest framework is used for this and testing will be done automatically as part of building unless -DBUILD_TESTING=OFF is specified. A script is provided (https://github.com/libjxl/libjxl/blob/main/ci.sh) to easily do building and testing with various build options (e.g. msan, asan etc).


    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]

    See e.g. https://github.com/libjxl/libjxl/actions/workflows/build_test.yml


    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]

    Currently the automated coverage testing only reaches 84%, see https://app.codecov.io/gh/libjxl/libjxl Reaching 90% is not impossible but it would require adding many explicit tests involving invalid inputs (many of the uncovered statements), which is something that is better tested with fuzzer-testing than with unit tests.


    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]

    Currently the automated coverage testing reaches 84%, see https://app.codecov.io/gh/libjxl/libjxl


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

    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]

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


    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]

    Found all required security hardening headers. https://securityheaders.com/?q=https%3A%2F%2Fgithub.com%2Flibjxl%2Flibjxl&followRedirects=on


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

    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]

    Hardening compiler flags are indeed typically used in builds intended for widespread distribution. See e.g. https://salsa.debian.org/debian-phototools-team/highway/-/blob/master/debian/rules#L6 and https://github.com/libjxl/libjxl/pull/2834#issuecomment-1761156078


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

    This is done as part of CI, see https://github.com/libjxl/libjxl/actions/workflows/fuzz.yml It is also done in the OSS-Fuzz project.


    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]

    See e.g. https://github.com/search?q=repo%3Alibjxl%2Flibjxl%20JXL_ASSERT&type=code



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

Projekt-Badge-Eintrag im Besitz von: Jon Sneyers.
Eintrag erstellt: 2023-09-19 14:13:59 UTC, zuletzt aktualisiert: 2023-10-13 09:14:45 UTC. Letztes erreichtes Badge: 2023-09-19 15:13:34 UTC.

Zurück