Я планирую выпускать обновления программного обеспечения для офлайн-машин через USB-накопители.
Машины будут отправлены, и на месте в течение потенциально много лет,
За это время новые разработчики будут наняты и уволены.

Я планирую использовать GnuPG для проверки обновлений на флешке перед их установкой.

Будет главный ключ, и каждому разработчику будет предоставлен свой собственный ключ разработчика.

Ключи разработчика будут подписаны главным ключом. Развернутые машины будут полностью доверять главному ключу. Однако развернутые машины не будут иметь все ключи разработчика.

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

В моих тестах gpg --verify package.tar.gz.sig терпит неудачу, потому что открытый ключ НЕ известен.

Чтобы заставить gpg --verify принять ключ, я должен сначала gpg --import developer_123.key.

Но это не проверяет, что новый ключ был подписан доверенным мастером!

Я могу создать новый ключ rogue_developer, не подписанный доверенным мастером, импортировать его, а затем gpg --verify выполнит аутентификацию пакета.

Я думаю, что я неправильно понимаю фундаментальное понимание того, как этот процесс должен работать?

Нужно ли мне...
1) Разрешить всем разработчикам подписывать с мастер-ключом (плохая идея, ключ будет утерян, и я не смогу отозвать его без повторного вызова развернутых машин!)
2) Связать экспортированный ключ разработчика с обновлением USB.
Но тогда как я могу проверить, что он был подписан мастером, прежде чем импортировать его?
3) Есть ли способ проверить, что пакет был подписан ключом, подписанным моим доверенным мастером, без необходимости импорта этого ключа?
4) Что-то еще, о чем я не думал?

Я уверен, что я что-то неправильно понимаю ... Когда Т подумал, что полное доверие к мастеру должно означать, что мы также проверяем ключи, которые были подписаны этим доверенным ключом?
Но как этот процесс работает?

Спасибо за любые указатели!

Крис.

РЕДАКТИРОВАТЬ:
Я создал для тестирования настоящего разработчика (DVKey) и мошенника (ROKey).
DVKey подписан главным ключом, которому доверяют полностью. ROKey НЕ подписан главным ключом. При проверке пакета, подписанного DVKey, я получаю

[cds @ notebook ~] $ gpg --homedir FMHOME - проверить ArchLinuxARM-rpi-2-latest.tar.gz.sig
gpg: при условии подписанных данных в 'ArchLinuxARM-rpi-2-latest.tar.gz'
gpg: подпись выполнена ср 18 ноя 2015 21:15:55 мск с использованием идентификатора ключа RSA B90C2061
gpg: Хорошая подпись от "DVKey" [полное]
[cds @ notebook ~] $ echo $?
0

Обратите внимание, что gpg вернул '0', успех.

Когда я проверяю мошеннический пакет, я получаю

[cds @ notebook ~] $ gpg --homedir FMHOME --verify Untitled.log.sig
gpg: при условии подписанных данных в «Untitled.log»
gpg: подпись сделана ср 18 ноя 2015 21:23:03 GMT с использованием идентификатора ключа RSA EEF5033E
gpg: хорошая подпись от "ROKey" [неизвестно]
gpg: ВНИМАНИЕ: Этот ключ не сертифицирован с доверенной подписью!
gpg: нет никаких признаков того, что подпись принадлежит владельцу.
Отпечаток первичного ключа: C00D C1EE 4670 2FE9 4B8D D03E 4DC6 8D9C EEF5 033E
[cds @ notebook ~] $ echo $?
0

Обратите внимание, что я получил предупреждение! но gpg все еще вернул '0', успех. Мне нужно отсутствие надежной подписи, чтобы быть НЕУКАЗАННЫМ для проверки.

Еще раз, СПАСИБО.

1 ответ1

0

Отвечая на мой собственный вопрос.

Я не мог найти хороший способ определить уровень доверия с одним gpg.

Я написал небольшую программу c. Я свяжу это здесь, если кому-то будет интересно.
https://github.com/chris-stones/gpg-verify-trust

скомпилировать с помощью gcc "src/gpg-verify-trust.c -lgpgme -o verify_trust".
зависит от заголовков / библиотек gpgme.

возвращает 0 за отсутствие доверия
возвращает 1 за предельное доверие
возвращает 2 для полного доверия
возвращает 3 за абсолютное доверие
любое другое возвращаемое значение указывает на ошибку.

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .