Для начала у всех комментаторов пишущих про "срубить бабла с государства" хочется спросить, хотя бы просто для расширения своего кругозора, а как это сделать? Расскажите, если у вас такой опыт имеется и видите сразу сходу такую перспективу. Отдельно интересно, как это сделать на OSS версии и зачем в таком случае вообще выпускать какую-то OSS версию? Есть у меня подозрения, что среди пишущих подобные комментарии нет никого, кто сам бы пытался вот так прийти и продать что-то в госкомпанию, либо получить какой-то грант от государства. Если коротко, это не секрет полишинеля, что хуже и труднее заказчика, чем госзаказчик для частного бизнеса - придумать сложно. Для компаний с участием государства возможно всё иначе, но я в таких не работал, не знаю.
А второй момент в том, что независимо от того, заинтересуются ли какие-нибудь госы нашим продуктом или нет - хочется продолжать разрабатывать достаточно хороший и проверенный временем веб-сервер, продолжать успешно применять свой опыт и знания в той сфере и в том продукте, где есть наибольшие компетенции. Если бы можно было продолжать разрабатывать nginx, мы бы сидели и спокойно продолжали его разрабатывать, никто бы и пальцем не пошевелил, никакого Angie не возникло. Но это вообще не наше решение. Это решение компании, которая владеет сейчас nginx, и довольно очевидно, что это её решение было принято не ради импортозамещения в России.
> Angie (и ещё тысячи “российских” продуктов из известного реестра т.н. “отечественного ПО”) вряд ли бы появился, кабы не принятый закон об импортозамещении (сослагательное наклонение призвано вполне недвусмысленно показать, что я этого не утверждаю, а лишь предполагаю/допускаю).
А Angie в реестре и не присутствует. В нем только Angie PRO.
Ссылаясь на этот закон, компании прекрасно используют nginx. Для OSS присутствие в реестре не дает примерно ничего, поэтому Angie OSS в реестре и не присутствует. Для не OSS пока тоже особо не дает, при наличии OSS аналога. Зато если не присутствуешь, то на твою коммерческую версию даже смотреть не будут.
Исходя из этого, по факту реестр отечественного ПО не особо работает, тем более в нашем случае.
Но мне интересно, почему вы написали определенные слова и в кавычках? Присутствие в данном реестре - это не какая-то формальность, из него и исключить могут. Это не означает, что все строчки кода ПО, которое там находится - были написаны в России, хотя для nginx это даже на 99% именно так. Но это означает прежде всего, что есть некая компания, некое юр.лицо в российской юрисдикции, которое может понести вполне себе не "ответственность", а ОТВЕТСТВЕННОСТЬ по всей строгости, если вдруг что. Как на мой взгляд, это вполне себе в духе отечества, чтобы не писать это слово в кавычках применительно к реестру. Готовы на себя такую ответственность за какой-нибудь продукт взять просто так?
Поднятие бабла с госов и военки в США с некоторых пор стало совсем невозможно совместить с наличием офиса в России. Поэтому проще всех уволить и закрыть офис, что и предопределило появление Angie.
Потому, что это ближе по концепции к LTS. Т.е. каждый mainline релиз является стабильным, просто некоторые из них получают продленный на год срок поддержки и исправления критических ошибок.
И если у кого-то ещё остаются какие-то сомнения по поводу стабильности и позиционирования mainline ветки, то отдельно обращу внимание на то, как появляется очередная stable ветка: раз в год, обычно весной, текущая mainline ветка превращается в очередную stable ветку, при этом не имеет никакого значения, что какие-то функции и модули там уже почти год, а какие-то были добавлены за месяц до того. И ничего другого не происходит, никакой стабилизации кода, никаких дополнительных тестов - это просто ежегодное чисто формальное мероприятие от которого код не становится каким-то магическим образом более стабилен, чем был до того.
И "экспериментальность" отдельных модулей и функций - тут тоже совершенно ортогональная история. От переименования mainline ветки в очередную stable - "экспериментальные" модули и функции не перестают быть экспериментальными. Так, например, perl-модуль является экспериментальным с момента своего появления (в версии 0.3.21, выпущенной ещё в 2006 году) и по сей день. Т.е. этот "экспериментальный" модуль входит во все stable ветки за последние 18 лет.
Давайте заменим экспериментальный на нестабильный, что изменится? Вероятно ничего.
Как вы справедливо заметили ниже: нестабильный код не добавляют в стабильные релизы.
Тут у меня пожалуй вопрос лишь - зачем нестабильный модуль добавлять в стабильный релиз?
Это было бы очень странным и недальновидным решением с нашей стороны. Поэтому мы этого не делали. Может авторы nginx это сделали? Ниже попробуем разобраться.
Нестабильный - это тот код который не покрыт тестами, не поддерживает полностью rfc и имеет прочие недочеты.
Код HTTP/3 модуля достаточно неплохо покрыт тестами, а также неплохо соответствует RFC, благодаря чему даже согласно независимым тестам имеет хорошие характеристики по кросс-совместимости с другими реализациями (которые, кстати, не маркируются экспериментальными): https://interop.seemann.io/
Просто процитирую старшего продуктового директора 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.
Да, название второй ветки не совсем точное, что может сбить с толку. Правильнее было бы назвать вторую ветку - legacy, т.к. stable в её названии прежде всего означает заморозку API, что более актуально, если у вас есть какие-то устаревшие модули, на поддержку совместимости и актуальности которых вы хотите тратить меньше сил.
Я также замечу, что разработчик, не только включил модуль HTTP/3 в ветку, которая позиционируется достаточно стабильной, но и собирает с ним пакеты, в чем не трудно убедиться, установив пакет из официального репозитория nginx. И само собой этот модуль входит в официальные стабильные сборки релизов коммерческой версии NGINX Plus.
Делаем ли мы в Angie что-то иначе? Нет. В сухом остатке, Angie от nginx отличается расширенным набором стабильной и востребованной функциональности, которую давно уже спрашивают и ждут от самого nginx.
Любопытно чем сейчас отличается freenginx от nginx. А отличается он только отсутствием релиза с исправлениями критических багов в HTTP/3. В чем не трудно убедиться сравнив репозитории на текущий момент:
Где, кто и кому тут свинью подложил? Просто мы, как и F5, не считаем, что пользователи HTTP/3 должны дожидаться очередного релиза, чтобы закрыть критические ошибки. И с учетом всего изложенного выше - есть веские основания так считать.
Отдельно отмечу, что оба бага, которые были расценены как критические, поскольку позволяют сделать DoS атаку на сервер - обнаружены благодаря тем самым пользователям HTTP/3, которые с ними столкнулись в продакшене и завели тикеты:
Цитирую: its on production machine and happened several times
Ага, спасибо им, что сообщили, но наплевать на них, пусть ждут следующего очередного релиза, ведь сами виноваты, что включили в конфигурационном файле экспериментальный модуль, который поставляется в официальной стабильной сборке сервера - так что ли?
Мы не просто взяли у nginx, а мы его в том числе разрабатывали. Один из активных разработчиков HTTP/3 в nginx - работает у нас. Поэтому мы также добавили поддержку HTTP/3 клиента в сторону бэкенда и попробовали даже предложить эти патчи в nginx: https://mailman.nginx.org/pipermail/nginx-devel/2023-December/THMZAQ36SN5BICJSCLX6FLEUI45FHR4H.html - и в том числе отчасти из-за этого у нас оказалось на одну уязвимость меньше, наш код отличается.
"Экспериментальный" - это не более, чем способ снять с себя ответственность. Надо заметить, довольно плохой способ. Пользователи же хотят видеть нормальную, полноценную поддержку современных протоколов, а не вот эти отмазки. Что им с этим делать? Эксперименты ставить? Переходить на конкурентов, где поддержка HTTP/3 ни чуть не лучше, но просто не содержит слова "экспериментальный"? Наша позиция заключается в том, что современный веб-сервер заслуживает иметь полноценную поддержку современных протоколов.
Проработав в nginx одиннадцать лет и будучи, среди прочего, разработчиком аж 3-х "экспериментальных" модулей/механизмов: SPDY, HTTP/2, thread pools - я догадываюсь, что во многом "экспериментальность" HTTP/3 обусловлена негативным отношением одного человека к самому протоколу и тем, что он лично не принимал активного участия в разработке и ревью данного кода. И этот человек вовсе даже не Игорь Сысоев, написавший большую часть кода и заложивший основную архитектуру сервера.
для многих core-чуваков в open source их проект - это ребенок, особенно когда они над ним работают 10+ лет, нужно делать на это скидку, менеджмент должен был это понимать
Менеджмент, который двумя годами ранее выставил их на улицу? (вопрос риторический)
Замечу также, что мы уже выпускали релиз с усилением безопасности на неделю раньше, чем это изменение попало в выпуск nginx. Именно потому, что мы придерживаемся более строгой политики в этом отношении.
CVE может запросить кто угодно, даже совершенно постороннее лицо. Реакцию вызвал факт выпуска внеочередного security-релиза с исправлением, о чем рассказано, как в последующих письмах в рассылку, так и недавнем интервью хабру. И, как можно заметить, форк freenginx уже отличается от nginx тем, что не содержит данного релиза.
Мы в Angie такую позицию не разделяем, не делим код на "экспериментальный" и "не экспериментальный" в этом отношении. Пользователи уже используют HTTP/3 на своих серверах и имеют право, как узнавать об уязвимостях как можно раньше, так и получать исправленную сборку.
Но что стоит собирать его еще и под несколько древних ОС - мне не очень понятно
Вы так пишете, будто nginx продолжает собираться под bionic. Но этот репозиторий давно объявлен устаревшим, последняя версия пакета nginx под bionic в данной репе датирована маем прошлого года - это уже достаточно старая 1.25.0 с известными уязвимостями.
То же самое касается большинства других репозиториев по ссылке, они просто лежат в качестве архива, как дистрибутивы, когда-то давно поддерживаемые. Но ставить из них какие-то пакеты - это, мягко говоря, плохая идея с точки зрения безопасности.
Речь шла о сертификации и для этого уже разработчики дистрибутива проводят свои тесты и выдают сертификат совместимости.
А так, разумеется, у нас развернута огромная инфраструктура по сборке и тестированию для 13 различных дистрибутивов и 28 версий, 2-х архитектурах. Каждый коммит инициирует запуск нескольких десятков виртуалок, где происходит множество циклов сборок в различных конфигурациях и прогон функциональных тестов, в том числе с санитайзерами и статический анализ.
Для начала у всех комментаторов пишущих про "срубить бабла с государства" хочется спросить, хотя бы просто для расширения своего кругозора, а как это сделать? Расскажите, если у вас такой опыт имеется и видите сразу сходу такую перспективу. Отдельно интересно, как это сделать на OSS версии и зачем в таком случае вообще выпускать какую-то OSS версию? Есть у меня подозрения, что среди пишущих подобные комментарии нет никого, кто сам бы пытался вот так прийти и продать что-то в госкомпанию, либо получить какой-то грант от государства. Если коротко, это не секрет полишинеля, что хуже и труднее заказчика, чем госзаказчик для частного бизнеса - придумать сложно. Для компаний с участием государства возможно всё иначе, но я в таких не работал, не знаю.
А второй момент в том, что независимо от того, заинтересуются ли какие-нибудь госы нашим продуктом или нет - хочется продолжать разрабатывать достаточно хороший и проверенный временем веб-сервер, продолжать успешно применять свой опыт и знания в той сфере и в том продукте, где есть наибольшие компетенции. Если бы можно было продолжать разрабатывать nginx, мы бы сидели и спокойно продолжали его разрабатывать, никто бы и пальцем не пошевелил, никакого Angie не возникло. Но это вообще не наше решение. Это решение компании, которая владеет сейчас nginx, и довольно очевидно, что это её решение было принято не ради импортозамещения в России.
> Angie (и ещё тысячи “российских” продуктов из известного реестра т.н.
“отечественного ПО”) вряд ли бы появился, кабы не принятый закон об
импортозамещении (сослагательное наклонение призвано вполне недвусмысленно показать, что я этого не утверждаю, а лишь предполагаю/допускаю).
А Angie в реестре и не присутствует. В нем только Angie PRO.
Ссылаясь на этот закон, компании прекрасно используют nginx. Для OSS присутствие в реестре не дает примерно ничего, поэтому Angie OSS в реестре и не присутствует. Для не OSS пока тоже особо не дает, при наличии OSS аналога. Зато если не присутствуешь, то на твою коммерческую версию даже смотреть не будут.
Исходя из этого, по факту реестр отечественного ПО не особо работает, тем более в нашем случае.
Но мне интересно, почему вы написали определенные слова и в кавычках? Присутствие в данном реестре - это не какая-то формальность, из него и исключить могут. Это не означает, что все строчки кода ПО, которое там находится - были написаны в России, хотя для nginx это даже на 99% именно так. Но это означает прежде всего, что есть некая компания, некое юр.лицо в российской юрисдикции, которое может понести вполне себе не "ответственность", а ОТВЕТСТВЕННОСТЬ по всей строгости, если вдруг что. Как на мой взгляд, это вполне себе в духе отечества, чтобы не писать это слово в кавычках применительно к реестру. Готовы на себя такую ответственность за какой-нибудь продукт взять просто так?
Поднятие бабла с госов и военки в США с некоторых пор стало совсем невозможно совместить с наличием офиса в России. Поэтому проще всех уволить и закрыть офис, что и предопределило появление Angie.
Готово: https://angie.software/configuration/modules/http_acme/
Потому, что это ближе по концепции к LTS. Т.е. каждый mainline релиз является стабильным, просто некоторые из них получают продленный на год срок поддержки и исправления критических ошибок.
А зачем для этого open-source делать?
И если у кого-то ещё остаются какие-то сомнения по поводу стабильности и позиционирования mainline ветки, то отдельно обращу внимание на то, как появляется очередная stable ветка: раз в год, обычно весной, текущая mainline ветка превращается в очередную stable ветку, при этом не имеет никакого значения, что какие-то функции и модули там уже почти год, а какие-то были добавлены за месяц до того. И ничего другого не происходит, никакой стабилизации кода, никаких дополнительных тестов - это просто ежегодное чисто формальное мероприятие от которого код не становится каким-то магическим образом более стабилен, чем был до того.
И "экспериментальность" отдельных модулей и функций - тут тоже совершенно ортогональная история. От переименования mainline ветки в очередную stable - "экспериментальные" модули и функции не перестают быть экспериментальными. Так, например, perl-модуль является экспериментальным с момента своего появления (в версии 0.3.21, выпущенной ещё в 2006 году) и по сей день. Т.е. этот "экспериментальный" модуль входит во все stable ветки за последние 18 лет.
Как вы справедливо заметили ниже: нестабильный код не добавляют в стабильные релизы.
Это было бы очень странным и недальновидным решением с нашей стороны. Поэтому мы этого не делали. Может авторы nginx это сделали? Ниже попробуем разобраться.
Код HTTP/3 модуля достаточно неплохо покрыт тестами, а также неплохо соответствует RFC, благодаря чему даже согласно независимым тестам имеет хорошие характеристики по кросс-совместимости с другими реализациями (которые, кстати, не маркируются экспериментальными): https://interop.seemann.io/
Ветка 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. В чем не трудно убедиться сравнив репозитории на текущий момент:
Где, кто и кому тут свинью подложил? Просто мы, как и 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
Ага, спасибо им, что сообщили, но наплевать на них, пусть ждут следующего очередного релиза, ведь сами виноваты, что включили в конфигурационном файле экспериментальный модуль, который поставляется в официальной стабильной сборке сервера - так что ли?
Мы не просто взяли у nginx, а мы его в том числе разрабатывали. Один из активных разработчиков HTTP/3 в nginx - работает у нас. Поэтому мы также добавили поддержку HTTP/3 клиента в сторону бэкенда и попробовали даже предложить эти патчи в nginx: https://mailman.nginx.org/pipermail/nginx-devel/2023-December/THMZAQ36SN5BICJSCLX6FLEUI45FHR4H.html - и в том числе отчасти из-за этого у нас оказалось на одну уязвимость меньше, наш код отличается.
"Экспериментальный" - это не более, чем способ снять с себя ответственность. Надо заметить, довольно плохой способ. Пользователи же хотят видеть нормальную, полноценную поддержку современных протоколов, а не вот эти отмазки. Что им с этим делать? Эксперименты ставить? Переходить на конкурентов, где поддержка HTTP/3 ни чуть не лучше, но просто не содержит слова "экспериментальный"? Наша позиция заключается в том, что современный веб-сервер заслуживает иметь полноценную поддержку современных протоколов.
Проработав в nginx одиннадцать лет и будучи, среди прочего, разработчиком аж 3-х "экспериментальных" модулей/механизмов: SPDY, HTTP/2, thread pools - я догадываюсь, что во многом "экспериментальность" HTTP/3 обусловлена негативным отношением одного человека к самому протоколу и тем, что он лично не принимал активного участия в разработке и ревью данного кода. И этот человек вовсе даже не Игорь Сысоев, написавший большую часть кода и заложивший основную архитектуру сервера.
Факт от этого не меняется, что заметная часть коллектива ушла делать Angie.
Менеджмент, который двумя годами ранее выставил их на улицу? (вопрос риторический)
Замечу также, что мы уже выпускали релиз с усилением безопасности на неделю раньше, чем это изменение попало в выпуск nginx. Именно потому, что мы придерживаемся более строгой политики в этом отношении.
CVE может запросить кто угодно, даже совершенно постороннее лицо. Реакцию вызвал факт выпуска внеочередного security-релиза с исправлением, о чем рассказано, как в последующих письмах в рассылку, так и недавнем интервью хабру. И, как можно заметить, форк freenginx уже отличается от nginx тем, что не содержит данного релиза.
Мы в Angie такую позицию не разделяем, не делим код на "экспериментальный" и "не экспериментальный" в этом отношении. Пользователи уже используют HTTP/3 на своих серверах и имеют право, как узнавать об уязвимостях как можно раньше, так и получать исправленную сборку.
Вы так пишете, будто nginx продолжает собираться под bionic. Но этот репозиторий давно объявлен устаревшим, последняя версия пакета nginx под bionic в данной репе датирована маем прошлого года - это уже достаточно старая 1.25.0 с известными уязвимостями.
То же самое касается большинства других репозиториев по ссылке, они просто лежат в качестве архива, как дистрибутивы, когда-то давно поддерживаемые. Но ставить из них какие-то пакеты - это, мягко говоря, плохая идея с точки зрения безопасности.
Angie скоро тоже будет автоматически получать сертификаты. Поддержка ACME уже на финальной стадии разработки.
Физтехам привет! ;)
Речь шла о сертификации и для этого уже разработчики дистрибутива проводят свои тесты и выдают сертификат совместимости.
А так, разумеется, у нас развернута огромная инфраструктура по сборке и тестированию для 13 различных дистрибутивов и 28 версий, 2-х архитектурах. Каждый коммит инициирует запуск нескольких десятков виртуалок, где происходит множество циклов сборок в различных конфигурациях и прогон функциональных тестов, в том числе с санитайзерами и статический анализ.
Поэтому разработчики библиотеки китайской криптографии рекомендуют Angie ;)
https://www.tongsuo.net/eco/
Большая часть вопросов должна отпасть, если учесть, что Angie разрабатывает та же команда, что до этого 10 лет разрабатывала nginx.
64 бита. Пойдет считать по второму кругу, с нуля.
... между тем помогаешь сфабриковать дело против Игоря Сысоева (просто погуглите).