On 09.08.2016 16:11, Sergey Budnevitch wrote:
Ну потому что советовать людям качать что-то из интернета и ставить безо
всякой проверки от рута - это глупость. Если хотя бы один из ста просто
проверит то, что он скачал, не говоря уж о проверке chain of trust,
перед установкой, то такое разделение на две команды оправдано.
Но ведь "gpgcheck=0" -- это и есть "советовать людям качать
что-то из интернета и ставить безо всякой проверки от рута".
Проблема со всеми этими подписями в том, что большинство не понимает как это
работает
и зачем это надо, объяснить как это устроено в самой инструкции - это лишнее,
инструкция
будет менее понятной. Поэтому инструкция написана максимально просто, а
объяснение
вынесено в конец статьи. Кстати на сайте сделано также:
http://nginx.org/en/linux_packages.html#signatures
gpgcheck надо как минимум для того, чтобы не было возможности взломать
DNS, и отправить пользователей скачивать неизвестный бинарник с левого
сайта по протоколу http, -- сейчас такая уязвимость на сайте nginx.org
имеется. Я всего лишь предлагаю эту уязвимость на сайте закрыть.
Я уж не говорю о том, что в CentOS принято ставить/удалять ключи
вместе с пакетом репозитория, так как это сделано в EPEL или remi.
И тогда не надо будет вручную править и менять GPG ключи в системе.
https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm
http://rpms.remirepo.net/enterprise/remi-release-7.rpm
Файл ключа задается прямо в конфиге репозитория через gpgkey=
Вы ставите пакет, непонятно откуда загруженный и yum при следующем
запуске установит ключ - это замечательно, но опять же ни проверки
ключа, ни проверки пакета при этом не происходит.
Сайт nginx.org по протоколу HTTPS - это разве "не понятно откуда" ?
Очень даже понятно, из-за протокола HTTPS подмена сайта-источника
с пакетом репозитория, включающим в себя GPG ключ будет исключена.
При первом запуске yum остановится и спросит что делать с ключем -
устанавливать этот ключ из файла или нет. Провести проверку ключа
при этом пользователю никто не запрещает.
А уж после установки ключа никто не сможет незаметно подменить пакет
с nginx, даже в случае взлома сайта nginx.org и подмены бинарника там.
(вероятность взлома сайта nginx.org и подмены бинарника -- выше нуля)
С другой стороны разница установки ключа и установка пакета минимально,
но с пакетом у вас когда-то потом возникнет вопрос при установке об
импорте ключа - зачем такая головная боль?
Вопрос об импорте ключа возникает всего один раз, при первом запуске.
Это не головная боль, а дополнительная защита и она вполне оправдана.
В случае gpgcheck=0 и протокола HTTP защиты от DNS cache poisoning нет.
Нет также защиты от взлома сайта nginx.org и подмены бинарника на нем.
"By default, the check is disabled for NGINX and NGINX Plus
repositories, but enabled for NGINX Amplify repositories."
Плюс к тому, упрощение жизни пользователям NGINX Amplify repositories,
потому что им всем придется теперь вручную менять ключи по инструкции.
--
Best regards,
Gena
_______________________________________________
nginx-ru mailing list
[email protected]
http://mailman.nginx.org/mailman/listinfo/nginx-ru
