BadgeApp

Qualität 12/13 ●

Produktivsystem

Criterion [build]
Erfüllt

Unerfüllt

N/A

?

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]
Ein Build-System bestimmt, welche Aktionen durchgeführt werden müssen, um die Software neu zu bauen (und in welcher Reihenfolge) und führt dann diese Schritte aus. Zum Beispiel kann es einen Compiler aufrufen, um den Quellcode zu kompilieren. Wenn eine ausführbare Datei aus dem Quellcode erstellt wird, muss es möglich sein, den Quellcode des Projekts zu ändern und dann eine aktualisierte ausführbare Datei mit diesen Modifikationen zu erzeugen. Wenn die vom Projekt produzierte Software von externen Bibliotheken abhängt, muss das Build-System diese externen Bibliotheken nicht bauen. Wenn es keine Notwendigkeit gibt, irgendetwas zu bauen, um die Software zu verwenden, nachdem ihr Quellcode geändert wurde, wählen Sie "nicht anwendbar" (N/A).

http://www.h5l.org/compile.html

Continuous integration via Travis and Appveyor builds every submitted patch.

Criterion [build_common_tools]
Erfüllt

Unerfüllt

N/A

?

Es ist EMPFHOLEN, dass gewöhnliche Werkzeuge zum Kompilieren von Software benutzt wird. ^{[build_common_tools]}
Beispielsweise, Maven, Ant, cmake, die Autotools, make, rake (Ruby) oder devtools (R).

http://www.h5l.org/compile.html

Criterion [build_floss_tools]
Erfüllt

Unerfüllt

N/A

?

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

On Linux and Solaris this is true.

Builds with Apple XCode for Apple platforms and Microsoft Visual Studio for Windows
Automatisierte Test-Suite

Criterion [test]
Erfüllt

Unerfüllt

?

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]
Das Projekt KANN mehrere automatisierte Test-Suiten benutzen (z. B. eine, die schnell läuft, eine andere, die gründlicher ist, aber spezielle Ausrüstung erfordert). Es gibt viele Test-Frameworks und Systeme die Tests unterstützten, einschließlich Selenium (web browser automation), Junit (JVM, Java), RUnit (R), testthat (R).

Test suite is integrated with the build system.

Criterion [test_invocation]
Erfüllt

Unerfüllt

?

Eine Test-Suite SOLLTE in einer üblichen Weise für diese Programmiersprache aufrufbar sein. ^{[test_invocation]}
Zum Beispiel, "make check", "mvn test", oder "rake test" (Ruby).

make check

Criterion [test_most]
Erfüllt

Unerfüllt

?

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

https://api.travis-ci.org/v3/job/543033748/log.txt

Criterion [test_continuous_integration]
Erfüllt

Unerfüllt

?

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

Travis (Linux and macOS) and Appveyor (Windows)

Neue Funktionalitätsüberprüfung

Erfüllt

Unerfüllt

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

ommit 4b2c3ea03277a42ff7d424e634213d15913229e2 Author: Luke Howard lukeh@padl.com Date: Tue May 21 15:18:16 2019 +1000

kuser: allow kinit to renew anonymous PKINIT tickets

Anonymous PKINIT tickets discard the realm information used to locate the
issuing AS. Store the issuing realm in the credentials cache in order to locate
a KDC which can renew them.

(cherry picked from commit d89b5cb966c41015fad524027107dd2d241b44e8)

commit 9793551bb919d0dc6b41d9d6b80356f44d82ac9e Author: Isaac Boukris iboukris@gmail.com Date: Mon Nov 12 20:08:06 2018 +0200

kdc: allow checksum of PA-FOR-USER to be HMAC_MD5

even if tgt used an enctype with a different checksum.

Per [MS-SFU] 2.2.1 PA-FOR-USER the checksum is always
HMAC_MD5, and that's what Windows and MIT clients send.

In heimdal both the client and kdc use instead the
checksum of the tgt, and therefore work with each other
but windows and MIT clients fail against heimdal KDC.

Both Windows and MIT KDC would allow any keyed checksum
to be used so Heimdal client work fine against it.

Change Heimdal KDC to allow HMAC_MD5 even for non RC4
based tgt in order to support per-spec clients.

Back ported from master, commit:
b7fe0fb85a780fed3c54ed2539fc974db1884dc2

Signed-off-by: Isaac Boukris <iboukris@gmail.com>

Erfüllt

Unerfüllt

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

ommit 4b2c3ea03277a42ff7d424e634213d15913229e2 Author: Luke Howard lukeh@padl.com Date: Tue May 21 15:18:16 2019 +1000

kuser: allow kinit to renew anonymous PKINIT tickets

Anonymous PKINIT tickets discard the realm information used to locate the
issuing AS. Store the issuing realm in the credentials cache in order to locate
a KDC which can renew them.

(cherry picked from commit d89b5cb966c41015fad524027107dd2d241b44e8)

commit 9793551bb919d0dc6b41d9d6b80356f44d82ac9e Author: Isaac Boukris iboukris@gmail.com Date: Mon Nov 12 20:08:06 2018 +0200

kdc: allow checksum of PA-FOR-USER to be HMAC_MD5

even if tgt used an enctype with a different checksum.

Per [MS-SFU] 2.2.1 PA-FOR-USER the checksum is always
HMAC_MD5, and that's what Windows and MIT clients send.

In heimdal both the client and kdc use instead the
checksum of the tgt, and therefore work with each other
but windows and MIT clients fail against heimdal KDC.

Both Windows and MIT KDC would allow any keyed checksum
to be used so Heimdal client work fine against it.

Change Heimdal KDC to allow HMAC_MD5 even for non RC4
based tgt in order to support per-spec clients.

Back ported from master, commit:
b7fe0fb85a780fed3c54ed2539fc974db1884dc2

Signed-off-by: Isaac Boukris <iboukris@gmail.com>

Erfüllt

Unerfüllt

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

Warnhinweise

Criterion [warnings]
Erfüllt

Unerfüllt

N/A

?

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]
Beispiele für Compiler-Warn-Flags sind gcc / clang "-Wall". Beispiele für einen "sicheren" Sprachmodus beinhalten JavaScript "use strict" und perl5's "use warnings". Ein separates "Linter" -Tool ist einfach ein Werkzeug, das den Quellcode untersucht, um nach qualitativen Fehlern im Code oder gängigen einfachen Fehlern zu suchen. Diese werden in der Regel im Quellcode aktiviert oder in den Einstellungen.

Criterion [warnings_fixed]
Erfüllt

Unerfüllt

N/A

?

Das Projekt MUSS auf Warnungen reagieren. ^{[warnings_fixed]}
Dies sind die Warnungen, die durch die Umsetzung des warnings Kriteriums identifiziert wurden. Das Projekt sollte Warnungen beheben oder im Quellcode als falsch positives Ergebnis markieren. Idealerweise gibt es keine Warnungen, aber ein Projekt DARF einige Warnungen akzeptieren (typischerweise weniger als 1 Warnung pro 100 Zeilen oder weniger als 10 Warnungen).

Criterion [warnings_strict]
Erfüllt

Unerfüllt

N/A

?

Es wird erwartet, dass Projekte Warnungen in der Software, die durch das Projekt produziert wird, sorgfältig berücksichtigen. ^{[warnings_strict]}
Bei manchen Projekten können einige Warnungen effektiv nicht aktiviert werden. Was benötigt wird, ist ein Beleg dafür, dass das Projekt danach strebt, Warnungen zu aktivieren, wo es möglich ist, so dass Fehler frühzeitig erkannt werden.

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

Heimdal

Grundlagen 7/13 ●

Identifizierung

Grundlegende Informationen auf der Projektwebseite

FLOSS-Lizenz

Dokumentation

Andere

Verbesserungs-/Nacharbeits-Kontrolle 9/9 ●

Öffentliches Versionskontroll-Source-Repository

Einzigartige Versionsnummerierung

Versionshinweise

Berichterstattung 7/8 ●

Bug-Report-Prozess

Anfälligkeits-Prozessbericht

Qualität 12/13 ●

Produktivsystem

Automatisierte Test-Suite

Neue Funktionalitätsüberprüfung

Warnhinweise

Sicherheit 16/16 ●

Wissen über sichere Entwicklungspraktiken

Verwende grundlegend gute kryptographische Praktiken

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

Öffentlich bekannte Schwachstellen wurden behoben

Andere Sicherheitsissues

Analyse 4/8 ●

Statische Codeanalyse

Dynamische Codeanalyse