rpmsign с запросом пароля CLI

Я работаю над рабочей станцией Fedora 25 (F25), спиной KDE. Я пишу несколько сценариев для автоматического тестирования.

Один из автоматических тестов включает вызов программы RPMSIGN (8), которая, в свою очередь, вызывает GPG (1) для присоединения цифровой подписи к некоторым файлам RPM, которые я создаю. Конечно, GPG использует pinentry (ввод PIN-кода), чтобы побудить человека ввести кодовую фразу для ключа подписи RPM (пара ключей RSA). Я хочу вывести человека из цикла и полностью автоматизировать задачу по предоставлению ключевой фразы для ключа подписи RPM. (И да, я знаю о последствиях безопасности. Это просто автоматическая тестовая среда, а не производственный узел, поэтому Я не слишком беспокоюсь о безопасности. В производственной версии пользователь вручную вводит пароль подписи RPM.)

Раньше я использовал сценарий EXPECT (1), который ждал, когда GPG запустит текст «Enter pass phrase:» на консоль, а затем сценарий EXPECT войдет в пропущенную фразу, и я поеду. Отлично.

В F25 функция pinentry разбивает мое существующее решение на основе EXPECT для автоматического ввода ключевой фразы для ключа подписи RPM.

Когда я запускаю RPMSIGN в окне консоли GUI на этом хосте F25, GPG использует pinentry для отображения диалогового окна GUI, в котором пользователю (мне) предлагается ввести кодовую фразу для ключа подписи RPM. Разумеется, это поведение, связанное с опорами, препятствует автоматическому вводу кодовой фразы.

Если я создаю сценарий Bash, который на мгновение отключает переменную среды DISPLAY, то я больше не получаю диалог GUI,

#!/bin/bash DISPLAY_SAVE=$DISPLAY unset DISPLAY rpmsign --resign "/path/to/test-1.0.0-1.fc25.noarch.rpm" export DISPLAY=$DISPLAY_SAVE 

но теперь я получаю версию диалога ncurses на консоли:

 +----------------------------------------------------------------+ | Please enter the passphrase to unlock the OpenPGP secret key: | | "Testing (rpm-sign)" | | 1024-bit RSA key, ID 0123456789ABCDEF, | | created 2016-12-02. | | | | | | Passphrase: __________________________________________________ | | | | <OK> <Cancel> | +----------------------------------------------------------------+ 

Опять же, «диалог» консоли pinentry-curses вмешивается и предотвращает автоматическую запись парольной фразы.

Я не хочу постоянно изменять или отключать модули pinentry; Я просто хочу временно отключить их, чтобы вернуться к подсказке CLI GPG «Введите пропущенную фразу:» (или что бы там ни было, строка приглашения) без вмешательства pinentry.

Любые предложения по полной автоматизации ввода кодовой фразы подписи ключа RPM через CLI без помехоустойчивости?

  • Как добавить Fedora Repo к установке CentOS 7?
  • CentOS 4.8 и glibc 2.5
  • RPM говорит, что общий объект отсутствует, но я могу найти его с ls
  • Создайте bash (или альтернативный пакет linux) с пользовательским именем двоичного файла / документа
  • Адвокат Fedora 16
  • libmpg123 bugging up yum
  • заставить zypper установить определенную версию
  • Как проверить один файл пакета, а не сам RPM
  • 2 Solutions collect form web for “rpmsign с запросом пароля CLI”

    Одним из решений этой проблемы является использование gpg-agent , который управляет секретными ключами GPG. Вы можете использовать этот инструмент в сочетании с gpg-preset-passphrase чтобы засеять кодовую фразу в кеш gpg-agent . Подробнее о gpg-agent читайте здесь . Это позволит вам избежать необходимости вводить ключевую фразу вручную, чтобы вы могли выполнять свои автоматизированные задачи.

    BTW, я написал полезное сообщение в блоге о подписании GPG и проверке пакетов RPM и репозиториев YUM , которые могут вам пригодиться.

    Спасибо @Joe Damato за то, что указали мне на утилиту gpg-preset-passphrase . Решение, описанное ниже, было разработано и протестировано на хосте Fedora 25 с установленным gnupg2-2.1.x .

    (nb Я еще не понял, как определить значение ключевого слова ключа подписи ключа RPM на платформах, на которых запущены более старые версии GnuPG, потому что они не поддерживают параметр --with-keygrip . Если кто-то хочет прокомментировать решение для этого , пожалуйста, сделай.)

    Убедитесь, что ~/.gnupg/gpg-agent.conf содержит строку.

     allow-preset-passphrase 

    После изменения ~/.gnupg/gpg-agent.conf перезагрузите gpg-agent.

     $ gpg-connect-agent reloadagent /bye OK 

    Перечислите ключи GPG, чтобы получить восемь идентификаторов ключа с шестнадцатеричной цифрой для вашего ключа подписи RPM. В этом примере, идентификатор ключа – 0123ABCD .

     $ gpg --list-keys /home/me/.gnupg/pubring.gpg ----------------------------------- pub 1024R/0123ABCD 2015-06-13 uid Test (rpm-sign) 

    Получите ключевой код для ключа подписи RPM. (nb На хостах RHEL 7.2 и Fedora 20, которые я использую для тестирования, программа GPG2(1) на этих хостах не распознала параметр --with-keygrip .)

     $ gpg2 --with-keygrip -K 0123ABCD sec rsa1024 2015-06-13 [SCEA] 0A1B2C3D4E5F6A7B8C9D0E0F1A2B3C4D0123ABCD Keygrip = 2EACA0C5A4B46168EB91970B6715AF1AA52968BE uid [ unknown] Test (rpm-sign) 

    Загрузите ключевую фразу для ключа подписи RPM. В командной строке, показанной ниже, замените 'PASSPHRASE' на фактическую кодовую фразу для ключа подписи RPM.

     $ /usr/libexec/gpg-preset-passphrase --passphrase 'PASSPHRASE' --preset 2EACA0C5A4B46168EB91970B6715AF1AA52968BE 

    :: КОНТРОЛЬНАЯ РАБОТА ::

    Создайте тестовый файл RPM, который не подписан. Убедитесь, что тестовый RPM-файл не подписан.

     $ rpm --checksig test-1.0.0-1.f25.noarch.rpm test-1.0.0-1.fc25.noarch.rpm: sha1 md5 OK 

    Убедитесь, что RPMSIGN(8) использует кешированный пароль – то есть, что RPMSIGN(8) не запрашивает ввести кодовую фразу для ключа подписи RPM – при подписании файла RPM теста.

     $ rpmsign --resign test-1.0.0-1.f25.noarch.rpm 

    Убедитесь, что файл тестовой RPM подписан.

     $ rpm --checksig test-1.0.0-1.f25.noarch.rpm test-1.0.0-1.fc25.noarch.rpm: rsa sha1 (md5) pgp md5 OK 

    :: ДОБАВЛЕНИЕ 1 (2016-12-17) ::

    Согласно этой веб-странице GnuPG Issue 2331 :

    gpg1 не знает о keygrips. Вместо ключевого слова gpg1 использует отпечаток пальца как cacheid для gpg-agent. Команда агента GET_PASSPHRAE, используемая gpg1, использует другой режим кэширования из того, что использует gpg-preset-passphrases. Таким образом, даже если вы замените keygrip на отпечаток клавиши (sub), это не сработает.

    Для чего это стоит, я провел некоторое тестирование с GnuPG версии 2.0.x на хостах RHEL7, а gpg-preset-passphrase , похоже, не поддерживается. Я могу получить только gpg-preset-passphrase для работы с GnuPG версии 2.1.x.

    Рекомендации

    GnuPG ArchWiki

    Linux и Unix - лучшая ОС в мире.