111 lines
8.5 KiB
Markdown
111 lines
8.5 KiB
Markdown
# Участники разработки
|
||
|
||
## Правовые аспекты и требования к контрибуторам
|
||
|
||
Настоящий документ устанавливает требования и процедуры для участников разработки программного изделия (ПИ) «Ъ» (компонент «Токенизатор») в рамках Проекта «Твердь».
|
||
|
||
---
|
||
|
||
### 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. Конфиденциальность и безопасность
|
||
|
||
* Участники разработки обязаны соблюдать требования конфиденциальности в отношении деталей реализации, касающихся безопасности.
|
||
* Обсуждение уязвимостей и вопросов безопасности должно проводиться в установленном порядке.
|
||
* Запрещается внесение изменений, которые могут компрометировать безопасность системы или создавать векторы атак.
|
||
|
||
---
|
||
|
||
### Примечания
|
||
|
||
* Настоящий документ может быть дополнен в соответствии с требованиями проекта и стандартами безопасной разработки.
|
||
* Все участники разработки должны быть ознакомлены с требованиями данного документа перед началом работы над проектом.
|
||
|