The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



"Уязвимости в библиотеке libxml2, потенциально приводящие к выполнению кода"
Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Изначальное сообщение [ Отслеживать ]

"Уязвимости в библиотеке libxml2, потенциально приводящие к выполнению кода"  +/
Сообщение от opennews (??), 19-Июн-25, 13:34 
В библиотеке Libxml2, разрабатываемой проектом GNOME и применяемой для разбора содержимого в формате XML, выявлено 5 уязвимостей, две из которых потенциально могут привести к выполнению кода при обработке специально оформленных внешних данных. Библиотека Libxml2 широко распространена в открытых проектах и, например, используется как зависимость в более чем 800 пакетах из состава Ubuntu...

Подробнее: https://www.opennet.dev/opennews/art.shtml?num=63431

Ответить | Правка | Cообщить модератору

Оглавление

Сообщения [Сортировка по времени | RSS]


1. "Уязвимости в библиотеке libxml2, потенциально приводящие к в..."  +2 +/
Сообщение от Аноним (1), 19-Июн-25, 13:34 
Пора переписать на Си, но чтоб без багов.
Ответить | Правка | Наверх | Cообщить модератору

2. "Уязвимости в библиотеке libxml2, потенциально приводящие к в..."  –1 +/
Сообщение от Аноним (2), 19-Июн-25, 13:36 
>"на Си, но чтоб без багов. "

Ну, вы поняли.

Ответить | Правка | Наверх | Cообщить модератору

3. "Уязвимости в библиотеке libxml2, потенциально приводящие к в..."  –10 +/
Сообщение от Аноним (3), 19-Июн-25, 13:38 
Пора полностью отказаться от си. И он XML тоже. Нах он нужен. Для хранения одного байта информации пихаем килобайти лишней информации
Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

6. "Уязвимости в библиотеке libxml2, потенциально приводящие к в..."  +1 +/
Сообщение от Аноним (6), 19-Июн-25, 13:42 
Ну тогда уж откажитесь и от HTML.
Ответить | Правка | Наверх | Cообщить модератору

78. "Уязвимости в библиотеке libxml2, потенциально приводящие к в..."  +/
Сообщение от Аноним (78), 20-Июн-25, 12:18 
внезапно, изначально был PS и PDF
Ответить | Правка | Наверх | Cообщить модератору

8. "Уязвимости в библиотеке libxml2, потенциально приводящие к в..."  +2 +/
Сообщение от Аноним (8), 19-Июн-25, 13:45 
Так xml так себе, но чем ты заменишь xslt?
Ответить | Правка | К родителю #3 | Наверх | Cообщить модератору

12. "Уязвимости в библиотеке libxml2, потенциально приводящие к в..."  +4 +/
Сообщение от Аноним (12), 19-Июн-25, 13:59 
Чем угодно. Xslt неоправданно сложный. Императивный код на любом яп, написанный в лоб, будет раз в 100 понятнее. Плюс, xslt абсолютно никакой для трансформации в режиме потока, потому что весь документ грузится в виде dom целиком. Это значит, что сто-метровый хмл будет занимать 500 метров оперативки, если не больше.
Ответить | Правка | Наверх | Cообщить модератору

38. Скрыто модератором  +4 +/
Сообщение от Аноним (-), 19-Июн-25, 15:54 
Ответить | Правка | К родителю #8 | Наверх | Cообщить модератору

31. "Уязвимости в библиотеке libxml2, потенциально приводящие к в..."  –1 +/
Сообщение от Аноним (31), 19-Июн-25, 15:05 
Слова недалёкого человека. XML нужнее всех остальных форматов, ибо остальные куда уже специализированнее, а XML самый универсальный. Это не только формат для хранения и передачи данных, но ещё и команд с данными не только для выполнения команды, но ещё и для разбора что это за команда, так можно реализовать единую точку входа для всех команд, а не тонну эндпоинтов, как для REST. Хранить очень сложную структуру данных тот-же JSON не может, попробую всю страницу сайта передать в JSON (не только для заполнения формочек, а саму страницу) - не выйдет, теоретически конечно можешь, но об ручной разбор типов и экранирование - пальцы в кровь сотрёшь, и итоговый размер файла может даже и выйдет больше чем у XML.
Ответить | Правка | К родителю #3 | Наверх | Cообщить модератору

42. "Уязвимости в библиотеке libxml2, потенциально приводящие к в..."  –1 +/
Сообщение от Аноним (42), 19-Июн-25, 17:05 
> об ручной разбор типов и экранирование - пальцы в кровь сотрёшь

JSON.stringify/parse()?

Ответить | Правка | Наверх | Cообщить модератору

67. "Уязвимости в библиотеке libxml2, потенциально приводящие к в..."  +1 +/
Сообщение от Аноним (67), 20-Июн-25, 08:07 
С потерей бигинтов и цифр в флоатах, ага.
Ответить | Правка | Наверх | Cообщить модератору

46. "Уязвимости в библиотеке libxml2, потенциально приводящие к в..."  +/
Сообщение от Аноним (46), 19-Июн-25, 19:01 
А может все же лучше переделать этот огород, чтобы не требовались "очень сложные структуры данных"?
Ответить | Правка | К родителю #31 | Наверх | Cообщить модератору

55. "Уязвимости в библиотеке libxml2, потенциально приводящие к в..."  +/
Сообщение от Аноним (3), 19-Июн-25, 20:22 
И кто тогда будет платить деньги за поддержку "очень сложные структуры данных"?
Все упростить, еще и работать стабильно начнет. Точно уволят и возьмут кого-то на меньшую зарплату.
Делай спагетти-код и "очень сложные структуры данных"!!!!!
Ответить | Правка | Наверх | Cообщить модератору

4. "Уязвимости в библиотеке libxml2, потенциально приводящие к в..."  +/
Сообщение от Аноним (6), 19-Июн-25, 13:41 
На C++ с умными указателями.
Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

11. "Уязвимости в библиотеке libxml2, потенциально приводящие к в..."  –1 +/
Сообщение от Аноним (-), 19-Июн-25, 13:58 
Дурной тон писать ядро, системные утилиты и библиотеки на Си плюс-плюс. Истинная системщина - только чистый Си.
Ответить | Правка | Наверх | Cообщить модератору

13. "Уязвимости в библиотеке libxml2, потенциально приводящие к в..."  +/
Сообщение от Аноним (13), 19-Июн-25, 14:05 
> Дурной тон писать ядро, системные утилиты и библиотеки на Си плюс-плюс. Истинная  системщина - только чистый Си.

Критерии истинности в студию.

Мне казалось что системщина - это надежный код, который без ошибок работает годами.
И его раньше писали на ассемблере.

А СИшка порождает дырявый овнокод, на пеньке последние 3 новости как раз про это убожество, которое придумали для тех, кто не осилил ассемблер.
Типа ПХП из 70х.


Ответить | Правка | Наверх | Cообщить модератору

29. "Уязвимости в библиотеке libxml2, потенциально приводящие к в..."  +/
Сообщение от Аноним (29), 19-Июн-25, 14:47 
>> Дурной тон писать ядро, системные утилиты и библиотеки на Си плюс-плюс. Истинная  системщина - только чистый Си.
> Критерии истинности в студию.
> Мне казалось что системщина - это надежный код, который без ошибок работает
> годами.
> И его раньше писали на ассемблере.
> А СИшка порождает дырявый овнокод, на пеньке последние 3 новости как раз
> про это убожество, которое придумали для тех, кто не осилил ассемблер.
> Типа ПХП из 70х.
Ответить | Правка | Наверх | Cообщить модератору

47. "Уязвимости в библиотеке libxml2, потенциально приводящие к в..."  –1 +/
Сообщение от Аноним (47), 19-Июн-25, 19:16 
> И его раньше писали на ассемблере.

В ассемблере хотя бы нет UB.
Но, конечно, сейчас на ассемблере писать не вариант.

Ответить | Правка | К родителю #13 | Наверх | Cообщить модератору

56. "Уязвимости в библиотеке libxml2, потенциально приводящие к в..."  +/
Сообщение от Аноним (56), 19-Июн-25, 20:48 
>> И его раньше писали на ассемблере.
> В ассемблере хотя бы нет 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.
>

Ответить | Правка | Наверх | Cообщить модератору

57. "Уязвимости в библиотеке libxml2, потенциально приводящие к в..."  +/
Сообщение от Аноним (47), 19-Июн-25, 21:08 
По-моему, здесь как раз поведение процессора вполне определённо описано.
Ответить | Правка | Наверх | Cообщить модератору

51. "Уязвимости в библиотеке libxml2, потенциально приводящие к в..."  +1 +/
Сообщение от Аноним (6), 19-Июн-25, 19:52 
Про ядро никто не упоминал, речь была про парсер XML. А юзерспейс на ссовременных стандартах C++ - самое то.
Ответить | Правка | К родителю #11 | Наверх | Cообщить модератору

71. "Уязвимости в библиотеке libxml2, потенциально приводящие к в..."  +/
Сообщение от Аноним (-), 20-Июн-25, 10:13 
SPARK?
Ответить | Правка | К родителю #11 | Наверх | Cообщить модератору

18. "Уязвимости в библиотеке libxml2, потенциально приводящие к в..."  –4 +/
Сообщение от Аноним (13), 19-Июн-25, 14:09 
> На C++ с умными указателями.

Но смогут ли СИшники осилить умные указатели?
Они же умные! (Указатели)

А СИшники до сих пор не могут делать зануление объекта, когда он уже не нужен((

Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

81. "Уязвимости в библиотеке libxml2, потенциально приводящие к в..."  +/
Сообщение от Аноним (81), 20-Июн-25, 12:56 
>А СИшники до сих пор не могут делать зануление объекта, когда он уже не нужен((

Хватит повторять эту ошибку. Если объектом владеет только один указатель, то занулять ничего не надо, и у нас получается что-то типа раста. Если объектом владеет несколько указателей и есть gc, то рантайм сам разберётся. Если gc нет, и продвинутых типов тоже нет, а владеет несколько указателей, то нужен двойной указатель, чтобы все владения обнулились сразу же, но это ухдшит производительность. В противном случае, проблема останется. Так что в си решения по прежнему нет.

Ответить | Правка | Наверх | Cообщить модератору

86. "Уязвимости в библиотеке libxml2, потенциально приводящие к в..."  +/
Сообщение от Аноним (81), 20-Июн-25, 13:28 
Кресты даже в лучшем случае исправят только часть ошибок с памятью.
Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

5. "Уязвимости в библиотеке libxml2, потенциально приводящие к в..."  –1 +/
Сообщение от Аноним (-), 19-Июн-25, 13:41 
> 5 уязвимостей, две из которых потенциально могут привести к выполнению кода
> используется как зависимость в более чем 800 пакетах из состава Ubuntu.

Ахахахаха!
Вот она сила СИстемных языков программирования!

>  Переполнение возникает при обработке очень длинных аргументов команд из-за отсутствия корректной проверки размера входных данных перед копированием данных функцией strcpy().

strcpy - "вам не нужны нормальные строки"!

> записи данных за пределы буфера из-за целочисленного переполнения при вычислении размера буфера

Классика, одобряю!

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

А ведь эти проблемы можно было предотвратить, используя нормальные современные ЯП, а не устраревший кусок kalа из прошлого тысячелетия!

Ответить | Правка | Наверх | Cообщить модератору

7. "Уязвимости в библиотеке libxml2, потенциально приводящие к в..."  –5 +/
Сообщение от Аноним (-), 19-Июн-25, 13:45 
Сегодня прям какой-то День Унижения Дыpяшeчников.
Что случилось? В каком-то популярном анализаторе вышла обнова и кто-то решил прогнать весь сишный хлам по 100500му кругу?

Да и сами уязвимости прям сишное булщит бинго:
переполнением буфера
целочисленное переполнение + запись за пределы буфера,
use-after-free,
null dereference

Ну что, как это овнокод оправдывать будете?
Опять раст виноват?

Ответить | Правка | Наверх | Cообщить модератору

9. "Уязвимости в библиотеке libxml2, потенциально приводящие к в..."  +7 +/
Сообщение от Аноним (6), 19-Июн-25, 13:52 
Только в твоём воображении.
Ответить | Правка | Наверх | Cообщить модератору

16. "Уязвимости в библиотеке libxml2, потенциально приводящие к в..."  +4 +/
Сообщение от Аноним (16), 19-Июн-25, 14:08 
> Ну что, как это овнокод оправдывать будете? Опять раст виноват?

На Расте ничего не написано, потому и багов нет, лол. И от целочисленного переполнения он тебя не спас бы. Он вообще не дает никаких гарантий! Синтаксис вырвиглазный! Неподдерживаемое! Абр! Абр-валг!!!

Ответить | Правка | К родителю #7 | Наверх | Cообщить модератору

22. "Уязвимости в библиотеке libxml2, потенциально приводящие к в..."  –1 +/
Сообщение от Аноним (13), 19-Июн-25, 14:18 
Ты забыл еще пройтись по личностям и внешности раст программеров


"Все эти с цветными волосами!
Да еще радужные! А вы слышали про Asahi?
И вообще для СИшника качество кода не главное!
Главное в трусы заглянуть, вдруг скрепа разгибаться начнет"

Это существенная не доработка, ты лишен кошка-жена на неделю!

Ответить | Правка | Наверх | Cообщить модератору

10. "Уязвимости в библиотеке libxml2, потенциально приводящие к в..."  –3 +/
Сообщение от Аноним (-), 19-Июн-25, 13:55 
Сегодня жаркий денек.
Спецвыпуск "Сишный овнокод и его фиксы"

+    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? Не сишечка ли это часом?

Ответить | Правка | Наверх | Cообщить модератору

19. "Уязвимости в библиотеке libxml2, потенциально приводящие к в..."  +/
Сообщение от Аноним (19), 19-Июн-25, 14:09 
Надо было использовать ИИ ассистента.
Ответить | Правка | Наверх | Cообщить модератору

23. "Уязвимости в библиотеке libxml2, потенциально приводящие к в..."  +1 +/
Сообщение от Аноним (23), 19-Июн-25, 14:23 
Так дело всё же в языке или в гении, который код писал!
Ответить | Правка | К родителю #10 | Наверх | Cообщить модератору

24. "Уязвимости в библиотеке libxml2, потенциально приводящие к в..."  +/
Сообщение от Аноним (23), 19-Июн-25, 14:24 
*?
Ответить | Правка | Наверх | Cообщить модератору

26. "Уязвимости в библиотеке libxml2, потенциально приводящие к в..."  –1 +/
Сообщение от Аноним (-), 19-Июн-25, 14:38 
> Так дело всё же в языке или в гении, который код писал!

То что убогий жигулятор при аварии убивает и пешехода и часто водилу (подушки? нет не слышал) это виноват водила?
Или то что эта древность проектировалась тяп ляп?

Так же и с дыряшкой.
Язык просто неявно кастит, быдлокодер не проверяет.

Если сам автор ЯП писал "комитет сделал язык на котором невозможно писать", то наверное он знал о чем говорил.

Ответить | Правка | К родителю #23 | Наверх | Cообщить модератору

44. "Уязвимости в библиотеке libxml2, потенциально приводящие к в..."  +/
Сообщение от Аноним (44), 19-Июн-25, 18:00 
Не знаю насколько удачный ваш пример. Кто виноват и что виновато, нужно смотреть по ситуации и не факт, что убогий жигулятор виноват, зависит от того, как им управляли и что творилось на дороге. Виноватыми могут быть и водила, и пешеход.
Ответить | Правка | Наверх | Cообщить модератору

48. "Уязвимости в библиотеке libxml2, потенциально приводящие к в..."  –1 +/
Сообщение от Аноним (47), 19-Июн-25, 19:18 
Но что ведро с гайками повышает аварийность, спорить ведь не будете? Или его просто правильно водить надо?
Ответить | Правка | Наверх | Cообщить модератору

74. "Уязвимости в библиотеке libxml2, потенциально приводящие к в..."  +/
Сообщение от нейм (?), 20-Июн-25, 11:12 
любая машина = ведро с гайками = средство передвижения повышенной опасности (или как оно там в пдд)
Ответить | Правка | Наверх | Cообщить модератору

76. "Уязвимости в библиотеке libxml2, потенциально приводящие к в..."  +/
Сообщение от Аноним (-), 20-Июн-25, 11:27 
> любая машина = ведро с гайками = средство передвижения повышенной опасности

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

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

Так и тут. Не существует абсолютного решения, но если есть то, которое может уменьшить кол-во проблем напр. на 30 (50, 70, whatever) процентов - то это уже решение.

Ответить | Правка | Наверх | Cообщить модератору

91. "Уязвимости в библиотеке libxml2, потенциально приводящие к в..."  +/
Сообщение от Аноним (91), 20-Июн-25, 13:37 
Горит сарай - гори и хата!
Ответить | Правка | К родителю #74 | Наверх | Cообщить модератору

58. "Уязвимости в библиотеке libxml2, потенциально приводящие к в..."  +/
Сообщение от Аноним (-), 19-Июн-25, 21:09 
> это виноват водила?

Ты неправильно вопрос ставишь, Дядя Фёдор.

Поиск виноватых -- это конечно хорошо, но это сужение общей проблемы поиска причин произошедшего. Если водила умер, но при наличии подушек безопасности он бы не умер, то подушки безопасности -- это причина его смерти, пускай их и сложно назначить виноватыми.

Причин может быть много, более того, _достаточных_ причин может быть много (т.е. таких причин, что каждой из них было бы достаточно, чтобы получить обсуждаемое следствие), а виноватым всегда будет стрелочник. Чтобы избегать неприятных следствий надо бороться с причинами, и совершенно бесполезно бороться со стрелочниками. Поэтому и вопрос надо ставить не о вине, а о причине. Или даже о причинах.

Ответить | Правка | К родителю #26 | Наверх | Cообщить модератору

36. "Уязвимости в библиотеке libxml2, потенциально приводящие к в..."  –1 +/
Сообщение от Аноним (1), 19-Июн-25, 15:43 
> А какой гений решил использовать signed переменную для newSize?

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

Ответить | Правка | К родителю #10 | Наверх | Cообщить модератору

80. "Уязвимости в библиотеке libxml2, потенциально приводящие к в..."  +/
Сообщение от ptr (ok), 20-Июн-25, 12:51 
Проблема не в языке, а в руках.
Например, в некотором языке значение res будет иметь разные значения (0 или 0.01), в зависимости кодогенератора LLVM и опций его оптимизатора:
let a: f32 = 1E-64;
let b: f32 = 1E64;
let c: f32 = 1E126;
let res = a/b*c;

Видите классический UB с исчезновением порядка?

Ответить | Правка | К родителю #10 | Наверх | Cообщить модератору

82. "Уязвимости в библиотеке libxml2, потенциально приводящие к в..."  +/
Сообщение от Аноним (-), 20-Июн-25, 13:19 
> Проблема не в языке, а в руках.

Но тут нет 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 языком определен однозначно.
А проблема в конкретной имплементации конкретного компилятора. Я ведь тоже могу накидать различий в выхлопе в другом языке при применении различных оптимизаций.

Ответить | Правка | Наверх | Cообщить модератору

83. "Уязвимости в библиотеке libxml2, потенциально приводящие к в..."  +/
Сообщение от ptr (ok), 20-Июн-25, 13:23 
> Но тут нет UB.

А при чем тут UB, если проблема именно в руках?

> Evaluation order языком определен однозначно.

Но не определено, будет ли промежуточный результат из 80-х битных регистров FPU сохраняться в память или останется в регистре. Проблема то именно в этом.

Ответить | Правка | Наверх | Cообщить модератору

93. "Уязвимости в библиотеке libxml2, потенциально приводящие к в..."  +/
Сообщение от Аноним (-), 20-Июн-25, 13:40 
> если проблема именно в руках?

Где?
Я расписал именно недостатки языка и его выразительности, которые привели к ошибке.
А вы пишите "именно в руках". Ну так раскройте свою мысль почему все аргументы про неявный каст и отсутствие ошибок на уровне языка не валидны.


Ответить | Правка | Наверх | Cообщить модератору

84. "Уязвимости в библиотеке libxml2, потенциально приводящие к в..."  +/
Сообщение от Аноним (81), 20-Июн-25, 13:26 
>Проблема не в языке, а в руках.

Проблема в руках, которые берут этот язык. Ибо одни языки сопротивляются г-коду, а другие наоборот, этот самый г-код поощрают.
>Например, в некотором языке значение res будет иметь разные значения (0 или 0.01)

В каком? Rust, например сразу же выдаёт ошибку компиляции, у ocaml вообще другой синтаксис, и основной компилятор llvm не использует.
>Видите классический UB с исчезновением порядка?

Я вижу ошибку компиляции. Хороший компилятор сделал своё дело.

Ответить | Правка | К родителю #80 | Наверх | Cообщить модератору

92. "Уязвимости в библиотеке libxml2, потенциально приводящие к в..."  +/
Сообщение от ptr (ok), 20-Июн-25, 13:37 
>>Видите классический UB с исчезновением порядка?
> Я вижу ошибку компиляции. Хороший компилятор сделал своё дело.

И где Вы увидели ошибку компиляции? Здесь классический UB, связанный с тем, было ли сохранение промежуточного результата из 80-битного регистра FPU в память с преобразованием его в f32 или нет.

Ответить | Правка | Наверх | Cообщить модератору

94. "Уязвимости в библиотеке libxml2, потенциально приводящие к в..."  +/
Сообщение от Аноним (-), 20-Июн-25, 13:43 
> И где Вы увидели ошибку компиляции?

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

Ответить | Правка | Наверх | Cообщить модератору

95. "Уязвимости в библиотеке libxml2, потенциально приводящие к в..."  +/
Сообщение от Аноним (81), 20-Июн-25, 13:43 
>И где Вы увидели ошибку компиляции?

Вы для начала язык назовите, а то телепаты в отпуске. Проверял здесь 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 default

error: 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

Ответить | Правка | К родителю #92 | Наверх | Cообщить модератору

96. "Уязвимости в библиотеке libxml2, потенциально приводящие к в..."  +/
Сообщение от ptr (ok), 20-Июн-25, 14:04 
> 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);
}

Ответить | Правка | Наверх | Cообщить модератору

97. "Уязвимости в библиотеке libxml2, потенциально приводящие к в..."  +/
Сообщение от Аноним (81), 20-Июн-25, 14:55 
Ну отлично, теперь это хотя бы компилируется. Но заявленного вами поведения не наблюдаю, и в дебаге и в релизе выдаёт 0.
Ответить | Правка | Наверх | Cообщить модератору

98. "Уязвимости в библиотеке libxml2, потенциально приводящие к в..."  +/
Сообщение от Аноним (-), 20-Июн-25, 15:04 
> Ну отлично, теперь это хотя бы компилируется. Но заявленного вами поведения не
> наблюдаю, и в дебаге и в релизе выдаёт 0.

"в зависимости кодогенератора LLVM и опций его оптимизатора"
Скорее всего нужна конкретная версия компилятора, уровень оптимизаций и возможно флаги.
Так что удачки это повторить.

При этом это все равно останется UB реализации, а не языка.

Ответить | Правка | Наверх | Cообщить модератору

99. "Уязвимости в библиотеке libxml2, потенциально приводящие к в..."  +/
Сообщение от Аноним (81), 20-Июн-25, 15:23 
>Скорее всего нужна конкретная версия компилятора, уровень оптимизаций и возможно флаги.

Скорее всего это просто баг llvm-а. Некоторые языки, тот же ocaml от llvm не зависят вообще. А вот ub в си возникает стабильно. Хоть на gcc, хоть на llvm, хоть на msvc. Ну может на экзотике типа tcc не возникает, пока туда оптимизаций не завезли, как завезут, так там тоже возникнут.

Ответить | Правка | Наверх | Cообщить модератору

14. "Уязвимости в библиотеке libxml2, потенциально приводящие к в..."  –1 +/
Сообщение от Аноним (19), 19-Июн-25, 14:08 
А вот писали бы они с помощью ИИ такой фигни бы не было.
Ответить | Правка | Наверх | Cообщить модератору

20. "Уязвимости в библиотеке libxml2, потенциально приводящие к в..."  +/
Сообщение от Аноним (13), 19-Июн-25, 14:13 
> А вот писали бы они с помощью ИИ такой фигни бы не было.

А ИИ на чем обучали?
На ЩитХабе и таких же кодах?
Ой, так он будет точно так же овнокодить и делать такие же ошибки.
Потому что shit in -> shit out


Ответить | Правка | Наверх | Cообщить модератору

27. "Уязвимости в библиотеке libxml2, потенциально приводящие к в..."  +/
Сообщение от Аноним (19), 19-Июн-25, 14:45 
Проверку длинны ИИ сделать в состоянии в отличии от коженных мешков.
Ответить | Правка | Наверх | Cообщить модератору

30. "Уязвимости в библиотеке libxml2, потенциально приводящие к в..."  +/
Сообщение от Аноним (-), 19-Июн-25, 15:03 
> Проверку длинны ИИ сделать в состоянии в отличии от коженных мешков.

Потому что он хоть и Искусственный, но Интеллект!

А для писания на СИшке мозг вообще не нужен.
Не сходятся типы? Кастуй к void*
Целочисленная функция должна возвращать ошибку? Пусть просто станет signed возвращает -1. Result<Value, Error> это что-то на смузихлебском.
Enum_Crocodile пытаются сравнивать с Enum_Bombardilo? Пофиг, под капотом все равно int.

Ответить | Правка | Наверх | Cообщить модератору

72. "Уязвимости в библиотеке libxml2, потенциально приводящие к в..."  +/
Сообщение от Аноним (19), 20-Июн-25, 10:59 
Дообучи ИИ как надо и он тебе исправит что угодно во всем проекте.
Ответить | Правка | Наверх | Cообщить модератору

33. "Уязвимости в библиотеке libxml2, потенциально приводящие к в..."  +/
Сообщение от нах. (?), 19-Июн-25, 15:39 
конечно не было бы - когда код xml-парсера не компилится или не парсит xml - никаких проблем он и не создаст.

Ответить | Правка | К родителю #14 | Наверх | Cообщить модератору

73. "Уязвимости в библиотеке libxml2, потенциально приводящие к в..."  +/
Сообщение от Аноним (19), 20-Июн-25, 11:00 
То что ты не умеешь пользоваться ИИ и не в состоянии написать нормальный промт виноват только ты.
Ответить | Правка | Наверх | Cообщить модератору

77. "Уязвимости в библиотеке libxml2, потенциально приводящие к в..."  +/
Сообщение от нах. (?), 20-Июн-25, 11:40 
> То что ты не умеешь пользоваться ИИ и не в состоянии написать
> нормальный промт виноват только ты.

ну ты-то умеешь, ии за тебя уже три хеловрота написал?

А мы так и будем жить с libxml2 и еще более ужасным xslt, автор которого видимо либо от старости помер либо в монастырь ушел, тяжкий грех до конца своих дней замаливать.

Поскольку твои хеловроты его не заменят решительно никак.

Скорее уж хрустики подтянутся и перепишут-перепишут (еще лет за двадцать, их темпами быстрее от борова не убежишь). Может даже ии припрягут, от борова бегать ему самое то занятие.

Ответить | Правка | Наверх | Cообщить модератору

17. "Уязвимости в библиотеке libxml2, потенциально приводящие к в..."  –1 +/
Сообщение от Аноним (-), 19-Июн-25, 14:09 
> Для устранения данных уязвимостей рассматривается возможность
> удаления из libxml2 поддержки языка разметки Schematron.

Да вообще libxml2 нужно отовюсюду выкинуть и заменить на что-то нормальное.
Напр. на quick-xml или xml-rs.

Иначе ситуация "более чем 800 пакетов из состава Ubuntu" оказались дырявы будет повторяться раз за разом.

Ответить | Правка | Наверх | Cообщить модератору

34. "Уязвимости в библиотеке libxml2, потенциально приводящие к в..."  +/
Сообщение от нах. (?), 19-Июн-25, 15:42 
> Да вообще libxml2 нужно отовюсюду выкинуть и заменить на что-то нормальное.

приступай.

Только - нормальное, а не подделку реализующую 1/100 от оригинала. (поддержку нахрен никому ненужного язычка шк070трон можешь выкинуть)

Как напишешь такую - приходи.

А пока это референсный парсер xml, и ничего на замену нет и не предвидится. Ну кроме попыток парсить xml грепом, обреченных на весьма специфичный успех.


Ответить | Правка | Наверх | Cообщить модератору

41. "Уязвимости в библиотеке libxml2, потенциально приводящие к в..."  +/
Сообщение от Аноним (-), 19-Июн-25, 16:56 
> Только - нормальное,

Типа того что сейчас))?

> а не подделку реализующую 1/100 от оригинала.

Если 95% юзеров этого достаточно, то можно и одну сотую.
А потом слушать нытье и добавлять именно то что нужно, а не "у нас тут для i286 есть костыли, их обязательно нужно перенести!!11"

Ответить | Правка | Наверх | Cообщить модератору

50. "Уязвимости в библиотеке libxml2, потенциально приводящие к в..."  +/
Сообщение от нах. (?), 19-Июн-25, 19:42 
> Если 95% юзеров этого достаточно, то можно и одну сотую.

эти 95 на винде сидят. С теми еще 2% которым недостаточно но они тоже уже там.

Ответить | Правка | Наверх | Cообщить модератору

21. "Уязвимости в библиотеке libxml2, потенциально приводящие к в..."  +/
Сообщение от Аноним (21), 19-Июн-25, 14:16 
последнее время много криков, переписать на rust, срочно переписать!

но при этом все продолжают пережевывать это сишное #### булшит

когда от возмущения перейдете к делу?

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

Ответить | Правка | Наверх | Cообщить модератору

25. "Уязвимости в библиотеке libxml2, потенциально приводящие к в..."  +/
Сообщение от Аноним (13), 19-Июн-25, 14:24 
> последнее время много криков, переписать на rust, срочно переписать!

Ага

> но при этом все продолжают пережевывать это сишное #### булшит

С чего ты взял?

> когда от возмущения перейдете к делу?

Сколько было воплей и подгорания оп от таких новостей:
- В Ubuntu 25.10 решено задействовать аналог sudo, написанный на Rust
- Для FreeBSD развивают опциональную поддержку компонентов базовой системы на Rust
- Разработчики GRUB2 рассматривают возможность использования языка Rust
- Браузер Chrome переведён на шрифтовой движок Skrifa, написанный на Rust
- Для ядра Linux 6.15 предложен начальный код драйвера Nova, написанный на

на минуточку Хром это 2+ миллиарда пользоватлей, про ядро вообще молчу

> зы. я девочка дизайнер, ко мне вопросов нет!

а можно вопрос не по теме?
Сиськи не покажешь)?

> но вот вы, вы же большинство программисты, так? чего ждете?

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


Ответить | Правка | Наверх | Cообщить модератору

28. "Уязвимости в библиотеке libxml2, потенциально приводящие к в..."  +/
Сообщение от Аноним (19), 19-Июн-25, 14:46 
Rust давно устарел сейчас все на ИИ.
Ответить | Правка | К родителю #21 | Наверх | Cообщить модератору

52. "Уязвимости в библиотеке libxml2, потенциально приводящие к в..."  +/
Сообщение от Аноним (6), 19-Июн-25, 20:00 
Ага, а я - тётка-бухгалтерша.
Ответить | Правка | К родителю #21 | Наверх | Cообщить модератору

100. "Уязвимости в библиотеке libxml2, потенциально приводящие к в..."  +/
Сообщение от Аноним (81), 20-Июн-25, 15:26 
>но вот вы, вы же большинство программисты, так? чего ждете?

Вы хоть представляете сколько тут работы? А так, процесс идёт. Что на go переписывают, что на rust, что изначально на ocaml или другом языке пишут.

Ответить | Правка | К родителю #21 | Наверх | Cообщить модератору

32. "Уязвимости в библиотеке libxml2, потенциально приводящие к в..."  +/
Сообщение от Аноним (32), 19-Июн-25, 15:19 
Libxml2 одна из главных либ. Весь дистриб пересобирать нужно при её изменении. Вдруг что отвалится.
Ответить | Правка | Наверх | Cообщить модератору

37. "Уязвимости в библиотеке libxml2, потенциально приводящие к в..."  +/
Сообщение от Аноним (-), 19-Июн-25, 15:49 
> Libxml2 одна из главных либ.

Поздравляю!
Одна из главных либ - кусок дырявого крэпа))
Но менять это разумеется низя, вдруг что-то отвалится!

Ответить | Правка | Наверх | Cообщить модератору

53. "Уязвимости в библиотеке libxml2, потенциально приводящие к в..."  +/
Сообщение от Аноним (6), 19-Июн-25, 20:09 
При багфиксе API и ABI не поменяются. Поэтому не придётся.
Ответить | Правка | К родителю #32 | Наверх | Cообщить модератору

54. "Уязвимости в библиотеке libxml2, потенциально приводящие к в..."  +/
Сообщение от Dom (?), 19-Июн-25, 20:14 
Есть один человек в России может пересобрать так что ничего не надо будет менять , но у него какое то кидало произошло через банк и он как мегаладон решил выжидать добычу как я понял , судя по статистике проекты годные , но как будто из будущего киберпанка и по этому немного не понятно откуда такие знания
Ответить | Правка | К родителю #32 | Наверх | Cообщить модератору

35. "Уязвимости в библиотеке libxml2, потенциально приводящие к в..."  +1 +/
Сообщение от Аноним (35), 19-Июн-25, 15:43 
> разрабатываемой проектом GNOME

Это и есть самая большая уязвимость.

Ответить | Правка | Наверх | Cообщить модератору

64. "Уязвимости в библиотеке libxml2, потенциально приводящие к в..."  +/
Сообщение от Карлос Сношайтилис (ok), 20-Июн-25, 01:45 
Поэтому программы на С и быстрые:  выкинули часть проверок (здесь указатель точно валидный), сделали несколько допущений (такого размера для буфера хватит всегда), намеренно проигнорировали пару UB (тут переполнения не будет) и вуаля: быстро написанный быстрый код! Красота!

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

Ответить | Правка | Наверх | Cообщить модератору

79. "Уязвимости в библиотеке libxml2, потенциально приводящие к в..."  +/
Сообщение от Аноним (81), 20-Июн-25, 12:22 
Господа сишники, вот к чему приводит отсутствие нормальной типизации. Для исправления данных уязвимостей нужно как минимум афинные типы использовать, но желательно ещё и зависимые добавить. Ну или просто быть внимательнее, чему сишники никак не научатся.
Ответить | Правка | Наверх | Cообщить модератору

85. "Уязвимости в библиотеке libxml2, потенциально приводящие к в..."  +1 +/
Сообщение от Аноним (-), 20-Июн-25, 13:28 
>Господа сишники, вот к чему приводит отсутствие нормальной типизации.

Вы о чём?

>Для исправления данных уязвимостей нужно как минимум афинные типы использовать

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

>у или просто быть внимательнее, чему сишники никак не научатся.

Среди нас есть разные люди, и с разной концентрацией внимания. Если бы сишники не были внимательными, то до сегоднешнего дня, ни одна Unix-подобная операционная система не состоялась бы.

Ответить | Правка | Наверх | Cообщить модератору

89. "Уязвимости в библиотеке libxml2, потенциально приводящие к в..."  +/
Сообщение от Аноним (81), 20-Июн-25, 13:35 
>В простом языке он захотел заиметь алгебраический тип данных.

В си просты только спецификации, писать на си крайне трудно.
>Среди нас есть разные люди, и с разной концентрацией внимания.

Ну как видим, у сишников, писавших libxml2 концентрации явно не хватило. И сюда ненастоящие сишники прорвались.

Ответить | Правка | Наверх | Cообщить модератору

90. "Уязвимости в библиотеке libxml2, потенциально приводящие к в..."  +/
Сообщение от Аноним (-), 20-Июн-25, 13:36 
> Среди нас есть разные люди, и с разной концентрацией внимания.

Сишка было создана для портирования юниксов. А кодовая база тех юникосов была 50-100 kLOC.
В ядре линя сейчас 40 MLOC кода. Было. Возможно уже больше.
В итоге кодовая база растет, а концентрация внимания людей нет.
Ну или тоже немного растет, но прям с разными порядками скоростей.

> Если бы сишники не были внимательными

Так сишники и так не внимательные. Вот тут не заметили что функция может вернуть ошибку.

> то до сегоднешнего дня, ни одна Unix-подобная
> операционная система не состоялась бы.

Состоялась бы. Просто какой ценой.
Ценой сотен тысяч багов, юязвимостей и потраченных в пустую человекочасов.

Ответить | Правка | К родителю #85 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2025 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру