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

"Уязвимость в Musl, эксплуатируемая при перекодировании текста в кодировке EUC-KR"	+/–
Сообщение от opennews (??), 14-Фев-25, 16:00
В стандартной Си-библиотеки Musl выявлена уязвимость (CVE-2024-2961), приводящая к переполнению буфера при преобразовании специально оформленного текста из кодировки EUC-KR в UTF-8 при помощи функции iconv(). Уязвимость проявляется начиная с версии musl 0.9.13 и будет исправлена  в готовящемся к публикации выпуске 1.2.6 (до публикации обновления следует использовать патч)... Подробнее: https://www.opennet.me/opennews/art.shtml?num=62719
Ответить | Правка | Cообщить модератору

Сообщения

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

1. "Уязвимость в Musl, эксплуатируемая при перекодировании текст..."	+/–
Сообщение от Аноним (1), 14-Фев-25, 16:00
В glibc такого нет!
Ответить | Правка | Наверх | Cообщить модератору

	3. "Уязвимость в Musl, эксплуатируемая при перекодировании текст..."	+15 +/–
	Сообщение от Аноним (3), 14-Фев-25, 16:07
	https://opennet.ru/54508 CVE-2019-25013 - переполнение буфера при обработке в функции iconv строки в кодировке EUC-KR, включающей некорректные многобайтовые последовательности (например, echo -en "\x00\xfe" | iconv -c -f EUC-KR -t "UTF-8"). https://opennet.ru/61033 CVE-2024-2961 - переполнение буфера при преобразовании специально оформленных строк в кодировке ISO-2022-CN-EXT функцией iconv(). https://opennet.ru/49059 CVE-2016-6261, CVE-2016-6263, CVE-2017-14062 - серия уязвимостей во встроенной реализации функций для разбора интернационализированных имён доменов.
	Ответить | Правка | Наверх | Cообщить модератору

	6. "Уязвимость в Musl, эксплуатируемая при перекодировании текст..."	+3 +/–
	Сообщение от Аноним (6), 14-Фев-25, 16:14
	Ну вот! Он все правльно сказал: в glibc такого (уже) нет! А то что было, это не считается.
	Ответить | Правка | Наверх | Cообщить модератору

	7. "Уязвимость в Musl, эксплуатируемая при перекодировании текст..."	+/–
	Сообщение от Аноним (7), 14-Фев-25, 16:14
	EUC-KR никак диверсия кетайцев!
	Ответить | Правка | К родителю #3 | Наверх | Cообщить модератору

	65. "Уязвимость в Musl, эксплуатируемая при перекодировании текст..."	+/–
	Сообщение от bircoph (ok), 14-Фев-25, 19:20
	Корейцев же. Северных.
	Ответить | Правка | Наверх | Cообщить модератору

	89. "Уязвимость в Musl, эксплуатируемая при перекодировании текст..."	+6 +/–
	Сообщение от Аноним (89), 14-Фев-25, 19:55
	Серверных.
	Ответить | Правка | Наверх | Cообщить модератору

	22. "Уязвимость в Musl, эксплуатируемая при перекодировании текст..."	+3 +/–
	Сообщение от Аноним (22), 14-Фев-25, 16:58
	Так-с, понятно откуда уязвимый код функции, под GPLv3 между прочим, был скопирован.
	Ответить | Правка | К родителю #3 | Наверх | Cообщить модератору

2. "Уязвимость в Musl, эксплуатируемая при перекодировании текст..."	+1 +/–
Сообщение от Аноним (7), 14-Фев-25, 16:05
Как эта либа читается? Мус-ел, -ыл, -ли...?
Ответить | Правка | Наверх | Cообщить модератору

	4. "Уязвимость в Musl, эксплуатируемая при перекодировании текст..."	+2 +/–
	Сообщение от Аноним (4), 14-Фев-25, 16:07
	насколько я помню "U" читается как "А". на выходе получаем "МАСЛ"
	Ответить | Правка | Наверх | Cообщить модератору

	25. "Уязвимость в Musl, эксплуатируемая при перекодировании текст..."	+4 +/–
	Сообщение от Аноним (25), 14-Фев-25, 17:00
	Масло.
	Ответить | Правка | Наверх | Cообщить модератору

	31. "Уязвимость в Musl, эксплуатируемая при перекодировании текст..."	+/–
	Сообщение от Аноним (31), 14-Фев-25, 17:09
	Как muzzle. Или как конец слова "шлимазл".
	Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

	43. "Уязвимость в Musl, эксплуатируемая при перекодировании текст..."	+/–
	Сообщение от _ (??), 14-Фев-25, 18:38
	"конец шлимазла" ... вона оно как ... 8-D
	Ответить | Правка | Наверх | Cообщить модератору

	36. "Уязвимость в Musl, эксплуатируемая при перекодировании текст..."	+1 +/–
	Сообщение от Пушистый Мастер (?), 14-Фев-25, 17:28
	Только это никакое не масло. Звучит как muscle (мускулы).
	Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

	81. "Уязвимость в Musl, эксплуатируемая при перекодировании текст..."	+/–
	Сообщение от Аноним (4), 14-Фев-25, 19:33
	>Звучит как muscle MySQL?
	Ответить | Правка | Наверх | Cообщить модератору

	46. Скрыто модератором	+1 +/–
	Сообщение от Аноним (-), 14-Фев-25, 18:42
	>на выходе получаем "МАСЛ" Садись, пять!
	Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

	10. "Уязвимость в Musl, эксплуатируемая при перекодировании текст..."	+5 +/–
	Сообщение от Аноним (10), 14-Фев-25, 16:19
	муслим
	Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

	28. "Уязвимость в Musl, эксплуатируемая при перекодировании текст..."	+/–
	Сообщение от Аноним (31), 14-Фев-25, 17:05
	Маслоу. Пирамида. Нижний уровень.
	Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

	48. "Уязвимость в Musl, эксплуатируемая при перекодировании текст..."	+1 +/–
	Сообщение от Аноним (-), 14-Фев-25, 18:44
	По-русски читается как [масл]. В английском омоним слова muscle - мускула.
	Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

	105. "Уязвимость в Musl, эксплуатируемая при перекодировании текст..."	+/–
	Сообщение от Аноним (105), 15-Фев-25, 01:55
	Мюсл
	Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

	106. "Уязвимость в Musl, эксплуатируемая при перекодировании текст..."	+2 +/–
	Сообщение от Аноним (106), 15-Фев-25, 04:56
	Мюсли - это жаргон. Как Silverlight - сервелат.
	Ответить | Правка | Наверх | Cообщить модератору

5. "Уязвимость в Musl, эксплуатируемая при перекодировании текст..."	–7 +/–
Сообщение от Уууууъъъ (?), 14-Фев-25, 16:10
Вот почему стоит сосредоточиться на улучшении инструментов для C/C++, таких как статический и динамический анализ кода, Address Space Layout Randomization и Data Execution Prevention, вместо того чтобы развивать Rust.
Ответить | Правка | Наверх | Cообщить модератору

	9. "Уязвимость в Musl, эксплуатируемая при перекодировании текст..."	+4 +/–
	Сообщение от Mikhail (??), 14-Фев-25, 16:18
	С/С++ очень сложны для современных программистов и любой знакомый с ними автоматом записывается в диды
	Ответить | Правка | Наверх | Cообщить модератору

	13. "Уязвимость в Musl, эксплуатируемая при перекодировании текст..."	+1 +/–
	Сообщение от Аноним (6), 14-Фев-25, 16:22
	> С/С++ очень сложны для современных программистов и > любой знакомый с ними автоматом записывается в диды Нет такого языка С/С++. Есть древний C, на котором пишут диды. А есть прекрасный современный C++, на котором крутые парни пишут весь современный софт! Проблема только в том, что некоторые сишники берут плюсы... но получается все равно программа на си. И этим портят репутацию нормальным плюсовикам.
	Ответить | Правка | Наверх | Cообщить модератору

	53. "Уязвимость в Musl, эксплуатируемая при перекодировании текст..."	+/–
	Сообщение от Аноним (53), 14-Фев-25, 19:01
	Что, разыменновывание нулевого указателя в крестах больше не UB? А может ещё и за границу массива нельзя вылезти? И двойных освобождений там нет?
	Ответить | Правка | Наверх | Cообщить модератору

	60. "Уязвимость в Musl, эксплуатируемая при перекодировании текст..."	–3 +/–
	Сообщение от Аноним (-), 14-Фев-25, 19:07
	> Что, разыменновывание нулевого указателя в крестах больше не UB? Все еще UB. К сожалению, это тяжелое наследие сишки. > А может ещё и за границу массива нельзя вылезти? Используй итераторы. > И двойных освобождений там нет? Используй smart pointer'ы. В с++ намного больше современных инструментов чтобы не выстрелить себе в ногу. Другое дело что ими не все пользуются - вот как раз люди с си головного мозга. А вот нормальные разрабы пишут на с++ на порядок более надежный софт. Иначе как объяснить, что сишка сейчас осталась только в легаси, а все нормальные проекты не на си, не на расте, не на фортране или аде, а на плюсах?
	Ответить | Правка | Наверх | Cообщить модератору

	72. "Уязвимость в Musl, эксплуатируемая при перекодировании текст..."	–2 +/–
	Сообщение от Аноним (53), 14-Фев-25, 19:24
	>Другое дело что ими не все пользуются - вот как раз люди с си головного мозга. Это - и есть проблема крестов. Если я вижу файл с расширением cpp, то не вчитываясь в код, я не могу быть уверенным в том, что там нет таких серьёзных проблем. >А вот нормальные разрабы пишут на с++ на порядок более надежный софт. Как бы не так. https://www.opennet.me/opennews/art.shtml?num=61748 >Задействован новый парсер формата JSON, переписанный с C++ на язык Rust, и обеспечивающий более высокую защищённость за счёт снижения вероятности появления ошибок при работе с памятью. Отмечается, что переход на новый парсер может привести к прекращению разбора некоторого некорректно оформленного контента в формате JSON, но при этом он также решает проблемы при работе с некорректным JSON, который раньше вызывал аварийное завершение, а теперь приводит к возврату кода ошибки Вот что-что, а парсер json, это что-то вроде hello world от мира парсеров, но даже такой формат плюсовики обработать не могут.
	Ответить | Правка | Наверх | Cообщить модератору

	95. "Уязвимость в Musl, эксплуатируемая при перекодировании текст..."	+/–
	Сообщение от Аноним (-), 14-Фев-25, 20:07
	> Если я вижу файл с расширением cpp, ... я не могу быть уверенным в том Вот я о том же! Если бы все писали в файлах cpp на с++, а не на си, то мир бы стал намного лучше. ЗЫ: а если c расширением "с", то можешь быть уверенным? А если можешь, то в чем?)) > Как бы не так. Речь идет не о rust vs с++, а c++ vs c. Понятно что раст дает больше гарантий чем плюсы (цена этих гарантий выходит за рамки обсуждения) Но плюсы дают больше гарантий чем чистый си. И даже не понимаю о чем тут спорить.
	Ответить | Правка | Наверх | Cообщить модератору

	103. "Уязвимость в Musl, эксплуатируемая при перекодировании текст..."	+/–
	Сообщение от Александр (??), 15-Фев-25, 00:43
	> Если я вижу файл с расширением cpp, то не вчитываясь в код, я не могу быть уверенным в том, что там нет таких серьёзных проблем Если я вижу файл с расширением rs, то не могу быть уверен в том, что там не используются unsafe конструкции, а соответственно нет уверенности, что там нет проблем. > >Задействован новый парсер формата JSON, переписанный с C++ на язык Rust, и обеспечивающий более высокую защищённость Это только время может показать
	Ответить | Правка | К родителю #72 | Наверх | Cообщить модератору

	122. "Уязвимость в Musl, эксплуатируемая при перекодировании текст..."	+/–
	Сообщение от Аноним (53), 15-Фев-25, 22:39
	>Если я вижу файл с расширением rs, то не могу быть уверен в том, что там не используются unsafe конструкции Наличие unsafe проверятеся обычным grep, кроме того есть #![forbid(unsafe_code)] >Это только время может показать Время это уже показало. Плюсовики неасилили json парсер, хотя это буквально учебный пример https://dev.realworldocaml.org/parsing-with-ocamllex-and-men...
	Ответить | Правка | Наверх | Cообщить модератору

	74. "Уязвимость в Musl, эксплуатируемая при перекодировании текст..."	+/–
	Сообщение от Аноним (53), 14-Фев-25, 19:26
	>> А может ещё и за границу массива нельзя вылезти? >Используй итераторы. А на запись?
	Ответить | Правка | К родителю #60 | Наверх | Cообщить модератору

	82. "Уязвимость в Musl, эксплуатируемая при перекодировании текст..."	–1 +/–
	Сообщение от филателист (?), 14-Фев-25, 19:33
	Запись придумали трусы. Динамические массивы - лентяи. Реальные пацаны ничего и ни на кого не пишут. И никогда не леняться. Реальные пацаны творят. Фу быть не пацаном.
	Ответить | Правка | Наверх | Cообщить модератору

	111. "Уязвимость в Musl, эксплуатируемая при перекодировании текст..."	+1 +/–
	Сообщение от Аноним (-), 15-Фев-25, 07:46
	>Все еще UB. К сожалению, это тяжелое наследие сишки. C++ не является продолжением языка Си. Сишка не говорила плюсам, скопируй меня. Когда разрабатывали C++ cишка никак не навязывала себя. Так что не надо говорить, по какое-то там "наследие". Все проблемы C++ это проблемы самой C++. Язык Си на 90% совершенный и завершённый продукт.
	Ответить | Правка | К родителю #60 | Наверх | Cообщить модератору

	116. "Уязвимость в Musl, эксплуатируемая при перекодировании текст..."	+1 +/–
	Сообщение от Аноним (116), 15-Фев-25, 11:25
	Очень интересное мнение, к сожалению автор С++ с вами не согласен: https://www.youtube.com/watch?v=86xWVb4XIyE&t=700s Как это сишка не навязывала себя, когда C++ изначально вообще был реализован трансляцией того, что было добавлено относительно C в код на C последующей компиляцией C-компилятором (https://en.wikipedia.org/wiki/Cfront) ?
	Ответить | Правка | Наверх | Cообщить модератору

	117. "Уязвимость в Musl, эксплуатируемая при перекодировании текст..."	+1 +/–
	Сообщение от Аноним (-), 15-Фев-25, 12:18
	> Очень интересное мнение, к сожалению автор С++ с вами не согласен: https://www.youtube.com/watch?v=86xWVb4XIyE&t=700s Ну ты сравнил какого-то автора С++ и целого анона с форума. Естественно анон лучше расскажет, как было на самом деле и что именл в виду автор))
	Ответить | Правка | Наверх | Cообщить модератору

	118. "Уязвимость в Musl, эксплуатируемая при перекодировании текст..."	+/–
	Сообщение от Аноним (118), 15-Фев-25, 12:45
	>Очень интересное мнение Это не мнение это факт. Страуструпа ни Томпсон, ни Ритчи не уговаривали, взять за основу C++, язык Си. Страуструп не умел писать компилятор, его первый компилятор С++ это надстройка над компилятором Си. Что умел то и налабал. Для Страуструпа важен был концепт ООП, а не то как он реализовал свой первый компилятор. И тем более в то время его не интересовали проблемы "неопределённого поведения".
	Ответить | Правка | К родителю #116 | Наверх | Cообщить модератору

	129. "Уязвимость в Musl, эксплуатируемая при перекодировании текст..."	+/–
	Сообщение от Аноним (116), 16-Фев-25, 10:59
	Да ну чушь же вы пишете. Интересовал бы концепт ООП и правильные идеи - разивавал бы Smalltalk. А его интересовало именно как имея все преимущества C, получить еще и ООП с сохранением всего этого.
	Ответить | Правка | Наверх | Cообщить модератору

	54. "Уязвимость в Musl, эксплуатируемая при перекодировании текст..."	+3 +/–
	Сообщение от _ (??), 14-Фев-25, 19:03
	>И этим портят репутацию нормальным плюсовикам. Смех в аудитории переходяший в откровенный ржач и LoL-ище :) А я то думал а в чём проблема С++ - а вот оно как! :)
	Ответить | Правка | К родителю #13 | Наверх | Cообщить модератору

	68. "Уязвимость в Musl, эксплуатируемая при перекодировании текст..."	+/–
	Сообщение от Аноним (-), 14-Фев-25, 19:22
	> Смех в аудитории переходяший в откровенный ржач Смех без причины - ну ты понял)) > А я то думал а в чём проблема С++ Причин может быть много, не? Я озвучил только одну из них, как раз в контексте абсолютно безграмотного наброса про некий язык "с/с++". Если хочешь обсудить проблемы современного с++, то можем сделать это в другой теме.
	Ответить | Правка | Наверх | Cообщить модератору

	26. "Уязвимость в Musl, эксплуатируемая при перекодировании текст..."	–1 +/–
	Сообщение от Аноним (22), 14-Фев-25, 17:01
	Ну да, а Rust простой и понятный, даёт легкочитаемый код.
	Ответить | Правка | К родителю #9 | Наверх | Cообщить модератору

	52. "Уязвимость в Musl, эксплуатируемая при перекодировании текст..."	+/–
	Сообщение от _ (??), 14-Фев-25, 19:01
	У него безопасТная работа в пямятью!(С)
	Ответить | Правка | Наверх | Cообщить модератору

	125. "Уязвимость в Musl, эксплуатируемая при перекодировании текст..."	+/–
	Сообщение от Аноним (125), 15-Фев-25, 22:44
	(TM)
	Ответить | Правка | Наверх | Cообщить модератору

	78. "Уязвимость в Musl, эксплуатируемая при перекодировании текст..."	+/–
	Сообщение от laindono (ok), 14-Фев-25, 19:31
	Ну да. Вполне себе. Можно сравнить что-то даже. Например вектор из стандартной библиотеки. https://github.com/gcc-mirror/gcc/blob/master/libstdc%2... https://doc.rust-lang.org/src/alloc/vec/mod.rs.html#397 В плюсовой версии происходит непонятная хтонь. В версии на расте есть свои нюансы, но там есть столько документации и комментариев, что не разберётся только тот, кто не умеет читать. Замечу, что стандартная библиотека - витрина языка.
	Ответить | Правка | К родителю #26 | Наверх | Cообщить модератору

	47. "Уязвимость в Musl, эксплуатируемая при перекодировании текст..."	+/–
	Сообщение от Аноним (47), 14-Фев-25, 18:43
	Как раз наоборот, они слишком примитивны и требуют писать слишком много кода чтобы добиться довольно скромных по нынешним временам результатов за приемлимое время. С — замечательный язык, если вас зовут Денис и вам нужно скрафтить «трёхнедельный юникс». Однако, глядя на гигантский проект Linux Kernel, мы можем видеть собственными глазами, насколько плохо С подходит для командной разработке в большой распределённой команде. Странным образом Танненбаум оказался прав, а Линус нет, но совершенно не в той плоскости в какой они спорили в своё время. Многих _организационных_ проблем проекта можно было бы избежать, отодвинь Линус эго в сторону и выбери микроядерную архитектуру. Но история не знает про сослагательное наклонение, и через тридцать с гаком лет проект страдает от того решения. Как именно страдает можно почитать в том числе и здесь.
	Ответить | Правка | К родителю #9 | Наверх | Cообщить модератору

	49. "Уязвимость в Musl, эксплуатируемая при перекодировании текст..."	+/–
	Сообщение от Аноним (-), 14-Фев-25, 18:52
	> Как раз наоборот, они слишком примитивны и требуют писать слишком много кода чтобы добиться довольно скромных по нынешним временам результатов за приемлимое время. А если зарплата почасовая ;) Но думаю вы правы оба - язык примитивны по возможностям, но сложный по всяким неочивидным какахам типа UB для сложения двух чисел. > С — замечательный язык, если вас зовут Денис и вам нужно скрафтить «трёхнедельный юникс». Или написать ядро на 10к строк) > Однако, глядя на гигантский проект Linux Kernel, мы можем видеть собственными глазами, насколько плохо С подходит для командной разработке в большой распределённой команде. Думаю тут дело не только в языке, но и в подходах. В современной разработке никому не придет в голову принимать и мерджить патч присланный по  почте (слава богу машине, не голубиной)). А потом осознавать что код тупо не компиляется. Тут будет куча CI, тестов, может линтер и тд > Странным образом Танненбаум оказался прав, а Линус нет, но совершенно не в той плоскости в какой они спорили в своё время. Многих _организационных_ проблем проекта можно было бы избежать, отодвинь Линус эго в сторону и выбери микроядерную архитектуру. Утверждение сомнительное, не уверен, что тогда бы линукс взлетел. Когда все начиналось было очень удобно наваливать код в огромную кучу. Я слабо представляю, как в почтовой рассылке обсуждать контракты для модулей, в перерывах отвлекаясь на срочное исправление color на colour.
	Ответить | Правка | Наверх | Cообщить модератору

	63. "Уязвимость в Musl, эксплуатируемая при перекодировании текст..."	+/–
	Сообщение от Аноним (53), 14-Фев-25, 19:15
	>В современной разработке никому не придет в голову принимать и мерджить патч присланный по  почте (слава богу машине, не голубиной)) Ядро до сих пор примерно так и пишут >Тут будет куча CI, тестов, может линтер и тд На всех линтеров не напасёшься. https://www.opennet.me/opennews/art.shtml?num=56449 >Опубликован набор патчей, ускоряющих сборку ядра Linux на 50-80% Сколько ещё разных проблем, не пойманных анализаторами - неизвестно >Утверждение сомнительное, не уверен, что тогда бы линукс взлетел. Популярности линукса способствовали: свободная лицензия, возвращающая наработки в апстрим, нежелание Таненбаума принимать патчи в миникс, позволяющие им нормально пользоваться, долгострой Hurd, который постоянно переписывался и не был пригоден для реального применения.
	Ответить | Правка | Наверх | Cообщить модератору

	73. "Уязвимость в Musl, эксплуатируемая при перекодировании текст..."	+/–
	Сообщение от Аноним (-), 14-Фев-25, 19:25
	> Популярности линукса способствовали Суд между BSDI и USL, а также тонны денег, которые были влиты в линукс, пока эти суды шли. Это была самая существенная причина. Все остальное мелочи. Особенно смешно про Hurd.
	Ответить | Правка | Наверх | Cообщить модератору

	84. "Уязвимость в Musl, эксплуатируемая при перекодировании текст..."	+/–
	Сообщение от Аноним (53), 14-Фев-25, 19:42
	>а также тонны денег, которые были влиты в линукс, пока эти суды шли. Деньги начали вливаться гораздо позже, чем была опубликована самая первая версия ядра, для начала ядру нужно было показать свою жизнеспособность. >Это была самая существенная причина. Все остальное мелочи Там было очень маленькое окно, условно в пару лет, в которое можно было запрыгнуть. Поторопись GNU, и деньги полились бы в Hurd. Или если бы кто-то написал свой аналог Minix-а.
	Ответить | Правка | Наверх | Cообщить модератору

	83. "Уязвимость в Musl, эксплуатируемая при перекодировании текст..."	+/–
	Сообщение от Аноним (4), 14-Фев-25, 19:35
	А куда тогда записывать тех, кто лабает на ассемблере? В восставших из мертвых?
	Ответить | Правка | К родителю #9 | Наверх | Cообщить модератору

	100. "Уязвимость в Musl, эксплуатируемая при перекодировании текст..."	+/–
	Сообщение от Аноним (-), 14-Фев-25, 20:57
	> А куда тогда записывать тех, кто лабает на ассемблере? Исключительно на ассемблере? > В восставших из мертвых? Тогда в красную книгу. С охранным статусом CR "Находящиеся на грани полного исчезновения" Где-то рядом с коболистами))
	Ответить | Правка | Наверх | Cообщить модератору

	133. "Уязвимость в Musl, эксплуатируемая при перекодировании текст..."	+/–
	Сообщение от Котофалк (?), 18-Фев-25, 13:49
	> Где-то рядом с коболистами)) Кобольдами же
	Ответить | Правка | Наверх | Cообщить модератору

	37. "Уязвимость в Musl, эксплуатируемая при перекодировании текст..."	+1 +/–
	Сообщение от Имя (?), 14-Фев-25, 17:45
	А что, на rust уже стало принято писать код без unsafe, и по этой причине ему стали не нужны все те же меры, что нужны коду на сишке?
	Ответить | Правка | К родителю #5 | Наверх | Cообщить модератору

	40. "Уязвимость в Musl, эксплуатируемая при перекодировании текст..."	+1 +/–
	Сообщение от Аноним (-), 14-Фев-25, 18:05
	> А что, на rust уже стало принято писать код без unsafe Вообще-то так всегда было. У них принято использовать unsafe только тогда, когда иначе написать невозможно. Собственно за это накидали в панамку истеричке-аффтору Actix - он пытался игнорировать правила использования unsafe (тут подробнее opennet.ru/opennews/art.shtml?num=52208) Многие либы используют атрибут #![forbid(unsafe_code)], который просто запрещает использование unsafe во всем крейте. А для карго есть cargo geiger, который проверяет все зависимости на наличие или отсутствие unsafe_code. Как результат - на середину 2024 года 80% пакетов не используют unsafe. opennet.ru/opennews/art.shtml?num=61251 Но есть ситуации когда ты его не имеешь права не использовать. Напр. при взаимодействии с чужим кодом через FFI.
	Ответить | Правка | Наверх | Cообщить модератору

	50. "Уязвимость в Musl, эксплуатируемая при перекодировании текст..."	–1 +/–
	Сообщение от Аноним (-), 14-Фев-25, 18:54
	Прикол с Растом в том, что если писать на нём прошивки, драйвера и прочие низкоуровневые вещи, то без unsafe блоков обойтить нельзя. И все преимущества безопасного языка улетучиваются. Тогда может возникнуть вопрос. А не проще ли сразу взять чистый Си.
	Ответить | Правка | Наверх | Cообщить модератору

	62. "Уязвимость в Musl, эксплуатируемая при перекодировании текст..."	+/–
	Сообщение от Аноним (-), 14-Фев-25, 19:14
	> то без unsafe блоков обойтить нельзя Да. И это абсолютно нормально. > И все преимущества безопасного языка улетучиваются. Нет, не улетучивается. У тебя unsafe код лежит отдельными кучками с большими предупредительными знаками, а не размазан равномерным слое по полу, стенам и так далее. Ну а то что кучек много... ну так это предметная область такая, ничего тут поделать нельзя. >  А не проще ли сразу взять чистый Си. Проще. А потом имеем что имеем)) Раст же это не столько safe и unsafe. Тот же боровинг и лайфтаймы проверяются и для unsafe code, если это не pointer'ы (которые по умолчанию unsafe). В расте есть нормальные типы, которые позволяют писать более строгий код.
	Ответить | Правка | Наверх | Cообщить модератору

	87. "Уязвимость в Musl, эксплуатируемая при перекодировании текст..."	+1 +/–
	Сообщение от Аноним (53), 14-Фев-25, 19:45
	В rust unsafe инкапсулирует разрушительный код. В си - любой код разрушительный, даже printf.
	Ответить | Правка | К родителю #50 | Наверх | Cообщить модератору

	57. "Уязвимость в Musl, эксплуатируемая при перекодировании текст..."	+/–
	Сообщение от _ (??), 14-Фев-25, 19:05
	>Как результат - на середину 2024 года 80% пакетов не используют unsafe. А то что вседи них нет _ни_одного_ системного, это ты скромно умолчал? А так то я согласен: JSON-ы с левой руки в правую можно в расте безопасТно перекладывать :)
	Ответить | Правка | К родителю #40 | Наверх | Cообщить модератору

	77. "Уязвимость в Musl, эксплуатируемая при перекодировании текст..."	+/–
	Сообщение от Аноним (53), 14-Фев-25, 19:30
	>А так то я согласен: JSON-ы с левой руки в правую можно в расте безопасТно перекладывать :) А вот на си - нельзя. Избавьте нас хотя-бы от ошибок в перекладывании json-ов и смены кодировки
	Ответить | Правка | Наверх | Cообщить модератору

	94. "Уязвимость в Musl, эксплуатируемая при перекодировании текст..."	+/–
	Сообщение от _ (??), 14-Фев-25, 20:07
	Если мне кто то предложит бизнес логику на Си писать - я его сам до мусоропровода провожу :) Впрочем системных ржавчиков - тоже, туда же :) (голосом генерала Михалыча) Ну! За консенсус!
	Ответить | Правка | Наверх | Cообщить модератору

	123. "Уязвимость в Musl, эксплуатируемая при перекодировании текст..."	+/–
	Сообщение от Аноним (53), 15-Фев-25, 22:41
	>Если мне кто то предложит бизнес логику на Си писать - я его сам до мусоропровода провожу :) Ага, только вот почему-то пишут. Тот же lxc, например.
	Ответить | Правка | Наверх | Cообщить модератору

	64. "Уязвимость в Musl, эксплуатируемая при перекодировании текст..."	+/–
	Сообщение от Аноним (64), 14-Фев-25, 19:17
	> он пытался игнорировать правила использования unsafe его проект, его правила. Его просто затравила толпа неспособных "правильных" фанатиков и троллей. Прям то достижение, которым надо гордиться
	Ответить | Правка | К родителю #40 | Наверх | Cообщить модератору

	85. "Уязвимость в Musl, эксплуатируемая при перекодировании текст..."	+/–
	Сообщение от Аноним (-), 14-Фев-25, 19:44
	> Его просто затравила толпа неспособных "правильных" фанатиков и троллей. "Фанатики" и "тролли" ему присылали патчи с исправлением проблем, но он их не принял потому что они "были слишком скучные" > Прям то достижение, которым надо гордиться Да, это достижение. Сообщество показало, что  ̶т̶е̶б̶е̶ ̶с̶ ̶н̶а̶м̶и̶ ̶н̶е̶ ̶п̶о̶ ̶д̶о̶р̶о̶г̶е̶,̶ ̶г̶р̶я̶з̶н̶ы̶й̶ ̶о̶в̶ц̶е̶е̶б̶!̶ такие быдлокодеры ему не нужны. Пусть катится писать на сишке, там таких любят.
	Ответить | Правка | Наверх | Cообщить модератору

	93. "Уязвимость в Musl, эксплуатируемая при перекодировании текст..."	+/–
	Сообщение от Аноним (64), 14-Фев-25, 20:05
	> ему присылали патчи с исправлением проблем, но он их не принял потому что они "были слишком скучные" это его проект, его право. Пусть хоть настроения не было > Сообщество показало, что оно, мягко говоря, не совсем здорово
	Ответить | Правка | Наверх | Cообщить модератору

	42. "Уязвимость в Musl, эксплуатируемая при перекодировании текст..."	+/–
	Сообщение от Аноним (42), 14-Фев-25, 18:29
	> стоит сосредоточиться на улучшении инструментов для C ...языку шел шестой десяток.
	Ответить | Правка | К родителю #5 | Наверх | Cообщить модератору

	61. "Уязвимость в Musl, эксплуатируемая при перекодировании текст..."	+/–
	Сообщение от _ (??), 14-Фев-25, 19:07
	>> стоит сосредоточиться на улучшении инструментов для C >...языку шел шестой десяток. Вечные ценности(С) Ваш то <куль_ЯП_наме> уже все забывать начали небось? :)
	Ответить | Правка | Наверх | Cообщить модератору

	76. "Уязвимость в Musl, эксплуатируемая при перекодировании текст..."	+1 +/–
	Сообщение от Аноним (53), 14-Фев-25, 19:28
	Так сишники теорию не знают. Они до сих пор не знают ни про аффиные типы, ни про зависимые, ни про кучу других вещей.
	Ответить | Правка | К родителю #42 | Наверх | Cообщить модератору

	92. "Уязвимость в Musl, эксплуатируемая при перекодировании текст..."	+1 +/–
	Сообщение от _ (??), 14-Фев-25, 20:03
	А те кто про них знает - программировать не умеют :) Вот так и живём :)
	Ответить | Правка | Наверх | Cообщить модератору

	51. "Уязвимость в Musl, эксплуатируемая при перекодировании текст..."	+/–
	Сообщение от Аноним (-), 14-Фев-25, 19:00
	> Вот почему стоит сосредоточиться на улучшении инструментов для C/C++, таких как статический и динамический анализ кода, Address Space Layout Randomization и Data Execution Prevention, Напомни когда СИ был представлен? Или хотя бы стандартизирован? Почему это не было сделано раньше, а шевелиться начали только когда появились какие-то смузихлебы с новым модным языком? Фигня в том, что им было пофигу. На ошибки, на постоянные CVE. Они просто говорили "мы так привыкли, идите отсюдова". И люди шли, на джаву, сишарп, котлин и прочие языки которые заменили СИшку практически во всех областях. С С++ ситуация немного лучше - там добавили smartpointer'ы и прочие блага цивилизации. Надеюсь они смогут внедрить модули и хотя бы часть из планов по Safe-C++
	Ответить | Правка | К родителю #5 | Наверх | Cообщить модератору

	107. "Уязвимость в Musl, эксплуатируемая при перекодировании текст..."	+/–
	Сообщение от Аноним (106), 15-Фев-25, 04:59
	>Надеюсь они смогут внедрить модули и хотя бы часть из планов по Safe-C++ Зачем нам модули? Модули это чисто Паскалевская тема.
	Ответить | Правка | Наверх | Cообщить модератору

	55. "Уязвимость в Musl, эксплуатируемая при перекодировании текст..."	–1 +/–
	Сообщение от Аноним (53), 14-Фев-25, 19:04
	Си, кресты и ржавчину давным давно пора закопать. В системном языке программирования обязаны присутствовать не только афинные типы, но и зависимые.
	Ответить | Правка | К родителю #5 | Наверх | Cообщить модератору

	80. "Уязвимость в Musl, эксплуатируемая при перекодировании текст..."	+/–
	Сообщение от Аноним (-), 14-Фев-25, 19:31
	> В системном языке программирования обязаны присутствовать > не только афинные типы, но и зависимые. Ты шутишь? Типикал сишники даже аффинные типы не осилили, в расте линейных нет (хотя есть крейты), а ты зависимые предлагаешь! Хотя я только за. Еще бы и формальную верификацию для всех mission critical приложений.
	Ответить | Правка | Наверх | Cообщить модератору

	96. "Уязвимость в Musl, эксплуатируемая при перекодировании текст..."	+/–
	Сообщение от _ (??), 14-Фев-25, 20:11
	Ваша проблема в том, что вы только трепаться горазды :) Возьми и сделай! Нарду понравится - дольше сами наперегонки побегут. Но вы не про сделать, вы про по-скулить... :)
	Ответить | Правка | Наверх | Cообщить модератору

	99. "Уязвимость в Musl, эксплуатируемая при перекодировании текст..."	+1 +/–
	Сообщение от Аноним (-), 14-Фев-25, 20:38
	> Возьми и сделай! Так мы уже сделали. И народу понравилось. А в ответ получаем "вы не заставите меня учить раст!", "мне не нужен второй мейнтейнер" и прочее от дидов.
	Ответить | Правка | Наверх | Cообщить модератору

	110. "Уязвимость в Musl, эксплуатируемая при перекодировании текст..."	+/–
	Сообщение от _ (??), 15-Фев-25, 05:42
	>Так мы уже сделали. И народу понравилось. У вас повреждение моска? Если бы понравилось народу то: > А в ответ получаем "вы не заставите меня учить раст!", Ух как понравилось! Люто! Вот не помню чтоб кто то орал Вы не заставите меня учить Си! :) > "мне не нужен второй мейнтейнер" и прочее от дидов. Правильно, он один в одиночку тянет больше чем все ржавчики на планете ... ну вот нах вы ему? Подгузники менять? Ну такое ...
	Ответить | Правка | Наверх | Cообщить модератору

	130. "Уязвимость в Musl, эксплуатируемая при перекодировании текст..."	+/–
	Сообщение от Прохожий (??), 17-Фев-25, 11:19
	>>Так мы уже сделали. И народу понравилось. >У вас повреждение моска? Rust - один из самых любимых языков программирования согласно опросам на Stackoverflow. >Ух как понравилось! Люто! Вот не помню чтоб кто то орал Вы не заставите меня учить Си! :) Есть и такие. Например, те, кто пишет ПО для бизнеса. Там долгое время Java с C# рулили. Как сейчас - не знаю. У вас, как не одна крайность, так другая. То вам кажется, что абсолютно все не любят Rust (вы судите исключительно по мнению нескольких людей), то вам кажется, что все любят C. >Правильно, он один в одиночку тянет больше чем все ржавчики на планете Как выясняется, не тянет уже. Период максимальной продуктивности давно пройден. Осталось только тёплое местечко, которое в любой момент могут выбить из-под ожиревшей задницы. Вот человек и истерит, вместо того, чтобы просто освоить более совершенный язык программирования.
	Ответить | Правка | Наверх | Cообщить модератору

	91. "Уязвимость в Musl, эксплуатируемая при перекодировании текст..."	+/–
	Сообщение от _ (??), 14-Фев-25, 20:02
	Возможно. Но - ты не сможешь! :)
	Ответить | Правка | К родителю #55 | Наверх | Cообщить модератору

8. "Уязвимость в Musl, эксплуатируемая при перекодировании текст..."	+4 +/–
Сообщение от Аноним (-), 14-Фев-25, 16:15
+    /* This failure condition should be unreachable, but +     * is included to prevent decoder bugs from translating +     * into advancement outside the output buffer range. */ +    if (k>4) goto ilseq; Это failure condition должно было быть unreachable, но что-то пошло не так (опять)... -    if (c >= 93 || c>=0xc6-0x81 && d>0x52) +    if (c > 0xc6-0x81 || c==0xc6-0x81 && d>0x52)                     goto ilseq; В этом коде прекрасно все! Просто иллюстрация мема "Damn Bitch, You Live Like This?" в жизни))
Ответить | Правка | Наверх | Cообщить модератору

	12. "Уязвимость в Musl, эксплуатируемая при перекодировании текст..."	+2 +/–
	Сообщение от Уууууъъъ (?), 14-Фев-25, 16:21
	Думаешь, что так было бы лучше? const int THRESHOLD_C = 0x45; // 0xc6 - 0x81 const int THRESHOLD_D = 0x52; if (c > THRESHOLD_C || (c == THRESHOLD_C && d > THRESHOLD_D))
	Ответить | Правка | Наверх | Cообщить модератору

	16. "Уязвимость в Musl, эксплуатируемая при перекодировании текст..."	+/–
	Сообщение от Аноним (6), 14-Фев-25, 16:34
	> Думаешь, что так было бы лучше? Немного, но не слишком. Там должно быть не THRESHOLD_C, а нормальный неминг что это за plane или символы и пояснение почем от сих и до сих оно не конвертируется. А так получается куча magic numbers.
	Ответить | Правка | Наверх | Cообщить модератору

	17. "Уязвимость в Musl, эксплуатируемая при перекодировании текст..."	+2 +/–
	Сообщение от Аноним (-), 14-Фев-25, 16:38
	Думаю да. Как минимум все магически константы именованы. И избавились от 0xc6 - 0x81. Ошибиться и написать 0xc7 - 0x83 стало сложнее. Но я верю в способности пограммистов))
	Ответить | Правка | К родителю #12 | Наверх | Cообщить модератору

	86. "Уязвимость в Musl, эксплуатируемая при перекодировании текст..."	+/–
	Сообщение от Аноним (4), 14-Фев-25, 19:44
	Сложно пишете, непонятно! Вот  так надо: &НаКлиенте Процедура ПрибавитьМесяц(Команда) ПрибавитьМесяцНаСервере(); КонецПроцедуры &НаСервере Процедура ПрибавитьМесяцНаСервере() Запрос = Новый Запрос; Запрос.Текст = "ВЫБРАТЬ |          ДОБАВИТЬКДАТЕ(ДАТАВРЕМЯ(2020, 3, 30), МЕСЯЦ, 1) КАК СледующийМесяц"; РезультатЗапроса = Запрос.Выполнить(); ВыборкаДетальныеЗаписи = РезультатЗапроса.Выбрать(); Пока ВыборкаДетальныеЗаписи.Следующий() Цикл Дата = ВыборкаДетальныеЗаписи.СледующийМесяц; КонецЦикла; Сообщить(Дата); КонецПроцедуры
	Ответить | Правка | Наверх | Cообщить модератору

	114. "Уязвимость в Musl, эксплуатируемая при перекодировании текст..."	+/–
	Сообщение от Аноним (-), 15-Фев-25, 09:08
	Ужас русского программиста.
	Ответить | Правка | Наверх | Cообщить модератору

	58. "Уязвимость в Musl, эксплуатируемая при перекодировании текст..."	+/–
	Сообщение от Аноним (-), 14-Фев-25, 19:05
	> Это failure condition должно было быть unreachable, но что-то пошло не так (опять)... Одна из фишек раста -- это макрос unreachable!(), который говорит компилятору, что код unreachable, но в дебаге компилятор всё же выполняет проверку и втыкает панику. Ты не представляешь, как познавательно ловить паники вида reached unreachable код. Такого рода паника позволяет видеть, как думал программист, который вписал unreachable, а git bitsect позволяет понять, как думал программист, который сломал недостижимость кода. В большинстве случаев, второй просто не думал о недостижимости, он в каком-то совершенно другом месте программы что-то правил, а недостижимость сломалась здесь. Собственно баг выше как раз такую ситуацию и демонстрирует. Без unreachable!() всё не так интересно. Во-первых, паника не случается, и ошибка может оставаться незамеченной годами, во-вторых, когда ошибка замечена и даже локализована, непонятно чем думал программист, когда оставил какое-то условие непроверенным. Исправить баг это не мешает, но нисколько не учит тому, где лежат грабли, и как бы так на них не наступить. > В этом коде прекрасно все! Это работа с чарами и их диапазонами. Если тебе эти числа ничего не говорят, то зачем ты смотришь в код?
	Ответить | Правка | К родителю #8 | Наверх | Cообщить модератору

	69. "Уязвимость в Musl, эксплуатируемая при перекодировании текст..."	+/–
	Сообщение от Аноним (-), 14-Фев-25, 19:22
	>> Это failure condition должно было быть unreachable, но что-то пошло не так (опять)... > Одна из фишек раста -- это макрос unreachable!(), Хм.. на раст код не похож. Так что твое замечание познавательно, но не более. Наверное твой макрос нужен только неопытным програмистам, а вот настоящие СИшники могут и без него) > Это работа с чарами и их диапазонами. Если тебе эти числа ничего не говорят, то зачем ты смотришь в код? В том то и дело что значат. И я бы это кон не писал тяп ляп. Я бы сделал константные переменные и добавил комментарий почему и зачем.
	Ответить | Правка | Наверх | Cообщить модератору

	88. "Уязвимость в Musl, эксплуатируемая при перекодировании текст..."	+/–
	Сообщение от Аноним (88), 14-Фев-25, 19:49
	> Хм.. на раст код не похож. Так что твое замечание познавательно, но не более. Это ты верно подметил, я чисто для познавательных целей и писал это. Более того, он коммент о познавательности использования unreachable!(). > Наверное твой макрос нужен только неопытным програмистам, а вот настоящие СИшники могут и без него) Может быть, но проблема в том, что опытный программист отличается от неопытного только тем, что он громче падает. У сишников просто голова дубовая, им не страшно по лбу граблями получать. > Я бы сделал константные переменные и добавил комментарий почему и зачем. Если кому-то нужны комментарии почему и зачем, значит им эти числа ни о чём не говорят, а значит прежде чем лезть своими грязными ручками в код, им следует сделать RTFM. Я тоже был большим фанатом комментариев, но последнее время я начинаю подозревать, что комментарии нужны только документационные и только для тех, кто использует код извне через внешний API. Вот этот API должен быть документирован. А всё остальное комментировать противопоказано, потому что комменты создают иллюзию понимания кода, и потом человек с ложной самоуверенностью начинает менять его, не понимая всех нюансов, а страдают от этого все. Специально запутывать код не стоит и стоит стремиться к простоте кода, но в ситуациях типа этой, когда от сложных условий никуда не деться, комментарии вредны. Человеку следует как следует курить этот код и документацию, до тех пор пока код не станет кристально ясным без комментариев, и только после этого ему можно приступать к правкам. Комменты могут быть полезны если ты описываешь там инварианты или ещё какие-то базовые положения, поверх которых код построен. Можно между делом упомянуть название используемого алгоритма и его автора, чтобы легко можно было бы найти статью и почитать, если очень нужно. Стоит тогда уж упомянуть и модификации алгоритма, которые ты привнёс. Но писать комментарии, типа "тут мы сравниваем с константой объявленной в <как там дока на стандарт utf8 называется?>" -- излишне совершенно.
	Ответить | Правка | Наверх | Cообщить модератору

	90. "Уязвимость в Musl, эксплуатируемая при перекодировании текст..."	+/–
	Сообщение от Аноним (-), 14-Фев-25, 20:01
	> А всё остальное комментировать противопоказано, потому что комменты создают иллюзию > понимания кода, и потом человек с ложной самоуверенностью начинает менять его, > не понимая всех нюансов, а страдают от этого все. С одной стороны это так. С другой - комментарии как раз могут указывать на неочевидные нюансы. Потому что в своей практике очень часто встречал код, в котором абсолютно понятно "что" он делает, но не понятно "зачем". Обычно это какая-то бизнес-логика, и найти причины принятия решения по тому или иному поведению тот еще челлендж. > Но писать комментарии, типа "тут мы сравниваем с константой > объявленной в <как там дока на стандарт utf8 называется?>" -- излишне совершенно. Но как минимум будет название стандарта (можно еще № страницы указать или параграфа). И при баге в таком коде первое что сделают - пойдут в стандарт и сверят константы.
	Ответить | Правка | Наверх | Cообщить модератору

	97. "Уязвимость в Musl, эксплуатируемая при перекодировании текст..."	+/–
	Сообщение от Аноним (-), 14-Фев-25, 20:16
	> Потому что в своей практике очень часто встречал код, в котором абсолютно понятно "что" он делает, но не понятно "зачем". Обычно это какая-то бизнес-логика, и найти причины принятия решения по тому или иному поведению тот еще челлендж. Для этого есть git blame и история git в целом. Комменты редко в таких случаях помогают, потому что они имеют тенденцию устаревать и не соответствовать действительности. История же изменений кода часто позволяет понять предназначение кода даже в тех случаях, когда комменты к коммитам абсолютно неадекватны. Если же всё не так плохо, то ты найдёшь все ответы в сообщениях к коммитам, и много чего ещё найдёшь, о чём даже не задумывался. Мало того, иногда есть возможность связаться с автором изменений и потрясти его, чтобы узнать что именно он думал, когда писал код, и может даже получить консультацию на тему того, как лучше внести в этот код те модификации, которые ты хочешь внести. > И при баге в таком коде первое что сделают - пойдут в стандарт и сверят константы. Если им надо сверять константы, то им нечего делать в этом коде. Не, ну вот например, в досе часто попадалась команда int 21h. Если человек не понимает, что это вызов прерывания доса, то ему следует отправляться читать документацию, причём не какую-то страницу или параграф, а начиная с заголовка и заканчивая указанием типографии, где эта документация печаталась. Константам нужны символические имена тогда, когда есть хотя бы малейший шанс на то, что константа может измениться. Им нужны символические имена тогда, когда эти константы были придуманы программистом. Им нужны имена тогда, когда эти имена короче, чем константа (M_PI, например, короче чем перечисление всех десятичных знаков). Возможны всякие другие ситуации, но эта не подпадает ни под одну из них. Константы фиксированы стандартом, более того, здесь используются не они, а производные от них, в стандарте указаны 32-х битные значения, здесь же 8-битные. Создание констант под каждое значение байта займёт больше места, чем сам кодер/декодер utf8. Использование же этих констант в коде кодера/декодера, раздует его размер в разы. Сомнительное повышение читабельности кода, не так ли?
	Ответить | Правка | Наверх | Cообщить модератору

	131. "Уязвимость в Musl, эксплуатируемая при перекодировании текст..."	+/–
	Сообщение от Прохожий (??), 17-Фев-25, 11:33
	>Для этого есть git blame и история git в целом. Комменты редко в таких случаях помогают, потому что они имеют тенденцию устаревать и не соответствовать действительности. Что проще: прочитать один комментарий или перелопачивать историю комитов? А комменты надо просто поддерживать в актуальном состоянии. >Мало того, иногда есть возможность связаться с автором изменений и потрясти его, чтобы узнать что именно он думал, когда писал код, и может даже получить консультацию на тему того, как лучше внести в этот код те модификации, которые ты хочешь внести. Иногда автор сам не помнит, зачем он это сделал. И только адекватные комментарии помогают.
	Ответить | Правка | Наверх | Cообщить модератору

	79. "Уязвимость в Musl, эксплуатируемая при перекодировании текст..."	+/–
	Сообщение от Аноним (53), 14-Фев-25, 19:31
	>это макрос unreachable!(), который говорит компилятору, что код unreachable Зависимые типы не изобретены, а компилятор сам не догадается.
	Ответить | Правка | К родителю #58 | Наверх | Cообщить модератору

14. "Уязвимость в Musl, эксплуатируемая при перекодировании текст..."	–4 +/–
Сообщение от ИмяХ (ok), 14-Фев-25, 16:23
musl-0.9.13 Вышла 30 августа 2013 года То есть внедрённый бекдор заметили лишь спустя 12 лет. Вот вам и безопасный опенсорс. Вот вам и тысячи глаз.
Ответить | Правка | Наверх | Cообщить модератору

	18. "Уязвимость в Musl, эксплуатируемая при перекодировании текст..."	+/–
	Сообщение от Аноним (-), 14-Фев-25, 16:41
	Щас набигут фанаты и ответят: 0. Это не бекдор, все ошибаются! 1. Зато же нашли! Значит 100500 глаз работают. 2. А что в вашей проприетаре лучше? 3. .....
	Ответить | Правка | Наверх | Cообщить модератору

	24. "Уязвимость в Musl, эксплуатируемая при перекодировании текст..."	+3 +/–
	Сообщение от Аноним (25), 14-Фев-25, 16:59
	Вот видишь даже сам понимаешь что все в порядке.
	Ответить | Правка | Наверх | Cообщить модератору

	32. "Уязвимость в Musl, эксплуатируемая при перекодировании текст..."	+/–
	Сообщение от Аноним (32), 14-Фев-25, 17:13
	Неа, это не нормально. Я это взял из книжки "100500 отмазок почему овнякод это хорошо", написанное 'настоящими программистами'))
	Ответить | Правка | Наверх | Cообщить модератору

	30. "Уязвимость в Musl, эксплуатируемая при перекодировании текст..."	+3 +/–
	Сообщение от Пользователь Чебурнета (?), 14-Фев-25, 17:08
	> musl-0.9.13 Вышла 30 августа 2013 года > То есть внедрённый бекдор заметили лишь спустя 12 лет. Вот вам и > безопасный опенсорс. Вот вам и тысячи глаз. Ага, уязвимость в кодировке лохматого года для корейского языка, которой на 2013 год уже не пользовались сами корейцы -- это мега-опасная дыра, поставившая под угрозу существование человечества. Нужно срочно спасать галактику! :-)))))
	Ответить | Правка | К родителю #14 | Наверх | Cообщить модератору

	35. "Уязвимость в Musl, эксплуатируемая при перекодировании текст..."	+/–
	Сообщение от Аноним (32), 14-Фев-25, 17:26
	Ага, ведь северокорейских хакеров не существует! Это все придумки капиталистических южан. И вообще наш Ын няшка и его народ любит!!
	Ответить | Правка | Наверх | Cообщить модератору

	124. "Уязвимость в Musl, эксплуатируемая при перекодировании текст..."	+/–
	Сообщение от Аноним (124), 15-Фев-25, 22:43
	Ну предположим существуют Но кого они ЭТИМ будут ломать? Кодировка мертвая, да еще и «уязвимость» в мюслях Страшно представить как долго они будут искать кого бы так сломать
	Ответить | Правка | Наверх | Cообщить модератору

15. "Уязвимость в Musl, эксплуатируемая при перекодировании текст..."	–5 +/–
Сообщение от Аноним (15), 14-Фев-25, 16:24
Неужели столмановский libc лутше этого? libc же сильно луддитный, как говорит молодежь!
Ответить | Правка | Наверх | Cообщить модератору

19. "Уязвимость в Musl, эксплуатируемая при перекодировании текст..."	+1 +/–
Сообщение от Аноним (19), 14-Фев-25, 16:43
Дыра, нацеленная на корейцев?
Ответить | Правка | Наверх | Cообщить модератору

	20. "Уязвимость в Musl, эксплуатируемая при перекодировании текст..."	+2 +/–
	Сообщение от Аноним (6), 14-Фев-25, 16:54
	> Дыра, нацеленная на корейцев? 146%! Не пробегал ли там Jin Tan? Надо бы проверить))
	Ответить | Правка | Наверх | Cообщить модератору

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

	29. "Уязвимость в Musl, эксплуатируемая при перекодировании текст..."	+/–
	Сообщение от Аноним (22), 14-Фев-25, 17:06
	Если начнут рассылать письма куда угодно с указанной в заголовке с MIME-типом (например, "text/plain; charset=EUC-KR"), то всем прилетит.
	Ответить | Правка | Наверх | Cообщить модератору

	39. "Уязвимость в Musl, эксплуатируемая при перекодировании текст..."	+/–
	Сообщение от Пользователь Чебурнета (?), 14-Фев-25, 17:56
	> Если начнут рассылать письма куда угодно с указанной в заголовке с MIME-типом > (например, "text/plain; charset=EUC-KR"), то всем прилетит. У 99% не-корейцев такое сразу попадёт в спам, откуда будет удалено без открытия. У тех, кто всё же попытается открыть, если там вообще муслик в качестве системной библиотеки будет вместо глибцы, максимум вылетит браузер или почтовый клиент.
	Ответить | Правка | Наверх | Cообщить модератору

	98. "Уязвимость в Musl, эксплуатируемая при перекодировании текст..."	+1 +/–
	Сообщение от _ (??), 14-Фев-25, 20:17
	Никому не прилетит! Ибо xpен ты в живой природе встретишь какой нить MUA и musl в одном флаконе :) Так что накидывайте тщательнее спасатели галактоГо! ;-)
	Ответить | Правка | К родителю #29 | Наверх | Cообщить модератору

	127. "Уязвимость в Musl, эксплуатируемая при перекодировании текст..."	+/–
	Сообщение от Аноним (125), 15-Фев-25, 22:58
	Alpine, PostmarketOS, да и в OpenWRT, вдруг, найдётся какой-нибудь mutt.
	Ответить | Правка | Наверх | Cообщить модератору

44. "Уязвимость в Musl, эксплуатируемая при перекодировании текст..."	+/–
Сообщение от Аноним (-), 14-Фев-25, 18:38
>EUC-KR Чо за кодировка такая? Какой негодяй в 2025 году не перешёл на Unicode?
Ответить | Правка | Наверх | Cообщить модератору

	102. "Уязвимость в Musl, эксплуатируемая при перекодировании текст..."	+3 +/–
	Сообщение от чатжпт (?), 14-Фев-25, 22:04
	зачем далеко ходить, opennet: <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=koi8-r"> (рукалицо.jpg)
	Ответить | Правка | Наверх | Cообщить модератору

59. "Уязвимость в Musl, эксплуатируемая при перекодировании текст..."	+/–
Сообщение от Аноним (53), 14-Фев-25, 19:07
Сишники вместе с плюсовиками не умеют работать не только с форматами данных типа json и xml, но и с кодировками.
Ответить | Правка | Наверх | Cообщить модератору

101. "Уязвимость в Musl, эксплуатируемая при перекодировании текст..."	+/–
Сообщение от чатжпт (?), 14-Фев-25, 21:41
шел 2025 год, сишники всё еще продолжали скакать по граблям xD хотя бы уже на zig переходили, позорище какое-то
Ответить | Правка | Наверх | Cообщить модератору

	104. "Уязвимость в Musl, эксплуатируемая при перекодировании текст..."	+/–
	Сообщение от Аноним (53), 15-Фев-25, 00:51
	Для языка, не привносящего ничего нового в плане типов у него слишком долго нет стабильной версии
	Ответить | Правка | Наверх | Cообщить модератору

120. "Уязвимость в Musl, эксплуатируемая при перекодировании текст..."	+/–
Сообщение от Аноним (120), 15-Фев-25, 14:30
я помню много проектов, которые начинались как musl, типа деды переусложняли код, понять невозможно.Так начинался MySQL, wayland и даже гуглохром. В итоге эти проекты неизменно становятся тем, против кого выступаали.
Ответить | Правка | Наверх | Cообщить модератору

	121. "Уязвимость в Musl, эксплуатируемая при перекодировании текст..."	+/–
	Сообщение от Аноним (-), 15-Фев-25, 14:46
	> я помню много проектов, которые начинались как musl, типа деды переусложняли код, понять невозможно. А это была не правда)? > Так начинался MySQL, wayland и даже гуглохром. В итоге эти проекты неизменно становятся тем, против кого выступаали. Э...? Может они и стали сложными, но дают гораздо больше возможностей. MySQL стал фактически стандартом, до появления новых БД. Wayland это отличный пример как надо делать: выкинули все, добавляем только необходимое (а не всякую чушь типа сетевой прозрачности) Хром - это наверное один из самых успешных проектов в мире, по кол-ву пользователей.
	Ответить | Правка | Наверх | Cообщить модератору

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

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