Как стать автором
Обновить

Комментарии 14

Ну, теперь этот Дунин создаст форк, где он волен не исправлять уязвимости. Свобода!

Хотя, я, конечно, предпочту продукт от разработчика, который не заявляет мне "если ты включил то, что отключено по умолчанию, то ты сам виноват, и уязвимость в этом коде не считается"..

Он не говорил, что не будет её исправлять, вообще-то. Просто не хотел заводить на неё CVE - разные вещи.

CVE может запросить кто угодно, даже совершенно постороннее лицо. Реакцию вызвал факт выпуска внеочередного security-релиза с исправлением, о чем рассказано, как в последующих письмах в рассылку, так и недавнем интервью хабру. И, как можно заметить, форк freenginx уже отличается от nginx тем, что не содержит данного релиза.

Мы в Angie такую позицию не разделяем, не делим код на "экспериментальный" и "не экспериментальный" в этом отношении. Пользователи уже используют HTTP/3 на своих серверах и имеют право, как узнавать об уязвимостях как можно раньше, так и получать исправленную сборку.

Замечу также, что мы уже выпускали релиз с усилением безопасности на неделю раньше, чем это изменение попало в выпуск nginx. Именно потому, что мы придерживаемся более строгой политики в этом отношении.

То есть вы взяли у nginx экспериментальный кусок кода, засунули его свой стабильный релиз и дали пользователям со словами «ааа, ну и так пойдет, в продакшн»? Смахивает на как будь то подложили свинью.

  1. Мы не просто взяли у nginx, а мы его в том числе разрабатывали. Один из активных разработчиков HTTP/3 в nginx - работает у нас. Поэтому мы также добавили поддержку HTTP/3 клиента в сторону бэкенда и попробовали даже предложить эти патчи в nginx: https://mailman.nginx.org/pipermail/nginx-devel/2023-December/THMZAQ36SN5BICJSCLX6FLEUI45FHR4H.html - и в том числе отчасти из-за этого у нас оказалось на одну уязвимость меньше, наш код отличается.

  2. "Экспериментальный" - это не более, чем способ снять с себя ответственность. Надо заметить, довольно плохой способ. Пользователи же хотят видеть нормальную, полноценную поддержку современных протоколов, а не вот эти отмазки. Что им с этим делать? Эксперименты ставить? Переходить на конкурентов, где поддержка HTTP/3 ни чуть не лучше, но просто не содержит слова "экспериментальный"? Наша позиция заключается в том, что современный веб-сервер заслуживает иметь полноценную поддержку современных протоколов.

  3. Проработав в nginx одиннадцать лет и будучи, среди прочего, разработчиком аж 3-х "экспериментальных" модулей/механизмов: SPDY, HTTP/2, thread pools - я догадываюсь, что во многом "экспериментальность" HTTP/3 обусловлена негативным отношением одного человека к самому протоколу и тем, что он лично не принимал активного участия в разработке и ревью данного кода. И этот человек вовсе даже не Игорь Сысоев, написавший большую часть кода и заложивший основную архитектуру сервера.

Снять ответственность если код помечен как экспериментальный или не снимать - это уже решение каждого разработчика или компании в целом к своей работе. Давайте заменим экспериментальный на нестабильный, что изменится? Вероятно ничего.

Тут у меня пожалуй вопрос лишь - зачем нестабильный модуль добавлять в стабильный релиз? Нестабильный - это тот код который не покрыт тестами, не поддерживает полностью rfc и имеет прочие недочеты. Есть же ветка mainline для этих целей, не так ли?

Давайте заменим экспериментальный на нестабильный, что изменится? Вероятно ничего.

Как вы справедливо заметили ниже: нестабильный код не добавляют в стабильные релизы.

Тут у меня пожалуй вопрос лишь - зачем нестабильный модуль добавлять в стабильный релиз?

Это было бы очень странным и недальновидным решением с нашей стороны. Поэтому мы этого не делали. Может авторы nginx это сделали? Ниже попробуем разобраться.

Нестабильный - это тот код который не покрыт тестами, не поддерживает полностью rfc и имеет прочие недочеты.

Код HTTP/3 модуля достаточно неплохо покрыт тестами, а также неплохо соответствует RFC, благодаря чему даже согласно независимым тестам имеет хорошие характеристики по кросс-совместимости с другими реализациями (которые, кстати, не маркируются экспериментальными): https://interop.seemann.io/

Есть же ветка mainline для этих целей, не так ли?

Ветка mainline - это основная стабильная ветка, которую разработчик рекомендует использовать, а также на базе этой ветки выпускает коммерческую версию NGINX Plus.

Просто процитирую старшего продуктового директора nginx:

We generally recommend using the mainline branch. This is where we commit all new features, performance improvements, and enhancements. We actively test and QA the mainline branch, so it’s arguably more stable than the “stable” branch. The mainline branch is also the source of NGINX Plus builds for our commercial customers.

https://www.nginx.com/blog/nginx-1-12-1-13-released/

Да, название второй ветки не совсем точное, что может сбить с толку. Правильнее было бы назвать вторую ветку - legacy, т.к. stable в её названии прежде всего означает заморозку API, что более актуально, если у вас есть какие-то устаревшие модули, на поддержку совместимости и актуальности которых вы хотите тратить меньше сил.

Я также замечу, что разработчик, не только включил модуль HTTP/3 в ветку, которая позиционируется достаточно стабильной, но и собирает с ним пакеты, в чем не трудно убедиться, установив пакет из официального репозитория nginx. И само собой этот модуль входит в официальные стабильные сборки релизов коммерческой версии NGINX Plus.

Делаем ли мы в Angie что-то иначе? Нет. В сухом остатке, Angie от nginx отличается расширенным набором стабильной и востребованной функциональности, которую давно уже спрашивают и ждут от самого nginx.

Любопытно чем сейчас отличается freenginx от nginx. А отличается он только отсутствием релиза с исправлениями критических багов в HTTP/3. В чем не трудно убедиться сравнив репозитории на текущий момент:

image

Где, кто и кому тут свинью подложил? Просто мы, как и F5, не считаем, что пользователи HTTP/3 должны дожидаться очередного релиза, чтобы закрыть критические ошибки. И с учетом всего изложенного выше - есть веские основания так считать.

Отдельно отмечу, что оба бага, которые были расценены как критические, поскольку позволяют сделать DoS атаку на сервер - обнаружены благодаря тем самым пользователям HTTP/3, которые с ними столкнулись в продакшене и завели тикеты:

https://trac.nginx.org/nginx/ticket/2585
https://trac.nginx.org/nginx/ticket/2586

Цитирую: its on production machine and happened several times

Ага, спасибо им, что сообщили, но наплевать на них, пусть ждут следующего очередного релиза, ведь сами виноваты, что включили в конфигурационном файле экспериментальный модуль, который поставляется в официальной стабильной сборке сервера - так что ли?

И если у кого-то ещё остаются какие-то сомнения по поводу стабильности и позиционирования mainline ветки, то отдельно обращу внимание на то, как появляется очередная stable ветка: раз в год, обычно весной, текущая mainline ветка превращается в очередную stable ветку, при этом не имеет никакого значения, что какие-то функции и модули там уже почти год, а какие-то были добавлены за месяц до того. И ничего другого не происходит, никакой стабилизации кода, никаких дополнительных тестов - это просто ежегодное чисто формальное мероприятие от которого код не становится каким-то магическим образом более стабилен, чем был до того.

И "экспериментальность" отдельных модулей и функций - тут тоже совершенно ортогональная история. От переименования mainline ветки в очередную stable - "экспериментальные" модули и функции не перестают быть экспериментальными. Так, например, perl-модуль является экспериментальным с момента своего появления (в версии 0.3.21, выпущенной ещё в 2006 году) и по сей день. Т.е. этот "экспериментальный" модуль входит во все stable ветки за последние 18 лет.

Какая то грусть и печаль если так появляется stable версия, путем простого копирования из mainline

Потому, что это ближе по концепции к LTS. Т.е. каждый mainline релиз является стабильным, просто некоторые из них получают продленный на год срок поддержки и исправления критических ошибок.

а как ещё она может появиться?

Любопытно чем сейчас отличается freenginx от nginx. А отличается он только отсутствием релиза с исправлениями критических багов в HTTP/3. В чем не трудно убедиться сравнив репозитории на текущий момент

ну на тот момент не было ни одного релиза freenginx. спустя несколько дней релиз появился, и содержит эти патчи из оригинального nginx.

P.S. хотя позиция Максима мне тоже непонятна. есть ощущение, что озвучен повод, а не причина появления форка.

P.P.S. любопытно, в итоге будет ли обмен патчами меду angie и freenginx? и насколько далеко разойдутся эти три проекта

Dev-версиями винды люди тоже пользуются, не смотря на имеющиеся в них баги, и явное о них предупреждение, но почему-то CVE не заводят

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Другие новости

Истории