Мы не просто взяли у 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-х архитектурах. Каждый коммит инициирует запуск нескольких десятков виртуалок, где происходит множество циклов сборок в различных конфигурациях и прогон функциональных тестов, в том числе с санитайзерами и статический анализ.
"usable" не означает, что это правильно и удобно. Всё-таки писать на С++ в стиле С - довольно неблагодарное занятие, а если не в стиле С, то это означает сильно отличаться от кода стандартных библиотек Python, что также сомнительный выбор для задачи расширения возможностей Python (как и любой необоснованный зоопарк языков в проекте).
Исключение тут составляют библиотеки, которые изначально были написаны на другом языке, а далее уже был сделан биндинг для Python.
Головной процесс работает от root и не принимает клиентских соединений, как по соображениям безопасности, так и стабильности (его падение будет фатальным).
То, что вы описали - больше похоже на некий дамп, который может сделать только админ локально. Но это в целом то и сейчас можно сделать, написав скрипт с использованием gdb, который подключится к каждому процессу и извлечет всю нужную информацию из его структур. А сравнивать длину костылей нет большого смысла.
Нет, на первый взгляд это совсем не то. В nginx есть разделяемая память и структуры данных, которые могут в ней жить. Данный модуль похоже просто реализует интерфейс к такой структуре типа очереди в разделяемой памяти.
Рабочие процессы могут добавлять элементы в эту память под мьютексом или lock-free, но им не нужно знать ничего друг о друге. Манипуляции с памятью целиком и польностью осуществляет тот процесс, в который пришел соответствующий запрос и ему не важно, что там происходит в других процессах, сколько их, существуют ли они вообще, и т.д., до тех пор, пока изменения происходят атомарно (за счет мьютекса или lock-free алгоритмом).
У нас же задача значительно сложнее: 1. Каждый рабочий процесс, в который может потенциально прийти запрос статуса, должен знать о существовании других процессов. 2. Поскольку сами процессы их число - величина не постоянная, то в момент, когда какой-то из процессов завершается или стартует новый, другие рабочие процессы должны узнавать об этом и получать каналы связи с новыми процессами. 3. Через эти каналы связи процесс, в который придет запрос статуса должен будет запросить из других процессов информацию, разбудив их и дождавшись, когда информация поступит из каждого процесса. 4. Все это сопровождается обработкой всевозможных race conditions, например, когда мы направили запрос в процесс, который как раз решил завершиться в этот момент, но он ещё не получил запроса, а мы ещё не получили информации о том, что он завершается. 5. Сама разделяемая память разумеется может служить таким каналом связи, но будет необходим ещё механизм, который позволит будить процессы, уведомлять их о новой информации или запросе из другого процесса.
Сдерживающие факторы такие, что это другой продукт получается, который не будет совместим со всеми сторонними модулями, а также потребует переписывания заметного количества кода существующих модулей. Дело в том, что весь текущий код nginx и сторонний код написан в парадигме отсутствия необходимости обеспечения thread-safety.
Да, было бы здорово такое реализовать. Но в nginx это достаточно нетривиальная задача. Можно получить информацию о запросах, которые обрабатываются в том же процессе, куда поступил запрос к статистике, но для извлечения информации из других рабочих процессов потребуется некий механизм ipc, который на данный момент в nginx просто отсутствует. Думаю рано или поздно мы это реализуем.
Мы не просто взяли у 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 бита. Пойдет считать по второму кругу, с нуля.
... между тем помогаешь сфабриковать дело против Игоря Сысоева (просто погуглите).
"usable" не означает, что это правильно и удобно. Всё-таки писать на С++ в стиле С - довольно неблагодарное занятие, а если не в стиле С, то это означает сильно отличаться от кода стандартных библиотек Python, что также сомнительный выбор для задачи расширения возможностей Python (как и любой необоснованный зоопарк языков в проекте).
Исключение тут составляют библиотеки, которые изначально были написаны на другом языке, а далее уже был сделан биндинг для Python.
Вообще-то
Numpyнаписан с использованием С, а не на С++. Большинство подобных библиотек написано на С, что логично, т.к. сам Python тоже написан на С.А кто тогда будет разрабатывать? =)
Головной процесс работает от root и не принимает клиентских соединений, как по соображениям безопасности, так и стабильности (его падение будет фатальным).
То, что вы описали - больше похоже на некий дамп, который может сделать только админ локально. Но это в целом то и сейчас можно сделать, написав скрипт с использованием gdb, который подключится к каждому процессу и извлечет всю нужную информацию из его структур. А сравнивать длину костылей нет большого смысла.
Нет, на первый взгляд это совсем не то. В nginx есть разделяемая память и структуры данных, которые могут в ней жить. Данный модуль похоже просто реализует интерфейс к такой структуре типа очереди в разделяемой памяти.
Рабочие процессы могут добавлять элементы в эту память под мьютексом или lock-free, но им не нужно знать ничего друг о друге. Манипуляции с памятью целиком и польностью осуществляет тот процесс, в который пришел соответствующий запрос и ему не важно, что там происходит в других процессах, сколько их, существуют ли они вообще, и т.д., до тех пор, пока изменения происходят атомарно (за счет мьютекса или lock-free алгоритмом).
У нас же задача значительно сложнее:
1. Каждый рабочий процесс, в который может потенциально прийти запрос статуса, должен знать о существовании других процессов.
2. Поскольку сами процессы их число - величина не постоянная, то в момент, когда какой-то из процессов завершается или стартует новый, другие рабочие процессы должны узнавать об этом и получать каналы связи с новыми процессами.
3. Через эти каналы связи процесс, в который придет запрос статуса должен будет запросить из других процессов информацию, разбудив их и дождавшись, когда информация поступит из каждого процесса.
4. Все это сопровождается обработкой всевозможных race conditions, например, когда мы направили запрос в процесс, который как раз решил завершиться в этот момент, но он ещё не получил запроса, а мы ещё не получили информации о том, что он завершается.
5. Сама разделяемая память разумеется может служить таким каналом связи, но будет необходим ещё механизм, который позволит будить процессы, уведомлять их о новой информации или запросе из другого процесса.
Собственно в Unit-е мы это сделали.
Сдерживающие факторы такие, что это другой продукт получается, который не будет совместим со всеми сторонними модулями, а также потребует переписывания заметного количества кода существующих модулей. Дело в том, что весь текущий код nginx и сторонний код написан в парадигме отсутствия необходимости обеспечения thread-safety.
Да, было бы здорово такое реализовать. Но в nginx это достаточно нетривиальная задача. Можно получить информацию о запросах, которые обрабатываются в том же процессе, куда поступил запрос к статистике, но для извлечения информации из других рабочих процессов потребуется некий механизм ipc, который на данный момент в nginx просто отсутствует. Думаю рано или поздно мы это реализуем.