Перейти к содержанию

Эксплуатация, обновления и повторные испытания ГОСТ CMS

Проверенная криптография может перестать работать после обновления GnuPG, libksba, libgcrypt, OpenSSL Engine или криптопровайдера второй стороны. Для НАЙС.ОС рекомендуется оформлять регрессионный набор и запускать его после каждой публикации соответствующих RPM.

Зафиксируйте эталон

Известная успешная конфигурация на 24.10.2026:

GPGSM:     2.4.8.1-gost
RPM GnuPG: 2.4.8-8.niceosc5
libksba:   1.7.0-5.niceosc5
libgcrypt: 1.11.1-1.niceosc5
OpenSSL:   3.5.6 + gost Engine
CryptCP:   5.0 (macOS 12.7.6, Intel)

После обновления сохраняйте новый rpm -q, а при необходимости хэши конкретных RPM и бинарных файлов. Сверяйте изменения GnuPG и libksba вместе: корректное чтение сертификата одним пакетом не компенсирует ошибку формата CMS в другом.

Минимальный перечень регрессионных испытаний

  1. Импорт открытого ГОСТ-2012/256 сертификата и проверка полей/кривой.
  2. GPGSM проверяет правильную подпись CryptCP → GOODSIG, VALIDSIG.
  3. GPGSM отвергает изменённый файл → BADSIG.
  4. CryptCP проверяет подпись GPGSM → успешный код.
  5. CryptCP отвергает изменённый файл → ошибка.
  6. P12 с ГОСТ-2012/256 импортируется в изолированный GPGSM; приватный ключ виден в --list-secret-keys.
  7. GPGSM шифрует ГОСТ28147 на учебный сертификат и расшифровывает; cmp успешен.
  8. В штатном режиме проверка доверия и CRL проходит на актуальной цепочке; отдельно протестируйте новый, пустой кэш.
  9. После завершения E-02/E-03 добавьте обязательные проверки между продуктами по шифрованию.

Что считать регрессией

  • Прежде работавшая подпись перестала криптографически проверяться при неизменном тестовом содержимом.
  • При подмене документа приложение возвращает успешный статус.
  • GPGSM теряет зарегистрированный приватный ключ после обновления агента или меняет его криптографическую интерпретацию.
  • Локальный --encrypt/--decrypt возвращает код 0, но результат cmp различается.
  • Восстановленный файл появляется при неуспешной проверке ключевого транспорта и не помечен как невалидный.
  • Проверка доверия проходит лишь при отключённых политике и CRL, тогда как штатный режим ломается.

Как проверять безопасность тестов

Не используйте в CI настоящие КЭП и аппаратные токены пользователей. Генерируйте одноразовые лабораторные пары; не публикуйте .key, .p12, пароли и PIN в CI artifacts. Разделяйте результаты криптографии и проверки доверия. При публикации новых возможностей сайта не повышайте статус «реализовано в патче» до «проверено», пока не зафиксированы команды и коды возврата.

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

После нового успешного опыта актуализируйте:

  • Матрицу подтверждений и машинный файл docs/assets/data/gost-cms-interop-r20.json;
  • Протокол с датой, версиями и кодами возврата;
  • технические оговорки о -nochain, --always-trust и пропущенных проверках CRL;
  • связанные страницы R19, если они содержат более старое состояние испытаний.

Текущие неизменённые страницы R19 описывают состояние на момент их написания; раздел R20 имеет приоритет для результатов, полученных позднее. Изменения разработчика и оформление сайта должны сохраняться при обновлениях документации.