marko

Проекты, которые следуют приведенным ниже лучшим практикам, могут добровольно и самостоятельно оценить себя и продемонстрировать, что они получили значок Open Source Security Foundation (OpenSSF).

Не существует набора практик, гарантирующего, что у программного обеспечения никогда не будет недостатков или уязвимостей; даже формальные методы могут не помочь, если спецификации или допущения ошибочны. Также не существует какой-либо практики, которая могла бы гарантировать, что проект будет поддерживать здоровое и хорошо функционирующее сообщество разработчиков. Однако следующие хорошие правила могут помочь улучшить результаты проектов. Например, некоторые правила описывают ревью несколькими участниками перед выпуском, что может помочь найти технические уязвимости, которые было бы сложно найти другим способом, и помочь построить доверие и желание дальнейшего взаимодействия между разработчиками из разных компаний. Чтобы получить значок, нужно выполнить все критерии с ключевыми словами "НЕОБХОДИМО"/"ОБЯЗАН"/"НЕДОПУСТИМО", все критерии со словом "СЛЕДУЕТ" либо должны удовлетворяться, либо должно быть приведено обоснование их невыполнения, и все критерии со словом "ЖЕЛАТЕЛЬНО" могут быть удовлетворены ИЛИ неудовлетворены (желательно, чтобы они были хотя бы рассмотрены). Если вы хотите ввести общий комментарий вместо объяснения, почему текущая ситуация приемлема, начните текст с '//' и пробела. Приветствуется обратная связь через сайт на GitHub в виде issues или pull requests. Существует также список рассылки для общих вопросов.

Мы с удовольствием предоставляем информацию на нескольких языках, однако, если есть какой-либо конфликт или несоответствие между переводами, английская версия является авторитетной.

Если это ваш проект, пожалуйста, покажите свой значок на странице проекта! Статус значка выглядит следующим образом:

Уровень значка для проекта 7029 - in_progress

Вот как вставить его:

Вы можете показать свой статус значка, вставив его в файл с разметкой Markdown:

[![OpenSSF Best Practices](https://www.bestpractices.dev/projects/7029/badge)](https://www.bestpractices.dev/projects/7029)

- или HTML:
<a href="https://www.bestpractices.dev/projects/7029"><img src="https://www.bestpractices.dev/projects/7029/badge"></a>

Это критерии уровня

. Вы также можете просмотреть критерии уровня

или

Качество 13/13 ●

Рабочая система сборки

Criterion [build]
Соответствует

Не соответствует

Неприменимо

?

Если программное обеспечение, создаваемое проектом, требует сборки для использования, проект ОБЯЗАН предоставить рабочую систему сборки, которая может автоматически пересобирать программное обеспечение из исходного кода. ^[build]
Система сборки определяет, какие действия необходимо предпринять для пересборки программного обеспечения (и в каком порядке), а затем выполняет эти действия. Например, она может вызывать компилятор для компиляции исходного кода. Если исполняемый файл создается из исходного кода, должна иметься возможность изменить исходный код проекта, а затем сгенерировать обновленный исполняемый файл с этими изменениями. Если программное обеспечение, создаваемое проектом, зависит от внешних библиотек, система сборки не обязана пересобирать эти внешние библиотеки. Если для использования программного обеспечения после изменения его исходного кода пересборка не требуется, выберите «неприменимо» (N/A).

https://github.com/marko-js/marko/blob/main/package.json contains a script build
Criterion [build_common_tools]
Соответствует

Не соответствует

Неприменимо

?

ЖЕЛАТЕЛЬНО использовать общеупотребительные инструменты для сборки программного обеспечения. ^{[build_common_tools]}
Например, Maven, Ant, cmake, autotools, make, rake или devtools (R).
All the tools used in the build scripts at https://github.com/marko-js/marko/blob/main/package.json are well known:
```
"build": "npm exec --ws -- babel ./src --out-dir ./dist --delete-dir-on-start --copy-files --config-file ../../babel.config.js --env-name=production && npm run build:types",
"build:types": "node scripts/types-babel-types.mjs > packages/compiler/dist/types.d.ts && node scripts/types-babel-traverse.js > packages/compiler/dist/traverse.d.ts",
"publish": "ENTRY=main:npm npm run set-entry && npm run build && changeset publish && ENTRY=main:dev npm run set-entry && npm ci",
```
Criterion [build_floss_tools]
Соответствует

Не соответствует

Неприменимо

?

Для сборки проекта СЛЕДУЕТ использовать только инструменты со свободными лицензиями. ^{[build_floss_tools]}

Tools in build script -

npm: Artistic License 2.0 babel: MIT license node: MIT license changeset: MIT license
Набор автотестов

Criterion [test]
Соответствует

Не соответствует

?

Проект ОБЯЗАН использовать по крайней мере один автоматизированный набор тестов, опубликованный как свободное ПО (этот набор тестов может поддерживаться как отдельный проект свободного ПО). Проект ОБЯЗАН ясно показывать или иметь документацию о том, как запускать наборы тестов (например, через непрерывную интеграцию (CI) или используя файлы документации, такие как BUILD.md, README.md или CONTRIBUTING.md). ^[test]
Проект МОЖЕТ использовать несколько автоматизированных наборов тестов (например, один, который работает быстро, а другой - более тщательный, но требует специального оборудования). Существует множество каркасов (frameworks) и систем поддержки тестирования, включая Selenium (автоматизация веб-браузера), Junit (JVM, Java), RUnit (R), testthat (R).

Unit tests use Mocha.

Criterion [test_invocation]
Соответствует

Не соответствует

?

Запуск набора тестов СЛЕДУЕТ реализовывать стандартным способом для этого языка. ^{[test_invocation]}
Например, «make check», «mvn test» или «rake test» (Ruby).

npm run test

Criterion [test_most]
Соответствует

Не соответствует

?

ЖЕЛАТЕЛЬНО охватывать набором тестов большинство (а в идеале все) ветви кода, поля ввода и функциональные возможности. ^[test_most]

89.73%

File | % Stmts | % Branch | % Funcs | % Lines | Uncovered Line #s ---------------------------------------|---------|----------|---------|---------|------------------- All files | 89.73 | 83.34 | 86.93 | 89.93 |

Criterion [test_continuous_integration]
Соответствует

Не соответствует

?

ЖЕЛАТЕЛЬНО реализовать непрерывную интеграцию (Continuous Integration - частая интеграция нового или измененного кода в центральное хранилище кода, и запуск автоматических тестов на получившейся базе кода). ^{[test_continuous_integration]}

Tests are run on push to the main branch. See e.g. https://github.com/marko-js/marko/actions/runs/4208297860
Тестирование новых функций

Criterion [test_policy]
Соответствует

Не соответствует

?

Проект ОБЯЗАН иметь общую политику (формальную или нет), обязывающую добавлять тесты в набор автоматических тестов по мере добавления новых функциональных возможностей к программному обеспечению, создаваемому проектом. ^{[test_policy]}
Если есть действующая политика, хотя бы «из уст в уста», которая говорит, что разработчики должны добавлять тесты в набор автотестов для новой функциональности, указывайте «соответствует».

The test coverage of 90% would be impossible if this wasn't true.

Criterion [tests_are_added]
Соответствует

Не соответствует

?

Проект ОБЯЗАН иметь доказательства того, что критерий test_policy о добавлении тестов соблюдался при недавних крупных изменениях ПО, создаваемого проектом. ^{[tests_are_added]}
Крупная функциональность обычно упоминается в замечаниях к выпуску. Совершенство не требуется, просто доказательство того, что на практике тесты обычно добавляются в набор автотестов, когда к ПО, создаваемому проектом, добавляются новые крупные функции.

The feature PR at https://github.com/marko-js/marko/pull/1836/files includes tests.
Criterion [tests_documented_added]
Соответствует

Не соответствует

?

ЖЕЛАТЕЛЬНО задокументировать эту политику добавления тестов (см. критерий test_policy) в инструкции к предложениям об изменениях. ^{[tests_documented_added]}
Однако даже неформальное правило приемлемо, если тесты добавляются на практике.
The template for "feat:" PRs has a checklist that includes a requirement that tests be added.

`Checklist:
- [ ] I have read the CONTRIBUTING document and have signed (or will sign) the CLA.
- [ ] I have updated/added documentation affected by my changes.
- [ ] I have added tests to cover my changes.`
Флаги предупреждений

Criterion [warnings]
Соответствует

Не соответствует

Неприменимо

?

Проект ОБЯЗАН включать один или несколько предупреждающих флагов компилятора, «безопасный» языковой режим или использовать отдельный инструмент «linter» для поиска ошибок качества кода или типовых простых ошибок, если есть хотя бы один инструмент на свободном ПО, который может реализовать этот критерий на выбранном языке. ^[warnings]
Примером предупреждающего флага компилятора может служить "-Wall" для gcc/clang. Примеры «безопасного» языкового режима включают «use strict» в JavaScript и «use warnings» в perl5. Отдельный инструмент «linter» - это просто инструмент, который исследует исходный код для поиска ошибок качества кода или типовых простых ошибок. Всё это обычно включается в исходный код или инструкции сборки.

package.json has linting scripts:

"lint": "npm run lint:eslint && npm run lint:prettier -- -l", "lint:eslint": "eslint -f visualstudio .", "lint:prettier": "prettier \"./**/*{.ts,.js,.json,.md,.yml}\"",

Criterion [warnings_fixed]
Соответствует

Не соответствует

Неприменимо

?

Проект ОБЯЗАН обращать внимание на предупреждения. ^{[warnings_fixed]}
Речь о предупреждениях, найденных при выполнении критерия warnings. Проект должен исправлять предупреждения или отмечать их в исходном коде как ложные срабатывания. В идеале не должно быть никаких предупреждений, но проект МОЖЕТ принимать существование каких-то предупреждений (обычно менее 1 предупреждения на 100 строк или менее 10 предупреждений).

The lint script invokes prettier to fix warnings at the level of convention.

Criterion [warnings_strict]
Соответствует

Не соответствует

Неприменимо

?

ЖЕЛАТЕЛЬНО, чтобы проекты использовали самый строгий режим предупреждений в производимом ПО, где это целесообразно. ^{[warnings_strict]}
Некоторые предупреждения не могут быть эффективно задействованы в некоторых проектах. Что необходимо в этом критерии - это доказательства того, что проект стремится включать флаги предупреждений там, где это возможно, чтобы ошибки обнаруживались на ранней стадии.

The tool used doesn't really have that feature. At least it is invoked with the -l flag to alert devs to noncormant files.

Эти данные доступны под лицензией Creative Commons Attribution версии 3.0 или более поздней (CC-BY-3.0+). Все могут свободно делиться и адаптировать эти данные, но должны указывать соответствующие ссылки. При распространении, пожалуйста, указывайте "Lucas Gonze and the OpenSSF Best Practices badge contributors".

Владелец анкеты на значок проекта: Lucas Gonze.
2023-02-16 00:46:08 UTC, последнее изменение сделано 2023-04-13 20:38:26 UTC.

marko

Основы 13/13 ●

Идентификация

Основная информация на веб-сайте проекта

Свободная лицензия

Документация

Другое

Управление изменениями 9/9 ●

Публичное хранилище исходного кода с поддержкой версий

Уникальная нумерация версий

Примечания к выпуску

Отчеты о проблемах 8/8 ●

Процесс сообщения об ошибках

Процесс отчета об уязвимостях

Качество 13/13 ●

Рабочая система сборки

Набор автотестов

Тестирование новых функций

Флаги предупреждений

Безопасность 14/16 ●

Знание безопасной разработки

Основы правильного использования криптографии

Доставка, защищенная от атак посредника (MITM)

Исправление обнародованных уязвимостей

Другие вопросы безопасности

Анализ 8/8 ●

Статический анализ кода

Динамический анализ кода