Уязвимости в проекте Pingora, позволяющие вклиниться

Им твоя библия в рундуке, как зайцу стоп-сигнал в лесу, они читать то не умели.

Вы, кажется, тоже не умеете. Чтобы хранить Библию в рундуке, читать вообще уметь не надо. Но для моряка и пирата это нормально. К современным программистам требования несколько выше.

Тоже мне секрет, хотел быструю симулу с таким синтакисом чтобы сишники не пугались и переходили. И тот же Страуструп накатал целую книжку-оправдание почему плюсы получились вот такими, дипломатично скажем, неказистыми.

иначе не писал бы такого бреда про С.

Ага, а потом плюсовики удивляются почему код с 8-битными числами или строками в разы тормознее чем с числами с большей битностью, несмотря на все современные симды и умные компиляторы.

1. Тесты есть всегда, даже на очень маленьком проекте. Может это просто «ручной» запуск и пониманием того, что все пути отработали. Цель тестов - проверка логики, остальное - побочное. Логических ошибок всегда больше. Почему-то обычно я не выхожу за границы, не течёт ничего и нет прочего use after free, но вот ошибка в логике - легко. Я не верю, что кто-то адекватный пишет какой-то код без всяких тестов и релизит софт на любом ЯП.

Если на внедрении код исполняется в среде с продвинутыми санитайзерами а-ля Fil-C++ или раст - то по крашу будет более понятно что произошло, чем если код исполнялся в среде без санитайзеров и упало через 1000 инструкций после реальной причины, и даже при наличии core-dump разбирательство займёт безумные человеко-дни потому что это будет угадайка на тему «а какой из 10 потоков перезаписал тут данные указателя числом 1 неизвестное количество времени назад». Или хуже того не упало, а внесло ошибку в данные, которая всплывёт через 5 лет

Ок, давай представим - у нас обычный с++ (не Fil-C++), у нас нет нормального покрытия тестами, мы хотим падать сразу и получать корку, а не непонятная ошибка когда-то там. Что можем сделать?

• шланг поддерживает опцию -Wunsafe-buffer-usage, мы будем получать предупреждения, когда проверить границы нельзя

void f(int *p) {
    ++ p; // warning
    *p = 4;
}

int i;
cin >> i;
int a[3] = {};
cout << a[i] << endl; // warning

• опция _GLIBCXX_ASSERTIONS - вставляет проверки границ в стандартных контейнерах (аля vector_instance[3]), ABI не ломается. Кстати, это дефолт в дебаге.

Вывод: тесты нужны всегда. Проверять границы в рантайме и падать сразу - можно без всяких Fil-C++ и раста

Не упавшая, а аварийно завершившая работу в условиях непредусмотренного нарушения инвариантов, корректно определив ситуацию.

Можешь назвать это как угодно, но по факту - это не то что ожидает от неё конечный пользователь/механизм. Упавшая программа - может даже нанести больший вред, кто знает чем она управляет

Если падение программы может принести большой вред, то это учитывается с самого начала проектирования програмно-аппаратного комплекса. Задача процесса — не портить память и файлы на диске. Всё остальное уже задача оркестратора.

А ну как перепишут приходи. Только этого не будет. Потому что слишком много всяких двусвязных списков или чего-то подобного им в ядре. Ах да там же не только двусвязные списки там ещё много чего такого вот что боров очень не будет любить. Удачи писать с нуля

А ну как перепишут приходи.

Чтобы приходить, нужно сначала уйти. А Rust is here to stay.

Только этого не будет.

Успокойтесь, вашу сишку никто не забирает, ведь на ней столько всего понаписано. C, fortran, cobol — ещё нас всех переживут.

15 человек на сундук мертвеца, про Библию ни слова.

Да что за бзик у хейтерков с списками, этот «довод» давно устарел если чё. Нормально всё со списками в расте и 1 и 2-ух и более связными, и в любом случае получше чем в си, особенно включая те что на сыроуказателях. Просто потому-что что угодно лучше чем на Си, слишком уж убогий и кривой язык.

Юникс выкинули на помойку тридцать лет назад. Алё.

Алё, Маня. А у кого 14,26% мирового рынка десктопов? Нет, это не линукс.

Каждый аргумент убойнее предыдущего. Вы б хоть до пятницы дотянули с алкоголем-то. Так и спиться не долго.

Ты можешь думать, что учитываешь что угодно. Пока ты не протестишь свою поделку как следует, на руках у тебя всего лишь прототип с потенциальными багами. И разговоры в духе: «ну у меня здесь безопасный язык, раз скомпилил, значит ок. А если и упало, то не упало, а завершилось» - бред.

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

https://www.opengroup.org/openbrand/register/apple.htm

Выкинули говоришь? 30 лет назад?

А у кого 14,26%

У того, кто умеет делать качественные продукты и не кладёт болт на безопасность.

мирового рынка десктопов?

Ещё рынок игровых приставок посчитайте.

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

Такие разговоры я слышал только от местных сишников. Собственно, на сам rust мне плевать, меня больше ошибки в логике софорумцев забавляют. У сишников раз за разом повторяются аргументы: «избиение соломенного чучела», «аппеляция к авторитету» и «сам дурак». И почти ничего кроме этого. Хотя казалось бы, чисто технические вопросы обсуждаем.

А если и упало, то не упало, а завершилось

В определённом контексте вполне разумный подход.

Не вертись как вошъ на гребешке. Кто прокукарекал «Юникс выкинули на помойку тридцать лет назад. Алё.»?

Не вертись как вошъ на гребешке.

Отчего бы вам самим не последовать своему совету? Юникс — это юникс. Выкинут на помойку и вполне заслужено. А макось и плейстейшн — это макось и плейстйшн — самостоятельные успешные продукты. Не обижайтесь, но это правда.

Под дурочку косишь? Специально для альт. одаренных, макось это и есть сертифицированный юникс.

Под дурочку косишь?

Вас в колхозе воспитывали?

макось это и есть сертифицированный юникс.

В контексте разговора о коде на С, написанном «отцами-оснвателями» — бриллиантово наплевать что там кому сертифицировали. Собственно, то, что вы банальный контекст не способны удержать в памяти и является лучшем аргументом в пользу Rust. Слабый разум нуждается в поддержке и защите.

Ну раз с этим ты согласен, тогда цель раста лично мне не ясна. Все пишут тесты, тесты должны покрыть максимально много. На своих плюсовых тестах я отловлю всё то, что достаётся растаманам в тяжелых баталиях с компилятором. Ну ладно, видимо, особые люди, которые любят страдания

Ко-ко-ко. Тебя конкретно ткнули носом в глупость, которую ты сморозил. «Юникс выкинули на помойку тридцать лет назад. Алё.» Теперь обтекай.

Похоже я и вправду ошибся. Вас в колхозе воспитывали-воспитывали, да не воспитали. Прискорбно.

Так что там со списками? Какими костылями по итогу подперли свой свинарник с боровом внутри?

Ну раз с этим ты согласен, тогда цель раста лично мне не ясна.

Люди тупые, ленивые, невнимательные. Я тут вынужден общаться с человеком, который контекст беседы дольше двух сообщений удержать не способен. Людям нужна помощь и поддержка. Типы и тесты — два мощных оружия современного программиста, которые не противоречат, но помогают один другому. Оба этих средства несовершенны: типы не способны покрыть сложную логику. Тесты покрывают только часть входных значений.

На своих плюсовых тестах я отловлю всё

Сишники и примкнувшие к ним плюсонавты не научились писать без дыр за минувшие десятилетия. Лично вы, уверен, не такой. Но все остальные тупо недостаточно хороши.

я не выхожу за границы, не течёт ничего и нет прочего use after free, но вот ошибка в логике - легко

Ты легко допускаешь ошибки в логике, но не допускаешь ошибки в логике работы с памятью. Объясни, что в них такого особенного, что тебе не удаётся их допускать?

Ты серьезно? Сложность алгоритмов не ограничена ничем. Это и есть то, чем занимается программист - не борьбой с компилятором, а придумыванием какой-то абстрактной модели и перкладыванием её на ЯП. Не учел то, неправильно подумал там, … . Не думаю, что если язык заставляет чесать гланды через зад, то это как-то позитивно отразится на такой творческой деятельности, это нельзя, там не ходи, …

На своих плюсовых тестах я отловлю всё то, что достаётся растаманам в тяжелых баталиях с компилятором.

Боров (какбе) строит доказательство, что с памятью всё чики-пуки.
А твои тесты - это коллекция примеров, на которых с памятью тоже всё чики-пуки.
Как известно из школьного курса математики, между доказательством теоремы и примерами, подтверждающими правильность этой теоремы, обычно лежит пропасть.
Бывает так, что на всех рассмотренных примерах утверждение оказалось истинно, но в общем случае оно истинным является не всегда (и доказательство его истинности для этого общего случая построить не получится).

Сложность алгоритмов не ограничена ничем. Это и есть то, чем занимается программист - не борьбой с компилятором, а придумыванием какой-то абстрактной модели и перкладыванием её на ЯП.

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

Боров подталкивает программиста к тому, чтобы использовать относительно простую модель владения памятью (как метко написал byko3y в своём бложике, "shared read-only state, one way data flow, acyclic data structures"). Если можно уложить программу на эту модель, то зачем с ней бороться?

Боров подталкивает программиста к тому, чтобы использовать относительно простую модель владения памятью (как метко написал byko3y в своём бложике, «shared read-only state, one way data flow, acyclic data structures»). Если можно уложить программу на эту модель, то зачем с ней бороться?

Я вцелом солидарен с этим взглядом, но бывают более сложные случаи, когда так просто не получается. Но! в этих случаях в расте превозмогание борова, а в С/С++ - тонны комментариев описывающих модель и ручная проверка что написанная логика им соответствует. Порядок сложности на мой взгляд ~сопоставим, таким образом аргумент «затратно бороться с боровом» разбивается о то, что «в любом языке тяжело поддерживать сложную архитектуру».

Боров (какбе) строит доказательство, что с памятью всё чики-пуки. А твои тесты - это коллекция примеров, на которых с памятью тоже всё чики-пуки.

Боров строит лишь доказательство, что с памятью чики-пуки в местах, где индексы статичны, а не зависят от входных данных. Для последнего ты получаешь проверку в рантайме с абортом. Нельзя ничего гарантировать в компайл тайме, когда индекс массива приходит от юзера из консоли.

Как ловить ошибки второго типа? Писать тесты. Как ловить логические ошибки? Писать тесты. Значит нужно писать тесты и покрывать ими все ветви? Да!

А твои тесты - это коллекция примеров, на которых с памятью тоже всё чики-пуки.

Нет, конечно. Во-первых, для достижения ветвей и проверки «статичных индексов» (да, раст это делает в компайл тайме, но взамен нужно делать странные и неудобные вещи). Во-вторых, проверка логики. В-третьих, разные входные данные в том числе для проверки «динамических индексов».

В сухом остатке - раст ни сколько не избавляет от написания тестов, ты должен писать их в том же объёме (для проверки логики, и для динамических условий, которые приходят в ран тайме). А раз так, то стоит ли вся эта игра с боровым свеч? (нет)

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

Вы откуда-то взяли, что типы (считаем проверку владения разновидностью типизации) должны избавлять от тестов и героически спорите с этим утверждением.

Я ни в коем случае не предлагаю отказываться от написания тестов.

Боров не позволит совершить ряд ошибок из числа тех, которые тестами пойманы не будут. Подтолкнет к тому, чтобы написать программу, которая будет корректна по построению. Просто поищи статистику по CVE: какой процент их связан с некорректной работой с памятью (примерно 50%).

И да, если выбирать между падением и remote code execution, то падение гораздо-гораздо лучше.

Повар глянул на свою ладонь.
– Черная метка! Так я и думал, - проговорил он. – Где вы достали бумагу?.. Но что это? Ах вы, несчастные! Вырезали из Библии! Ну, будет уж вам за это! И какой дурак разрезал Библию?
– Вот видите! – сказал Морган. – Что я говорил? Ничего хорошего не выйдет из этого.
– Ну, теперь уж вам не отвертеться от виселицы, – продолжал Сильвер. – У какого дурака вы взяли эту Библию?
– У Дика, – сказал кто-то.
– У Дика? Ну, Дик, молись богу, - проговорил Сильвер, – потому что твоя песенка спета. Уж я верно тебе говорю. Пропало твое дело, накажи меня бог!

Раз они этого не делают, то вся эта возня с боровым смысла не имеет, ничего кроме боли от запретов. Ведь раст заявляет о себе так, что «у нас все безопасно», логично подумать, ну что и тестить тогда не нужно. Но это неверно. А покрытый код тестами и без всякого раста нормально себя чувствует

Ведь раст заявляет о себе так, что «у нас все безопасно»

Со стороны разработчиков раста никогда не заявлялось, что там *всё* безопасно. Они претендуют на «memory-safety and thread-safety», и претензии эти спорны.

логично подумать, ну что и тестить тогда не нужно.

Вообще не логично. Может быть, лично тебе так думается, но это просто ошибочное суждение (логическая ошибка) с твоей стороны.

А покрытый код тестами и без всякого раста нормально себя чувствует

Это снова логическая ошибка. Тесты не могут гарантировать корректность. Вон openssl и тестируют, и используют широко, и порядок там пытались наводить, и вот что мы имеем из свеженького:

CVE-2025-15467 - Published at 27 January 2026 - Stack buffer overflow in CMS (Auth)EnvelopedData parsing
CVE-2025-68160 - Published at 27 January 2026 - Heap out-of-bounds write in BIO_f_linebuffer on short writes
CVE-2025-69419 - Published at 27 January 2026 - Out of bounds write in PKCS12_get_friendlyname() UTF-8 conversion
CVE-2025-9230 - Published at 30 September 2025 - Out-of-bounds read & write in RFC 3211 KEK Unwrap
CVE-2025-9232 - Published at 30 September 2025 - Out-of-bounds read in HTTP client no_proxy handling

Ведь раст заявляет о себе так, что «у нас все безопасно»

Где? Вот, где он это о себе заявляет? Заявляется отсутствие проблем с памятью. На этом всё. Всё!

логично подумать, ну что и тестить тогда не нужно

Нелогично. То, что у программы нет проблем с памятью вообще не означает, что она делает то, что от неё ожидают.

А покрытый код тестами и без всякого раста нормально себя чувствует

База CVE чувствует себя ещё лучше.

А если есть тесты, которые можно запускать с санитарами, нахрен нужен раст? Сражаться героически с его компилятором, а потом всё равно запускать те же тесты? Какая-то ненужная боль

Ты знаешь, я недавно пытался контрибутить в llama.cpp, и я осознал, насколько есть иная культура разработки, нежели та, в которой я привык, поддерживая 15-летнее легаси. Челы в прод два раза в день новые программы выдают. На скорость. Старые баги фиксить некогда — новых фич багфиксы не добавят. Но самое страшное то, что это таки работает — когда-нибудь кто-нибудь эти баги пофиксит... или нет... или софтина уже никому не нужна будет к этому времени.

Если тесты писать «некогда», то всё-таки иметь более безопасный язык фоном намного приятнее. Поэтому применяют нынче не Rust, и даже не C++, а Go. Иронично, что таки Ollama написана на Go, и таки этот кусок говна постоянно с неправильными конфигами запускает мне нейросетки. Тестирование? Что это такое? Не, не слышали.

И безопасной бритвой можно порезаться. Толко всё кричат «безопасная», и все забывают «бритва». Вот это смешит.

Исправдливости ради, HTTP — исключительно сложный и запутанный протокол, как бы раст тут не при чём. Обработку HTTP на любом языке нужно писать и исправлять десятилетями.

Если на внедрении код исполняется в среде с продвинутыми санитайзерами а-ля Fil-C++ или раст - то по крашу будет более понятно что произошло, чем если код исполнялся в среде без санитайзеров и упало через 1000 инструкций после реальной причины, и даже при наличии core-dump разбирательство займёт безумные человеко-дни потому что это будет угадайка на тему «а какой из 10 потоков перезаписал тут данные указателя числом 1 неизвестное количество времени назад». Или хуже того не упало, а внесло ошибку в данные, которая всплывёт через 5 лет

Я тебе скажу страшную вещь, но Rust не защищает от повреждения памяти. Один unsafe может разнести всю программу — разница в том, что в Rust потенциальные опасные точки явно отмечены, в то время, как в C++ о-о-очень любят писать неявное поведение, из-за чего опасная операция может скрываться за каким нибудь c = a + b.

Как сказал один мудрый комментарий в интернете, вольный пересказ: «лучшие программы, в разработке которых я участвовал, были написаны командой на C++; но это было просто потому, что в команде разработки C++ были очень сильные программисты».

Fil-C++ кажется даёт этот же эффект. То есть доя кода хорошо покрытого тестами безопасность раст и Fil-C++ одинакова. Тут сложно сказать кто из них будет проще в поддержке/разработке через 15 лет, поскольку при поддержании сложной по архитектуре кодовой базы с хорошим покрытием тестами - большая часть времени уходит на проектирование, а никак на борьбу с компилятором.

Если тебе нужно быстро что-то написать и быть уверенным в надёжности софтины, то ты не используешь ни C++, ни Rust, ни Fil-C.

Пример такого проекта - QtCreator, там каждая фича запилена побыстрому за 2 недели и половина его версий - глючит/падает раз в 2 дня при работе в нём с большим проектом.
Учитывая что проектов такого вида много боше чем хорошо покрытых тестами - для них раст был бы очень полезен сокращением числа ошибок при условии что структура проекта не слишком сильно вынуждает бороться с компилятором.

Неочевидный факт: программы на Rust падают чаще, чем на C++. Как ты думаешь, почему?

В конце концов, если ты настолько туп, что косячишь с указателями и памятью, то может не стоит заниматься системщиной, а пойти в детский сад. Отцы целиком написали промышленный Unix на сырых указателях, а это, минуточку, 30 млн. строк. Расскажи им про раст, они вообще бы не поняли про что это и зачем.

https://bykozy.me/blog/llm-s-are-not-smart-rather-programming-is-retarded/
Писали на Си, и глючили много эти системы. Дело не в языке, а в фундаментальной ненадёжности аппаратной платформы. Си — это просто язык, наиболее близкий к аппаратной платформе (после асма), и потому наиболее ненадёжный. У меня давно есть теория, что на то воля господа, и развитие компов тормозится к лучшему.

Ну то есть если взять те же FPGA — если в цепи нет циклов или слишком больших задержек, то она в принципе не может выдать никакого некорректного результата, потому что там нет никаких указателей и изменение вообще любой ячейки памяти не приводит к радикальному и непредсказуемому результату.

Жалко Страуструп не дожал и сразу не выкинул весь сишный рак с типами(одна вот эта херня с char=int8_t=uint8_t, а если пририсовать * то вообще чему угодно, чего стоит). И именно в системщине типы и касты должны быть строгими и точными настолько насколько это вообще возможно.

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

Сишный говнокод и дырени с самих отцов и начался.

Неочевидный факт, потому что многие сидящие тут ещё не родились к тому времени: как правило, сишный код тех времён был крайне низкого качества. Начиная, собственно, с самого компилятора Си.

А двусвязные списки прекрасно реализуются на массивах.

Только это уже не двухсвязанные списки, а trie-mapped array. Официальная позиция растовиков: «двухсвязанные списки не нужны».

Где безопасные ОС на безопасном расте?

Теперь здесь.

Ни в какое ближайшее время Linux не будет переписан на расте. Даже в самом оптимистичном сценарии это всё равно не имеет смысла, потому что взаимодействие с железом на расте нельзя безопасно написать.

Боров подталкивает программиста к тому, чтобы использовать относительно простую модель владения памятью (как метко написал byko3y в своём бложике, «shared read-only state, one way data flow, acyclic data structures»). Если можно уложить программу на эту модель, то зачем с ней бороться?

А если нельзя? Ты примерно представляешь, какие софтины ложатся на эту модель? Какие-нибудь парсеры, неинтерактивные консольные утилиты, какие-нибудь библиотеки/программы с обработкой данных либо в одном потоке, либо в независимых потоках. GUI? Не подходит. БД? Нет. Stateful сервисы? Тоже нет.

Набор возможностей оказывается настолько куцым, что даже Mozilla до сих пор не смогла написать на Rust браузер, хотя это именно они начали писать браузер на расте. Писать браузер целиком на Rust бессмысленно — он будет просто сношать мозги, не давая никаких дополнительных гарантий надёжности для большей части кода.

Только это уже не двухсвязанные списки

Пардоньте. Двусвязный список это то, что обладает семантикой двусвязного списка. А уж как оно внутри устроено: на массивах, указателях или как ещё, то совсем другое дело.

Ни в какое ближайшее время Linux не будет переписан на расте.

Весь целиком — конечно не будет. Никто и задачи такой не ставит. Просто сишечка постепенно мигрирует из «язык по умолчанию для всего» в нишевый загончик. Теперь и в ядре тоже.

покрытый код тестами и без всякого раста нормально себя чувствует

Только если ты пишешь достаточно простой код, чтобы его было возможно покрыть тестами.

Во-первых, рейсы.

Во-вторых, окружение может быть сколько угодно сложным и вариативным. У были и юнит-тесты, и санитайзеры, и три тестировщика целыми днями гоняли стенды. И мы продолжали ловить use-after-free в кейсах в духе «На windows 7, на слабой виртуалке пропадает сеть на более чем 30 секунд, потом юзер жмет кнопку X, потом свитчится на юзера2 без админских прав, и тут сеть восстанавливается; воспроизводится 1 раз из 5, шаг влево-вправо - не воспроизводится». Юнит-тесты тут бесполезны и пишутся пост-фактум, чтобы зафиксировать исправление. И выглядят тупо как многоступенчатое переключение состояний, удачи такое покрыть заранее.

Пардоньте. Двусвязный список это то, что обладает семантикой двусвязного списка. А уж как оно внутри устроено: на массивах, указателях или как ещё, то совсем другое дело.

Я так понимаю, что ты каждый запрос к БД делаешь фулсканом, правильно? Ну а какая разница, как записи хранить?