tverd-plus-tokenizer/docs/CONTRIBUTORS.md

Участники разработки

Правовые аспекты и требования к контрибуторам

Настоящий документ устанавливает требования и процедуры для участников разработки программного изделия (ПИ) «Ъ» (компонент «Токенизатор») в рамках Проекта «Твердь».

---

1. Общие положения

Разработка ПИ ведется в соответствии с требованиями к безопасной разработке (SDL) и направлена на создание детерминированного системного программного обеспечения, предназначенного для сертификации на отсутствие недекларированных возможностей (НДВ).

2. Требования к участникам разработки

2.1. Квалификационные требования

Участники разработки должны обладать:

• Технической компетентностью: Знание языка программирования Rust, понимание принципов компиляторостроения, лексического анализа и обработки формальных грамматик.
• Безопасностью разработки: Понимание принципов безопасной разработки программного обеспечения, знание методов защиты от внедрения уязвимостей.
• Специализацией: Опыт работы с системами, требующими сертификации, понимание специфики разработки для архитектур семейства «Эльбрус» и x86.

2.2. Обязательства участников

• Соблюдение принципов безопасной разработки (SDL) на всех этапах жизненного цикла программного обеспечения.
• Обеспечение прослеживаемости всех изменений кода и документации.
• Строгое следование установленным стандартам кодирования и архитектурным решениям проекта.
• Гарантирование отсутствия недекларированных возможностей в реализуемом коде.

3. Процедура внесения изменений

3.1. Подготовка изменений

• Все изменения должны быть задокументированы с указанием мотивации и области применения.
• Изменения должны сопровождаться соответствующими тестами, обеспечивающими верификацию функциональности.
• Код должен соответствовать требованиям no_std окружения и не использовать внешние динамические библиотеки.

3.2. Процесс ревью

• Все изменения проходят обязательное ревью кода с фокусом на безопасность и соответствие требованиям проекта.
• Особое внимание уделяется проверке отсутствия потенциальных векторов атак и скрытых возможностей.
• Изменения, затрагивающие критичные компоненты (токенизатор, обработка UTF-8, грамматика), требуют расширенного ревью.

3.3. Требования к коммитам

• Коммиты должны содержать четкое описание внесенных изменений.
• Ссылки на соответствующие задачи и требования технического задания.
• Информация о влиянии изменений на безопасность и детерминизм системы.

4. Области ответственности

4.1. Модули проекта

Модуль	Область ответственности	Критичность
tokenizer.rs	Основной лексический анализатор	Высокая
token.rs	Определения типов токенов	Высокая
grammar.rs	Правила и константы грамматики	Высокая
dfa.rs	Состояния детерминированного конечного автомата	Высокая
utf8.rs	Обработка UTF-8 последовательностей	Высокая
position.rs	Отслеживание позиций токенов	Средняя
error.rs	Обработка ошибок	Средняя
comment.rs	Обработка комментариев	Низкая

4.2. Тестирование

• Все новые функции должны сопровождаться соответствующими тестами.
• Особое внимание уделяется тестам для кириллических идентификаторов и обработки UTF-8.
• Интеграционные тесты должны покрывать критические сценарии использования.

5. Контроль качества кода

5.1. Статический анализ

• Код должен проходить статический анализ без ошибок и предупреждений.
• Использование механизмов строгой типизации языка Rust для обеспечения безопасности на этапе компиляции.
• Соблюдение принципов no_std разработки.

5.2. Проверка безопасности

• Анализ на наличие потенциальных уязвимостей безопасности.
• Проверка отсутствия недекларированных возможностей.
• Верификация детерминизма реализуемых алгоритмов.

6. Документирование

6.1. Требования к документации

• Все публичные функции и структуры должны содержать документацию в формате Rust doc.
• Изменения в грамматике языка должны отражаться в файле docs/grammar.md.
• Критические архитектурные решения должны документироваться отдельно.

6.2. Обновление документации

• Документация должна обновляться синхронно с изменениями кода.
• Изменения в API должны быть задокументированы с указанием причин и миграционных путей.

7. Конфиденциальность и безопасность

• Участники разработки обязаны соблюдать требования конфиденциальности в отношении деталей реализации, касающихся безопасности.
• Обсуждение уязвимостей и вопросов безопасности должно проводиться в установленном порядке.
• Запрещается внесение изменений, которые могут компрометировать безопасность системы или создавать векторы атак.

---

Примечания

• Настоящий документ может быть дополнен в соответствии с требованиями проекта и стандартами безопасной разработки.
• Все участники разработки должны быть ознакомлены с требованиями данного документа перед началом работы над проектом.