После шести месяцев разработки опубликован релиз системной библиотеки GNU C Library (glibc) 2.40, которая полностью следует требованиям стандартов ISO C11 и POSIX.1-2017. В состав нового выпуска включены исправления от 68 разработчиков...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=61594
> Устранены уязвимости:
> - CVE-2024-2961 - переполнение буфера ...
> - CVE-2024-33599 - переполнение буфера ...
> - CVE-2024-33600 - разыменование нулевого указателя ...
> - CVE-2024-33601 - ошибка при работке с кэшем ... из-за сбоя при выделении памяти
> - CVE-2024-33602 - повреждение памяти при работе с кэшем ...Срочно писать письмо разрабам с требованием переписать Glibc на Rust!
> Срочно писать письмо разрабам с требованием переписать Glibc на Rust!Вот ты и попался любитель Раста!
СИшка это лучшее что изобрело человечество!
Эти все ошибки только потому, что уровень программистов опустился на дно.
Настоящий СИ программист всегда проверяет входные данные, выделяет столько памяти сколько нужно и правильно ее освобождает.
Тонко, тонко... Но одного единственного на всю планету настоящего си-программиста Дэниэла Бернштейна на все программы мира не хватит
А не фиг плодить тучу бесполезных программ.
Достаточно нормальных С программистов, проблема в том, что эти ребята привыкли делом заниматься, а не свистоперделки ваять и менеджерский идиотизм переваривают с трудом, потому, что привыкли думать о результатах, а так как лохотронщики от псевдомаркетинга победили, то пользователь будет довольствоваться хламом от вебмартышек.
И просто пример, софт для системы навигации написан на С/аsm в 2008, железо, где этот софт крутится летает на орбите уже больше 15 лет и память не течет, сбоев не зафиксировано.
Будто программисты на Си много пишут,дописывают и исправляют уж лучше сказать.Хрустеры вот не могут так.Некуда свои закорючки дописывать.Такая же элита как и сишники и вообще программисты в целом. Давно кончились советские инженеры и примазываться к ним вам всем дружно плохая идея.Бгг.
а код туда чтоли запаян? насколько знаю вояджеры перепрограммируют под реалии по ходу полета, и таки там были ошибки в коде
Да, ты всё правильно написал.
> Настоящий СИ программист всегда проверяет входные данные, выделяет столько
> памяти сколько нужно и правильно ее освобождает.А что за клизмы тогда код Xorg писали? Это подделки были? Ведь такая хренота в коде 1988 года выпуска?!
> А что за клизмы тогда код Xorg писали? Это подделки были? Ведь такая хренота в коде 1988 года выпуска?!Значит это были Не Настоящие Сишники, все просто.
Может их подбросили в проект, чтобы они плохо писали и дисредитировали Идеальный Язык Программирования!
Надо проверить, вдруг они в свободное время на паскале пописывали.
not a true Scotsman: https://en.wikipedia.org/wiki/No_true_ScotsmanЧеснслова уже в зубах завяз этот аргумент. Можно включить креативность и придумать что-нибудь новенькое для обеления C?
> not a true Scotsman: https://en.wikipedia.org/wiki/No_true_Scotsman
> Чеснслова уже в зубах завяз этот аргумент. Можно включить креативность и придумать что-нибудь новенькое для обеления C?Один из вариантов Закона По гласит что "Любой достаточно развитый тролль неотличим от подлинно помешанного на какой-либо идее."
Так вот ты троллинг не распознал)
А зачем делать одно и то же по сто раз, если это уже сделали в расте?
>Срочно писать письмо разрабам с требованием переписать Glibc на Rust!Вот тут-то точно случится Stable and unstable ABI is nonsence.
Не проверяли, что из этого написано "дидами" четаерть века назад, а что новой порослью?
Единственное с чем ассоциируется у меня libc это с отсутствием обратной совместимости...
> Единственное с чем ассоциируется у меня libc это с отсутствием обратной
> совместимости...Потому что как завещал Самый Главный - stable api is nonsense.
Ну и усе остальное стабль тоже нонсенс.
Ведь пользователи как радостно прыгают, когда версия приложения работает только с определеннной версией ядра.
Главный про ядро говорил. Также говорил, что поломки юзерспейса не допустит.
> stable api is nonsenseу тебя есть конкретные возражения к тому документу?
Но ведь обратное утверждение. Это поддерживать Легаси тысячилетиями. Из двух зол Легаси или отсутствие стабильности нормальный человек выберет второе.
Нормальный человек, конечно, выберет первое, а вот ленивый разработчик — второе.
> Но ведь обратное утверждение. Это поддерживать Легаси тысячилетиями.Nope. Это две разные, но связанные вещи.
Можно поддерживать море всякого древнего омна и некроплафторм.
При этом умудряясь ломать обратную совместимость везде.
А потом героически всё чинить. Вот линукс это практически оно.Только ты не всегда даже знаешь что какая-то платформа сломалась уже несколько лет назад, потом что все ее пользователи уже в доме престарелых. А потом появляется какой-то какир с купленной не гаражной распродаже железкой, который начинает вопить "аааа! вся сламалася!"
А что же ты на Винду не идёшь, ведь, там всё штабильно? Чего тут-то околачиваешься?
Блин, stable-api-nonsense всё-таки великая статья. Подрывает ламеров уже почти третий десяток лет. Опустим, что ее написал не самый главный, а Грег К-Х и что там речь идёт о внутри ядерных интерфейсах)
Не, ну если цель была в "подрывании ламеров", то да - "великая цель великой статьи достигнута" - правда работать целеполагателю надо не в it, а в стендапе - цель так же достигнется, а вреда окружающим меньше.
А так - да, в "манифесте agile" тоже вот не написано "забейте на документацию" - но норот читает дупой и эгегей! Впрочем, даже если бы норот читал написанное головой - количество проблем с теми же драйверами от "нонсенса" ничуть бы не уменьшилось...
> и что там речь идёт о внутри ядерных интерфейсах)Речь могла идти про что угодно.
Но по факту оно более чем применимо к ядру целиком, иначе у нас не было бы столько проблем с драйверами, прибитыми ржавыми гвоздями к конкретной версии ядра.
Они прибиты из-за того, что люди, вроде автора высказывания, нарушают совместимость и осознанно ломают сборку сторонних модулей в районе версии x.y.255, вместо того, чтобы оставить такие изменения для новой ветки, только потому, что у них стоит цель нагадить в тапки конкурирующим (и куда более успешным) корпорациям.
А можно десяток примеров, когда libc ломает обратную совместимость?
Десяток подавай... Десятка нет. А есть один, зато мощный. Клиент 1С работает под Astra двухлетней давности, но не работает под новой (обновление тоже ломает, поэтому обновлять систему нельзя со всеми вытекающими последствиями). Причину мы установили - как раз сабж. Версию клиента, привязанную к серверу, сменить нельзя. Выход нашли - переходим на Windows.
Ну вы даёте. Там и 1С, и Астра (которая "подправляет" и libc тоже), а виновата glibc. Впрочем, выход верный --- BSOD, с чистой совестью идём пить кофе и трындеть в курилке.
Типичные импортозмещатели. Вопрос только зачем за это взялись если все равно готовить не умеете.
Диванный анонимный эксперт зато умеет.))) Балаболить
Ставьте Альт
вангую - прога грузит две libc - через nssкак говорить - танцору всё мешает :DDDDDDD
А у меня ассоциируется с тем, что относительно скоро или переставлять успевший устареть выпуск дистра или собирать эту жлибс стопервый раз и обновлять, так как прикладной софт будет требовать
Прикладной софт должен быть в контейнерах со всеми своими либами.
Твоими устами мёд бы пить.. Но грубая реальность такова что через полгодика ктонить соберет ключевую софтину под новую glibc...
Как пример можно привести Blender, они одно время в версиях 2.8x увлекались слишком новыми glibc, народ начал жаловаться, в следующем выпуске откатили обратно и это стало происходить более умеренно
> Прикладной софт должен быть в контейнерах со всеми своими либами.Если память некуда девать, то конечно. А если есть лишняя, то ты просто бездельник.
> Устранены уязвимостиТипикал сишка...
Хоть бы одна проблема не с памятью была!
А вот за это растаманов и не любят.Выбрать из более чем 90 исправленных багов 6 багов с памятью. Ну такое себе решение.
> А вот за это растаманов и не любят.
> Выбрать из более чем 90 исправленных багов 6 багов с памятью. Ну такое себе решение.Баг багу рознь.
Ладно когда у тебя просто аутпут кривой, или логов нету. Или
А когда CVE "может быть использована для удалённой атаки на PHP-приложения, приводящей к выполнению кода" то это просто профнепригодность.За это сишников и любят - как не заглянешь в код, а там кака.
Троллить их никогда не наскучит.
> А вот за это растаманов и не любят.
> Выбрать из более чем 90 исправленных багов 6 багов с памятью. Ну
> такое себе решение.Потому что баги багами, а уязвимости - уязвимостями.
Вот сколько исправленных CVE произошли по причине порчи памяти?
ВСЕ! Пять из пять.Вот поэтому дыряшечники бракоделы, которые не умели в память, не умеют и никогда не научатся.
Те кто cve вещают, расскажите, чем вот этоCVE-2024-33601 - ошибка при работке с кэшем netgroup может привести к аварийному завершению процесса nscd из-за сбоя при выделении памяти.
Опаснее вот этого
[31603] math: math: x86 trunc traps when FE_INEXACT is enabled
> Опаснее вот этогоДумаешь кто-то реально полезет разбираться?
Напр. потому что CVE-2024-33601 можно стригерить удаленно.
Вот что пишут ораклы:
Attack Vector: Local network
Attack Complexity: LowИли FE_INEXACT используется крайне редко.
Или разрабы решили замести проблему под ковер и сделать вид что 31603 не уязвимость.Вообще там в списке еще кучка крешей и других проблем, которые не записали в CVE. И наверное на это были причины.
>Функциональность для выявления возможных переполнений буфера и связанных с безопасностью ошибок во время выполнения функций работы со строками и управления памятью ("_FORTIFY_SOURCE") адаптирована для сборки Glibc при помощи компилятора Clang.Давно собираю с _FORTIFY_SOURCE=3 clangом, проблем не видел.
> На системах x86 для ускорения записи больших наборов данных в функции memset предоставлена возможность отключения использования временных буферов. Оптимизация активируется при помощи настройки "x86_memset_non_temporal_threshold".Пугающее улучшение.
В СИшке с одним бушером разобраться за 40 лет не могут, а тут еще будут временные.
Это же сколько возможностей выйти за пределы открывается.
>одним бушеромПри чём здесь Иран?
Просто переводил надмозг. Речь про размер буфера для заливки, после которого будет использоваться реализация с non-temporal stores. (Адекватного перевода этого термина я не знаю.)
https://snapshots.sourceware.org/glibc/trunk/2024-06-12_21-1...
Смотрите, есть такая замечательная штука, как libstdc++_nonshared. Как она работает? Вот установлен у тебя в системе GCC 4.8. Рядышком стоит GCC 9. Ты собираешь проги при помощи GCC 9... И готовые бинари требуют GCC 4.8, а не GCC 9!Я не знаю, как ред хат его готовит, однако эта библиотека есть только в репозитории devtoolset.
А теперь внимание, вопрос! Как собрать бинарник в системе, в которой установлен Glibc 2.32, таким образом, чтобы бинарник хотел Glibc 2.17? Чтобы было аналогично случаю выше, только не с C++, а с обычным C.
Опция -L/путь/к/каталогу/с/другой/Glibc при сборке
И это будет работать? Может все таки надо собирать компилятор для старой glibc?
Плюсы зависят от компилятора, у плюсов нет abi. У си есть.
>у плюсов нет abiЗадумайся, что написал.
Если ABI официально не стандартизирован, то это не значит, что его нет. А так-то у большинства языков, которые символы маглят, ABI официально не стандартизированы: D, Nim, ...
По этой причине эти языки никогда не будут востребованы. Главное, что при обновлении половина программ гарантированно разлетается (до сих пор!), а тот же wxwidgets надо сразу пересобирать под целевой компилятор. В этом отношении не намного лучше раста.
Ну вы как-то определитесь: вы с миром открытых исходников или с миром блобов? Если вы выбрали открытые исходники, то должны понимать, что здесь совместимость на уровне исходников. Так что перекомпиляция здесь это естесственно.
Касательно ABI C++, он последний раз для g++ серьёзно менялся в версии 3.4.
System V Application Binary Interface
AMD64 Architecture Processor Supplement
(With LP64 and ILP32 Programming Models)
Version 1.0...
Chapter 9
Conventions9.1 C++
For the C++ ABI we will use the IA-64 C++ ABI and instantiate it appropriately.
The current draft of that ABI is available at:
http://mentorembedded.github.io/cxx-abi/
Нет, не будет.Предпочтительнее --- да (получится заведомо консистентная конструкция). Но вполне может быть жизнеспособным и в других комбинациях (сильно зависит от того, как этим пользоваться).
Статическими плюсовыми библиотеками не увлекались бы --- есть существенные тонкости в использовании.
> А теперь внимание, вопрос! Как собрать бинарник в системе, в которой установлен Glibc 2.32, таким
> образом, чтобы бинарник хотел Glibc 2.17?короткий ответ: никак.
Длинный: теоретически ты бы мог это собрать если бы имел полный набор (не одну лишь libc.so.6!) абсолютно всех системных библиотек где-то в стороне от реально действующих системных, И одновременно - полный набор для замены /usr/include (потому что таки stable nonsense), тоже где-то в стороне.
Дальше тебе предстоит освоить ключик -nostdinc и -nostdlib а потом вручную скармливать компилятору пути к его собственным внутренним инклудам и библиотекам (потому что они тоже отрубятся этими ключами) помимо, очевидных, системных.Практически - ничего кроме хеловрота ты так не соберешь, потому что будет практически невозможно объяснить модным-современным сборочным системам что ты такое хочешь.
Учитывая что для тебя даже -static-libstdc++ какая-то магия непонятная, требующая каких-то загадочных штуковин - ты точно не сможешь.
Практически - берется докер с нужной средой и собирается там...
спрашивали-то как в другой системе собрать, а не в "нужной".
> короткий ответ: никак....
Это совершенно не так. Если debian (включая производные) этого по большому счёту не умеет, то из этого не следует, что не умеет никто. Вот я умею, например. (Тезис про helloword --- это тоже не так).
Интересно то, что три четверти проектов, которым я покидывал двух-трёхсторчные патчи по этому поводу уходили на бесконечность со словами "нууу... мы как-то сомневаемся... надо бы подумать...".
причем тут - дебиан?> Вот я умею, например.
п-деть.
Зависит от того, что именно из libc ты используешь. Если что-то, что не менялось с 2.17, то ничего делать не придется - собранный бинарник и так будет требовать 2.17. Если ты используешь что-то более свежее, то извини, в 2.17 этого нет, и с ним твой бинарник будет несовместим.
1. Самый простой вариант - кросскомпиляция. Берёшь старый дистр с нужной версией libc, ставишь его в отдельную папочку (sysroot), дальше зависит от системы сборки. Для cmake, например, пишешь toolchain.cmake, где задаёшь всё, что касается нового sysroot. Для большинства других систем сборки есть аналоги. Руками тоже можно, но нужно будет указывать `-sysroot`, `-isystem`, `-L` и ещё что-нибудь.2. Есть компилятор C от zig, который из коробки умеет задавать максимальную требуемую версию glibc, но это не gcc.
3. Как предлагали выше отключать все стандартные библиотеки и линковаться с ними вручную. Но в таком случае нужно будет rpath править руками и граблей там, на мой взгляд, будет больше чем с кросскомпиляцией.
> 1. Самый простой вариант -и самый действенный - окончательно собирать приложение в системе с самой старой версией, если, как заметили выше, не используются новые функции (еще помним и о deprecated). Так одно время и делал, имея для этого отдельный компьютер с Ubuntu 18.04, а разрабатываю на Ubuntu 22.04. Потом отказался, правда. Надоело.
> Потом отказался, правда. Надоело.прочитай про docker
Предпочитаю развертывать приложения Linux по образцу Windows.
для кросскомпиляции ему нужен - кросскомпилятор. Т.е. не надо путать твой опыт, я так подозреваю - пользования готовыми сборками, и попытки сделать самому из подручных средств.Проблема в том что кросскомпилятор собран специальным образом, -isystem ты вряд ли отделаешься (потому что он не для этого был придуман, он добавляет пути поиска а не заменяет полностью)
Теоретически, можно еще попробовать самому собрать кросс-gcc+toolchain под такое дерево, а не использовать копию из старой системы, но я не уверен что это тоже будет легко (я напрочь не помню как оно собирается, да и двадцать раз могло поменяться с тех пор как мне такое бывало надо - боюсь что там не отключить сравнение target и текущей архитектуры). Но попробовать стоит - это хотя бы тривиально и недолго. Если получится - то проблема внезапно решилась.
rpath (в ручной схеме) руками править как раз не нужно - когда он не задан, при _сборке_ библиотека ищется по -L, но пути к ней в собранное не прописываются, предполагая что о них позаботится ld.so при старте, что в данном случае и требуется. Более того - собранное будет запускаться в современной системе (все же обратная совместимость в glibc - в основном сохраняется) но в нем не окажется прекрасных символов @GLIBC_2.40.0
1. Ты можешь взять самый обычный компилятор из своего дистрибутива и кросс-компилировать им без всяких пересборок компилятора и подобного. Я так регулярно делаю. Абсолютно штатным x86_64 gcc или клангом из федоры. С g++ начиная где-то с 12-ой версии возникают проблемы, т.к. они безбожно ломают совместимость с собственной libstdc++. С клангом всё впорядке и с плюсами, и с сишкой.
Ключевую роль тут играет `-sysroot`, именно он переопределяет основные пути поиска и т.п. Возможно, если в sysroot какой-то очень хитрый дистрибутив, то придётся что-то пересобирать или много всего прописывать. С более-менее нормальным линуксом всё ок либо решается парой симлинков.2. Руками я пробовал только в рамках потыкать, так что вполне возможно, что я где-то накосячил и у меня появились пляски с rpath. Если без этого всё работает, то отлично.
>> Ключевую роль тут играет `-sysroot`, именно он переопределяет основные пути поиска иа, наверное --sysroot ? Это не -isysroot, это может даже и работает.
Но он же переопределит заодно и пути к всяким crtbeginS.o и прочей бжне - а этого-то как раз делать и не стоило. Может оно такое и работает, но авторы компилятора этого не предусматривали.
Авторы компилятора предусмотрели, что пути можно посмотретьgcc -print-file-name=crtbeginS.o
и поменять STARTFILE_SPEC https://gcc.gnu.org/onlinedocs/gccint/Driver.html
может оно такое и работает. :)
Направление мысли в целом верное. Там только всё не то что сложнее, скорее сильно "затейливей".
Писать самому диспетчер исключений не придётся? Всё в исходниках есть, и их можно посмотреть?
> Авторы компилятора предусмотрели, что пути можно посмотретья в свое время (для совсем других целей) просто подменял collect2
- заодно получая полный список невидимых запчастей, линкующихся по умолчанию.> может оно такое и работает. :)
оно такое работает, но тут тебе приносют какую-нибудь поделку от гугля - и чорта с два ты объяснишь это их билдсистеме на нескучном йезычке.
А хеловроты да, можно так собирать.
Взять Nix. Но ты не осилил.
Хеловорлд под 2 мегабайта жрет оперативки слинкованный с глибц, не многовато ли?
На мюслях ~350кб
Приветмир (слип и зависимости), у глибц 143кб и 1.9мб шаред, у мюслей 584кб (328/318кб с 2 копиями в памяти) + 512кб шаред, но мюсли ощутимо тормознее и проблемнее. Если линковать статически, у мюслей 64кб + 0 шаред, у глибц 692кб + 640кб шаред. Зачем ты загоняешь себя в угол мюслями и даже не используешь их по назначению, линкуя статически?