Фонд OSTIF (Open Source Technology Improvement Fund), созданный с целью усиления защищённости открытых проектов, опубликовал результаты аудита безопасности библиотек Boost, применяемых во многих проектах на языке C++. Аудит, который был проведён по заказу OSTIF и Amazon Web Services итальянской компанией Shielder, выявил 7 проблем, из которых одной присвоен средний уровень опасности, а четырём - низкий, две проблемы опубликованы в виде информационных замечаний...Подробнее: https://www.opennet.me/opennews/art.shtml?num=61233
Из отчета:
> Если вы являетесь разработчиком, использующим библиотеки Boost, рекомендуется выполнить строгую проверку входных данных.А что, можно не проверять?
Можно, конечно. Кто тебя заставит?
Обычно в документации к функциям программных библиотек отражают необходимость верификации/очистки входных данных. Иначе будет беспорядок. Раньше были случаи, когда за корректность данных отвечали сами функции. Например, библиотеки ASA или SSP. Но это совершенно неудобно - анализировать множество кодов при некорректном завершении (можно, кстати, перепутать, какой код что означает). Считаю, что незачем нагружать функции несвойственными процедурами. Их цель - корректно отрабатывать алгоритмы обработки при правильных входных данных.
> Считаю, что незачем нагружать функции несвойственными процедурами. Их цель - корректно отрабатывать алгоритмы обработки при правильных входных данных.А о допустимых значениях аргументов функции где узнать? В документации? Отлично.
Таким же макаром, зачем вообще нагружать аргументы этих функции типами? Функция работает с целыми числами, так и запишем в документации.пс: типы ведь проверяет компилятор (и кусок рантайма) :)
Да документация это хорошо. Но лучше провести тест как поведёт себя функция. А если функция ожидает сам тип? Тут можно написать статью про тестирование.... Ааа зачем вам тесты забыл, покажем типа работает, получим денег. Ве не с бюджетной организации?
> Ааа зачем вам тестыНу да фаззинг тесты в приложении к документации, повторяю, типы зачем тогда?
> Ве не с бюджетной организации?
Нет, из "карманно-алэгархической" :)
Вот кстати libtorrent использует boost и там применяют фаззинг-тесты, вопрос качества этих тестов остается отарытым.
> вопрос качества этих тестов остается отарытым.как и обычных тестов и всяких санитайзеров и мемликфайндеров. Ну че готовы писать документацию (талмуды)?
>Их цель - корректно отрабатывать алгоритмы обработки при правильных входных данныхАга, а цель программы - обрабатывать данные юзера, вот пусть он сам свои входные данные и проверяет. Классный подход, как жаль, что такого никогда не будет.
Входные данные предлагается очищать перед их правомерным использованием и только затем предъявлять функциям обработки в адекватном виде.Не нужно здесь выкатывать свои измышления, а потом пафосно их опровергать.
> Не нужно здесь выкатывать свои измышления, а потом пафосно их опровергать.типы тогда зачем нужны?
мне на собесе такой тест давали.
приложение не проверяет входные данные из полей и вам нужно разработать тесты чтобы в итоге работала сумма двух полей без ошибок. и назвать все возможные комбинации (то есть произнести). мосбиржа.
A kak vi predlagaete togda postupat‘? Dva raza proveryat‘ bufer? Tak eto medlenno, bistree srazu parsit‘ i reshat‘, pravilniye dannie ili net.
Если тебя держат в подвале, где нет воды и нормальной клавиатуры, моргни два раза
Ну что ты, чел просто слаку поставил
И что - по ходу установки забыл как русские буквы выглядят?
> Можно, конечно. Кто тебя заставит?Можно всё. Но потом прилетит обратка.
Если написано на расте, то да (тег "сарказм", надеюсь, ставить не надо?)
>Переполнение стека в библиотеке Boost.Regex × 3Зачем нужен сабж при наличии std::regex, ctre и кучи специализированных библиотек регулярок?
> Зачем нужен сабж при наличии std::regexstd::regex взят прямо из boost с минимумом изменений. Как и большая часть остальный нововведений стандартной библиоткки.
Почему после этого их не выкинуть из современных версий Boost?
Как раз поэтому - Boost, как внешнюю библиотеку, обновить проще, чем стд.
Нет, проще не иметь дела с boost вообще там, где он не требуется. Тогда его и обновлять не надо, а только компилятор и станд. библиотеку, которые всё равно надо обновлять: для всех самых вкусных constexpr-фич (ranges-кхе-кхе) потребуется самая последняя версия языка с самыми последними экспериментальными фичами.
а где он требуется?
Буст, или Ranges? Буст - ну у него полно уникальных либ, опережающих по фичам и качеству не-Буст-аналоги. Жаль, что многие на другие бусто-либы завязаны. Ranges? Ну представь, у тебя 5 массивов, в каждом куча string_view, из каждого из них нужно сформировать строку путём подстановки в шаблон. Нужно оценить максимальный размер выходной строки чтобы под неё выделить буфер. С помощью ranges ты можешь во время компиляции выбрать длиннейшие строки из каждого массива, после чего можешь так же во время компиляции подставить их в шаблон и взять его длину. На сишке или старых плюсах ты бы ручками выбирал строку максимальной длины максимальную длину, и отдельно длину шаблона, и ручками же считал, уделяя особое внимание нулевым байтам. А потом, при добавлении очередной строки, делал бы круглые глаза на "сишные дырени".
Проще ли?
Тогда зачем с самого начала было совать это в std?
Т.е. потому что это помойка из багов и гогнокода. Ну да, всё так.
Значит ли жто, что значительная часть реализаций std::regex страдает теми же проблемами?
Ну... нет, STL-ые варианты редко совместимы с бустовыми. regex в частности
Для программ, написанных для <(C++11), например. И компиляторов, умеющих только 98 и 03.
А что сразу не на Си, зачем какие-то ++, на Си писать надо, как Линус завещал :)
> Зачем нужен сабж при наличии std::regex, ctre и кучи специализированных библиотек регулярок?Затем, что Boost.Regex быстрее std::regex (в любом из популярных компиляторов).
ctre быстрее обоих.
а PCRE вообще умеет в JIT
Почему не asio?
Почему не asio что?
Аноним имел ввиду, почему Boost.ASIO не проверяли?
Не знаю
> Не знаюа кто знает, если не эксперты опенет?
Свалка лишних зависимостей.
Вот, кстати, да: небезопасный код на расте следует искать в первую очередь именно в его стандартной библиотеке. Скидывайтесь на аудит.
>boost::dllОтличная вещь могла бы быть, но
* завязанность на остальные буст-либы
* header-only-ness
* завязанность на бустовые типы вместо std::
* работа через парсинг бинари, деманглинг всех символов, и уже поиск среди демангленныхпортит всю малину.
Касательно деманглинга, они сказали, что у них была идея сделать наоборот
https://www.boost.org/doc/libs/1_66_0/doc/html/boost_dll/des...
но типа
>нет надёжного способа получить mangled имя символа из нутра компилятора во время компиляции
- это плохая отмазка, потому что когда стоит такая задача, то надо генерить не для конкретного компилятора, а вообще все возможные варианты, и их проверять, и генерить как раз надо силами constexpr C++-кода, а не от компилятора получать.
Мне как раз нужна реализация их гипотетического
> std::string mangled_name = boost::dll::magic_mangle(boost::foo);
, но чтобы
* явно генерила mangled-имена для всех компиляторов
* в compile-timeто есть
consteval std::array<std::string_view> mangled_names{
boost::dll::magic_mangle<boost::foo, boost::dll::compiler::msvc>(),
boost::dll::magic_mangle<boost::foo, boost::dll::compiler::gcc>(),
};Разумеется, ещё лучше бы было, если бы она генерила класс, который
1. генерит все варианты манглинга функции для платформы в виде таблицы enum -> результат манглинга
2. первым делом проверяет "свой" компилятор
3. далее - все остальные компиляторы в порядке убывания частоты использования
4. кэширует значение enumа для сдетектированного компилятора
5. при дальнейших поисках функций в этой либе ищет сразу по схеме манглинга сдектектированного компилятора.
> генерить не для конкретного компилятора, а вообще все возможные вариантыВ том числе и те, которые ещё не изобретены? Положи машину времени где взял и шатай континуум своими конпеляциями!
Си плюс-плюсники напряглись. Программируешь на Си плюс-плюс - вляпаешся в буст.
> Си плюс-плюсники напряглись. Программируешь на Си плюс-плюс - вляпаешся в буст.либо в кути
Не обязательно, есть ещё рандомные гитхабовские поделки
Qt - вещь животворящая.
Не нравится? У оригинального Qt как минимум 3 форка.
Хорошо, а на С какие либы?
Сделал немало проектов на С++, ни разу сабж не использовал. Всегда лучше писать самому.
> Всегда лучше писать самому.Ну показывай уже самописанную прошивку для процессора, ядро, компилятор, юзерленд…
По вашему, сабж - это "прошивка для процессора, ядро, компилятор, юзерленд"? Не много ли?
>> Всегда лучше писать самому.
> Ну показывай уже самописанную прошивку для процессора, ядро, компилятор, юзерленд…В ядре и прошивках сабжу совершенно точно не место.
Наверное, и ввод-вывод сам писал?
Это - да. И весьма оригинально, кстати.
В этом комментарии не хватает ссылки на житхаб
нормальные люди на жидхабе не сидят.
порядочные люди этнофолизмы не используют.
Ну то поделитесь опытом. Давайте уже ссылку на проект
Буст не нужен. Почти любая ошибка выдает сообщение на несколько экранов, без бутылки не разобрать про что. Средство должно помогать в работе а не доводить до истерики
>>> Почти любая ошибка выдает сообщение на несколько экранов, без бутылки не разобрать про что. <<<просто переходите на Rust
>>>> Почти любая ошибка выдает сообщение на несколько экранов, без бутылки не разобрать про что. <<<
> просто переходите на Rustкогда в раст завезут ООП - плюсы можно закапывать смело
>>> когда в раст завезут ООП <<<ООП не панацея: при композиции проблем меньше чем при наследовании, так что используйте композицию + трейты и будет вам счастье!
Ой, измученные ООП мозги исправить почти невозможно. Это как религия.
Негибкое мышление. Так нужно изучать другие технологии, не всё в одном ООП сидеть.
А как в этой композиции обеспечить полиморфизм? Я понимаю, что vtable можно и в плоскоСишке ручками прикрутить. Но всё придётся ручками, ручками, а не компилятору поручать. Выразительность страдает.
не понял вопрос, что вам нужно! для начала гляньте это и далее: https://doc.rust-lang.org/book/ch17-01-what-is-oo.html
>>> плюсы можно закапывать смело <<<Плюсы никогда не умрут, - и это факт! Раст это просто достойная альтернатива которая даёт куда больше гарантий безопастновсти чем С++! Точно также как когда-то появился С++ и он давал больше гарантий безопастности чем С! Так что глупо игнорировать эту альтернативу!
>Плюсы никогда не умрут, - и это фактБудут как фортран сейчас - выбросить хочется, а переписать лень.
Да вроде фортран выбрасывать желающих нет. Именно свои задачи он хорошо выполняет.
шаблоны с синтаксисом раст? лучше сразу застрелиться
Rust в Qt уже поддерживается? Нет? Как будет, проинформируйте.
>>> Rust в Qt уже поддерживается? Нет? Как будет, проинформируйте. <<<Cкажем Rust появился в 2015, а С++ в 1985, - вы ведь понимаете что у С++ фора в 30 лет; а теперь представьте какая экосистема будет у Раста через эти самые 30 лет; так что будьте реалистом - всему своё время!
Короче, "Либо падишах помрет, либо ишак сдохнет" (с) Ходжа Насреддин. Я точно не доживу.
Не через 30, а может через 10 появится новый "революцинный" язык... Уже появились и не один.
Сразу пишите - 20 лет. Чтобы денег дали, а проверять не пришли.
А кто вообще кутэ поддерживает нормально кроме сишки? Только не надо про pyqt, на нем живых проектов целых полтора.
>>> Средство должно помогать в работе а не доводить до истерики <<<Именно поэтому новичкам (да и не только новичкам) нравится Rust где компилятор это как чувак который сидит с тобой за одним столом и говорит тебе что не так, где именно и как это исправить: С++ до такого как до луны!
В чём проблема прописать ключи компиляции -Wall -Wextra -Wpedantic -Werror и поверх clang-tidy c включённым core guidelines и bugprone-* ? Всё будет ещё круче, чем в Rust, но ты не умеешь в это.
Проблема в том, что всё что ты предлагаешь, это куча эвристик, которые ничего не гарантируют. Rust формально доказывает свои гарантии. Все его ограничения накладываемые на safe код, это заявка на то, чтобы войти в разряд языков, позволяющих формально доказывать спецификации, но не факт, что она будет принята: раст доказывает не всё, лишь то, что можно описать его системой типов, что с одной стороны минус, с другой стороны это компромисс, который позволяет всё же писать программы на нём.Rust позволяет больше чем C++ из коробки, и есть десятки проектов, которые пытаются полную формальную верификацию приделать сверху. С идеями типа вот пишешь ты в коде assert, а тебе IDE подчёркивает его зелёным, потому что удалось формально доказать, что он никогда не выстрелит. Или формальные доказательства unsafe кода на соблюдение инвариантов.
И тут ты такой с пачкой эвристик... Ты бы ещё AI предложил бы задействовать для проверки кода на безбажность.
>>> -Wall -Wextra -Wpedantic -Werror и поверх clang-tidy c включённым core guidelines <<<в расте лайфтаймы и борроу чекер всё разрулят - аналога этому в С++ просто нет - (некоторые конечно пытаются прикрутить сбоку бантик) - но пока это всё не то!
Раз проблемы нет, то объясни тогда, почему в наблюдаемой реальности мало кто так делает? Тем более, если таким образом «всё будет ещё круче»?
Сам-то давно так делал? С включенным clang-tidy в принципе невозможно что либо скомпилировать. Орёт ошибками на всё подряд, делаешь по-другому, всё равно орёт.
Тут проблема не в конкретной библиотеке шаблонов. STL тоже хорошо вываливает тонны на экран. Проблема в реализации шаблонной подсистемы в C++. Подозреваю, что реализовано отчасти всё на том же унаследованном старом "добром" препроцессоре.
> Тут проблема не в конкретной библиотеке шаблонов. STL тоже хорошо вываливает тонны
> на экран. Проблема в реализации шаблонной подсистемы в C++. Подозреваю, что
> реализовано отчасти всё на том же унаследованном старом "добром" препроцессоре.Ложь.
auto SomeFoo(auto x, auto y){
return x * y + (x + y);
}Препроцессор ничего не знает о языке. Система шаблонов построена на статическом анализе и гигантском полиморфизме.
Я сказал предполагаю, а не утверждаю. Но то, что и STL, мягко говоря, не отличается внятностью сообщений о проблемах, это точно.
Это именно что препроцессор. C++, например, не может проверить эту функцию, насколько она не нарушает установленных правил, пока в неё не будут подставлены конкретные типы, и потом лололо ошибки полезут из этой функции, а не в том месте, где кто-то в качестве аргументов передал значения, для которых операторы + и * не реализованы. Ошибка не в том месте, где кто-то вызвал функцию с неподходящими аргументами, а внутри этой функции, где-то в недрах библиотеки, о которой ты никогда не слышал. Это чистой воды поведение макросов, это именно то за что макросы очень не любят все поголовно, даже те кто ими довольно свободно пользуется: библиотечный код прекращает быть поверхностью API, теперь надо нырять под этот API, и выяснять как оно там работает и почему это оно не принимает аргументы.Но в C++ на этом принципе вся система типов выстроена. Слово template если ты поинтересуешься переводом, говорит о том же -- это не отсылка к типам переменных, это шаблоны для кода. Но если в нормальных языках, шаблоны для кода называются макросами, то C++ чего-то попутал, и решил что это про типы.
> Препроцессор ничего не знает о языке.
Сишный препроцессор ничего не знает. Но он такой уникальный. Нормальные макроязыки знают о языке немало, отличают статически известные константы, от выражений, чьё значение можно только в рантайме узнать.
> без бутылки не разобрать про чтоПоздравляем, вы постигли тонкости програмизма
>Буст не нужен. Почти любая ошибка выдает сообщение на несколько экранов, без бутылки не разобрать про что. Средство должно помогать в работе а не доводить до истерикиДумать головой не пробовал?
> Буст не нужен.У нас говорили: "Не нравится - сделай лучше".
Там ещё говорили: "Ешь что дают" и просовывали тебе это на лопате.
Будто в остальных плюcах как-то иначе. Когда наконец таки везде прикрутят концепты, то мб станет лучше
>Когда наконец таки везде прикрутят концепты, то мб станет лучшеАга, "потерпите немножко". Вот-вот станет лучше, вы только маленько потерпите.
Ну все пойдем на руст, много уже на нём написали?
Оно и так стало лучше уже сейчас, если сравнивать с комиляторами 10-15 летней давности. Но этого мало и процесс улучшения плюсов как раз последние лет 15 идёт достаточно бодро
Не пользуюсь, но уважаю.
Это настолько гигантский и сложный проект, что это найденный пяток проблем - просто смешно ) Я реально в шоке от такого высокого качества кода.
с чего ты взял, что проверили каждую строчку? стат.анализатор показал несколько проблем, вот за них и уцепились, чтобы отработать оплаченное
с чего ты взял, что я считаю что проверили каждую строчку?