Обработка секретных ключей OpenPGP для модульного тестирования

Я работаю над проектом, в котором программное обеспечение выполняет криптографические операции с двоичным файлом GnuPG. Некоторые функции имеют зашифрованный вывод OpenPGP, а некоторые принимают зашифрованный ввод OpenPGP.

Для модульного тестирования я планирую сгенерировать ключ без пароля для [email protected] и включить его в репозиторий. Это (естественно) сделает ключ непригодным для производственного использования, но это нормально, поскольку ожидается, что пользователи будут генерировать/использовать свой собственный ключ.


Теперь к моему вопросу. Если ключ включен в репозиторий, любой может загрузить его на сервер ключей, использовать его для подписи собственного ключа или отозвать его (и загрузить отзыв). GPG может автоматически загружать ключи с серверов ключей, и кажется неразумным иметь такой ключ (где закрытый ключ является общедоступным) в личной связке ключей.

Можно ли загрузить отозванную версию ключа на сервер ключей (чтобы цепочка ключей не доверяла ей) и включить в репозиторий версию ключа, где ключ не отозван? Решит ли это проблему появления ключа и будет ли он доверенным в личной цепочке для ключей, и в то же время позволит проводить модульное тестирование с тем же ключом?


person jornane    schedule 03.08.2015    source источник
comment
Почему бы не генерировать новые ключи для каждого запуска теста в неинтерактивном режиме?   -  person frasertweedale    schedule 04.08.2015
comment
Затем я также должен изменить тестовый набор для каждого запуска теста. Зашифрованная полезная нагрузка является частью ожидаемого вывода.   -  person jornane    schedule 04.08.2015


Ответы (1)


Отзыв ключа на серверах ключей при локальном включении неаннулированной версии будет работать без проблем, если только вы не получите отозванную версию с серверов ключей. Просто создайте копию перед отзывом ключа и обязательно используйте локальный или даже новый домашний каталог GnuPG (в любом случае это следует сделать, чтобы обеспечить воспроизводимость модульных тестов и сохранить их отдельно от учетной записи разработчика). Таким образом, вы должны быть уверены, что у вас не будет сертификата отзыва в вашей цепочке ключей, если только кто-то не получит его вручную (чего он не должен делать, вы можете захотеть задокументировать это где-нибудь).

Еще один сценарий, который следует рассмотреть, — сохранение секретного первичного секретного ключа, но публикация только секретного подключа. Это может упростить последующие изменения ключа, фактически используемого для шифрования, и помешать другим возиться с первичным ключом (создавать идентификаторы пользователей, отзывать что-либо, выдавать сертификаты и т. д.).

person Jens Erat    schedule 03.08.2015
comment
Планировалось начать с нового домашнего каталога GnuPG, поэтому экспорт ключа перед отзывом, сохранение его в репозитории и повторный импорт в качестве тестовой настройки должны помочь. Хранение основного ключа в секрете — интересная мысль, единственная проблема, которую я могу придумать, — это сделать проект менее поддающимся разветвлению. - person jornane; 03.08.2015
comment
Каждый может положить туда новый набор ключей, когда ему это нужно. Тем не менее, документирование процедуры и мыслей, стоящих за ней, может быть полезным. - person Jens Erat; 03.08.2015