BadgeApp

Compte-rendu 8/8 ●

Procédure de signalement des bogues

Criterion [report_process]
Atteint

Non atteint

?

Le projet DOIT fournir un processus permettant aux utilisateurs de soumettre des signalements de bogue (par exemple, en utilisant un suivi des problèmes ou une liste de diffusion). (URL requise) ^{[report_process]}

Issue tracker: https://github.com/magma/magma/issues/

Criterion [report_tracker]
Atteint

Non atteint

?

Le projet DEVRAIT utiliser un suivi des problèmes pour le suivi des problèmes individuels. ^{[report_tracker]}

https://github.com/magma/magma/issues

Criterion [report_responses]
Atteint

Non atteint

?

Le projet DOIT confirmer une majorité des signalements de bogues soumis au cours des 2 à 12 derniers mois (inclus) ; la réponse ne doit pas nécessairement inclure une correction. ^{[report_responses]}

is:issue created:>2022-05-02 interactions:0 label:"type: bug" 24 open, 32 closed

is:issue created:>2022-05-02 interactions:>0 label:"type: bug" 37 open, 135 closed

The proportion of acknowledged is 24 / (32+37+135) = 0.11
Criterion [enhancement_responses]
Atteint

Non atteint

?

Le projet DEVRAIT répondre à une majorité (>50%) des demandes d'amélioration au cours des 2 à 12 derniers mois (inclus). ^{[enhancement_responses]}
La réponse PEUT être « non » ou une discussion sur ses mérites. Le but est simplement qu'il y ait une réponse à certaines demandes, ce qui indique que le projet est toujours en vie. Aux fins de ce critère, les projets ne doivent pas compter les fausses demandes (par exemple, provenant de spammeurs ou de systèmes automatisés). Si un projet ne fait plus d'améliorations, sélectionnez « non satisfait » et incluez l'URL qui rend cette situation claire pour les utilisateurs. Si un projet tend à être submergé par le nombre de demandes d'amélioration, sélectionnez « non satisfait » et expliquez.
This query shows relevant items: https://github.com/magma/magma/issues?q=is%3Aissue+label%3A%22type%3A+enhancement%22+created%3A%3E2022-06-13+

Status of items (2 open, 1 closed):

[Enhancement] Migration of hashlists to protobuf map for imei_htbl and sac_to_tacs_map_htbl #14734 (responded to on 6/13/2023) Enable S1AP Tester for ARM based AGW for magma-ci #14102 (responded to with much discussion)
```
[Enhancement] TRF Server VM should be migrated to Ubuntu 20.04 #13203 (closed)
```
Response rate: 100%.
Criterion [report_archive]
Atteint

Non atteint

?

Le projet DOIT avoir une archive publique pour les signalements et les réponses pour une recherche ultérieure. (URL requise) ^{[report_archive]}

https://github.com/magma/magma/issues/
Processus de signalement de vulnérabilité

Criterion [vulnerability_report_process]
Atteint

Non atteint

?

Le projet DOIT publier le processus de signalement des vulnérabilités sur le site du projet. (URL requise) ^{[vulnerability_report_process]}
Les projets hébergés sur GitHub DEVRAIENT envisager d'activer le signalement privé d'une vulnérabilité de sécurité . Les projets sur GitLab DEVRAIENT envisager d'utiliser sa capacité à signaler une vulnérabilité en privé . Les projets PEUVENT identifier une adresse postale sur https://PROJECTSITE/security, souvent sous la forme security@example.org. Ce processus de rapport de vulnérabilité PEUT être le même que son processus de rapport de bogue. Les rapports de vulnérabilité PEUVENT toujours être publics, mais de nombreux projets ont un mécanisme de rapport de vulnérabilité privé.

https://github.com/magma/magma/security/policy

Criterion [vulnerability_report_private]
Atteint

Non atteint

N/A

?

Si les signalements de vulnérabilités privés sont pris en charge, le projet DOIT inclure la façon d'envoyer l'information de manière confidentielle. (URL requise) ^{[vulnerability_report_private]}
Des exemples incluent un signalement de défaut privé envoyé sur le Web en utilisant HTTPS (TLS) ou un courrier électronique chiffré à l'aide d'OpenPGP. Si les signalements de vulnérabilités sont toujours publics (donc il n'y a jamais de signalements de vulnérabilités privés), choisissez « non applicable » (N/A).

https://github.com/magma/magma/security/advisories/new

Criterion [vulnerability_report_response]
Atteint

Non atteint

N/A

?

Le temps de réponse initial du projet pour tout signalement de vulnérabilité reçu au cours des 6 derniers mois DOIT être inférieur ou égal à 14 jours. ^{[vulnerability_report_response]}
S'il n'y a pas eu de vulnérabilité signalée au cours des 6 derniers mois, choisissez « non applicable » (N/A).

These URLs are access controlled.

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).

https://github.com/magma/magma/actions

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).

https://github.com/magma/magma/actions

Criterion [build_floss_tools]
Atteint

Non atteint

N/A

?

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

Only FLOSS tools are used.
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).

https://magma.github.io/magma/docs/basics/quick_start_guide

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).

yarn run test

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]

I don't know t

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

https://github.com/magma/magma
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 ».

https://github.com/magma/magma/wiki/Contributing-Code

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.

Release notes (https://github.com/magma/magma/issues/15127) show growth in tests to accompany new features "Testing with new gNB for 5G SA"

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.

The checklist for PRs requires submitters to document how they tested, ideally with unit tests.
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.

The project uses eslint and other linters.

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.
```
Golang pass: code can be assumed to be strict because the language doesn't have a non-strict option.
C pass: "${CMAKE_C_FLAGS} ${C_FLAGS_PROCESSOR} -std=gnu99 -Wall -Wstrict-prototypes -fno-strict-aliasing 
C++ fail: -Wall is rarely used. (See find . -name CMakeLists.txt -exec grep " -W" "{}" \; -print)
Python N/A: "Python does not have a use strict or any near-equivalent as any of the safety features it provides are either mandatory or not available in the Python language, and does not have a use warnings"
Shell scripts: N/A
Javascript pass: tsconfig.json sets "strict": true
```

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 Lucas Gonze et les contributeurs du badge des meilleures pratiques de la OpenSSF.

magma

Notions de base 13/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 8/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é 14/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 7/8 ●

Analyse statique de code

Analyse dynamique de code