Linux kernel backports

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

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

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

        

 Основы 13/13 ●

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

    The Linux kernel backports project automatically backports the Linux kernel, it provide drivers released on newer kernels backported for usage on older kernels.

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

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


    Достаточно для значка!

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

    https://backports.wiki.kernel.org/index.php/Documentation


    Достаточно для значка!

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

    https://backports.wiki.kernel.org/index.php/Documentation/reporting-bugs


    Достаточно для значка!

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

    https://backports.wiki.kernel.org/index.php/Documentation/backports/hacking

    Developer's Certificate of Origin 1.1 is used, from the Linux kernel.


    Достаточно для значка!

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

    https://backports.wiki.kernel.org/index.php/Documentation/backports/hacking#Requirements_for_contributions


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

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


    Достаточно для значка!

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

    https://backports.wiki.kernel.org/index.php/License


    Достаточно для значка!

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

    Достаточно для значка!

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

    https://git.kernel.org/cgit/linux/kernel/git/backports/backports.git/tree/COPYING


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


    Достаточно для значка!

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

    https://backports.wiki.kernel.org/index.php/Documentation


    Достаточно для значка!

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

    The backports project is a subset of the Linux kernel, as such what you get out of it are Linux kernel modules or a kernel with newer drivers from a future version of Linux backported for your choice of Linux. Users can opt to download and install a packaged release, or to use the backports infrastructure for direct kernel integration. Both interfaces are documented separately:

    https://backports.wiki.kernel.org/index.php/Documentation/packaging https://backports.wiki.kernel.org/index.php/Documentation/integration

    The way this works and how this is possible is best documented through the developer documentation:

    https://backports.wiki.kernel.org/index.php/Documentation/backports/hacking

    The technical details in more elaborate detail is provided in paper form:

    http://coccinelle.lip6.fr/papers/backport_edcc15.pdf


  • Другое


    Достаточно для значка!

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

    https://www.kernel.org/pub/linux/kernel/projects/backports/ https://git.kernel.org/pub/scm/linux/kernel/git/backports/backports.git

    There is temporary "splash" page generated automatically here:

    http://drvbp1.linux-foundation.org/~mcgrof/rel-html/backports/

    However this does not use https, and is simply temporary. If we need a permanent splash page we can work on that, the tool, rel-html, used to generate the splash page just needs to be extended to automatically infer release by using PGP, PGP signed tags, and PGP signed tags for release deprecation.


    Достаточно для значка!

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

    A mailing list is public: backports@vger.kernel.org

    The archive: http://marc.info/?l=linux-backports

    To subscribe send an e-mail to majordomo@vger.kernel.org with anything on the subject and with this on the body of the e-mail: subscribe backports

    This is all documented here:

    https://backports.wiki.kernel.org/index.php/Mailing_list


    Достаточно для значка!

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

    We use the kernel.org bugzilla, users must select the Backports project section, or can use this URL directly:

    https://bugzilla.kernel.org/enter_bug.cgi?product=Backports%20project

    This is all documented for users here:

    https://backports.wiki.kernel.org/index.php/Documentation/reporting-bugs https://backports.wiki.kernel.org/index.php/Bugzilla


    Достаточно для значка!

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


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



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


    Достаточно для значка!

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

    https://git.kernel.org/pub/scm/linux/kernel/git/backports/backports.git


    Достаточно для значка!

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

    https://git.kernel.org/pub/scm/linux/kernel/git/backports/backports.git

    All changes go into the git repository. We track the changes, who made the changes, when the changes were made. Other than this we also track who merged the change. We have two key maintainers:

    Hauke Mehrtens Luis R. Rodriguez

    The repository is shared on kernel.org between both of these maintainers, they coordinate via IRC and e-mail about when one can / should merge changes.


    Достаточно для значка!

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

    The project mirrors Linux's own release mechanisms. The project relies on linux-next to generate snapshot releases based on the latest development efforts both on Linux and on the Linux backports project, these are the linux-next based snapshots. Once Linus releases a kernel as a release candidate the backports project follows with a respective release candidate for it. Once Linus blesses a final release a respective backports project follows through with a respective final release.

    During the development phase of Linux we have daily linux-next based snapshots, these are dated, the latest one being based on linux-next tag next-20160122, and so the respective backports release is:

    https://www.kernel.org/pub/linux/kernel/projects/backports/2016/01/22/backports-20160122.tar.gz

    Packaged releases are also made to mirror Linux stable releases, so for instance we have the v3.10-rc1 release:

    https://www.kernel.org/pub/linux/kernel/projects/backports/stable/v3.10-rc1/

    Then the v3.10 final release:

    https://www.kernel.org/pub/linux/kernel/projects/backports/stable/v3.10/

    After that we have follow up fixes to upstream Linux, and then a respective backports release for it, there were 3 extra version releases for v3.10:

    https://www.kernel.org/pub/linux/kernel/projects/backports/stable/v3.10.4/ https://www.kernel.org/pub/linux/kernel/projects/backports/stable/v3.10.17/ https://www.kernel.org/pub/linux/kernel/projects/backports/stable/v3.10.19/

    If the need ever arises to make a backports release update between the same snapshot of Linux a postfix digit is used to annotate this. For instance, we had two v3.8-rc2 releases, -1 and -2:

    https://www.kernel.org/pub/linux/kernel/projects/backports/stable/v3.8-rc2/compat-drivers-3.8-rc2-1.tar.bz2 https://www.kernel.org/pub/linux/kernel/projects/backports/stable/v3.8-rc2/compat-drivers-3.8-rc2-2.tar.bz2


    Достаточно для значка!

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

    Git is used:

    https://git.kernel.org/cgit/linux/kernel/git/backports/backports.git/


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


    Достаточно для значка!

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

    The release tags for backports mirror the Linux kernel release scheme. When releases are made based on linux-next, the respective tag is used but instead of "next", "backports" is used. So for instance, a release based on linux-next next-20160122 would have a tag "backports-20160122".

    For stable releases the same Linux versioning scheme is followed, starting with release candidates (v3.10-rc1-1, v3.10-rc1-2), to final version (v3.10-1, v3.10-2), to extra version stable updates (v3.10.4-1, v3.10.19-1):

    v3.10-1 v3.10-2 v3.10-rc1-1 v3.10-rc1-2 v3.10.17-1 v3.10.17-2 v3.10.19-1 v3.10.4-1

    Since this project builds on Linux, we needed a way to distinguish between backport specific releases. This is accounted for the extra dash followed by the release number, so v3.10-1, v3.10-2, both -1 and -2 are backport specific annotations.


    Едва достаточно для значка.

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

    The Linux kernel does not make API changes that affect userspace, so there is no need to have denote api compatibility, it is always stable.


    Достаточно для значка!

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

    Here's an example release using tag backports-20160122

    https://git.kernel.org/cgit/linux/kernel/git/backports/backports.git/tag/?h=backports-20160122

    Likewise, here's a stable release using tag v4.4.2-1:

    https://git.kernel.org/cgit/linux/kernel/git/backports/backports.git/tag/?h=v4.4.2-1


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


    Достаточно для значка!

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

    Since the backports project mirrors Linux the ChangeLog of Linux is referred to for changes, backport specific updates are too many to list, but major updates are referenced when a release is made, and the respective project README is updated to account for subsystems that are backported. This is available here:

    https://git.kernel.org/cgit/linux/kernel/git/backports/backports.git/tree/README

    When a new device driver is added it is mentioned only in the commit logs, we could do a better job at not only annotating subsystems but also device drivers, this becomes tricky however as we backport over 700 device drivers now. We will discuss what things we can do better to improve on this area.


    Достаточно для значка!

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

    The backports project builds on top of Linux, the amount of backports specific code accounts for about 1%-2% of the code used. Although there is a risk of a security issue within backports, the major attack surface consists of non-backports related code: device drivers, or libraries carried over. Security fixes from Linux are carried over, we do not explicitly mirror the changelog of Linux, instead refer people to Linux' own changelog for security fixes on Linux.


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


    Достаточно для значка!

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

    This is documented here:

    https://backports.wiki.kernel.org/index.php/Documentation/reporting-bugs https://backports.wiki.kernel.org/index.php/Bugzilla


    Достаточно для значка!

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

    The "Backports project" section of bugzilla is used.


    Достаточно для значка!

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

    Example of latest fixes:

    https://bugzilla.kernel.org/show_bug.cgi?id=105921 https://bugzilla.kernel.org/show_bug.cgi?id=71501 https://bugzilla.kernel.org/show_bug.cgi?id=66601 https://bugzilla.kernel.org/show_bug.cgi?id=65881

    Sadly most reports are bogus. Most issues are actually reported on the mailing list and addressed there. There is no metric to address the number of issues mentioned on the mailing list and fixed there. We however do have an archive.


    Достаточно для значка!

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

    The mailing list is used for this and requests to add new drivers considered and discussed.


    Достаточно для значка!

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

    Bugzilla is used:

    https://backports.wiki.kernel.org/index.php/Bugzilla

    The project also has mailing list and that is archivedi

    https://backports.wiki.kernel.org/index.php/Mailing_list


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


    Достаточно для значка!

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

    https://backports.wiki.kernel.org/index.php/Reporting-vulnerabilities

    This explains the process to follow to report vulnerabilities.


    Достаточно для значка!

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

    It is requested private vulnerabilities are reported via e-mail directly to the Linux backports maintainers. This is documented here:

    https://backports.wiki.kernel.org/index.php/Reporting-vulnerabilities


    Достаточно для значка!

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

    We have not had any vulnerabilities reported.


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


    Достаточно для значка!

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

    Since Linux backports mirrors Linux, the build testing / automatic builds are borrowed, so linux-next daily builds are done by IBM, likewise, Intel's 0-day test infrastructure . There is no home page to linux-next daily builds tests, but its known that this merges all development trees and there is a compile test done daily. 0-day's home page:

    https://01.org/lkp

    Other than this currently backports build tests are done prior to each release, since all supported kernels need to be tested against, currently 24 kernels need to be compile tested against, compile testing with all features enabled takes a long time. HP, Linux Foundation, and SUSE donated a server to help with this, we grant access to key developers to help build test prior to making a release, or when incorporating a patch to test the build.

    We will work on automating builds though this may be a bit complex given the overhead.


    Достаточно для значка!

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

    All required tools are free and open source software. The same tools to build Linux are the same tools to build backports Linux releases, with the addition of Coccinelle needed to generate packages for users. Only developers need coccinelle. Needed tools to build Linux backports packages:

    make gcc python perl

    When using integration the kernel is built as you typically would otherwise build the Linux kernel.


    Достаточно для значка!

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

    All required tools are the same to build Linux, its obvious Linux can only be built by open source tools.


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


    Достаточно для значка!

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

    Intel uses Linux backports for their own builds / release for users of 802.11 wifi. They have a series of run time tests against the 802.11 Intel wifi driver. This test the 802.11 subsystem and Intel's specific device driver against specific kernels.

    Its not okay to not have a generic run time automation test suite, this however is a bit complex though as it would mean testing at run time Linux backports builds on each supported 24 kernels for each release. There is also the issue of needing emulated devices to load and test drivers. This is a major undertaking. Some form of automating run time testing is desirable. As it stands we rely on independent stakeholders to do their own run time testing of supported device drivers. The rest of the drivers are supported as best effort.


    Достаточно для значка!

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

    Едва достаточно для значка.

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

    We definitely cannot test all known functions provided. We will try to at least do as much testing as possible in the future, but this will be restricted to what drivers can be emulated, and to each stakeholder's interest in the project and its driver's users.


    Достаточно для значка!

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

    The 0-day bot does testing of every commit before it is merged into the main repository.


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


    Достаточно для значка!

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

    Достаточно для значка!

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

    Едва достаточно для значка.

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

    Not yet done.


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


    Достаточно для значка!

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

    Since Linux kernel code is used we match the same practice and use the same tools to help look for issues. The same build flags are also used. The kernel build process enables a lot of warning flags, and it also provides the tool 'sparse' to check for many other coding problems. And a full test suite of coccineele scripts is integrated into the kernel source tree itself.


    Достаточно для значка!

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

    Достаточно для значка!

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

    Where ever practical, all warnings are fixed.


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


    Достаточно для значка!

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

    Достаточно для значка!

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

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

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

    Достаточно для значка!

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

    Достаточно для значка!

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

    Достаточно для значка!

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

    Достаточно для значка!

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

    Достаточно для значка!

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

    Достаточно для значка!

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

    Достаточно для значка!

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

    Достаточно для значка!

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

    Достаточно для значка!

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

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


    Достаточно для значка!

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

    Достаточно для значка!

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

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


    Достаточно для значка!

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

    Достаточно для значка!

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

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


    Достаточно для значка!

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

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


    Не хватает обязательной информации, недостаточно для значка.

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

    Предупреждение: Нужно обоснование подлиннее.


    Достаточно для значка!

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

    Достаточно для значка!

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

    Достаточно для значка!

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

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


    Достаточно для значка!

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

    Достаточно для значка!

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

    Достаточно для значка!

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

    Достаточно для значка!

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


Эти данные доступны под лицензией Creative Commons Attribution версии 3.0 (CC-BY-3.0) в соответствии с условиями использования Open Source Security Foundation. Все могут свободно делиться и адаптировать эти данные, но должны указывать соответствующие ссылки. При распространении, пожалуйста, указывайте "Luis Rodriguez and the OpenSSF Best Practices badge contributors".
Владелец анкеты на значок проекта: Luis Rodriguez.
2016-05-04 16:39:37 UTC, последнее изменение сделано 2016-05-19 15:28:55 UTC. Значок последний раз потерян 2021-04-11 18:16:21 UTC. Последний раз условия для получения значка были выполнены 2016-05-04 22:16:00 UTC.

Назад