BadgeApp

Reporting 8/8 ●

Bug-reporting process

Criterion [report_process]
Met

Unmet

?

The project MUST provide a process for users to submit bug reports (e.g., using an issue tracker or a mailing list). (URL required) ^{[report_process]}

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

Criterion [report_tracker]
Met

Unmet

?

The project SHOULD use an issue tracker for tracking individual issues. ^{[report_tracker]}

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

Criterion [report_responses]
Met

Unmet

?

The project MUST acknowledge a majority of bug reports submitted in the last 2-12 months (inclusive); the response need not include a fix. ^{[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]
Met

Unmet

?

The project SHOULD respond to a majority (>50%) of enhancement requests in the last 2-12 months (inclusive). ^{[enhancement_responses]}
The response MAY be 'no' or a discussion about its merits. The goal is simply that there be some response to some requests, which indicates that the project is still alive. For purposes of this criterion, projects need not count fake requests (e.g., from spammers or automated systems). If a project is no longer making enhancements, please select "unmet" and include the URL that makes this situation clear to users. If a project tends to be overwhelmed by the number of enhancement requests, please select "unmet" and explain.
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]
Met

Unmet

?

The project MUST have a publicly available archive for reports and responses for later searching. (URL required) ^{[report_archive]}

https://github.com/magma/magma/issues/
Vulnerability report process

Criterion [vulnerability_report_process]
Met

Unmet

?

The project MUST publish the process for reporting vulnerabilities on the project site. (URL required) ^{[vulnerability_report_process]}
Projects hosted on GitHub SHOULD consider enabling privately reporting a security vulnerability. Projects on GitLab SHOULD consider using its ability for privately reporting a vulnerability. Projects MAY identify a mailing address on https://PROJECTSITE/security, often in the form security@example.org. This vulnerability reporting process MAY be the same as its bug reporting process. Vulnerability reports MAY always be public, but many projects have a private vulnerability reporting mechanism.

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

Criterion [vulnerability_report_private]
Met

Unmet

N/A

?

If private vulnerability reports are supported, the project MUST include how to send the information in a way that is kept private. (URL required) ^{[vulnerability_report_private]}
Examples include a private defect report submitted on the web using HTTPS (TLS) or an email encrypted using OpenPGP. If vulnerability reports are always public (so there are never private vulnerability reports), choose "not applicable" (N/A).

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

Criterion [vulnerability_report_response]
Met

Unmet

N/A

?

The project's initial response time for any vulnerability report received in the last 6 months MUST be less than or equal to 14 days. ^{[vulnerability_report_response]}
If there have been no vulnerabilities reported in the last 6 months, choose "not applicable" (N/A).

These URLs are access controlled.

Quality 12/13 ●

Working build system

Criterion [build]
Met

Unmet

N/A

?

Ikiwa programu iliyotengenezwa na mradi inahitaji ujenzi wa matumizi, mradi LAZIMA utoe mfumo wa kujenga ambao unaweza kujenga programu kiotomatiki kutoka kwa chanzo-msimbo. ^[build]
Mfumo wa kujenga huamua ni hatua gani zinahitaji kutendeka ili kujenga tena programu (na kwa mpangilio gani), na kisha kutekeleza hatua hizo. Kwa mfano, inaweza kuomba kikusanyaji kukusanya fumbo-chanzo. Ikiwa inayoweza kutekelezwa imeundwa kutoka kwa fumbo-chanzo, lazima iwezeshe marekebisho kwenye fumbo-chanzo ya mradi na kisha itengeneze msasisho inayoweza kutekelezwa na marekebisho hayo. Ikiwa programu iliyotolewa na mradi unategemea maktaba ya nje, mfumo wa kujenga haina haja ya kujenga maktaba hizo za nje. Ikiwa hakuna haja ya kujenga chochote kutumia programu baada ya fumbo-chanzo kubadilishwa, chagua "haitumiki" (N / A).

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

Criterion [build_common_tools]
Met

Unmet

N/A

?

INAPENDEKEZWA kuwa zana za kawaida zitumike kujenga programu. ^{[build_common_tools]}
Kwa mfano, Maven, Ant, cmake, autotools, make, rake (Ruby), au devtools (R).

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

Criterion [build_floss_tools]
Met

Unmet

N/A

?

Mradi UNAPASWA kujengwa kwa kutumia zana za FLOSS pekee yake. ^{[build_floss_tools]}

Only FLOSS tools are used.
Automated test suite

Criterion [test]
Met

Unmet

?

The project MUST use at least one automated test suite that is publicly released as FLOSS (this test suite may be maintained as a separate FLOSS project). The project MUST clearly show or document how to run the test suite(s) (e.g., via a continuous integration (CI) script or via documentation in files such as BUILD.md, README.md, or CONTRIBUTING.md). ^[test]
The project MAY use multiple automated test suites (e.g., one that runs quickly, vs. another that is more thorough but requires special equipment). There are many test frameworks and test support systems available, including Selenium (web browser automation), Junit (JVM, Java), RUnit (R), testthat (R).

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

Criterion [test_invocation]
Met

Unmet

?

A test suite SHOULD be invocable in a standard way for that language. ^{[test_invocation]}
For example, "make check", "mvn test", or "rake test" (Ruby).

yarn run test

Criterion [test_most]
Met

Unmet

?

It is SUGGESTED that the test suite cover most (or ideally all) the code branches, input fields, and functionality. ^[test_most]

I don't know t

Criterion [test_continuous_integration]
Met

Unmet

?

It is SUGGESTED that the project implement continuous integration (where new or changed code is frequently integrated into a central code repository and automated tests are run on the result). ^{[test_continuous_integration]}

https://github.com/magma/magma
New functionality testing

Criterion [test_policy]
Met

Unmet

?

The project MUST have a general policy (formal or not) that as major new functionality is added to the software produced by the project, tests of that functionality should be added to an automated test suite. ^{[test_policy]}
As long as a policy is in place, even by word of mouth, that says developers should add tests to the automated test suite for major new functionality, select "Met."

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

Criterion [tests_are_added]
Met

Unmet

?

The project MUST have evidence that the test_policy for adding tests has been adhered to in the most recent major changes to the software produced by the project. ^{[tests_are_added]}
Major functionality would typically be mentioned in the release notes. Perfection is not required, merely evidence that tests are typically being added in practice to the automated test suite when new major functionality is added to the software produced by the project.

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

Unmet

?

It is SUGGESTED that this policy on adding tests (see test_policy) be documented in the instructions for change proposals. ^{[tests_documented_added]}
However, even an informal rule is acceptable as long as the tests are being added in practice.

The checklist for PRs requires submitters to document how they tested, ideally with unit tests.
Warning flags

Criterion [warnings]
Met

Unmet

N/A

?

The project MUST enable one or more compiler warning flags, a "safe" language mode, or use a separate "linter" tool to look for code quality errors or common simple mistakes, if there is at least one FLOSS tool that can implement this criterion in the selected language. ^[warnings]
Examples of compiler warning flags include gcc/clang "-Wall". Examples of a "safe" language mode include JavaScript "use strict" and perl5's "use warnings". A separate "linter" tool is simply a tool that examines the source code to look for code quality errors or common simple mistakes. These are typically enabled within the source code or build instructions.

The project uses eslint and other linters.

Criterion [warnings_fixed]
Met

Unmet

N/A

?

The project MUST address warnings. ^{[warnings_fixed]}
These are the warnings identified by the implementation of the warnings criterion. The project should fix warnings or mark them in the source code as false positives. Ideally there would be no warnings, but a project MAY accept some warnings (typically less than 1 warning per 100 lines or less than 10 warnings).
Criterion [warnings_strict]
Met

Unmet

N/A

?

It is SUGGESTED that projects be maximally strict with warnings in the software produced by the project, where practical. ^{[warnings_strict]}
Some warnings cannot be effectively enabled on some projects. What is needed is evidence that the project is striving to enable warning flags where it can, so that errors are detected early.
```
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
```

This data is available under the Creative Commons Attribution version 3.0 or later license (CC-BY-3.0+). All are free to share and adapt the data, but must give appropriate credit. Please credit Lucas Gonze and the OpenSSF Best Practices badge contributors.

magma

Basics 13/13 ●

Identification

Basic project website content

FLOSS license

Documentation

Other

Change Control 9/9 ●

Public version-controlled source repository

Unique version numbering

Release notes

Reporting 8/8 ●

Bug-reporting process

Vulnerability report process

Quality 12/13 ●

Working build system

Automated test suite

New functionality testing

Warning flags

Security 14/16 ●

Secure development knowledge

Use basic good cryptographic practices

Secured delivery against man-in-the-middle (MITM) attacks

Publicly known vulnerabilities fixed

Other security issues

Analysis 7/8 ●

Static code analysis

Dynamic code analysis