В AUR есть много пакетов, при попытке установки которых возникает следующая ошибка:==> ERROR: One or more PGP signatures could not be verified!
Это решается путем импорта ключа с помощью чего-то вроде gpg --recv-keys 123456789ABCDEF. Обсуждение AUR часто предоставляет ключ.
У меня есть несколько вопросов по этому поводу:
Что именно делают эти ключи? Что проверяется GPG и зачем это нужно?
Почему необходимо импортировать ключи вручную? Почему это нельзя автоматизировать?
Если слепой импорт ключа из ветки комментариев AUR плох, какие шаги мне следует предпринять, чтобы «проверить» ключ?
Где я должен найти ключ, если никто не удосужился разместить его в комментариях, и если у меня нет времени опубликовать комментарий и надеяться, что разработчик ответит?
Поискав в Интернете, я нашел ссылки нахорошо известный пост в блоге. Мне грустно говорить об этом, но после нескольких внимательных прочтений я все еще не понимаю вышеизложенных пунктов.
решение1
Что именно делают эти ключи? Что проверяется GPG и зачем это нужно?
Ключи используются для проверки того, что загружаемое вами программное обеспечение является тем, что задумал автор пакета, а не вредоносным троянским конем с сервера репозитория, который мог быть успешно внедрен злоумышленником. Или, возможно, злоумышленник может перенаправить ваш запрос на загрузку в свой замаскированный репозиторий вредоносного ПО вместо подлинного репозитория AUR. Проверка GPG значительно затрудняет для злоумышленника успешное использование репозиториев программного обеспечения в качестве канала распространения вредоносного ПО.
Почему необходимо импортировать ключи вручную? Почему это нельзя автоматизировать?
Предполагается, что вы делаете осознанный выбор, доверяете ли вы конкретному автору/упаковщику программного обеспечения или нет, и достаточно ли вы уверены в своих целях, что полученный вами ключ является подлинным, а не получен от мошенника.
Необходимый уровень доверия и уверенности зависит от того, что именно вы делаете: частная домашняя система для развлечения, сервер, который будет обрабатывать информацию о здоровье и/или кредитных картах других людей для бизнеса, и вспомогательный сервер поддержки для национальной системы противоракетной обороны должны иметь несколько разные требования.
Если слепой импорт ключа из ветки комментариев AUR плох, какие шаги мне следует предпринять, чтобы «проверить» ключ?
Если ключ подписан другими людьми, чьи ключи у вас уже есть, и вы доверяете суждениям этих людей, по крайней мере, когда дело касается подписи ключей GPG, вы можете принять это как доказательство того, что ключ, вероятно, подлинный. В противном случае вы можете попробовать получить ключ из нескольких разных источников и сравнить результаты. Если это достаточно важно для вас, вы можете даже позвонить или встретиться с разработчиком, чтобы получить более весомое подтверждение того, что у вас правильный ключ.
Где я должен найти ключ, если никто не удосужился разместить его в комментариях, и если у меня нет времени опубликовать комментарий и надеяться, что разработчик ответит?
Открытые ключи GPG, предназначенные для широкого использования, обычно публикуются на серверах ключей SKS: если у вас нет нужного ключа, пакетные инструменты должны иметь возможность отобразить keyID требуемого ключа, и вы можете использовать его для поиска ключа на серверах ключей.
Более подробную информацию о сети серверов ключей SKS смотрите здесь:https://sks-keyservers.net/
Вы также можете поискать keyID в Google.
решение2
TL;DR - новое, улучшенное и автоматизированное «проверка md5sum загрузки по списку, размещенному на веб-сайте»
Подпись — это цифровая проверка того, кто подписал пакет, с гарантией того, что он не был изменен с момента его создания. Обычно подписывается либо сопровождающим пакета, либо менеджером по выпуску, либо кем-то «авторитетным» в группе поддержки основного проекта дистрибутивов. По сути, это улучшенная и автоматизированная проверка целостности того, что вы собираетесь установить — новое «мы опубликовали хэш md5sum списка файлов, вам следует сравнить то, что вы загружаете, с этим».
Это работает по принципу открытого/закрытого ключа — я создаю закрытый ключ с паролем (хорошим и надежным) и генерирую открытый ключ с его помощью. Я могу выдать открытый ключ. Я генерирую пакет, подписываю его, и когда вы его устанавливаете, вам сообщают, что открытый ключ, соответствующий ABC321FF или какому-либо другому, необходим для проверки подписи. После импорта ключа программное обеспечение на вашей стороне может проверить, что идентификационный хэш тот же самый и что хэш был подписан моим закрытым ключом.
Проблемы безопасности при добавлении программного обеспечения из репозитория в вашу систему заключаются в следующем: «кто стоит за этим программным обеспечением — ах да, и ключ тоже». Если это ключ для дистрибутива (некоторые релизы имеют свои собственные ключи или отозвали и создали новые ключи), то это не имеет значения, вы в любом случае используете программное обеспечение из их дистрибутива. Обратите внимание, что когда вы попадаете в сторонние репозитории (например, Ubuntu и PPA проекта), вам придется импортировать ключ для каждого из них, и это может стать для вас проблемой.
Что вам следует знать, так это то, что этот ключ теперь будет просто работать для всего остального, что подписал этот ключ. В зависимости от уровня вашей паранойи, вы можете захотеть добавить ключ по мере необходимости и удалить его из списка доверенных ключей, когда закончите установку пакета. Конечно, с частыми обновлениями вы создаете больше работы и шагов для обновления.
И если вы настолько параноидально относитесь к тому, что этот ключ подписывает что-то неприятное, вам, вероятно, не стоит пытаться устанавливать что-либо из этого репозитория.