BadgeApp

Qualité 12/13 ●

Système de construction opérationnel

Criterion [build]
Atteint

Non atteint

N/A

?

Si le logiciel produit par le projet nécessite d'être construit pour être utilisé, le projet DOIT fournir un système de construction fonctionnel qui peut reconstruire automatiquement le logiciel à partir du code source. ^[build]
Un système de construction détermine quelles actions doivent se produire pour reconstruire le logiciel (et dans quel ordre), puis exécute ces étapes. Par exemple, il peut invoquer un compilateur pour compiler le code source. Si un exécutable est créé à partir du code source, il doit être possible de modifier le code source du projet, puis de générer un exécutable mis à jour avec ces modifications. Si le logiciel produit par le projet dépend de bibliothèques externes, le système de construction n'a pas besoin de construire ces bibliothèques externes. S'il n'est pas nécessaire de construire quoi que ce soit pour utiliser le logiciel après la modification de son code source, sélectionnez « non applicable » (N/A).

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

Continuous integration via Travis and Appveyor builds every submitted patch.

Criterion [build_common_tools]
Atteint

Non atteint

N/A

?

Il est PROPOSÉ d'utiliser des outils courants pour la construction du logiciel. ^{[build_common_tools]}
Par exemple, Maven, Ant, cmake, autotools, make, rake (Ruby) ou devtools (R).

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

Criterion [build_floss_tools]
Atteint

Non atteint

N/A

?

Le projet DEVRAIT être constructible en utilisant uniquement des outils FLOSS. ^{[build_floss_tools]}

On Linux and Solaris this is true.

Builds with Apple XCode for Apple platforms and Microsoft Visual Studio for Windows
Suite de tests automatisée

Criterion [test]
Atteint

Non atteint

?

Le projet DOIT utiliser au moins une suite de tests automatisée publiée publiquement comme FLOSS (cette suite de tests peut être maintenue sous la forme d'un projet FLOSS distinct). Le projet DOIT clairement montrer ou documenter comment exécuter la ou les suites de tests (par exemple, via un script d'intégration continue (CI) ou via la documentation dans des fichiers tels que BUILD.md, README.md ou CONTRIBUTING.md). ^[test]
Le projet PEUT utiliser plusieurs suites de tests automatisées (par exemple, une qui s'exécute rapidement, par rapport à une autre qui est plus approfondie, mais nécessite un équipement spécial). De nombreuses plate-formes de tests et environnements de tests sont disponibles, tels que Selenium (automatisation de navigateur Web), Junit (JVM, Java), RUnit (R), testthat (R).

Test suite is integrated with the build system.

Criterion [test_invocation]
Atteint

Non atteint

?

Une suite de tests DEVRAIT être invocable d'une manière standard pour ce langage. ^{[test_invocation]}
Par exemple, « make check », « mvn test » ou « rake test » (Ruby).

make check

Criterion [test_most]
Atteint

Non atteint

?

Il est PROPOSÉ que la suite de tests couvre la plupart (ou idéalement toutes) les branches du code, les champs de saisie et les fonctionnalités. ^[test_most]

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

Criterion [test_continuous_integration]
Atteint

Non atteint

?

Il est PROPOSÉ que le projet utilise une intégration continue (où le code nouveau ou modifié est fréquemment intégré dans un dépôt de code central et des tests automatisés sont exécutés sur le résultat). ^{[test_continuous_integration]}

Travis (Linux and macOS) and Appveyor (Windows)
Nouveau test de fonctionnalité
Criterion [test_policy]
Atteint

Non atteint

?

Le projet DOIT avoir une politique générale (formelle ou non) qui spécifie que, dès qu'une nouvelle fonctionnalité majeure est ajoutée au logiciel produit par le projet, des tests de cette fonctionnalité devraient être ajoutés à une suite de tests automatisée. ^{[test_policy]}
Dès qu'une politique est en place, même par le bouche à oreille, qui spécifie que les développeurs devraient ajouter des tests à une suite de tests automatisée pour toute nouvelle fonctionnalité importante, sélectionnez « Atteint ».
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>
```
Criterion [tests_are_added]
Atteint

Non atteint

?

Le projet DOIT avoir la preuve que la politique de test pour l'ajout de tests a été respectée dans les dernières modifications majeures apportées au logiciel produit par le projet. ^{[tests_are_added]}
Les principales fonctionnalités sont généralement mentionnées dans les notes de version. La perfection n'est pas nécessaire, il suffit de prouver que les tests sont généralement ajoutés en pratique à la suite de tests automatisée lorsque de nouvelles fonctionnalités majeures sont ajoutées au logiciel produit par le projet.
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>
```
Criterion [tests_documented_added]
Atteint

Non atteint

?

Il est PROPOSÉ que cette politique sur l'ajout de tests (voir la politique de test) soit documentée dans les instructions pour les propositions de modification. ^{[tests_documented_added]}
Cependant, même une règle informelle est acceptable tant que les tests sont ajoutés dans la pratique.
Options d'avertissement

Criterion [warnings]
Atteint

Non atteint

N/A

?

Le projet DOIT activer une ou plusieurs options d'avertissement du compilateur, un mode du langage « sûr » ou utiliser un outil « linter » séparé pour rechercher des erreurs de qualité de code ou des erreurs simples courantes, s'il existe au moins un outil FLOSS qui peut implémenter ce critère dans le langage sélectionné. ^[warnings]
Des exemples d'options d'avertissement du compilateur incluent « -Wall » pour gcc/clang. Des exemples d'un mode de langage « sûr » incluent « use strict » en JavaScript et « use warnings » de perl5. Un outil « linter » distinct est simplement un outil qui examine le code source pour rechercher des erreurs de qualité de code ou des erreurs simples courantes. Ceux-ci sont généralement activés par le code source ou par les instructions de construction.

Criterion [warnings_fixed]
Atteint

Non atteint

N/A

?

Le projet DOIT résoudre les avertissements. ^{[warnings_fixed]}
Ce sont les avertissements identifiés par la mise en œuvre du critère warnings. Le projet doit corriger les avertissements ou les marquer dans le code source comme faux positifs. Idéalement, il n'y aurait pas d'avertissement, mais un projet PEUT accepter certains avertissements (généralement moins de 1 avertissement pour 100 lignes ou moins de 10 avertissements).

Criterion [warnings_strict]
Atteint

Non atteint

N/A

?

Il est PROPOSÉ que les projets soient maximalement stricts avec les avertissements dans le logiciel produit par le projet, quand cela est approprié. ^{[warnings_strict]}
Certains avertissements ne peuvent être efficacement activés sur certains projets. Ce qui est nécessaire est la preuve que le projet s'efforce d'activer les options d'avertissements où il peut, de sorte que les erreurs soient détectées tôt.

Ces données sont disponibles sous une licence Creative Commons Attribution version 3.0 ou ultérieure (CC-BY-3.0+). Chacun peut librement partager et adapter les données, à condition de créditer leur origine. Veuillez créditer Jeffrey Altman et les contributeurs du badge des meilleures pratiques de la OpenSSF.

Heimdal

Notions de base 7/13 ●

Identification

Contenu basique du site Web du projet

Licence FLOSS

Documentation

Autre

Contrôle des modifications 9/9 ●

Dépôt source public sous contrôle de version

Numérotation unique de la version

Notes de version

Compte-rendu 7/8 ●

Procédure de signalement des bogues

Processus de signalement de vulnérabilité

Qualité 12/13 ●

Système de construction opérationnel

Suite de tests automatisée

Nouveau test de fonctionnalité

Options d'avertissement

Sécurité 16/16 ●

Connaissance du développement sécurisé

Utiliser de bonnes pratiques de base de cryptographie

Livraison sécurisée contre les attaques man-in-the-middle (MITM)

Vulnérabilités publiquement identifiées et corrigées

Autres problèmes de sécurité

Analyse 4/8 ●

Analyse statique de code

Analyse dynamique de code