Замечу также, что мы уже выпускали релиз с усилением безопасности на неделю раньше, чем это изменение попало в выпуск 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. Именно потому, что мы придерживаемся более строгой политики в этом отношении.
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 просто отсутствует. Думаю рано или поздно мы это реализуем.
Спасибо за напоминание. Действительно, с кросс-компиляцией беда. Занес ваше пожелание в список потенциальных улучшений.
Вы же не считаете, что отказавшись помогать пользователю выполнить законодательное требование - кто-то бы улучшил репутацию того самого органа или хоть как-то поборол тех, кто её испортил?
На ваш пример у меня есть свой пример. Сюжет тот же, но только помочь надо остановить насильника или террориста. К чему эти фантазии?
Очевидно, что преступники и террористы пользуются шифрованными каналами связи для подготовки своих преступлений. В то же время бывают и обратные ситуации, когда злоупотребляют полномочиями не для тех целей, которым по идее должны служить. Мир не состоит из черного и белого.