У меня есть открытый ключ GPG с дополнительным ключом. Когда я пытаюсь подписать свои артефакты Maven как часть процесса выпуска, плагин подписывает вспомогательный ключ вместо основного ключа.
Глядя на документы для плагина здесь: http://maven.apache.org/plugins/maven-gpg-plugin/sign-mojo.html
Я не вижу очевидного свойства для управления используемой клавишей. Можно ли это контролировать?
После того, как я задал несколько вопросов в списках рассылки, оказалось, что я был не единственным, кто столкнулся с этой проблемой.
В моем случае я создал свои пары ключей с помощью пользовательского интерфейса GPG Keychain Access на моем Mac. Другие пользователи, которые использовали тот же инструмент для создания своих ключей, также сообщили о той же проблеме с Maven.
По какой-то причине, когда вы создаете пару ключей с помощью этого пользовательского интерфейса, создается не только ключ верхнего уровня, но и дополнительный ключ. Этого не происходит, когда вы используете инструменты командной строки для создания новой пары ключей.
Итак, я зашел в командную строку, отозвал подраздел, и все заработало.
Я не уверен, что основная проблема связана с тем, как пользовательский интерфейс GPG KeyChain Access создает ключи, или с тем, как подключаемый модуль maven читает ключи.
TLDR; Вы можете управлять им, удаляя или отзывая подраздел. Рекомендуется отзыв.
--
Например, это обсуждалось в этой проблеме сонатипа. Кроме того, это влияет не только на пользовательский интерфейс — я создал свои ключи с помощью gpg4win в Windows 7 и командной строки. Генерация ключей сгенерировала как pub, так и подразделы:
> gpg --gen-key
> gpg --list-keys
pub 2048R/xxxxxxxx 2014-12-18
uid
sub 2048R/yyyyyyyy 2014-12-18
Комментарии говорят, что у вас есть два варианта:
вы захотите удалить подраздел, а затем подписать, развернуть снова
..
Я отозвал ключ (не удалял его), и это тоже сработало.
В комментариях к выпуску говорится, что документ был обновлен относительно инструкций, но ссылка больше не работает. Используя некоторые кэши страниц, я смог спасти содержимое, которое читалось так:
Удалить вложенный ключ
Некоторые инструменты PGP по умолчанию генерируют дополнительный ключ подписи и используют его для подписи вместо использования первичного ключа. Это проблема, если вы используете его для подписи артефактов и развертывания артефактов в центральном репозитории, потому что Nexus не может получить идентификатор первичного ключа из подписи, созданной подключом, поэтому он не может импортировать открытый ключ и не сможет проверить артефакт. Исправление заключается в удалении дополнительного ключа подписи, чтобы PGP использовал для подписи первичный ключ.
Чтобы получить представление о том, есть ли у вас дополнительный ключ подписи, запустите команду ниже с вашим собственным идентификатором ключа:
$ gpg --edit-key A6BAB25C
gpg (GnuPG/MacGPG2) 2.0.17; Copyright (C) 2011 Free Software
Foundation, Inc. This is free software: you are free to change and
redistribute it. There is NO WARRANTY, to the extent permitted by law.
Secret key is available.
pub 2048R/A6BAB25C created: 2011-08-31 expires: 2012-06-26 usage: SC
trust: ultimate validity: ultimate
sub 2048R/DD289F64 created: 2011-08-31 expired: 2011-09-30 usage: E
sub 2048R/8738EC86 created: 2011-12-19 expires: 2012-06-16 usage: S
[ultimate] (1). Juven Xu (for testing) <[email protected]>
Как видно из приведенного выше примера, этот ключ имеет 2 дополнительных ключа с идентификаторами DD289F64 и 8738EC86. Вывод также показывает время создания и время истечения срока действия. Здесь важно использование: E означает шифрование, поэтому ключ DD289F64 используется только для шифрования, S означает подпись, поэтому ключ 8738EC86 используется только для подписи. Если первичный ключ имеет вложенный ключ S, он будет использовать его для подписи, в противном случае сам выполнит задание по подписанию. Итак, мы хотим удалить подключ 8738EC86.
Сначала выберите подраздел, который мы хотим удалить, поскольку его индекс равен 2 (индексы начинаются с 0), мы запускаем команду:
gpg> ключ 2
pub 2048R/A6BAB25C created: 2011-08-31 expires: 2012-06-26 usage: SC
trust: ultimate validity: ultimate
sub 2048R/DD289F64 created: 2011-08-31 expired: 2011-09-30 usage: E
sub* 2048R/8738EC86 created: 2011-12-19 expires: 2012-06-16 usage: S
[ultimate] (1). Juven Xu (for testing) <[email protected]>
Как видно из вывода, подключ 8738EC86 помечен *. Теперь удалите его:
gpg> делкей
Do you really want to delete this key? (y/N) y
pub 2048R/A6BAB25C created: 2011-08-31 expires: 2012-06-26 usage: SC
trust: ultimate validity: ultimate
sub 2048R/DD289F64 created: 2011-08-31 expired: 2011-09-30 usage: E
[ultimate] (1). Juven Xu (for testing) <[email protected]>
Совет Если вы уже распространили свой открытый ключ, лучше отозвать дополнительный ключ подписи, а не удалять его, хотя в любом случае вы можете сделать свой первичный ключ ключом подписи. См. Справочник по конфиденциальности GNU, чтобы узнать о разнице между удалением и отзывом. Чтобы отозвать дополнительный ключ, используйте gpg> revkey вместо gpg> delkey.
Я! 8738EC86 больше не указан, последним шагом является сохранение нашего изменения:
gpg> сохранить
Вот и все! Теперь вы можете протестировать изменение, подписав файл, а затем проверить его. Вывод должен содержать что-то вроде:
gpg: Подпись сделана ************************* с использованием идентификатора ключа *** [YOUR-PRIMARY-KEY-ID]
Итак, для меня практические шаги были
gpg --edit-key PRIMARYKEYID
key 1
revkey
[y]
[3]
save
и переделывать знак/освобождение.
