GnuPG 2, gpg-agent
и Loopback Pinentry
GnuPG 2.0 и новее учитывают только --passphrase-...
--passphrase -...-, когда также применяется --batch
. От man gpg
:
Обратите внимание, что эта фраза-пароль используется только в том случае, если также была указана опция --batch
. Это отличается от GnuPG версии 1.x.
Таким образом, рабочая команда для GnuPG 2.0 будет выглядеть так:
gpg --batch --passphrase-fd 0 --import <path>
Кроме того, начиная с GnuPG 2.1, gpg-agent
обрабатывает все операции с секретным ключом, а также запрашивает фразу-пароль. Идея заключается в том, чтобы иметь небольшое базовое приложение, обрабатывающее наиболее важные биты криптографии, и иметь (сравнительно) большой GnuPG с потенциально большим количеством ошибок и проблем безопасности, выполняющих все остальное. По умолчанию, gpg-agent
не будет запрашивать gpg
для парольной фразы, но попытается напрямую спросить пользователя (что, очевидно, приведет к сбою в автоматической сборке). Однако есть последний выход: вы можете использовать --pinentry-mode loopback
чтобы сделать gpg-agent
запросом gpg
для ключевой фразы, но так как это влияет на безопасность, как обсуждалось ранее, вы также должны сконфигурировать gpg-agent
чтобы разрешить обратную петлю.
Добавьте следующую строку в ~/.gnupg/gpg-agent.conf
:
allow-loopback-pinentry
Теперь вы сможете использовать следующую команду в GnuPG 2.1 и новее:
gpg --batch --pinentry-mode loopback --passphrase-fd 0 --import <path>
Проходя в сокет gpg-agent
Лучшим вариантом, чем импорт закрытых ключей в контейнеры Docker, обычно является хранение (и разблокировка) закрытого ключа на хосте, а затем передача сокета gpg-agent
в контейнер Docker. Таким образом, критические секреты никогда не попадут в контейнер Docker, и вы можете быть уверены, что он не будет сохранен в слоях изображений и опубликован случайно.