Что объединять-то? Самба на 99.9% линуховых машинах вообще не включена. Комментом выше я ответил, что даже включив ее, нужно очень постараться, чтобы сделать из нее уязвимость, которую можно эффективно эксплуатировать.
А данный эксплоит можно воспроизвести только при физическом доступе в компу. Удаленный запуск возможен лишь теоретически: например, нааллоцировать тонны памяти в браузере и заставить записанный код с нужной привилегией выполняться. Сомнительно, что это можно провести. Во всяком случае, у меня не получилось, как и у ребят из статьи.
А при физическом доступе к компу вообще может быть много проблем, в том числе и приделанные к его системнику или харду ноги, мало зависящие от IT.
Для того, чтобы выполнить сторонний код в дыре Samba на Linux, нужно иметь открытую папку на запись. Если важные личные папки сотрудников лежат в открытых доступе на чтение/запись, хоть на самбе, хоть на фтп, хоть еще где — это в любом случае плохо.
Если же доки лежат в закрытых на запись папках, а какая-нибудь одна папка upload открыта на запись, то залитый туда эксплоит позволит лишь выполнить код с правами Samba. То есть никакие документы пользователя и прочее она не сможет удалить.
Все это может произойти, только если у вас проблемы с админом. На все 777, доступ везде, максимальные права. Но это, ё моё, надо постараться еще и вообще не понимать, что делаешь.
Просто когда пишут о проблемах в мире Linux, пишут О БОЖЕ ВЗЛОМ ХАКЕРЫ УЯЗВИМОСТЬ ВСЕ УКРАДУТ.
В реальности баг на самбе едва ли можно было эксплуатировать (почти ни у кого сервис не работает, а у кого работает — только с правами самбы, то есть вообще почти никакими).
Насчет этого бага — во-первых, как его удаленно воспроизвести? Во-вторых, «при смежном размещении стека и кучи не исключены ситуации, когда содержимое переполненной кучи может оказаться в области стека, или стек, наоборот <...>». То есть этого всего нужно еще и добиться.
В общем, на серьезную прям дыру это не похоже, хотя исправлять, конечно, надо.
На самом деле, только основы послушать. Я пробежался по кадрам, cmake там используется именно тот, что они пишут в минимальной версии — 2.8 Это очень старо, начиная с 3 версии добавилось много киллер фич, поэтому их и нужно использовать. Все, о чем говорится в статье, кроме target_compile_features, добавилось с версии 3.0 (а target_compile_features добавилось в 3.1).
А вообще, мой опыт использования открытых библиотек Яндекса говорит о том, что сборочные файлы cmake они пишут откровенно плохо.
Программное обеспечение автомобиля премиум-класса содержит около 100 миллионов строк кода
Признаться, очень сомнительно. В вашей же ссылке на статью о разборе кода Toyota (или вот тут вот чуть покороче) написано про 280 тысяч строк — и это куда реальнее, как по мне. Понятно, что нынче и коробка, и движок, и всякие ESP, и многое другое работают за счет ПО, но едва ли все эти системы можно назвать сильно интеллектуальными. Колесо прокручивается, включаем ESP. На педаль нажали на Х%, заслонку открыли на X%.
Linux — это ~20 млн. строк кода. Крайне сомневаюсь, что в авто бизнес-класса в 5 раз больше. Ну или ребята считаю ядро Linux + ядро БД + OpenCV + куча всего еще + свой код.
Это все хрень, которую зачем-то проталкивают вот такие авторы статей. У любого уважающего себя программиста на любом языке программирования есть инструментарий, с помощью которого он может быстро решить типичный набор задач. Никто не будет писать свой класс строки на плюсах, несмотря даже на то, что в стандартной либе поддержка так себе.
Мне кажется, отлично все эти споры разруливает Геннадий Короткевич под ником tourist, почти что ежегодный победитель соревнований Яндекс.Алгоритм, Google Code Jam и многих других. А фишка в том, что они пишет везде, где возможно, на Pascal. Хотя казалось бы.
Размеры бинарников Qt находятся на адекватном уровне. QtCore где-то в 3.5 раза больше libstdc++, но и предоставляемый функционал намного шире. Собранного CS у меня нет, но, вангую, из-за
Соглашусь, конечно, что иногда нужный функционал лежит где-то не там, и брать здоровенный модуль ради одной нужной функции очень не хочется. Но это проблема всегда будет преследовать большие проекты — что и куда класть, как разделять логику модулей.
Да и вообще, есть же LTO. Можно сразу разрабатывать с оглядкой на него.
Ну Qt с LTO собирается.
А можете пояснить где ломается ABI? Если у них рефлексия вся в заголовочных файлах
Если мы инлайним шаблонный код в сорцы нашей либы, то любое изменение каких-либо задействованных структур данных приведет к полной перекомпиляции либы, которая станет несовместимой с предыдущей реализацией. Конечно, есть решения, но это дополнительная сложность. Почитать, например, можно тут.
А, ну вы про компиляцию, а не линковку — тут вопросов нет.
Как я уже писал в соседних сообщениях, это все будет хорошо, если будет в стандарте. Пока у CS есть и обратная сторона:
1) время компиляции
2) размер получаемых файлов
3) производительность
и самый важный косяк
4) нет бинарной совместимости
Да не надо ничего гуглить, я читаю блог автора, у него есть своя реализация QMetaObject без moc. Практически все фичи свежего Qt 5 работают.
Я просил код не потому, что это сделать нельзя, а потому что это такие же костыли. При этом, если у Оливера получилось сделать Qt без moc почти также со стороны производительности, времени компиляции, бинарной совместимости, то у CS получилось откровенное хреново все.
Может быть позже, когда это все будет в стандарте, я полностью соглашусь с мнением, что moc можно выбросить на помойку, но сейчас замена одних костылей на другие костыли едва ли принесет хоть какую-то пользу.
Рефлексию будут рассматривать в C++20. Ну и не факт, что примут (и это будет жаль).
напрямую линковать CS библиотеки к программе, т.е. не нужен qmake/moc
Причем здесь линковка, qmake и moc? Идея CS — убрать moc, то есть генерацию исходников с кодом метаинформации на основе других исходников, использующих макрос Q_OBJECT. Идея-то, в целом, хорошая, позволит, например, использовать шаблонные классы с QObject, но на текущий момент она решается точно таким же костылированием, что и moc. При этом, еще и выдает намного меньшую скорость.
Это не так. (x+1) этапов сборки больше чем (х) этапов сборки, что добавляет соответствующие потенциальные проблемы в виде багов moc'a и moc-aware систем сборки.
Ну это звучит так, как будто вы докопались к формулировке. В том же cmake вся проблема со сборкой решается банально одной строчкой:
set(CMAKE_AUTOMOC ON)
Насчет именно этапов: я готов согласится с автором, что если перенести moc на макросы и шаблоны, вычислительных ресурсов будет потрачено больше (инстанцирование шаблонов). Так что в некотором роде можно сказать, что с moc это даже проще.
Чегоооо? Вы же не серьезно, да?
Qt — это одна из нескольких больших библиотек в мире C++, которую можно начать использовать прям сразу, не вникая в дебри ее построения и мира плюсов вообще. Студенты без серьезного опыта плюсов осваивают либу без особых проблем. О какой сложности идет речь — прям реально любопытно!
вы теряете кросс-платформенность
Чееееееего? Мы вообще про Qt точно говорим?
Qt собирается почти под все девайсы, которые можно найти, включая всякие хитрые микроконтроллеры, отечественные Эльбрусы и прочие смесители от унитаза. Если нужно совсем что-то хитрое, берем близкий конфиг из папки mkspecs, правим его и собираем. Можно узнать, на какую платформу это сделать не получилось?
Я слабо представляю, как туда вкрутить QtCore.
Проинсталлировали вместе с приложением и профит, не?
небольшие велосипеды для недостающей системно-зависимой функциональности
Вы чуть выше писали про велосипеды с сетью и ФС. Это, мягко говоря, не могут быть «небольшие велосипеды», если только вы не делаете эхо-сервер.
А данный эксплоит можно воспроизвести только при физическом доступе в компу. Удаленный запуск возможен лишь теоретически: например, нааллоцировать тонны памяти в браузере и заставить записанный код с нужной привилегией выполняться. Сомнительно, что это можно провести. Во всяком случае, у меня не получилось, как и у ребят из статьи.
А при физическом доступе к компу вообще может быть много проблем, в том числе и приделанные к его системнику или харду ноги, мало зависящие от IT.
Если же доки лежат в закрытых на запись папках, а какая-нибудь одна папка upload открыта на запись, то залитый туда эксплоит позволит лишь выполнить код с правами Samba. То есть никакие документы пользователя и прочее она не сможет удалить.
Все это может произойти, только если у вас проблемы с админом. На все 777, доступ везде, максимальные права. Но это, ё моё, надо постараться еще и вообще не понимать, что делаешь.
В реальности баг на самбе едва ли можно было эксплуатировать (почти ни у кого сервис не работает, а у кого работает — только с правами самбы, то есть вообще почти никакими).
Насчет этого бага — во-первых, как его удаленно воспроизвести? Во-вторых, «при смежном размещении стека и кучи не исключены ситуации, когда содержимое переполненной кучи может оказаться в области стека, или стек, наоборот <...>». То есть этого всего нужно еще и добиться.
В общем, на серьезную прям дыру это не похоже, хотя исправлять, конечно, надо.
А вообще, мой опыт использования открытых библиотек Яндекса говорит о том, что сборочные файлы cmake они пишут откровенно плохо.
Признаться, очень сомнительно. В вашей же ссылке на статью о разборе кода Toyota (или вот тут вот чуть покороче) написано про 280 тысяч строк — и это куда реальнее, как по мне. Понятно, что нынче и коробка, и движок, и всякие ESP, и многое другое работают за счет ПО, но едва ли все эти системы можно назвать сильно интеллектуальными. Колесо прокручивается, включаем ESP. На педаль нажали на Х%, заслонку открыли на X%.
Linux — это ~20 млн. строк кода. Крайне сомневаюсь, что в авто бизнес-класса в 5 раз больше. Ну или ребята считаю ядро Linux + ядро БД + OpenCV + куча всего еще + свой код.
По себе заметил, что после этих статей выработался полезный скилл быстро делать ревью на ТОП-100 типичных ошибок и находить их.
Мне кажется, отлично все эти споры разруливает Геннадий Короткевич под ником tourist, почти что ежегодный победитель соревнований Яндекс.Алгоритм, Google Code Jam и многих других. А фишка в том, что они пишет везде, где возможно, на Pascal. Хотя казалось бы.
Размеры бинарников Qt находятся на адекватном уровне. QtCore где-то в 3.5 раза больше libstdc++, но и предоставляемый функционал намного шире. Собранного CS у меня нет, но, вангую, из-за
Соглашусь, конечно, что иногда нужный функционал лежит где-то не там, и брать здоровенный модуль ради одной нужной функции очень не хочется. Но это проблема всегда будет преследовать большие проекты — что и куда класть, как разделять логику модулей.
Ну Qt с LTO собирается.
Если мы инлайним шаблонный код в сорцы нашей либы, то любое изменение каких-либо задействованных структур данных приведет к полной перекомпиляции либы, которая станет несовместимой с предыдущей реализацией. Конечно, есть решения, но это дополнительная сложность. Почитать, например, можно тут.
Как я уже писал в соседних сообщениях, это все будет хорошо, если будет в стандарте. Пока у CS есть и обратная сторона:
1) время компиляции
2) размер получаемых файлов
3) производительность
и самый важный косяк
4) нет бинарной совместимости
Я просил код не потому, что это сделать нельзя, а потому что это такие же костыли. При этом, если у Оливера получилось сделать Qt без moc почти также со стороны производительности, времени компиляции, бинарной совместимости, то у CS получилось откровенное хреново все.
Может быть позже, когда это все будет в стандарте, я полностью соглашусь с мнением, что moc можно выбросить на помойку, но сейчас замена одних костылей на другие костыли едва ли принесет хоть какую-то пользу.
Причем здесь линковка, qmake и moc? Идея CS — убрать moc, то есть генерацию исходников с кодом метаинформации на основе других исходников, использующих макрос Q_OBJECT. Идея-то, в целом, хорошая, позволит, например, использовать шаблонные классы с QObject, но на текущий момент она решается точно таким же костылированием, что и moc. При этом, еще и выдает намного меньшую скорость.
Ну это звучит так, как будто вы докопались к формулировке. В том же cmake вся проблема со сборкой решается банально одной строчкой:
Насчет именно этапов: я готов согласится с автором, что если перенести moc на макросы и шаблоны, вычислительных ресурсов будет потрачено больше (инстанцирование шаблонов). Так что в некотором роде можно сказать, что с moc это даже проще.
Ну на целевую платформу все статически собирается. Речь про разработчиков.
Чегоооо? Вы же не серьезно, да?
Qt — это одна из нескольких больших библиотек в мире C++, которую можно начать использовать прям сразу, не вникая в дебри ее построения и мира плюсов вообще. Студенты без серьезного опыта плюсов осваивают либу без особых проблем. О какой сложности идет речь — прям реально любопытно!
Чееееееего? Мы вообще про Qt точно говорим?
Qt собирается почти под все девайсы, которые можно найти, включая всякие хитрые микроконтроллеры, отечественные Эльбрусы и прочие смесители от унитаза. Если нужно совсем что-то хитрое, берем близкий конфиг из папки mkspecs, правим его и собираем. Можно узнать, на какую платформу это сделать не получилось?
Проинсталлировали вместе с приложением и профит, не?
Вы чуть выше писали про велосипеды с сетью и ФС. Это, мягко говоря, не могут быть «небольшие велосипеды», если только вы не делаете эхо-сервер.