grid2op

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

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

Это критерии уровня Passing. Вы также можете просмотреть критерии уровня Silver или Gold.

        

 Основы 13/13

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

    Grid2Op a testbed platform to model sequential decision making in power systems.

    Какие языки программирования используются для реализации проекта?
  • Основная информация на веб-сайте проекта


    Веб-сайт проекта ОБЯЗАН кратко описывать, что делает программное обеспечение (какую проблему решает?). [description_good]

    The "index" page of the documentation has, in my opinion this first description, see https://grid2op.readthedocs.io/

    A short description is also available on the readme: https://github.com/Grid2op/grid2op?tab=readme-ov-file#core-functionalities



    Веб-сайт проекта ОБЯЗАН предоставлять информацию о том, как: получать и предоставлять обратную связь (например, отчеты об ошибках или улучшения) и вносить свой вклад в программное обеспечение. [interact]

    The project has a contribute.md file (see here https://github.com/Grid2op/grid2op/blob/master/CONTRIBUTING.md), active github issues (to provide or obtain feedback, bugs or enhancements) here https://github.com/Grid2op/grid2op/issues and a discord chanel (https://discord.gg/cYsYrPT, links on the readme of the project) for public announcements (new versions, new packages, etc.) and direct communication with the maintainer.



    В описании того, как сделать вклад, НЕОБХОДИМО объяснить процесс внесения вклада (например, используются ли pull request'ы). (Требуется URL) [contribution]

    Non-trivial contribution file in repository: https://github.com/Grid2op/grid2op/blob/master/CONTRIBUTING.md.



    В информацию о том, как внести вклад, СЛЕДУЕТ включать требования к приемлемым взносам (например, ссылку на любой требуемый стандарт кодирования). (Требуется URL) [contribution_requirements]
  • Свободная лицензия

    Под какой/какими лицензией/ями выпускается проект?



    ПО, создаваемое проектом, ОБЯЗАНО быть выпущено под свободной лицензией. [floss_license]

    The MPL-2.0 license is approved by the Open Source Initiative (OSI).



    ЖЕЛАТЕЛЬНО, чтобы все лицензии для ПО, создаваемого проектом, были одобрены Open Source Initiative (OSI). [floss_license_osi]

    The MPL-2.0 license is approved by the Open Source Initiative (OSI).



    Проект ОБЯЗАН публиковать лицензию или лицензии своих результатов в стандартном расположении в своем репозитории исходного кода. (Требуется URL) [license_location]

    Non-trivial license location file in repository: https://github.com/Grid2op/grid2op/blob/master/LICENSE.md.


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


    Проект ОБЯЗАН предоставлять базовую документацию для программного обеспечения, создаваемого проектом. [documentation_basics]

    Some documentation basics file contents found.



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

    There is a public documentation of more than 95% of the public function of grid2op available here: https://grid2op.readthedocs.io/en/latest/

    It contains also examples and "how to" to help people using the interfaces.

    This documentation is more than 700 a4 pages long when last checked.


  • Другое


    Сайты проекта (веб-сайт, репозиторий и URL-адреса для загрузки) ОБЯЗАНЫ поддерживать HTTPS с использованием TLS. [sites_https]

    Given only https: URLs.



    Проект ОБЯЗАН иметь один или несколько механизмов для обсуждения (включая предлагаемые изменения и проблемы), которые доступны для поиска, позволяют ссылаться на сообщения и темы по URL, позволяют новым людям участвовать в некоторых обсуждениях и не требуют установки на стороне клиента проприетарного программного обеспечения. [discussion]

    GitHub supports discussions on issues and pull requests.



    Проекту СЛЕДУЕТ предоставлять документацию на английском языке и иметь возможность принимать отчеты об ошибках и комментарии о коде на английском языке. [english]

    Documentation is hosted on "read the docs" () and people can submit issues through github issues here https://github.com/Grid2op/grid2op/issues. There are templates for bug report, enhancement or documentation issues.



    НЕОБХОДИМО, чтобы проект поддерживался. [maintained]


(Дополнительно) Какие другие пользователи имеют дополнительные права на редактирование этой записи значка? В настоящее время: []



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


    Проект ОБЯЗАН иметь репозиторий (хранилище) исходного кода с управлением версиями, который является общедоступным и имеет URL. [repo_public]

    Repository on GitHub, which provides public git repositories with URLs.



    Проектный репозиторий исходного кода ОБЯЗАН отслеживать, какие изменения были внесены, кто внес изменения и когда изменения были сделаны. [repo_track]

    Repository on GitHub, which uses git. git can track the changes, who made them, and when they were made.



    Чтобы обеспечить возможность для проверки другими участниками, проектный репозиторий исходного кода ОБЯЗАН включать промежуточные версии для проверки между релизами; НЕДОПУСТИМО хранить в репозитории лишь финальные версии. [repo_interim]

    The "master" branch is equal to the last published version (the one available on pypi for example)

    There are also some "dev" branch, for example https://github.com/Grid2op/grid2op/tree/dev_1.11.0 which contain the code the for the next public release. This code is open to review and merge request should be made on this branch (NB this is the last development branch as of writing, this changes for each new release. For example when grid2op 1.11.0 will be finilized, the nex development branch will be dev_1.11.1 as explained in the CONTRIBUTING.md)

    There are also development branch for particular features (2 such branches exists, see https://github.com/Grid2op/grid2op/tree/dev-switches or https://github.com/Grid2op/grid2op/tree/dev_multiagent for example) The difference with the main branch is that these contains contain code that are not ready to be merged (because not fully specified, documented, nor tested but can be reviewed and used by grid2op users. This is the case for the multi-agent branch, see for example https://github.com/Grid2op/grid2op/pull/696 for the pull-request or https://github.com/Grid2op/grid2op/issues/613 for the related issue)



    Для хранилища проектного исходного кода ЖЕЛАТЕЛЬНО использовать типовое ПО для распределенного управления версиями (например, git). [repo_distributed]

    Repository on GitHub, which uses git. git is distributed.


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


    Результаты проекта ОБЯЗАНЫ иметь уникальный идентификатор версии для каждой версии, предназначенной для конечных пользователей. [version_unique]

    Grid2op versions follow python core principles. Available version are on pypi, see, https://pypi.org/project/Grid2Op/#history



    Для выпусков ЖЕЛАТЕЛЬНО использовать семантическую либо календарную нумерацию версий. При использовании календарной нумерации к версии ЖЕЛАТЕЛЬНО добавлять микро-компоненту. [version_semver]


    Проектам ЖЕЛАТЕЛЬНО идентифицировать каждый выпуск в своей системе управления версиями. Например, при использовании git ЖЕЛАТЕЛЬНО идентифицировать каждую версию, используя теги git. [version_tags]

    It is done with git tags, see https://github.com/Grid2op/grid2op/tags (for tags) and https://github.com/Grid2op/grid2op/releases (for releases)


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


    Проект ОБЯЗАН предоставлять с каждой выпускаемой версией замечания к выпуску - удобочитаемые человеком сведения об основных изменениях в этом выпуске, помогающие пользователям определить, должны ли они обновляться и какими будут последствия обновления. НЕДОПУСТИМО делать замечания к выпуску сырым выводом журнала управления версиями (например, результаты команды «git log» не являются замечаниями к выпуску). Проекты, результаты которых не предназначены для повторного использования в нескольких местах (например, программное обеспечение для одного веб-сайта или службы) И выдаются через непрерывную доставку (continuous delivery) МОГУТ выбрать «неприменимо» (N/A). (Требуется URL) [release_notes]

    Release notes are included in the github release (see eg https://github.com/Grid2op/grid2op/releases/tag/v1.10.5) and (most of the time) public annoucements are made in a discord post see eg https://discord.com/channels/698080905209577513/698133564381724764)



    В замечаниях о выпуске НЕОБХОДИМО упоминать каждую общеизвестную уязвимость, исправленную ​​в каждой новой версии, для которой существует CVE или аналогичная публичная запись. Критерий может быть отмечен как неприменимый (N/A), если у пользователей обычно нет практической возможности обновить данное ПО самостоятельно (это часто относится к, например, обновлениям ядра операционной системы). Если замечаний о выпуске не публиковалось или не было обнародованных уязвимостей, отвечайте "неприменимо". [release_notes_vulns]

    There been no publicly known vulnerabilities yet.


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


    Проект ОБЯЗАН предоставить пользователям возможность отправлять сообщения об ошибках (например, используя систему отслеживания ошибок или список рассылки). (Требуется URL) [report_process]

    Bug reports are done using github issues (specific type of issues): https://github.com/Grid2op/grid2op/issues



    СЛЕДУЕТ использовать трекер вопросов (issue tracker) для отслеживания отдельных вопросов. [report_tracker]

    Проект ОБЯЗАН подтверждать получение большинства сообщений об ошибках, отправленных за последние 2-12 месяцев (включительно); подтверждение не обязательно включает исправление. [report_responses]

    See open github issues (https://github.com/Grid2op/grid2op/issues) (tag bug). As far as I know all of them have an answer. Bug reports are treated as soon as possible and merged in the code with the tag "[FIX]" on the changelog here https://github.com/Grid2op/grid2op/blob/master/CHANGELOG.rst, see eg https://github.com/Grid2op/grid2op/blob/master/CHANGELOG.rst#1104---2024-10-14 for a concrete example.

    This is available since the most early stage of grid (2019-11-28 is the first recorded date in the changelog)



    Проекту СЛЕДУЕТ реагировать на большинство (>50%) запросов на улучшения в течение последних 2-12 месяцев (включительно). [enhancement_responses]

    See open github issues https://github.com/Grid2op/grid2op/issues (tag enhancements). As far as I know, all of them have an answer. But not all of them are included in the codebase yet.



    Проект ОБЯЗАН иметь общедоступный архив для отчетов и ответов для последующего поиска. (Требуется URL) [report_archive]

    Done thanks to github issues https://github.com/Grid2op/grid2op/issues (as far as I know no issues have been deleted)


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


    Проект ОБЯЗАН публиковать процесс уведомления об уязвимостях на сайте проекта. (Требуется URL) [vulnerability_report_process]

    Если поддерживаются приватные отчеты об уязвимости, проект ОБЯЗАН включить описание того, как отправлять сведения конфиденциальным способом. (Требуется URL) [vulnerability_report_private]

    It is explained in https://github.com/Grid2op/grid2op?tab=security-ov-file to sent them via e mail for critical and important security vulnerabilities.



    Проект ОБЯЗАН обеспечивать время первоначального отклика на любой отчет об уязвимости, полученный за последние 6 месяцев, в пределах 14 дней или меньше. [vulnerability_report_response]

    No vulnerability has been reported as of writing


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


    Если программное обеспечение, создаваемое проектом, требует сборки для использования, проект ОБЯЗАН предоставить рабочую систему сборки, которая может автоматически пересобирать программное обеспечение из исходного кода. [build]

    Project is developed in "pure python", no build system is required.



    ЖЕЛАТЕЛЬНО использовать общеупотребительные инструменты для сборки программного обеспечения. [build_common_tools]

    Project is developed in "pure python", which does not require any build. It can be installed with the standard "pip" command.



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

    Project is developed in "pure python", which does not require any build. It can be installed with the standard "pip" command.


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


    Проект ОБЯЗАН использовать по крайней мере один автоматизированный набор тестов, опубликованный как свободное ПО (этот набор тестов может поддерживаться как отдельный проект свободного ПО). Проект ОБЯЗАН ясно показывать или иметь документацию о том, как запускать наборы тестов (например, через непрерывную интеграцию (CI) или используя файлы документации, такие как BUILD.md, README.md или CONTRIBUTING.md). [test]

    Each commit is tested on circle ci see https://app.circleci.com/pipelines/github/Grid2op/grid2op for different cases (depending on some the optional dependencies installed). More than 3000 tests are currently run automatically.

    Package is also tested using github actions https://github.com/Grid2op/grid2op/actions Tests there are lighter, but performed for different python versions and on different OS.



    Запуск набора тестов СЛЕДУЕТ реализовывать стандартным способом для этого языка. [test_invocation]

    The readme indicated how to run the tests of grid2op (see https://github.com/Grid2op/grid2op?tab=readme-ov-file#perform-tests-locally) which can be done with:

    cd grid2op/tests python3 -m unittest discover



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

    Tests are performed by circleci and github actions for all commits of all branches of the main repository.



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

    This is done with circleci and github actions.


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


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

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

    ЖЕЛАТЕЛЬНО задокументировать эту политику добавления тестов (см. критерий test_policy) в инструкции к предложениям об изменениях. [tests_documented_added]
  • Флаги предупреждений


    Проект ОБЯЗАН включать один или несколько предупреждающих флагов компилятора, «безопасный» языковой режим или использовать отдельный инструмент «linter» для поиска ошибок качества кода или типовых простых ошибок, если есть хотя бы один инструмент на свободном ПО, который может реализовать этот критерий на выбранном языке. [warnings]

    No building is required for grid2op (pure python)



    Проект ОБЯЗАН обращать внимание на предупреждения. [warnings_fixed]

    No building is required for grid2op (pure python)



    ЖЕЛАТЕЛЬНО, чтобы проекты использовали самый строгий режим предупреждений в производимом ПО, где это целесообразно. [warnings_strict]

    No building is required for grid2op (pure python)


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


    По крайней мере один основной разработчик на проекте ОБЯЗАН знать, как проектировать безопасное программное обеспечение (точные требования описаны в подробностях к критерию). [know_secure_design]


    По крайней мере, один из основных разработчиков проекта ОБЯЗАН знать об общих видах ошибок, которые приводят к уязвимостям в этом виде программного обеспечения, а также по крайней мере одному методу противодействия или смягчения каждого из них. [know_common_errors]

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

    Обратите внимание, что некоторое ПО не нуждается в использовании криптографических механизмов.

    Программное обеспечение, созданное проектом, ОБЯЗАНО использовать по умолчанию только публикуемые криптографические протоколы и алгоритмы, которые анализируются экспертами (если используются криптографические протоколы и алгоритмы). [crypto_published]

    Python standard library hashlib and urllib modules are used for such purpose anywhere appropriate.



    Если программное обеспечение, создаваемое проектом, является приложением или библиотекой, и его основной целью является не внедрение криптографии, тогда для реализации криптографических функций СЛЕДУЕТ обращаться к программному обеспечению, специально предназначенному для этого; НЕ СЛЕДУЕТ повторно реализовывать свои собственные функции. [crypto_call]

    Python standard library hashlib and urllib modules are used for such purpose anywhere appropriate.



    Вся функциональность программного обеспечения, создаваемого проектом, которая зависит от криптографии, ОБЯЗАНА быть реализована с использованием свободного ПО. [crypto_floss]

    Python standard library is FLOSS compliant.



    Механизмы безопасности в программном обеспечении, создаваемом проектом, ОБЯЗАНЫ использовать стандартные длины криптографических ключей, которые, по крайней мере, соответствуют минимальным требованиям NIST до 2030 года (как указано в 2012 году). Проект ОБЯЗАН предоставлять возможность настройки ПО таким образом, чтобы уменьшенные длины ключей были полностью отключены. [crypto_keylength]

    Default of the python standard library hashlib are not modified.



    Механизмы безопасности по умолчанию в программном обеспечении, создаваемом проектом, НЕДОПУСТИМО делать зависимыми от взломанных криптографических алгоритмов (например, MD4, MD5, single DES, RC4, Dual_EC_DRBG) или использовать режимы шифрования, которые не подходят для контекста, если только они не требуются для интероперабельности протокола (поддерживающего самую новую версию стандарта на этот протокол, широко распространенного в сетевой экосистеме, причем эта экосистема требует использования данного алгоритма или режима, не предлагая более безопасных альтернатив). В документации НЕОБХОДИМО описать все связанные с этим риски безопасности и все известные способы смягчения рисков, если данные алгоритмы или режимы действительно нужны для совместимости с другими реализациями этого протокола. [crypto_working]

    Nothing of the sort is used within the project, project code is run on the user computer using the user resources.



    Механизмы безопасности по умолчанию в программном обеспечении, создаваемом проектом, НЕ СЛЕДУЕТ делать зависимыми от криптографических алгоритмов или режимов с известными серьезными слабостями (например, криптографический алгоритм хеширования SHA-1 или режим CBC в SSH). [crypto_weaknesses]


    В механизмах безопасности в программном обеспечении, создаваемом проектом, СЛЕДУЕТ реализовать совершенную прямую секретность для протоколов соглашений о ключах, чтобы ключ сеанса, произведенный из набора долгосрочных ключей, не мог быть скомпрометирован, если один из долгосрочных ключей скомпрометирован в будущем. [crypto_pfs]

    No such concepts are used withing the project, project code is run on the user computer using the user resources.



    Если ПО, создаваемое проектом, требует хранить пароли для аутентификации внешних пользователей, НЕОБХОДИМО хранить пароли как итерированные хеши с солью для каждого пользователя с использованием алгоритма (итерированного) растяжения ключа (например, PBKDF2, Bcrypt или Scrypt). См. также: OWASP Password Storage Cheat Sheet (на англ.). [crypto_password_storage]

    No password are used by the software, project code is run on the user computer using the user resources.



    Механизмы безопасности в программном обеспечении, создаваемом проектом, ОБЯЗАНЫ генерировать все криптографические ключи и временные значения с использованием криптографически безопасного генератора случайных чисел; НЕДОПУСТИМО делать это с использованием генераторов, которые криптографически небезопасны. [crypto_random]

    No keys are generated, project code is run on the user computer using the user resources.


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


    Проект ОБЯЗАН использовать механизм доставки, устойчивый против атак посредника (MITM). Приемлемо использование https или ssh + scp. [delivery_mitm]

    data are downloaded using https



    НЕДОПУСТИМО получать криптографические контрольные суммы (например, sha1sum) по HTTP и использовать их без проверки криптографической подписи. [delivery_unsigned]

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


    НЕДОПУСТИМО оставлять незакрытыми уязвимости со степенью серьезности средней или выше, опубликованные более 60 дней назад. [vulnerabilities_fixed_60_days]


    Проектам СЛЕДУЕТ оперативно исправлять критические уязвимости после сообщения о них. [vulnerabilities_critical_fixed]

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


    НЕДОПУСТИМА утечка действующих частных учетных данных (например, рабочий пароль или закрытый ключ), предназначенных для ограничения общего доступа, из публичных репозиториев. [no_leaked_credentials]

    This is also automatically checked by github.


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


    НЕОБХОДИМО применять по крайней мере, один инструмент анализа статического кода (помимо предупреждений компилятора и "безопасных" режимов языка) к любой предлагаемой основной версии создаваемого ПО до ее выпуска, если есть хотя бы один инструмент на свободном ПО, который реализует этот критерий на выбранном языке. [static_analysis]

    2 such tools are actually used: - codacy - sonar cloud



    ЖЕЛАТЕЛЬНО включать по крайней мере в один из инструментов статического анализа, используемых для критерия static_analysis, правила или подходы для поиска распространенных уязвимостей в анализируемом языке или среде. [static_analysis_common_vulnerabilities]

    Done by both codacy and sonar cloud



    Все уязвимости со средней и высокой степенью серьезности, обнаруженные при статическом анализе кода, НЕОБХОДИМО своевременно исправлять после их подтверждения. [static_analysis_fixed]

    No vulnerabilities have been found yet.



    ЖЕЛАТЕЛЬНО выполнять анализ статического исходного кода при каждом коммите или по крайней мере ежедневно. [static_analysis_often]

    Codacy and sonarcloud are run for every merge request on every branch.


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


    ЖЕЛАТЕЛЬНО применять по крайней мере один инструмент динамического анализа к любой предлагаемой основной (major) версии программного обеспечения перед ее выпуском . [dynamic_analysis]

    Test coverage is not updated on codacy or sonarcloud (is it required ?) but it is higher than 95% for the entire project.



    ЖЕЛАТЕЛЬНО регулярно использовать по меньшей мере один динамический инструмент (например, fuzzer или сканер веб-приложения) в сочетании с механизмом для обнаружения проблем безопасности памяти, таких как перезапись буфера, если программное обеспечение, создаваемое проектом, включает части, написанные на небезопасном языке (например, C или C++). Если проект не создает программное обеспечение, написанное на небезопасном языке, выберите «неприменимо» (N/A). [dynamic_analysis_unsafe]

    Grid2op is python, which is a "memory safe" language



    ЖЕЛАТЕЛЬНО включать в ПО, создаваемое проектом, достаточно много утверждений (assertions) времени выполнения, проверяемых при динамическом анализе. Во многих случаях эти утверждения не должны попадать в сборки под эксплуатацию (production). [dynamic_analysis_enable_assertions]

    There are no difference between "released package" and "dynamic analysis" in python. Lots of assertions are performed to validate user provided data in both tests and "production".



    Проект ОБЯЗАН своевременно исправлять все уязвимости средней и выше степени серьезности, обнаруженные при динамическом анализе кода, после их подтверждения. [dynamic_analysis_fixed]

    All have been fixed



This data is available under the Community Data License Agreement – Permissive, Version 2.0 (CDLA-Permissive-2.0). This means that a Data Recipient may share the Data, with or without modifications, so long as the Data Recipient makes available the text of this agreement with the shared Data. Please credit Benjamin DONNOT and the OpenSSF Best Practices badge contributors.

Владелец анкеты на значок проекта: Benjamin DONNOT.
2025-03-31 15:06:03 UTC, последнее изменение сделано 2025-04-01 12:33:58 UTC. Значок последний раз потерян 2025-04-01 12:33:58 UTC. Последний раз условия для получения значка были выполнены 2025-04-01 09:37:55 UTC.

Назад