В библиотеке Libxml2, разрабатываемой проектом GNOME и применяемой для разбора содержимого в формате XML, выявлено 5 уязвимостей, две из которых потенциально могут привести к выполнению кода при обработке специально оформленных внешних данных. Библиотека Libxml2 широко распространена в открытых проектах и, например, используется как зависимость в более чем 800 пакетах из состава Ubuntu...Подробнее: https://www.opennet.me/opennews/art.shtml?num=63431
Пора переписать на Си, но чтоб без багов.
>"на Си, но чтоб без багов. "Ну, вы поняли.
Пора полностью отказаться от си. И он XML тоже. Нах он нужен. Для хранения одного байта информации пихаем килобайти лишней информации
Ну тогда уж откажитесь и от HTML.
внезапно, изначально был PS и PDF
Где был? Изначально — это как? Проснулись пещерные люди, смотрят: а на полу PS и PDF лежат?
Так xml так себе, но чем ты заменишь xslt?
Чем угодно. Xslt неоправданно сложный. Императивный код на любом яп, написанный в лоб, будет раз в 100 понятнее. Плюс, xslt абсолютно никакой для трансформации в режиме потока, потому что весь документ грузится в виде dom целиком. Это значит, что сто-метровый хмл будет занимать 500 метров оперативки, если не больше.
> Так xml так себе, но чем ты заменишь xslt?Эту жесть не надо было использовать с самого начала, чтоб вас.
Слова недалёкого человека. XML нужнее всех остальных форматов, ибо остальные куда уже специализированнее, а XML самый универсальный. Это не только формат для хранения и передачи данных, но ещё и команд с данными не только для выполнения команды, но ещё и для разбора что это за команда, так можно реализовать единую точку входа для всех команд, а не тонну эндпоинтов, как для REST. Хранить очень сложную структуру данных тот-же JSON не может, попробую всю страницу сайта передать в JSON (не только для заполнения формочек, а саму страницу) - не выйдет, теоретически конечно можешь, но об ручной разбор типов и экранирование - пальцы в кровь сотрёшь, и итоговый размер файла может даже и выйдет больше чем у XML.
> об ручной разбор типов и экранирование - пальцы в кровь сотрёшьJSON.stringify/parse()?
С потерей бигинтов и цифр в флоатах, ага.
С каких это пор JSON содержит информацию о типах и не теряет данные в зависимости от десериализатора?
А может все же лучше переделать этот огород, чтобы не требовались "очень сложные структуры данных"?
И кто тогда будет платить деньги за поддержку "очень сложные структуры данных"?
Все упростить, еще и работать стабильно начнет. Точно уволят и возьмут кого-то на меньшую зарплату.
Делай спагетти-код и "очень сложные структуры данных"!!!!!
И заодно вернёмся к сайтам визиткам в лучшем случае на HTML4, про фин.тех. вообще молчу.
Да, давай. Все только за будут. Всего-то нужно сложность решаемых задач понизить, и дело в шляпе, обойдёмся одним массивом байтов на всё про всё. А если одни только hello world писать, то может быть и вовсе без структур данных обойдёмся. А там и от компьютера можно отказаться, вон в древнем Египте на глиняных табличках бухгалтерию вели, и ничего, великая страна была, могла показать!
При переходе на массив байт главное не забыть про BigLittle/LitleBig...
На C++ с умными указателями.
Дурной тон писать ядро, системные утилиты и библиотеки на Си плюс-плюс. Истинная системщина - только чистый Си.
> Дурной тон писать ядро, системные утилиты и библиотеки на Си плюс-плюс. Истинная системщина - только чистый Си.Критерии истинности в студию.
Мне казалось что системщина - это надежный код, который без ошибок работает годами.
И его раньше писали на ассемблере.А СИшка порождает дырявый овнокод, на пеньке последние 3 новости как раз про это убожество, которое придумали для тех, кто не осилил ассемблер.
Типа ПХП из 70х.
>> Дурной тон писать ядро, системные утилиты и библиотеки на Си плюс-плюс. Истинная системщина - только чистый Си.
> Критерии истинности в студию.
> Мне казалось что системщина - это надежный код, который без ошибок работает
> годами.
> И его раньше писали на ассемблере.
> А СИшка порождает дырявый овнокод, на пеньке последние 3 новости как раз
> про это убожество, которое придумали для тех, кто не осилил ассемблер.
> Типа ПХП из 70х.
> И его раньше писали на ассемблере.В ассемблере хотя бы нет UB.
Но, конечно, сейчас на ассемблере писать не вариант.
>> И его раньше писали на ассемблере.
> В ассемблере хотя бы нет UB.
> Но, конечно, сейчас на ассемблере писать не вариант.Угу-угу.
Навскидку:
https://c9x.me/x86/html/file_module_x86_id_285.html
> SAL/SAR/SHL/SHR
> The CF flag contains the value of the last bit shifted out of the destination operand; it is undefined for SHL and SHR instructions where the count is greater than or equal to the size (in bits) of the destination operand. The OF flag is affected only for 1-bit shifts (see "Description" above); otherwise, it is undefined. The SF, ZF, and PF flags are set according to the result. If the count is 0, the flags are not affected. For a non-zero count, the AF flag is undefined.
>
По-моему, здесь как раз поведение процессора вполне определённо описано.
>> SHL r/m8,CL Multiply r/m8 by 2, CL times.
>> The OF flag is affected only for 1-bit shifts (see "Description" above); otherwise, it is undefined
>> The CF flag contains the value of the last bit shifted out of the destination operand; it is undefined for SHL and SHR instructions where the count is greater than or equal to the size (in bits) of the destination operand.--
> По-моему, этодругоевынепонимаете!🙄
https://c9x.me/x86/html/file_module_x86_id_19.html
> Searches the source operand (second operand) for the least significant set bit (1 bit).
> If the content of the source operand is 0, the content of the destination operand is undefined.А уж написать что-то ассемблирующееся, но с "unpredictable behavior" - вполне можно только так
https://cr.yp.to/2005-590/x86-volume2a.pdf
>> it is undefined for SHL and SHR instructions…
>> undefined
> поведение процессора вполне определённо описаноЭто многое объясняет! На си не пишешь случайно?
Аноним увидел слово undefined, дальше всё как в тумане.
Про ядро никто не упоминал, речь была про парсер XML. А юзерспейс на ссовременных стандартах C++ - самое то.
Зато упоминали системные утилиты и библиотеки.
>А юзерспейс на ссовременных стандартах C++ - самое то.Спасибо, не надо. Такое впечатление, что крестовиков хаскелисты покусали.
https://habr.com/ru/companies/jugru/articles/438260/ - «Современный» C++: сеанс плача с причитаниями
Это не говоря уже про то, что для того, чтобы повторить безопасность условной жабы, нужно будет писать крайне много строк.
Ну а в ядре тогда как xml парсить?
SPARK?
> На C++ с умными указателями.Но смогут ли СИшники осилить умные указатели?
Они же умные! (Указатели)А СИшники до сих пор не могут делать зануление объекта, когда он уже не нужен((
>А СИшники до сих пор не могут делать зануление объекта, когда он уже не нужен((Хватит повторять эту ошибку. Если объектом владеет только один указатель, то занулять ничего не надо, и у нас получается что-то типа раста. Если объектом владеет несколько указателей и есть gc, то рантайм сам разберётся. Если gc нет, и продвинутых типов тоже нет, а владеет несколько указателей, то нужен двойной указатель, чтобы все владения обнулились сразу же, но это ухдшит производительность. В противном случае, проблема останется. Так что в си решения по прежнему нет.
Кресты даже в лучшем случае исправят только часть ошибок с памятью.
> 5 уязвимостей, две из которых потенциально могут привести к выполнению кода
> используется как зависимость в более чем 800 пакетах из состава Ubuntu.Ахахахаха!
Вот она сила СИстемных языков программирования!> Переполнение возникает при обработке очень длинных аргументов команд из-за отсутствия корректной проверки размера входных данных перед копированием данных функцией strcpy().
strcpy - "вам не нужны нормальные строки"!
> записи данных за пределы буфера из-за целочисленного переполнения при вычислении размера буфера
Классика, одобряю!
> обращения к уже освобождённой области памяти ..., разыменования нулевого указателя... и неправильной обработки типов
А ведь эти проблемы можно было предотвратить, используя нормальные современные ЯП, а не устраревший кусок kalа из прошлого тысячелетия!
Сегодня жаркий денек.
Спецвыпуск "Сишный овнокод и его фиксы"
+ int lenn, lenp;
+ size_t lenn, lenp;
...
+ if ((ncname == NULL) || (len < 0)) return(NULL);
Тут даже комментировать нечего.parser.c
- if (newSize) {
+ if (newSize < 0) {
xmlFatalErr(ctxt, XML_ERR_NAME_TOO_LONG, "VersionNum");
}
tmp = xmlRealloc(buf, newSize);Ну кто же мог подумать что size для реалока может быть отрицательным!
Хотя... это даже логично что не может...
А какой гений решил использовать signed переменную для newSize?
И в каком это убогом недоязычке идет неявный каст signed в unsigned size_t в realloc? Не сишечка ли это часом?
Надо было использовать ИИ ассистента.
Так дело всё же в языке или в гении, который код писал!
*?
> Так дело всё же в языке или в гении, который код писал!То что убогий жигулятор при аварии убивает и пешехода и часто водилу (подушки? нет не слышал) это виноват водила?
Или то что эта древность проектировалась тяп ляп?Так же и с дыряшкой.
Язык просто неявно кастит, быдлокодер не проверяет.Если сам автор ЯП писал "комитет сделал язык на котором невозможно писать", то наверное он знал о чем говорил.
Не знаю насколько удачный ваш пример. Кто виноват и что виновато, нужно смотреть по ситуации и не факт, что убогий жигулятор виноват, зависит от того, как им управляли и что творилось на дороге. Виноватыми могут быть и водила, и пешеход.
Но что ведро с гайками повышает аварийность, спорить ведь не будете? Или его просто правильно водить надо?
любая машина = ведро с гайками = средство передвижения повышенной опасности (или как оно там в пдд)
> любая машина = ведро с гайками = средство передвижения повышенной опасностиРазумеется.
Но безопасность вещь измеримая. Причем по различным критериям (для водителя, для пассажира, для пешихода и тд). И достигается это целыми схемами пассивной и активной безопасности.Понятно что можно разогнаться до такой скорости что даже они не помогут.
Но при обычной езде шансы участвников движения остаться целыми возрастают очень значимо.Так и тут. Не существует абсолютного решения, но если есть то, которое может уменьшить кол-во проблем напр. на 30 (50, 70, whatever) процентов - то это уже решение.
Горит сарай - гори и хата!
Любая, рано или поздно, но дьявол в деталях. Мне в жизни довелось дважды (и успешно!) совершить один и тот же опасный номер на двух разных автомобилях: уклониться от препятствия на трассе зимой в снегопад на скорости 80км/ч. Жигуль раскрутило, почти вылетел на встречку под фуру, но в последний момент смог найти достаточно сцепления с дорогой и вырулить. Второй раз делал то же самое на бмв с xdrive, пассажиры даже толком не заметили ничего. А так да, ведро с гайками что одна, что вторая. Когда продавал оба раза радовался.
> это виноват водила?Ты неправильно вопрос ставишь, Дядя Фёдор.
Поиск виноватых -- это конечно хорошо, но это сужение общей проблемы поиска причин произошедшего. Если водила умер, но при наличии подушек безопасности он бы не умер, то подушки безопасности -- это причина его смерти, пускай их и сложно назначить виноватыми.
Причин может быть много, более того, _достаточных_ причин может быть много (т.е. таких причин, что каждой из них было бы достаточно, чтобы получить обсуждаемое следствие), а виноватым всегда будет стрелочник. Чтобы избегать неприятных следствий надо бороться с причинами, и совершенно бесполезно бороться со стрелочниками. Поэтому и вопрос надо ставить не о вине, а о причине. Или даже о причинах.
> А какой гений решил использовать signed переменную для newSize?Дак ведь даже тут в комментах к другой новости один фанат раста решил продемонстрировать какой он крутой и... сделал точно так же. Так что сишники тут не причем, растаманы делают так же, когда берут в руки Си.
Проблема не в языке, а в руках.
Например, в некотором языке значение res будет иметь разные значения (0 или 0.01), в зависимости кодогенератора LLVM и опций его оптимизатора:
let a: f32 = 1E-64;
let b: f32 = 1E64;
let c: f32 = 1E126;
let res = a/b*c;Видите классический UB с исчезновением порядка?
> Проблема не в языке, а в руках.Но тут нет UB. Проблема именно в языке.
xmlRealloc принимает size_t.
void* (*xmlReallocFunc) (void *mem, size_t size);Туда передается int newSize;
Если бы язык был к такому строг и требовал явной конвертации signed в unsigned - то с 99% вероятностью проблемы не произошло.Почему так сделано? А потому что xmlGrowCapacity возвщает не только значение, а еще и ошибку -1.
github.com/GNOME/libxml2/blob/477f9c6b20ef4a0745aefe735e9ebc7573a4fdae/include/private/memory.h#L32Почему? Потому нет нормального возврата ошибок на уровне языка
Если бы там возвращался условый Result<Value, Error> то сама такая ситуация была бы невозможна - result нужно было бы "развернуть", а ошибку или обработать, или СОЗНАТЕЛЬНО проигнорировать. Т.е. это опять ограниченность языка.К программисту претензия только в том, что он не полез в xmlGrowCapacity и посмотрел на возвращаемые значения. Но это бы не спасло от ситуации, когда -1 добавлися бы после написания кода, который использует функцию - копилятор точно также неявно все закастил и отстрелил ногу.
> Например, в некотором языке значение res будет иметь разные значения (0 или 0.01),
> в зависимости кодогенератора LLVM и опций его оптимизатораПроблема не в языке. Evaluation order языком определен однозначно.
А проблема в конкретной имплементации конкретного компилятора. Я ведь тоже могу накидать различий в выхлопе в другом языке при применении различных оптимизаций.
> Но тут нет UB.А при чем тут UB, если проблема именно в руках?
> Evaluation order языком определен однозначно.
Но не определено, будет ли промежуточный результат из 80-х битных регистров FPU сохраняться в память или останется в регистре. Проблема то именно в этом.
> если проблема именно в руках?Где?
Я расписал именно недостатки языка и его выразительности, которые привели к ошибке.
А вы пишите "именно в руках". Ну так раскройте свою мысль почему все аргументы про неявный каст и отсутствие ошибок на уровне языка не валидны.
> Если бы язык был к такому строг и требовал явной конвертации signed в unsigned - то с 99% вероятностью проблемы не произошло.Напиши уже clang-tidy правило для этого и реши 99%. Что ждешь?
> Напиши уже clang-tidy правило для этого и реши 99%. Что ждешь?А потом чел без такого правила закоммитит такой код. А у тебя оно билдиться не будет.
Может тогда pre-commit хук написать? А вдруг патч по почте пришлют?))Зачем это все, если можно просто не пользоваться мусором из 70х, а взять нормальных язык?
>> Напиши уже clang-tidy правило для этого и реши 99%. Что ждешь?
> А потом чел без такого правила закоммитит такой код. А у тебя
> оно билдиться не будет.
> Может тогда pre-commit хук написать? А вдруг патч по почте пришлют?))
> Зачем это все, если можно просто не пользоваться мусором из 70х, а
> взять нормальных язык?Понятно, очередной воздухан.
> Понятно, очередной воздухан.Вы пытаетесь оправдать убогость недоязычка си и исправить это какими-то костылями.
Так что из нас воздухан?
>> Понятно, очередной воздухан.
> Вы пытаетесь оправдать убогость недоязычка си и исправить это какими-то костылями.Ты сказал, что простой проверкой решишь 99% проблем. Но потом сдал назад резко вдруг) А теперь и на личности стал переходить.
>Проблема не в языке, а в руках.Проблема в руках, которые берут этот язык. Ибо одни языки сопротивляются г-коду, а другие наоборот, этот самый г-код поощрают.
>Например, в некотором языке значение res будет иметь разные значения (0 или 0.01)В каком? Rust, например сразу же выдаёт ошибку компиляции, у ocaml вообще другой синтаксис, и основной компилятор llvm не использует.
>Видите классический UB с исчезновением порядка?Я вижу ошибку компиляции. Хороший компилятор сделал своё дело.
>>Видите классический UB с исчезновением порядка?
> Я вижу ошибку компиляции. Хороший компилятор сделал своё дело.И где Вы увидели ошибку компиляции? Здесь классический UB, связанный с тем, было ли сохранение промежуточного результата из 80-битного регистра FPU в память с преобразованием его в f32 или нет.
> И где Вы увидели ошибку компиляции?godbolt.org/z/GfcbTeY4T
error: literal out of range for `f32`
--> <source>:12:18
|
12 | let b: f32 = 1E64;
| ^^^^
|
= note: the literal `1E64` does not fit into the type `f32` and will be converted to `f32::INFINITY`
= note: `#[deny(overflowing_literals)]` on by default
>И где Вы увидели ошибку компиляции?Вы для начала язык назовите, а то телепаты в отпуске. Проверял здесь https://play.rust-lang.org/?version=stable&mode=debug&editio...
Compiling playground v0.0.1 (/playground)
error: literal out of range for `f32`
--> src/main.rs:3:18
|
3 | let b: f32 = 1E64;
| ^^^^
|
= note: the literal `1E64` does not fit into the type `f32` and will be converted to `f32::INFINITY`
= note: `#[deny(overflowing_literals)]` on by defaulterror: literal out of range for `f32`
--> src/main.rs:4:18
|
4 | let c: f32 = 1E126;
| ^^^^^
|
= note: the literal `1E126` does not fit into the type `f32` and will be converted to `f32::INFINITY`error: could not compile `playground` (bin "playground") due to 2 previous errors
> https://play.rust-lang.org/?version=stable&mode=debug&editio...Простите, по памяти писал.
Правильно так:
fn main() {
let a: f32 = 1E-23;
let b: f32 = 1E23;
let c: f32 = 1E38;
let res = a/b*c;
println!("{}",res);
}
Ну отлично, теперь это хотя бы компилируется. Но заявленного вами поведения не наблюдаю, и в дебаге и в релизе выдаёт 0.
> Ну отлично, теперь это хотя бы компилируется. Но заявленного вами поведения не
> наблюдаю, и в дебаге и в релизе выдаёт 0."в зависимости кодогенератора LLVM и опций его оптимизатора"
Скорее всего нужна конкретная версия компилятора, уровень оптимизаций и возможно флаги.
Так что удачки это повторить.При этом это все равно останется UB реализации, а не языка.
>Скорее всего нужна конкретная версия компилятора, уровень оптимизаций и возможно флаги.Скорее всего это просто баг llvm-а. Некоторые языки, тот же ocaml от llvm не зависят вообще. А вот ub в си возникает стабильно. Хоть на gcc, хоть на llvm, хоть на msvc. Ну может на экзотике типа tcc не возникает, пока туда оптимизаций не завезли, как завезут, так там тоже возникнут.
> + int lenn, lenp;
> + size_t lenn, lenp;Когда копировал этот кусок патча, ничего странного не заметил, умник?
А вот писали бы они с помощью ИИ такой фигни бы не было.
> А вот писали бы они с помощью ИИ такой фигни бы не было.А ИИ на чем обучали?
На ЩитХабе и таких же кодах?
Ой, так он будет точно так же овнокодить и делать такие же ошибки.
Потому что shit in -> shit out
Проверку длинны ИИ сделать в состоянии в отличии от коженных мешков.
> Проверку длинны ИИ сделать в состоянии в отличии от коженных мешков.Потому что он хоть и Искусственный, но Интеллект!
А для писания на СИшке мозг вообще не нужен.
Не сходятся типы? Кастуй к void*
Целочисленная функция должна возвращать ошибку? Пусть просто станет signed возвращает -1. Result<Value, Error> это что-то на смузихлебском.
Enum_Crocodile пытаются сравнивать с Enum_Bombardilo? Пофиг, под капотом все равно int.
Дообучи ИИ как надо и он тебе исправит что угодно во всем проекте.
конечно не было бы - когда код xml-парсера не компилится или не парсит xml - никаких проблем он и не создаст.
То что ты не умеешь пользоваться ИИ и не в состоянии написать нормальный промт виноват только ты.
> То что ты не умеешь пользоваться ИИ и не в состоянии написать
> нормальный промт виноват только ты.ну ты-то умеешь, ии за тебя уже три хеловрота написал?
А мы так и будем жить с libxml2 и еще более ужасным xslt, автор которого видимо либо от старости помер либо в монастырь ушел, тяжкий грех до конца своих дней замаливать.
Поскольку твои хеловроты его не заменят решительно никак.
Скорее уж хрустики подтянутся и перепишут-перепишут (еще лет за двадцать, их темпами быстрее от борова не убежишь). Может даже ии припрягут, от борова бегать ему самое то занятие.
> ну ты-то умеешь, ии за тебя уже три хеловрота написал?Если твоя кодобаза состоит из «хеловротов» — напишет «хеловрот». У нас кодобаза в основном сложный процессинг данных, и таки ии генерит по ней отличный код, если правильно попросить. Но чтобы правильно попросить надо хорошо знать что ты хочешь, поэтому эта чалма работает только со сковородой в штанах, в том смысле что надо хорошо знать предметную область чтобы, во-первых, написать запрос, и, во-вторых, понять не лажа ли ответ. Иными словами, это профессиональный инструмент для ускорения процесса разработки, а не штука, которая за тебя всё делать будет. Штука, которая за тебя всё делать будет называется джун или интерн, но там и промпты куда сложнее, и выхлоп надо куда внимательнее проверять.
>Штука, которая за тебя всё делать
>и выхлоп надо куда внимательнее проверять.Взаимоисключающие утверждения.
не, все правильно - он такой конечно сделает, что сказали, а не будет галлюционировать, и даже наверное догадается задать дополнительные вопросы ДО того как бросаться кодить.Но быстрее опять окажется самому все запилить.
Так что новой libxml без багов от ИИ по прежнему не дождемся, потому что ЭТОТ джун даже переспросить без пинка не догадается если что не понял. И даже поправить баги в старой хрен там, потому что "в контекстное окно не лезет".
> Для устранения данных уязвимостей рассматривается возможность
> удаления из libxml2 поддержки языка разметки Schematron.Да вообще libxml2 нужно отовюсюду выкинуть и заменить на что-то нормальное.
Напр. на quick-xml или xml-rs.Иначе ситуация "более чем 800 пакетов из состава Ubuntu" оказались дырявы будет повторяться раз за разом.
> Да вообще libxml2 нужно отовюсюду выкинуть и заменить на что-то нормальное.приступай.
Только - нормальное, а не подделку реализующую 1/100 от оригинала. (поддержку нахрен никому ненужного язычка шк070трон можешь выкинуть)
Как напишешь такую - приходи.
А пока это референсный парсер xml, и ничего на замену нет и не предвидится. Ну кроме попыток парсить xml грепом, обреченных на весьма специфичный успех.
> Только - нормальное,Типа того что сейчас))?
> а не подделку реализующую 1/100 от оригинала.
Если 95% юзеров этого достаточно, то можно и одну сотую.
А потом слушать нытье и добавлять именно то что нужно, а не "у нас тут для i286 есть костыли, их обязательно нужно перенести!!11"
> Если 95% юзеров этого достаточно, то можно и одну сотую.эти 95 на винде сидят. С теми еще 2% которым недостаточно но они тоже уже там.
последнее время много криков, переписать на rust, срочно переписать!но при этом все продолжают пережевывать это сишное #### булшит
когда от возмущения перейдете к делу?
зы. я девочка дизайнер, ко мне вопросов нет! но вот вы, вы же большинство программисты, так? чего ждете?
> последнее время много криков, переписать на rust, срочно переписать!Ага
> но при этом все продолжают пережевывать это сишное #### булшит
С чего ты взял?
> когда от возмущения перейдете к делу?
Сколько было воплей и подгорания оп от таких новостей:
- В Ubuntu 25.10 решено задействовать аналог sudo, написанный на Rust
- Для FreeBSD развивают опциональную поддержку компонентов базовой системы на Rust
- Разработчики GRUB2 рассматривают возможность использования языка Rust
- Браузер Chrome переведён на шрифтовой движок Skrifa, написанный на Rust
- Для ядра Linux 6.15 предложен начальный код драйвера Nova, написанный нана минуточку Хром это 2+ миллиарда пользоватлей, про ядро вообще молчу
> зы. я девочка дизайнер, ко мне вопросов нет!
а можно вопрос не по теме?
Сиськи не покажешь)?> но вот вы, вы же большинство программисты, так? чего ждете?
Мы работаем в поте лица.
Но объективно: овнокода много, диды копротивляются.
Вон недавно вахтера выкинули из мейнтенеров за намерненное непринятие измененией на расте.
Rust давно устарел сейчас все на ИИ.
Ага, а я - тётка-бухгалтерша.
>но вот вы, вы же большинство программисты, так? чего ждете?Вы хоть представляете сколько тут работы? А так, процесс идёт. Что на go переписывают, что на rust, что изначально на ocaml или другом языке пишут.
Libxml2 одна из главных либ. Весь дистриб пересобирать нужно при её изменении. Вдруг что отвалится.
> Libxml2 одна из главных либ.Поздравляю!
Одна из главных либ - кусок дырявого крэпа))
Но менять это разумеется низя, вдруг что-то отвалится!
При багфиксе API и ABI не поменяются. Поэтому не придётся.
Есть один человек в России может пересобрать так что ничего не надо будет менять , но у него какое то кидало произошло через банк и он как мегаладон решил выжидать добычу как я понял , судя по статистике проекты годные , но как будто из будущего киберпанка и по этому немного не понятно откуда такие знания
> разрабатываемой проектом GNOMEЭто и есть самая большая уязвимость.
Поэтому программы на С и быстрые: выкинули часть проверок (здесь указатель точно валидный), сделали несколько допущений (такого размера для буфера хватит всегда), намеренно проигнорировали пару UB (тут переполнения не будет) и вуаля: быстро написанный быстрый код! Красота!Бежать по минимуму полю всегда быстрее, чем его разминировать.
Господа сишники, вот к чему приводит отсутствие нормальной типизации. Для исправления данных уязвимостей нужно как минимум афинные типы использовать, но желательно ещё и зависимые добавить. Ну или просто быть внимательнее, чему сишники никак не научатся.
>Господа сишники, вот к чему приводит отсутствие нормальной типизации.Вы о чём?
>Для исправления данных уязвимостей нужно как минимум афинные типы использовать
Ах вот о чём! Господа, ну что скажем этому оленю? В простом языке он захотел заиметь алгебраический тип данных.
>у или просто быть внимательнее, чему сишники никак не научатся.
Среди нас есть разные люди, и с разной концентрацией внимания. Если бы сишники не были внимательными, то до сегоднешнего дня, ни одна Unix-подобная операционная система не состоялась бы.
>В простом языке он захотел заиметь алгебраический тип данных.В си просты только спецификации, писать на си крайне трудно.
>Среди нас есть разные люди, и с разной концентрацией внимания.Ну как видим, у сишников, писавших libxml2 концентрации явно не хватило. И сюда ненастоящие сишники прорвались.
> Среди нас есть разные люди, и с разной концентрацией внимания.Сишка было создана для портирования юниксов. А кодовая база тех юникосов была 50-100 kLOC.
В ядре линя сейчас 40 MLOC кода. Было. Возможно уже больше.
В итоге кодовая база растет, а концентрация внимания людей нет.
Ну или тоже немного растет, но прям с разными порядками скоростей.> Если бы сишники не были внимательными
Так сишники и так не внимательные. Вот тут не заметили что функция может вернуть ошибку.
> то до сегоднешнего дня, ни одна Unix-подобная
> операционная система не состоялась бы.Состоялась бы. Просто какой ценой.
Ценой сотен тысяч багов, юязвимостей и потраченных в пустую человекочасов.
40M строк кода решаются выделением драйвера АМД и другой фигни в отдельные модули.Но это потребует хотя бы на какое-то время и хотя бы в одну сторону STABLE API...
Но Торвальдс заранее продекламировал, что это невозможно. ХЗ, может и так...
> Но это потребует хотя бы на какое-то время и хотя бы в одну сторону STABLE API...Не будет такого.
> Но Торвальдс заранее продекламировал, что это невозможно. ХЗ, может и так...
Это не невозможно, это противоречит модели разработки ядра линукса.
Ядро должно все время требовать подпиливания и подкручивания, чтобы всей толпе мейнтейнеров на зп было чем заняться. Иначе представь - взял ты дрова АМД и они работают на всей мажорной версии ядра! Ужас!А так обновился с 6.12.27 до 6.12.30 и драйвер накрылся (linux.org.ru/forum/linux-hardware/18001697). Значит кто-то должен его пойти и заадоптить.
Все при деле, все довольны. А главное донатить LF перестать нельзя))
>Но Торвальдс заранее продекламировал, что это невозможно. ХЗ, может и так...Народ, а что там у бсд, насколько драйвера стабильны?
> но желательно ещё и зависимые добавитьНу вот ты и перейдешь на парсер xml на языке с завтипами, умник.
> перед копированием данных функцией strcpyв 21-ом веке у сишников так и нету нормальных строк...
Если в С добавить полноценные строки, это будет уже не С
А что такое нормальные строки?
> А что такое нормальные строки?Что-то что хотя бы знает свою длину. Чтобы не нужно было каждый раз strlen бегать.
И чтобы этот размер менялся вместе с содержимым, а не телепаться рядом отдельной переменной с не иллюзорными шансами рассинхронаЧтобы строка не оканчивалась дурацким \n, для которого нужно каждый раз считать "а сколько же +1 нужно добавить в размер буфера при работе с несколькими строками" и все равно нафакапить и выйти за границу буфера.
Ну и конечно поддержка utf8 из коробки.
С валидацией, с итерацией по Unicode scalar value, а не по байтам и тд.
2025й год как бы на дворе.
> Уязвимости в библиотеке libxml2просто используйте JSON =)
Хрен редьки не слаще: и его надо парсить. А это слабое место С – вылезут все классические ошибки с буферами, переполнения и прочее.
Ну тогда используйте нормальные языки, такие как Go / Java / RustНу или если совсем "прикипели" к C / C++ - настройте сканеры / линтеры / санитайзеры, как это делает Google при сборке Chrome
Для простых задач если только.
expat надо использовать
Его можно использовать только для чтения.
Плюс, он не поддерживает современные спеки XML