Updating the GPG Key for NGINX Products

[Gena Makhomed]

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