forum.opennet.ru - "Уязвимось в Glibc, позволяющая вызвать крах чужого процесса" (128)

"Уязвимось в Glibc, позволяющая вызвать крах чужого процесса"

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

"Уязвимось в Glibc, позволяющая вызвать крах чужого процесса"	+/–
Сообщение от opennews (??), 17-Авг-21, 08:52
В Glibc выявлена уязвимость (CVE-2021-38604), дающая возможность инициировать крах процессов в системе через отправку специально оформленного сообщения через POSIX message queues API. В дистрибутивах проблема не успела проявиться, так как присутствует только в выпуске 2.34, опубликованном две недели назад... Подробнее: https://www.opennet.dev/opennews/art.shtml?num=55646
Ответить \| Правка \| Cообщить модератору

Оглавление

Призываю в тред всех тех кто отписывался по поводу недавней уязвимости в стандар, Аноним (1), 08:52 , 17-Авг-21, (1) +8

Скрыто модератором, Аноним (3), 08:53 , 17-Авг-21, (3) –14

Скрыто модератором, Аноним (30), 09:58 , 17-Авг-21, (30) –5

Скрыто модератором, Аноним (63), 12:07 , 17-Авг-21, (63) +5
Скрыто модератором, Аноним (70), 13:09 , 17-Авг-21, (70) +6

Скрыто модератором, Аноним (71), 13:15 , 17-Авг-21, (71)

Скрыто модератором, Аноним (75), 13:26 , 17-Авг-21, (75) +3

Никто не будет говорить, что это другое Во всех языках могут быть уязвимости,, Аноним (7), 08:58 , 17-Авг-21, (7) +3

Ты что если перекрыть один из тысячи векторов ошибок язык мгновенно становится б, Аноним (17), 09:24 , 17-Авг-21, (17) +1

Ну, допустим, три четверти уязвимостей приходятся на этот один из тысячи векторо, Аноним (30), 09:54 , 17-Авг-21, (29)

Допустим одна из тысячи уязвимостей приходится на это вектор , Аноним (33), 10:04 , 17-Авг-21, (33) –2

Допустим, еще и 749 тоже В сумме как раз 750 получается , Аноним (30), 10:42 , 17-Авг-21, (39)

Ага, а вы помнити seg fault , another_one (ok), 09:03 , 17-Авг-21, (8) –2
Хаха, да ладно не будут Что же скажет Хан, Урри, Онаним, пох, нах , стоп, послед, Аноним (1), 09:08 , 17-Авг-21, (10) +6

Им пофиг на glibc, у них systemd32 dll, в которой дыр нет , Аноним (30), 09:49 , 17-Авг-21, (26) +6
Урри скажет, что рукожопы У Урри его сишный код уже много лет не падал, хотя кр, Урри (ok), 11:16 , 17-Авг-21, (48) –2

Потому что сишечки не позиционируют себя как безопасный езычог , Онаним (?), 09:10 , 17-Авг-21, (12) –6

Ну, всяко побезопаснее хруста, на котором даже за границы буфера фиг выйдешь , Аноним (30), 09:51 , 17-Авг-21, (27) –3
Так и хруст не позиционируется как супербезопасный Он позиционируется как норма, Аноним (30), 10:54 , 17-Авг-21, (43)

А, ну раз он позиционируется как нормальный, как и множество других, то нах он т, Аноним (70), 13:17 , 17-Авг-21, (72)
Нормальный С таким синтаксисом Хера себе у вас нормальность C позиционируется , Онаним (?), 00:02 , 20-Авг-21, (157)

В про то что была уязвимость и твоём святом растике, ты не написал Какой же ты , Аноним (17), 09:22 , 17-Авг-21, (15) –2

А на раст мне пофиг - я на нем не пишу У Го нет такого пункта в продвижении как, Аноним (1), 09:30 , 17-Авг-21, (19) +3

Ну, все более-менее в курсе, что там нельзя просто взять и переполнить буфер А э, Аноним (30), 10:55 , 17-Авг-21, (44) –1

Легко и просто Сишники, пишущие либси а не орут на каждом углу, что борроу чеке, Dzen Python (ok), 11:18 , 17-Авг-21, (49) –1

ну допустим а не проверять на NULL перед разыменованием это чей уровень чувако, Аноним (1), 11:49 , 17-Авг-21, (58) +4
В принципе, достаточно, чтобы составить мнение о квалификации очередного онал, Аноним (-), 14:48 , 17-Авг-21, (97) +1
Это шикарно Снимаю шляпу Молодец, красиво и верно Я даже себе запишу , Аноним (118), 18:49 , 17-Авг-21, (118) +1
Ну вы же ничего не знаете о той ситуации и делаете прямо противоположные реально, freecoder (ok), 22:55 , 17-Авг-21, (125) +3
Мне как пользователи софта вообще накласть, что дам думают сишники и иже с ними , Брат Анон (ok), 12:21 , 18-Авг-21, (134)

Кстати, там и в самом деле другое, причем как раз еще больше _не_ в пользу сишеч, Аноним (55), 11:36 , 17-Авг-21, (55) +5
Потому что есть такое понятие как дискретный контроль доступа DAC и в некоторы, Аноним (96), 14:47 , 17-Авг-21, (96) –3

Вы новость прочитали ПРОЦЕССЫ ПАДАЮТ И меня как пользователя совершенно не уст, Брат Анон (ok), 12:27 , 18-Авг-21, (136) +1

Го это си для вебмакак Они одинаковы , Аноним (128), 01:32 , 18-Авг-21, (128) –2

Лол, хорошо что успеши обнаружитьарчегосподин с 2 33 версия гну библеотек, Аноним (3), 08:52 , 17-Авг-21, (2) –6

так торопился упомянуть любимый рачик, что и на подсветку орфографии не обратил , Аноним (9), 09:05 , 17-Авг-21, (9) –6

Не спал долго просто, а што чем тебе рач не нравиться ниасилил, да , Аноним (3), 09:09 , 17-Авг-21, (11) –5

возможно не осилить pacman -S base , макпыф (ok), 09:16 , 17-Авг-21, (13) –3

Исходя из того количетсво пользователей что сидят на бомжару, думаю что дамимоАр, Аноним (3), 09:21 , 17-Авг-21, (14) –3

Мне вот -- невменяемостью рачешкольников любого возраста, пытающихся впарить ЭТО, Michael Shigorin (ok), 14:08 , 17-Авг-21, (89) –1

Гентушникам не только вики потеряли, а и сами цели дистра поменяли Генто сегодн, Аноним (96), 14:51 , 17-Авг-21, (99)
Михаил, раб божий, Вы то, что этом треде потеряли Лучше идите домой , Аноним (-), 19:02 , 17-Авг-21, (121) –1
Даю руб за два, что михаэль один из срущих анонимов Аргументация соответствующе, Аноним (123), 21:42 , 17-Авг-21, (123) –2

Я бы то же обмазывался бы будь они у меня Архитектура интересная, и духовная , Аноньимъ (ok), 23:52 , 17-Авг-21, (127) +1

а вам мне напоминает некого свидетеля альта который тут во всех трэдах по поводу, муу (?), 19:12 , 20-Авг-21, (160)

Первым пунктом из свода правил Арчеводов Сообщи всем, что у тебя Арч , анонн (ok), 14:51 , 17-Авг-21, (100) +6

Пытались пофиксить одну дыру и в процессе создали другую побольше Это бывает С, Какаянахренразница (ok), 08:56 , 17-Авг-21, (5) +8

Ктулху фтанг , Брат Анон (ok), 12:29 , 18-Авг-21, (137) +2

Мда Поспешное исправление ошибки - лучший способ сделать новую , Stanislav (??), 08:58 , 17-Авг-21, (6) +6

Ну да, not a bug, конечно, лучше , Аноним (70), 13:33 , 17-Авг-21, (80) –3

интересно, будут ли они делать релиз с фиксом , макпыф (ok), 09:24 , 17-Авг-21, (16) –2

Читайте внимательней новость Уже успели опубликовать, отозвать, в релизы не поп, Брат Анон (ok), 12:30 , 18-Авг-21, (138)

что отозвать P S У меня кстати этот выпуск, макпыф (ok), 19:02 , 18-Авг-21, (144)

Значит не надо неофициальные репы в список автообновления добавлять , Брат Анон (ok), 23:37 , 18-Авг-21, (146)

Вы о чем у меня на LFS ни каких репов нету И тем более автообновления, макпыф (ok), 08:34 , 19-Авг-21, (148) +2

Тогда указанная версия к вам не могла попасть Что-то вы путаете , Брат Анон (ok), 09:13 , 19-Авг-21, (149)

Это вы что то путаете Она попала также как и все пакеты configure make make i, макпыф (ok), 11:24 , 19-Авг-21, (150) –1

яснопонятно , Брат Анон (ok), 11:36 , 19-Авг-21, (151) +1

Резко зауважал , Какаянахренразница (ok), 19:49 , 19-Авг-21, (156) +1

Используйте musl дистрибутивы и будет вам щастье , Разбойник (?), 09:30 , 17-Авг-21, (18) –10

Ты сам пробовал их использовать Они тормозят, как удолбанный джа-будда Ради ин, hefenud (ok), 09:46 , 17-Авг-21, (22) +11

Попробуй поставить jemalloc и добавить ее LD_PRELOAD , Аноним (30), 09:47 , 17-Авг-21, (24) +1

171 А вы на шкаф залезьте 187 старый анекдотНу и смысл тогда юзать musl, ес, hefenud (ok), 12:01 , 17-Авг-21, (62) +3

Брехун, нормально они работают , Разбойник (?), 10:04 , 17-Авг-21, (34) –5

Смотря что считать нормальной работой Лично когда-то наступил на баг, когда н, YetAnotherOnanym (ok), 10:22 , 17-Авг-21, (38) +1

У меня под Alpine работает всё, что только можно сервера, почтовики, базы данны, Разбойник (?), 10:45 , 17-Авг-21, (40) –4

ЛПП, системда отлично работает с musl, если отключить NSS-специфичные фишки И, к, Аноним (30), 10:51 , 17-Авг-21, (42)

Не работает , Разбойник (?), 10:56 , 17-Авг-21, (45) –1
Ответ КО Проприетарщина под EULA , Аноним (70), 13:39 , 17-Авг-21, (81) –1

Извините за оффтоп Раз у Вас так много на Alpine работает, значит знаете ее вдо, Аноним (55), 11:59 , 17-Авг-21, (61) +3

Я очень давно не использовал самба, на алпайн вообще ни разу Но вообще в твоей , Разбойник (?), 13:00 , 17-Авг-21, (69) –5

А другие сетевые ФС Вроде как этот случай относится ко всем автомонтируемым с, Аноним (55), 14:40 , 17-Авг-21, (95) +1

С NFS подобных проблем не наблюдалось , Разбойник (?), 14:57 , 17-Авг-21, (101) –1

Спасибо, Аноним (55), 16:44 , 17-Авг-21, (113) –1

Узнайте от какого пакета у вас umount https pkgs alpinelinux org contents fil, дохтурЛол (?), 13:21 , 17-Авг-21, (73)

У меня не edge, у меня стабильная пакетная база 3 14, но та же фигня была и в 3, Аноним (55), 14:12 , 17-Авг-21, (90)

Раз релиз - значит и правда util-linux Чтоб убедиться, что точно не busybox - по, дохтурЛол (?), 19:00 , 17-Авг-21, (120)

Обычно люди просто предполагают, что malloc работает быстро Это так для glibc, Аноним (30), 10:47 , 17-Авг-21, (41) +3

Зачем тогда нужна стандартная библиотека musl, если пользоваться ей все равно не, Dzen Python (ok), 11:27 , 17-Авг-21, (52)

Так хипстоподелку впихнули, например, в OpenWRT , Аноним (70), 13:32 , 17-Авг-21, (79)

musl известен тем, что там даже в printf ухитрились переполнение сделать Про т, Аноним (30), 09:46 , 17-Авг-21, (23) +4

Почему даже Принтф довольно сложная функция , Аноним (107), 15:54 , 17-Авг-21, (107)

Этой довольно сложной функции уже поди лет 40 И до сих пор допускать в реализац, Брат Анон (ok), 12:33 , 18-Авг-21, (139) +1

ухты, релиз новой версии уязвимости , Аноним (28), 09:53 , 17-Авг-21, (28) +4
Я ж говорил, старые исправили, новые добавили Главная цель кодирования Зато к, Ананоним (?), 10:01 , 17-Авг-21, (32) +1
Мда, печально Но вот от таких ошибок как раз Rust спасает по-умолчанию нет ник, freecoder (ok), 10:58 , 17-Авг-21, (46) +2

Ансейф в расте очень сложен к проверке корректности Обычно если ты пишешь ансей, Аноним зеленый (?), 11:12 , 17-Авг-21, (47) +2
Ну спасает твой раст а в C их вообще нет Будем дальше ржавное Г вно прот, Gogi (??), 12:25 , 17-Авг-21, (66) –4

Свистишь анон Есть, проверено лично , Брат Анон (ok), 12:36 , 18-Авг-21, (141) +1

MISRA спасёт, а не этот ваш Хруст , Аноним (70), 13:29 , 17-Авг-21, (78) –2

Кто не хочет гуглить про это мисру - это просто стандарт-пожелание в стиле Прос, Аноним (107), 14:22 , 17-Авг-21, (92) +4
Ага Расскажи это от десятка до сотни трупов на кладбище, которые рассекали на Т, Брат Анон (ok), 12:37 , 18-Авг-21, (142) +1

Может ошибка вообще в том, что он и не должен быть NULL, но по какой-то причине , Аноним (82), 13:40 , 17-Авг-21, (82) –2

ОС проц не будет разбираться что за лох по ту сторону экрана разыменовывает null, Хан (?), 15:17 , 17-Авг-21, (104)
В Rust по-умолчанию все инициализировано и не NULL Если хочется NULL - использу, freecoder (ok), 22:29 , 17-Авг-21, (124)

Печально что кто-то думает что для того чтобы не делать таких ошибок надо брать , Аноним (118), 18:41 , 17-Авг-21, (117) –1
За любое использование unsafe надо избивать палками до посинения А после этого , Брат Анон (ok), 12:36 , 18-Авг-21, (140) +2

В Rust принят другой подход используя unsafe-блок программист должен сам позабо, freecoder (ok), 22:13 , 18-Авг-21, (145)

Это вредная практика Безопасность кода должна быть доказана Программист -- это, Брат Анон (ok), 23:39 , 18-Авг-21, (147)

К сожалению со сторонниками черное-белое и никаких оттенков спорить бесполезно, freecoder (ok), 11:54 , 19-Авг-21, (152) –2

Я топлю не за чёрно-белое А за то, что инструмент должен давать какие-то базо, Брат Анон (ok), 13:42 , 19-Авг-21, (155) +1

Ты это можешь сказать тем, кто продвигает российскую вакцину Или рабское сознан, Аноним (-), 12:21 , 21-Авг-21, (161)

Вы меня с кем-то путаете, уважаемый аноним , Брат Анон (ok), 09:12 , 24-Авг-21, (163)

Вот вам более понятный пример вы доказываете теорему При этом ссылаетесь на др, freecoder (ok), 16:37 , 23-Авг-21, (162)

Вы привели пример, известный в логике, как подмена понятий Всё что вы написал, Брат Анон (ok), 09:15 , 24-Авг-21, (164)

Лучшее - враг хорошего, Аноним (53), 11:28 , 17-Авг-21, (53) +1
Скрыто модератором, Zenitur (ok), 11:55 , 17-Авг-21, (59) –1

Скрыто модератором, Аноним (70), 13:27 , 17-Авг-21, (77)

Вот и выросло поколение ЕГЭ , пишущее программы , Gogi (??), 12:24 , 17-Авг-21, (65) –6

Среди разработчиков Glibc есть хоть один россиянин , Аноним (70), 13:23 , 17-Авг-21, (74) +2

Выпустивший https www opennet ru opennews art shtml num 48009 с час как зашёл , Michael Shigorin (ok), 14:17 , 17-Авг-21, (91) +2

они, конечно же, придумали как кардинально изменить си-туацию даю хинт Dlang, Microsoft GNU Assembly (?), 14:50 , 17-Авг-21, (98) –2

Даю правильный хинт выкидываем весь этот треш в виде go, rust, dlang и прочее и, Аноним (118), 18:39 , 17-Авг-21, (116) –2

И кто заплатит за чтение книжек Заказчику надо здесь и сейчас, потом следующую , Аноним (154), 12:01 , 19-Авг-21, (154)

Надо полагать, что следующее исправление приведёт к ещё большему упрощению краха, joda (?), 15:01 , 17-Авг-21, (102)

Вангую, что абсолютное большинство программистов вообще почти ничерта не знает , Аноним (108), 15:59 , 17-Авг-21, (108) +1

Если не хочешь копаться в особенностях процессора и оси то не стоит связываться , Хан (?), 16:31 , 17-Авг-21, (111) –1
если у меня ничего вышеперечисленного нет - могу ли я стать хорошим системным пр, Аноним (126), 23:50 , 17-Авг-21, (126)

Это необходимое условие, но недостаточное , Аноним (108), 05:28 , 18-Авг-21, (130)

Программист это что-то врожденное , Аноним (132), 08:33 , 18-Авг-21, (132) +1

Зато крестовики уже присобачили борроу чеккер к сиплюсплюшечке https www youtu, Аноним (33), 16:08 , 17-Авг-21, (109)

Когда в появится в стандарте C тогда и говори, Хан (?), 16:32 , 17-Авг-21, (112) –2

О чем с тобой говорить с хрустиком Ты сначала напиши что-нибудь продакшн реди , Аноним (132), 08:33 , 18-Авг-21, (131)

Что плохого в borrow checker e , Аноним (135), 12:22 , 18-Авг-21, (135)

Делает мозги почем зря , Аноним (154), 11:59 , 19-Авг-21, (153)

Хм А в Fedora пока 2 33 Не спешат в таких вопросах , Аноним (-), 08:59 , 18-Авг-21, (133)

Читайте внимательно новость Релиз уже отозван, ни в дин дистр это не попадёт по, Брат Анон (ok), 12:41 , 18-Авг-21, (143)

Чужих процессов не бывает , village_coder (ok), 16:51 , 20-Авг-21, (158)

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

1. "Уязвимось в Glibc, позволяющая вызвать крах чужого процесса" +8 +/–

Сообщение от Аноним (1), 17-Авг-21, 08:52

Призываю в тред всех тех кто отписывался по поводу недавней уязвимости в стандартной библиотеке Go. Расскажите почему "это другое!"

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

3. Скрыто модератором –14 +/–

Сообщение от Аноним (3), 17-Авг-21, 08:53

ты как с двача вышел то? а ну бырсь обратно в /s faggot

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

30. Скрыто модератором –5 +/–

Сообщение от Аноним (30), 17-Авг-21, 09:58

Не раньше, чем вы расскажете стишок про безопасную сишку
*пододвигает табуретку

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

63. Скрыто модератором +5 +/–

Сообщение от Аноним (63), 17-Авг-21, 12:07

А кто и когда топил за безопасность сишки?

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

70. Скрыто модератором +6 +/–

Сообщение от Аноним (70), 17-Авг-21, 13:09

Толко после поэмы про безопастный Rust.

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

71. Скрыто модератором +/–

Сообщение от Аноним (71), 17-Авг-21, 13:15

Только после Элиады о победе языка Си, над Rust.

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

75. Скрыто модератором +3 +/–

Сообщение от Аноним (75), 17-Авг-21, 13:26

Историческая литература в соседнем отделе.

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

7. "Уязвимось в Glibc, позволяющая вызвать крах чужого процесса" +3 +/–

Сообщение от Аноним (7), 17-Авг-21, 08:58

Никто не будет говорить, что "это другое". Во всех языках могут быть уязвимости, во всех процессорах могут быть уязвимости, во всех математических операциях могут быть уязвимости. Просто адепты "безопасных" языков с этим никак смириться не могут и рейдят новости о других "небезопасных" языках. Включите голову немного и исключите из цепочки человек-машина человека - тогда точно никаких узвимостей не будет, я гарантирую это! (ц)

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

17. "Уязвимось в Glibc, позволяющая вызвать крах чужого процесса" +1 +/–

Сообщение от Аноним (17), 17-Авг-21, 09:24

Ты что если перекрыть один из тысячи векторов ошибок язык мгновенно становится безопасными и весь его софт становится безопасным по определению. Кроме сторонних библиотек и стандартных библиотек на этом языке. Но это не язык виноват он же безопасный.

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

29. "Уязвимось в Glibc, позволяющая вызвать крах чужого процесса" +/–

Сообщение от Аноним (30), 17-Авг-21, 09:54

Ну, допустим, три четверти уязвимостей приходятся на этот один из тысячи векторов.

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

33. "Уязвимось в Glibc, позволяющая вызвать крах чужого процесса" –2 +/–

Сообщение от Аноним (33), 17-Авг-21, 10:04

Допустим одна из тысячи уязвимостей приходится на это вектор.

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

39. "Уязвимось в Glibc, позволяющая вызвать крах чужого процесса" +/–

Сообщение от Аноним (30), 17-Авг-21, 10:42

Допустим, еще и 749 тоже. В сумме как раз 750 получается.

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

8. "Уязвимось в Glibc, позволяющая вызвать крах чужого процесса" –2 +/–

Сообщение от another_one (ok), 17-Авг-21, 09:03

Ага, а вы помнити seg fault?!

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

10. "Уязвимось в Glibc, позволяющая вызвать крах чужого процесса" +6 +/–

Сообщение от Аноним (1), 17-Авг-21, 09:08

Хаха, да ладно не будут)
Что же скажет Хан, Урри, Онаним, пох, нах?, стоп, последнего вроде не было...
... приводящей к разыменования указателя NULL ...
> Эпичное смузихлёбство в ретро-академической степени
> оне художнеги, оне так видют.

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

26. "Уязвимось в Glibc, позволяющая вызвать крах чужого процесса" +6 +/–

Сообщение от Аноним (30), 17-Авг-21, 09:49

Им пофиг на glibc, у них systemd32.dll, в которой дыр нет.

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

48. "Уязвимось в Glibc, позволяющая вызвать крах чужого процесса" –2 +/–

Сообщение от Урри (ok), 17-Авг-21, 11:16

Урри скажет, что рукожопы. У Урри его сишный код уже много лет не падал, хотя крутится миллионами копий в продакшене на серверах гугла.
А что?

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

12. "Уязвимось в Glibc, позволяющая вызвать крах чужого процесса" –6 +/–

Сообщение от Онаним (?), 17-Авг-21, 09:10

Потому что сишечки не позиционируют себя как "безопасный езычог".

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

27. "Уязвимось в Glibc, позволяющая вызвать крах чужого процесса" –3 +/–

Сообщение от Аноним (30), 17-Авг-21, 09:51

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

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

43. "Уязвимось в Glibc, позволяющая вызвать крах чужого процесса" +/–

Сообщение от Аноним (30), 17-Авг-21, 10:54

>  Потому что сишечки не позиционируют себя как "безопасный езычог".
Так и хруст не позиционируется как супербезопасный. Он позиционируется как нормальный. Как Go, Java, Erlang и множество других, менее распространённых языков. Содержание уязвимостей не более 5% объёма.
А вот C и C++ позиционируются как ультрасупердырявые языки, состоящие из дыр на 95%, и любой нетривиальный код на них будет содержать как минимум одну дыру.

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

72. "Уязвимось в Glibc, позволяющая вызвать крах чужого процесса" +/–

Сообщение от Аноним (70), 17-Авг-21, 13:17

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

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

157. "Уязвимось в Glibc, позволяющая вызвать крах чужого процесса" +/–

Сообщение от Онаним (?), 20-Авг-21, 00:02

Нормальный? С таким синтаксисом? Хера себе у вас нормальность.
C позиционируется как язык, на котором можно с машиной делать практически всё.
Поэтому "обизянпасность" там конечно требует сурового подхода, а фактор человеческий значит очень многое. С другой стороны, то, что можно на сях (ядрышко например) - на хрусте разве что через жопу, и то не факт, что вообще работать будет.

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

15. "Уязвимось в Glibc, позволяющая вызвать крах чужого процесса" –2 +/–

Сообщение от Аноним (17), 17-Авг-21, 09:22

В про то что была уязвимость и твоём святом растике, ты не написал. Какой же ты смешной)

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

19. "Уязвимось в Glibc, позволяющая вызвать крах чужого процесса" +3 +/–

Сообщение от Аноним (1), 17-Авг-21, 09:30

А на раст мне пофиг - я на нем не пишу. У Го нет такого пункта в продвижении как "супербезопасный язык".
Но раз ты уже вспомнил раст, то да, на нем разыменовать NULL тоже бы не получилось.

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

44. "Уязвимось в Glibc, позволяющая вызвать крах чужого процесса" –1 +/–

Сообщение от Аноним (30), 17-Авг-21, 10:55

> У Го нет такого пункта в продвижении как "супербезопасный язык".
Ну, все более-менее в курсе, что там нельзя просто взять и переполнить буфер.
А это уже повод для ненависти.

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

49. "Уязвимось в Glibc, позволяющая вызвать крах чужого процесса" –1 +/–

Сообщение от Dzen Python (ok), 17-Авг-21, 11:18

Легко и просто.
Сишники, пишущие либси:
а) не орут на каждом углу, что борроу чекер и анальные ограничения вне блоков unsafe есть какая-то панацея "от всего".
б) понимают, что поломать можно даже полную ява-виртуалку без инвоков внешнего бинарного кода, была бы критическая кривизна рук.
в) просто правят баги, живущие в коде у КРУПНОГО ЫНТЫРПРАЙСА (привет, шиндошвс), на который молятся молодые хрустикофанатики, десятилетиями.
В отличие от них, молодое хрустопоколение смуззихрустиков:
а) Возводит в фичи языка умственные костыли.
б) Набегает на новости про ошибки, правленные сишниками.
в) Травит создателей своих же библиотек за "неоправданное" (по мнению ребёнка с подкатанными штанишками, естессно) использование ансейфа в критичных по времени операциях
и при этом
г) Устраивает лютую, дикую истерику пятилетнего малыша, когда у них в стандартном неткоде нашли факап, достойный первокура провинциальной россеянской ит-шараги.

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

58. "Уязвимось в Glibc, позволяющая вызвать крах чужого процесса" +4 +/–

Сообщение от Аноним (1), 17-Авг-21, 11:49

> г) ...в стандартном неткоде нашли факап, достойный первокура провинциальной россеянской ит-шараги
ну допустим...
а не проверять на NULL перед разыменованием это чей уровень?
чуваков которые пишут либу для миллиардов устройств?
или студня которого отчислили после первой сессий?
или чувака из пту который прочитал книгу "C for dummies", правда бухой и не до конца?
Это ошибка уровня перепутать педали в авто.

PS
а) это орут только упоротые сишники не знающие матчасть, поэтому в каждой теме приходится давать ссылки от чего конкретно защищает borrow checker
б) пфф, это все знаю. просто где-то это можно делать незаметно для себя и окружающих, а где-то придется постараться и написать что-то вроде mem::forget
в) вы хотя бы в теме разобрались - его не за ансейф "травили" (хаха, травили, неженка какой нашелся, может пойти поплакаться своему психиатру), а за то что он по сути насpал в коде, а сверху прикрыл ковриком чтобы видно не было.

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

97. "Уязвимось в Glibc, позволяющая вызвать крах чужого процесса" +1 +/–

Сообщение от Аноним (-), 17-Авг-21, 14:48

>> уязвимости в стандартной библиотеке Go.
>> Go
> а) не орут на каждом углу, что борроу чекер и анальные ограничения вне блоков unsafe
> молодые хрустикофанатики, десятилетиями.
> В отличие от них, молодое хрустопоколение смуззихрустиков:
В принципе, достаточно, чтобы составить мнение о "квалификации" очередного "оналитега" (о том, что очередной Эксперд ни на сишке, ни растишке ничего не пишет, можно догадаться из контекста).
ЗЫ:
Еще пару раз напиши, кто именно истерику устраивает и в какие новости набегает, чтобы точно-точно никто не перепутал :)

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

118. "Уязвимось в Glibc, позволяющая вызвать крах чужого процесса" +1 +/–

Сообщение от Аноним (118), 17-Авг-21, 18:49

> Легко и просто.
> Сишники, пишущие либси:
...
Это шикарно!!! Снимаю шляпу. Молодец, красиво и верно. Я даже себе запишу.

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

125. "Уязвимось в Glibc, позволяющая вызвать крах чужого процесса" +3 +/–

Сообщение от freecoder (ok), 17-Авг-21, 22:55

> в) Травит создателей своих же библиотек за "неоправданное" (по мнению ребёнка с подкатанными штанишками, естессно) использование ансейфа в критичных по времени операциях
Ну вы же ничего не знаете о той ситуации и делаете прямо противоположные реальности выводы. А я вам расскажу, что случилось: Николай написал unsafe-код в недрах библиотеки actix-web так, что появилась возможность триггерить UB из пользовательского safe-кода! И что должно было сообщество сделать, когда в самом популярном веб-фреймворке есть такое? Стали обсуждать и предлагать патчи. А Николай взял, и удалил обсуждения. Дескать, это его сервер для рекордов, он должен быть супер-быстрым и ему плевать, что пользовательский safe-код будет время от времени приводить к UB. Ну, кто-то ему в комментариях написал, что с таким отношением к unsafe и UB Rust не для него. Николай тут же взял и удалил репозиторий с проектом, а потом написал, что уходит из Open Source.
Вообще, вся эта ситуация крайне странная. Николай вел себя очень истерично, хотя дискуссия в целом была довольно мирная (есть отзеркаленные треды обсуждений, которые Николай потер). Кроме того, не надо забывать, что Николай работает в security-подразделении MS. Может быть он так и планировал - оставить бэкдор в библиотеке, которая станет стандартом де-факто в экосистеме Раста. А тут спалился. Поднял истерику, чтобы отвлечь внимание от настоящей проблемы - и это сработало. Вот вы, например, повелись на этот шум.
Сообщество же сработало очень четко и максимально корректно. Никакой травли не было, Николая уговаривали остаться. Даже движение в поддержку его пошатнувшейся психики организовали, и открытое письмо - мол, мы тебя любим, вернись. Но UB все равно требовалось убрать. В итоге actix-web был восстановлен и передан другому мейнтейнеру, а Николай начал свой новый личный рекордный проект, который делает уже от своего имени и не позиционирует его как проект сообщества. Все встало на свои места.

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

134. "Уязвимось в Glibc, позволяющая вызвать крах чужого процесса" +/–

Сообщение от Брат Анон (ok), 18-Авг-21, 12:21

Мне как пользователи софта вообще накласть, что дам думают сишники и иже с ними. Я вижу сегфолты, уязвимости и падения прикладнух. Если это сишники победить не могут, а я теряю данные -- я не хочу, чтобы мой софт писали на си, я не хочу, чтобы каждый божий день постили новости об очередном CVE.
От того, что кто-то передо мной кто-то непрерывно годами повторяет "халва" -- от этого у меня халва не появится.

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

55. "Уязвимось в Glibc, позволяющая вызвать крах чужого процесса" +5 +/–

Сообщение от Аноним (55), 17-Авг-21, 11:36

Кстати, там и в самом деле другое, причем как раз еще больше _не_ в пользу сишечки и повышает в рейтинге нужности раст с го. В расте/го какие-то ленивые балбесы поленились правильно, "с точностью до буквы", стандарт закодить (или логическая ошибка бизнес-логики),а в данном случае - разыменование NULL-указателя, чего в расте в Safe-mode не сделаешь. Еще один жирный плюс в копилку раста/го. Т.е в раст-программе, при условии Safe-mode, присутствуют логические ошибки бизнес-логики, а в сишечке - и логические ошибки бизнес-логики и ошибки программирования типа этой и ей подобных, коих по статистике 70%.

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

96. "Уязвимось в Glibc, позволяющая вызвать крах чужого процесса" –3 +/–

Сообщение от Аноним (96), 17-Авг-21, 14:47

> > Уязвимось в Glibc, позволяющая вызвать крах чужого процесса
> Расскажите почему "это другое!"
Потому что есть такое понятие как дискретный контроль доступа (DAC) и в некоторых GNU/Linux дистрибутивах, использующих технологии YAMA или CONFIG_GRKERNSEC_PROC технологии DAC распространяются на процессы в памяти и процесс не имеет доступа к процессам других пользователей, а при жестких настройках YAMA нет доступа даже к процессам того же пользователя.

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

136. "Уязвимось в Glibc, позволяющая вызвать крах чужого процесса" +1 +/–

Сообщение от Брат Анон (ok), 18-Авг-21, 12:27

Вы новость прочитали? ПРОЦЕССЫ ПАДАЮТ!!
И меня как пользователя совершенно не устраивает ситуация: я два часа набирал бесценную хайку, а тут внезапно текстовый редактор сложился без объяснений, потому что зачесалась левая пятка правой ноги.

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

128. "Уязвимось в Glibc, позволяющая вызвать крах чужого процесса" –2 +/–

Сообщение от Аноним (128), 18-Авг-21, 01:32

Го это си для вебмакак. Они одинаковы.

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

2. "Уязвимось в Glibc, позволяющая вызвать крах чужого процесса" –6 +/–

Сообщение от Аноним (3), 17-Авг-21, 08:52

Лол, хорошо что успеши обнаружить
арчегосподин с 2.33 версия гну библеотек

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

9. "Уязвимось в Glibc, позволяющая вызвать крах чужого процесса" –6 +/–

Сообщение от Аноним (9), 17-Авг-21, 09:05

> успеши
так торопился упомянуть любимый рачик, что и на подсветку орфографии не обратил внимание? лол
з.ы. вижу корень "арч" — сразу минусую

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

11. "Уязвимось в Glibc, позволяющая вызвать крах чужого процесса" –5 +/–

Сообщение от Аноним (3), 17-Авг-21, 09:09

Не спал долго просто, а што? чем тебе рач не нравиться?
ниасилил, да?

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

13. "Уязвимось в Glibc, позволяющая вызвать крах чужого процесса" –3 +/–

Сообщение от макпыф (ok), 17-Авг-21, 09:16

возможно не осилить pacman -S base ?

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

14. "Уязвимось в Glibc, позволяющая вызвать крах чужого процесса" –3 +/–

Сообщение от Аноним (3), 17-Авг-21, 09:21

Исходя из того количетсво пользователей что сидят на бомжару, думаю что да
мимоАрче+и3вмГосподин

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

89. "Уязвимось в Glibc, позволяющая вызвать крах чужого процесса" –1 +/–

Сообщение от Michael Shigorin (ok), 17-Авг-21, 14:08

> чем тебе рач не нравиться?
Мне вот -- невменяемостью рачешкольников любого возраста, пытающихся впарить ЭТО невзирая ни на что и тем напоминающих когда иеговистов, когда канадских мальчиков или MLM-щиков.
А вики у арча хорошая, молодцы (пока гентушники свою непроэтсамое, хорошая была у них). :-)

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

99. "Уязвимось в Glibc, позволяющая вызвать крах чужого процесса" +/–

Сообщение от Аноним (96), 17-Авг-21, 14:51

>  (пока гентушники свою непроэтсамое, хорошая была у них). :-)
Гентушникам не только вики потеряли, а и сами цели дистра поменяли. Генто сегодня и 10 лет назад это две большие разницы.

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

121. "Уязвимось в Glibc, позволяющая вызвать крах чужого процесса" –1 +/–

Сообщение от Аноним (-), 17-Авг-21, 19:02

Михаил, раб божий, Вы то, что этом треде потеряли. Лучше идите домой.

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

123. "Уязвимось в Glibc, позволяющая вызвать крах чужого процесса" –2 +/–

Сообщение от Аноним (123), 17-Авг-21, 21:42

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

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

127. "Уязвимось в Glibc, позволяющая вызвать крах чужого процесса" +1 +/–

Сообщение от Аноньимъ (ok), 17-Авг-21, 23:52

Я бы то же обмазывался бы будь они у меня.
Архитектура интересная, и духовная.

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

160. "Уязвимось в Glibc, позволяющая вызвать крах чужого процесса" +/–

Сообщение от муу (?), 20-Авг-21, 19:12

а вам мне напоминает некого свидетеля альта который тут во всех трэдах по поводу и без оный альт упоминает?

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

100. "Уязвимось в Glibc, позволяющая вызвать крах чужого процесса" +6 +/–

Сообщение от анонн (ok), 17-Авг-21, 14:51

> чем тебе рач не нравиться?
Первым пунктом из свода правил Арчеводов: "Сообщи всем, что у тебя Арч!"

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

5. "Уязвимось в Glibc, позволяющая вызвать крах чужого процесса" +8 +/–

Сообщение от Какаянахренразница (ok), 17-Авг-21, 08:56

Пытались пофиксить одну дыру и в процессе создали другую побольше. Это бывает. Сам так делал.

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

137. "Уязвимось в Glibc, позволяющая вызвать крах чужого процесса" +2 +/–

Сообщение от Брат Анон (ok), 18-Авг-21, 12:29

Ктулху фтанг!

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

6. "Уязвимось в Glibc, позволяющая вызвать крах чужого процесса" +6 +/–

Сообщение от Stanislav (??), 17-Авг-21, 08:58

Мда...
"Поспешное исправление ошибки - лучший способ сделать новую."

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

80. "Уязвимось в Glibc, позволяющая вызвать крах чужого процесса" –3 +/–

Сообщение от Аноним (70), 17-Авг-21, 13:33

Ну да, not a bug, конечно, лучше.

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

16. "Уязвимось в Glibc, позволяющая вызвать крах чужого процесса" –2 +/–

Сообщение от макпыф (ok), 17-Авг-21, 09:24

интересно, будут ли они делать релиз с фиксом?

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

138. "Уязвимось в Glibc, позволяющая вызвать крах чужого процесса" +/–

Сообщение от Брат Анон (ok), 18-Авг-21, 12:30

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

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

144. "Уязвимось в Glibc, позволяющая вызвать крах чужого процесса" +/–

Сообщение от макпыф (ok), 18-Авг-21, 19:02

что отозвать?
> присутствует в выпуске 2.34
P.S. У меня кстати этот выпуск

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

146. "Уязвимось в Glibc, позволяющая вызвать крах чужого процесса" +/–

Сообщение от Брат Анон (ok), 18-Авг-21, 23:37

> что отозвать?
>> присутствует в выпуске 2.34
> P.S. У меня кстати этот выпуск
Значит не надо неофициальные репы в список автообновления добавлять.

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

148. "Уязвимось в Glibc, позволяющая вызвать крах чужого процесса" +2 +/–

Сообщение от макпыф (ok), 19-Авг-21, 08:34

Вы о чем? у меня на LFS ни каких репов нету. И тем более автообновления

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

149. "Уязвимось в Glibc, позволяющая вызвать крах чужого процесса" +/–

Сообщение от Брат Анон (ok), 19-Авг-21, 09:13

> Вы о чем? у меня на LFS ни каких репов нету. И
> тем более автообновления
Тогда указанная версия к вам не могла попасть. Что-то вы путаете.

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

150. "Уязвимось в Glibc, позволяющая вызвать крах чужого процесса" –1 +/–

Сообщение от макпыф (ok), 19-Авг-21, 11:24

Это вы что то путаете.
Она попала также как и все пакеты. ./configure make make install

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

151. "Уязвимось в Glibc, позволяющая вызвать крах чужого процесса" +1 +/–

Сообщение от Брат Анон (ok), 19-Авг-21, 11:36

> Это вы что то путаете.
> Она попала также как и все пакеты. ./configure make make install
#яснопонятно.

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

156. "Уязвимось в Glibc, позволяющая вызвать крах чужого процесса" +1 +/–

Сообщение от Какаянахренразница (ok), 19-Авг-21, 19:49

> у меня на LFS
Резко зауважал.

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

18. "Уязвимось в Glibc, позволяющая вызвать крах чужого процесса" –10 +/–

Сообщение от Разбойник (?), 17-Авг-21, 09:30

Используйте musl дистрибутивы и будет вам щастье.

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

22. "Уязвимось в Glibc, позволяющая вызвать крах чужого процесса" +11 +/–

Сообщение от hefenud (ok), 17-Авг-21, 09:46

Ты сам пробовал их использовать? Они тормозят, как удолбанный джа-будда. Ради интереса пробовал Void и Alpine ставить в качестве десктопных в виртуалку. Вот Ubuntu/Debian в такой же виртуалке прекрасно работает, а муслевые тормозят, что капец. И это я молчу про то, что далеко не всякий софт у тебя вообще в них заведется

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

24. "Уязвимось в Glibc, позволяющая вызвать крах чужого процесса" +1 +/–

Сообщение от Аноним (30), 17-Авг-21, 09:47

Попробуй поставить jemalloc и добавить ее LD_PRELOAD.

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

62. "Уязвимось в Glibc, позволяющая вызвать крах чужого процесса" +3 +/–

Сообщение от hefenud (ok), 17-Авг-21, 12:01

«А вы на шкаф залезьте!» старый анекдот
Ну и смысл тогда юзать musl, если сверху надо обмазываться костылями?
Пусть себе живет в OpenWRT(если они с него не слезли, не помню уже), а на десктопе останусь на нормальных дистрах с glibc

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

34. "Уязвимось в Glibc, позволяющая вызвать крах чужого процесса" –5 +/–

Сообщение от Разбойник (?), 17-Авг-21, 10:04

Брехун, нормально они работают.

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

38. "Уязвимось в Glibc, позволяющая вызвать крах чужого процесса" +1 +/–

Сообщение от YetAnotherOnanym (ok), 17-Авг-21, 10:22

Смотря что считать "нормальной работой". Лично когда-то наступил на баг, когда некий умник завязался на функцию из внутренностей glibc, вместо официально документированной. А в мусле её не было. Вина на авторе прикладухи, но не все готовы копаться в исходниках. Под муслом не работает - виноват мусл, вот и вся логика.

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

40. "Уязвимось в Glibc, позволяющая вызвать крах чужого процесса" –4 +/–

Сообщение от Разбойник (?), 17-Авг-21, 10:45

У меня под Alpine работает всё, что только можно: сервера, почтовики, базы данных, докеры. Да проще сказать, что там не работает. А не работает там только проприетарщина и говнософт по типу системГ. Вот, собственно, и всё.

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

42. "Уязвимось в Glibc, позволяющая вызвать крах чужого процесса" +/–

Сообщение от Аноним (30), 17-Авг-21, 10:51

ЛПП, системда отлично работает с musl, если отключить NSS-специфичные фишки.
И, кстати, что больше проприетарщина - системда под LGPL, или musl под MIT?

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

45. "Уязвимось в Glibc, позволяющая вызвать крах чужого процесса" –1 +/–

Сообщение от Разбойник (?), 17-Авг-21, 10:56

Не работает.

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

81. "Уязвимось в Glibc, позволяющая вызвать крах чужого процесса" –1 +/–

Сообщение от Аноним (70), 17-Авг-21, 13:39

Ответ КО: Проприетарщина под EULA.

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

61. "Уязвимось в Glibc, позволяющая вызвать крах чужого процесса" +3 +/–

Сообщение от Аноним (55), 17-Авг-21, 11:59

Извините за оффтоп. Раз у Вас так много на Alpine работает, значит знаете ее вдоль и поперек, со всеми прибабахами и возможно сталкивались с одной мелкой проблемой. Нужен совет. Не троллю, реально нужно, столкнулся. Проблема возникает при завершении работы системы. Для размонтирования SMB-шары там в скрипте netmount (/etc/init.d/netmount), засунутого в запуск в уровень default, в функции остановки системы выполняется команда:
umount -a -O _netdev
Ну, типа размонтировать все файловые системы, которые завязаны на сеть (_netdev).
Так вот, выбивает в этом месте ошибку, про неверный флаг -O. Гугление дало ответ, что вроде как busybox не поддерживает этот флаг (забавно, как это мэйнтейнеры такого не ловили, там же все сетевые ФС аффектятся). Временно, как залипуху, убрал из строчки этот флаг вместе с _netdev и заменил на что-то типа "... -t smb(или cifs),nfs,...", вроде отрабатывает без ошибок, но хотелось бы правильного решения. Сталкивались?

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

69. "Уязвимось в Glibc, позволяющая вызвать крах чужого процесса" –5 +/–

Сообщение от Разбойник (?), 17-Авг-21, 13:00

Я очень давно не использовал самба, на алпайн вообще ни разу. Но вообще в твоей проблеме нет ничего удивительного, ведь линукс это тот ещё Франкенштейн, ослеплённый из говна и палок. В любом дистрибутиве что-то да не работает, не совместимо, забагованно и тд.

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

95. "Уязвимось в Glibc, позволяющая вызвать крах чужого процесса" +1 +/–

Сообщение от Аноним (55), 17-Авг-21, 14:40

> Я очень давно не использовал самба, на алпайн вообще ни разу
А другие сетевые ФС? Вроде как этот случай относится ко всем "автомонтируемым" сетевым ФС, в том числе, предполагаю, и к NFS. Вы не использовали в алпайне монтируемые при запуске сетевые ФС?
Команда "umount -a ..." размонтирует все ФС, которые указаны в /etc/mtab (кроме корневой?), а опция "-O _netdev" уточняет что размонтировать надо не все, а только те ФС, которые в fstab имеют опцию "_netdev" (зависимость от сети), которая (опция) означает, что при запуске системы монтироваться эта ФС должна после поднятия сети (размонтируется, очевидно, в обратном порядке). Полагаю, что любая автомонтируемая в алпайне сетевая ФС, наверное и NFS, должна иметь эту опцию.
Ну, раз не использовали, тогда проехали.

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

101. "Уязвимось в Glibc, позволяющая вызвать крах чужого процесса" –1 +/–

Сообщение от Разбойник (?), 17-Авг-21, 14:57

С NFS подобных проблем не наблюдалось.

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

113. "Уязвимось в Glibc, позволяющая вызвать крах чужого процесса" –1 +/–

Сообщение от Аноним (55), 17-Авг-21, 16:44

Спасибо

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

73. "Уязвимось в Glibc, позволяющая вызвать крах чужого процесса" +/–

Сообщение от дохтурЛол (?), 17-Авг-21, 13:21

Узнайте от какого пакета у вас umount: https://pkgs.alpinelinux.org/contents?file=umount&path=&name... (это поиск для edge, у вас может стабильный релиз).
Раз вы почему-то пишете про busybox, то попробуйте вызвать команду не как `umount -a -O _netdev`, а как `\umount -a -O _netdev`.

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

90. "Уязвимось в Glibc, позволяющая вызвать крах чужого процесса" +/–

Сообщение от Аноним (55), 17-Авг-21, 14:12

У меня не edge, у меня стабильная пакетная база (3.14, но та же фигня была и в 3.13 кажись). Там только два пакета:
util-linux
util-linux-bash-completion
что относится, как я понимаю, к одной "логически связанной" группе пакетов (типа как в пакетах "aria2","aria2-bash-completion","aria2-daemon","aria2-doc"... всё связано с aria2).
Так что выходит один-единственный пакет - util-linux. Вероятно, стандартный для Alpine.
> Раз вы почему-то пишете про busybox
Это пишет тот, кто сталкивался с этой проблемой (и она, если я правильно понял, вроде как осталась незакрытой) и википедия: "Alpine Linux —...Основан на musl и BusyBox,..."
> то попробуйте вызвать команду
так это я не ручками вызываю, это в стандартном скрипте netmount стандартного пакета (системы инициализации) openrc. Я предполагал что человек выше с большущим опытом работы наверняка сталкивался с этим (ведь это все монтируемые сетевые ФС тогда "поломаны", а не только SMB) и имеет какое-то стандартное, правильное, решение, а не ручками ломать стандартный скрипт системы инициализации.
А если ручками ломать, то я уже и так поломал. Сейчас не могу проверить, но предложение вызывает удивление - вызов команды внутри тех кавычек запустит что-то другое, что поддерживает  флаг "-O"?
Сейчас еще раз поискал. Ошибка, если я правильно понимаю, открыта 2 года назад и до сих пор не закрыта:
https://gitlab.alpinelinux.org/alpine/aports/-/issues/9923

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

120. "Уязвимось в Glibc, позволяющая вызвать крах чужого процесса" +/–

Сообщение от дохтурЛол (?), 17-Авг-21, 19:00

Раз релиз - значит и правда util-linux.
Чтоб убедиться, что точно не busybox - посмотрите что вернёт `ls -lash $(which umount)`.
`` - это моё обрамление дословных команд для запуска.
Если команда выше не покажет, что umount на самом деле не бинарь от пакета выше, а мягкая ссылка на бизибокс - тогда надо просто это исправить.
А `\umount` - это защита от алиасов, вряд ли защитит от мягкой ссылки на бизибокс.

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

41. "Уязвимось в Glibc, позволяющая вызвать крах чужого процесса" +3 +/–

Сообщение от Аноним (30), 17-Авг-21, 10:47

Обычно люди просто предполагают, что malloc() работает быстро. Это так для glibc, но совсем не так для musl. Поэтому, если нужна хоть какая-то производительность при работе с памятью на musl - просто берём язык с собственным менеджером памяти, который практически не зависит от скорости стандартного аллокатора (Java, Go). Ну или сразу берём в зависимости jemalloc и линкуем с ним.

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

52. "Уязвимось в Glibc, позволяющая вызвать крах чужого процесса" +/–

Сообщение от Dzen Python (ok), 17-Авг-21, 11:27

Зачем тогда нужна стандартная библиотека musl, если пользоваться ей все равно нельзя и нужно линковать внешний jemalloc?
Бред. Как хорошо, что я даже не смотрю на все эти хипстоподелки.

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

79. "Уязвимось в Glibc, позволяющая вызвать крах чужого процесса" +/–

Сообщение от Аноним (70), 17-Авг-21, 13:32

Так хипстоподелку впихнули, например, в OpenWRT.

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

23. "Уязвимось в Glibc, позволяющая вызвать крах чужого процесса" +4 +/–

Сообщение от Аноним (30), 17-Авг-21, 09:46

musl известен тем, что там даже в printf() ухитрились переполнение сделать.
Про тормозной аллокатор вообще молчу.

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

107. "Уязвимось в Glibc, позволяющая вызвать крах чужого процесса" +/–

Сообщение от Аноним (107), 17-Авг-21, 15:54

Почему "даже" ? Принтф довольно сложная функция.

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

139. "Уязвимось в Glibc, позволяющая вызвать крах чужого процесса" +1 +/–

Сообщение от Брат Анон (ok), 18-Авг-21, 12:33

Этой довольно сложной функции уже поди лет 40. И до сих пор допускать в реализации её ошибки -- это уже за гранью добра и зла.

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

28. "Уязвимось в Glibc, позволяющая вызвать крах чужого процесса" +4 +/–

Сообщение от Аноним (28), 17-Авг-21, 09:53

ухты, релиз новой версии уязвимости.

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

32. "Уязвимось в Glibc, позволяющая вызвать крах чужого процесса" +1 +/–

Сообщение от Ананоним (?), 17-Авг-21, 10:01

Я ж говорил, старые исправили, новые добавили. Главная цель кодирования. Зато "кот" всегда нужен.

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

46. "Уязвимось в Glibc, позволяющая вызвать крах чужого процесса" +2 +/–

Сообщение от freecoder (ok), 17-Авг-21, 10:58

Мда, печально. Но вот от таких ошибок как раз Rust спасает: по-умолчанию нет никаких NULL, если нужно отсутствие - используешь Option, который типобезопасен и проверяется компилятором. Конечно, в unsafe при желании можно что угодно разыменовать, но на то он и unsafe, чтобы покрывать 0-1% кода, а не 100%.

$ git clone https://github.com/rust-lang/rust
$ cd rust
$ cargo count --separator , --unsafe-statistics
Gathering information...
         Language    Files  Lines    Blanks  Comments  Code     Unsafe (%)
         --------    -----  -----    ------  --------  ----     ----------
         Rust        6,018  528,510  66,984  133,698   327,792  3,163 (0.96%)
         C           54     9,962    1,445   1,492     7,025    7,025 (100.00%)
         CSS         4      1,266    149     52        1,065
         JavaScript  4      1,118    131     166       821
         Python      31     4,797    843     585       3,369
         C Header    13     1,865    284     585       996      996 (100.00%)
         C++         4      1,611    185     81        1,345    1,345 (100.00%)
         --------    -----  -----    ------  --------  ----     ----------
Totals:              6,128  549,129  70,021  136,659   342,413  12,529 (3.66%)

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

47. "Уязвимось в Glibc, позволяющая вызвать крах чужого процесса" +2 +/–

Сообщение от Аноним зеленый (?), 17-Авг-21, 11:12

Ансейф в расте очень сложен к проверке корректности. Обычно если ты пишешь ансейф значит пытаешься обойти компилятор и тут закрадываются комплексные ошибки. Может их всего и 1% в коде, но ревьюить их надо как будто это 10%

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

66. "Уязвимось в Glibc, позволяющая вызвать крах чужого процесса" –4 +/–

Сообщение от Gogi (??), 17-Авг-21, 12:25

Ну спасает твой раст... а в C# их вообще нет! Будем дальше ржавное Г****вно проталкивать??

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

141. "Уязвимось в Glibc, позволяющая вызвать крах чужого процесса" +1 +/–

Сообщение от Брат Анон (ok), 18-Авг-21, 12:36

Свистишь анон. Есть, проверено лично.

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

78. "Уязвимось в Glibc, позволяющая вызвать крах чужого процесса" –2 +/–

Сообщение от Аноним (70), 17-Авг-21, 13:29

MISRA спасёт, а не этот ваш Хруст.

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

92. "Уязвимось в Glibc, позволяющая вызвать крах чужого процесса" +4 +/–

Сообщение от Аноним (107), 17-Авг-21, 14:22

Кто не хочет гуглить про это мисру - это просто стандарт-пожелание в стиле "Просто не пиши с UB и все. А еще не забывай про статический анализ"
Как глаза мне открыли. Молодцы парни. (сарказм)

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

142. "Уязвимось в Glibc, позволяющая вызвать крах чужого процесса" +1 +/–

Сообщение от Брат Анон (ok), 18-Авг-21, 12:37

Ага. Расскажи это от десятка до сотни трупов на кладбище, которые рассекали на Тойоте Короле.

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

82. "Уязвимось в Glibc, позволяющая вызвать крах чужого процесса" –2 +/–

Сообщение от Аноним (82), 17-Авг-21, 13:40

Может ошибка вообще в том, что он и не должен быть NULL, но по какой-то причине он им стал и часть кода, которая посыпалась, этого и не ожидала. Чем вам поможет в данном случае safe/unsafe, кроме как только замедлит код проверками того, что и не нужно проверять?

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

104. "Уязвимось в Glibc, позволяющая вызвать крах чужого процесса" +/–

Сообщение от Хан (?), 17-Авг-21, 15:17

ОС/проц не будет разбираться что за лох по ту сторону экрана разыменовывает null pointer просто отправит ее в /dev/null с сообщение в консоли RTFM

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

124. "Уязвимось в Glibc, позволяющая вызвать крах чужого процесса" +/–

Сообщение от freecoder (ok), 17-Авг-21, 22:29

В Rust по-умолчанию все инициализировано и не NULL. Если хочется NULL - используется Option, и тогда да, компилятор потребует вставить проверки при использовании. Но точно также Сишный код  должен будет иметь проверки, но компилятор не подскажет где. И нужно будет вставлять лишние проверки, потому что статическими средствами языка невозможно выразить того факта, что объект никогда не должен быть NULL.

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

117. "Уязвимось в Glibc, позволяющая вызвать крах чужого процесса" –1 +/–

Сообщение от Аноним (118), 17-Авг-21, 18:41

Печально что кто-то думает что для того чтобы не делать таких ошибок надо брать какой-то rust.
Для этого вполне достаточно нормального C++ и никакой rust не нужен. И синтаксис нормальный и ошибок таких не будет. И этому уже 100 лет в обед как в современных плюсах этого нет.

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

140. "Уязвимось в Glibc, позволяющая вызвать крах чужого процесса" +2 +/–

Сообщение от Брат Анон (ok), 18-Авг-21, 12:36

За любое использование unsafe надо избивать палками до посинения. А после этого -- уволнять.
На практике unsafe в го начиная с 2014 года не использовал ни разу, потому что это крест сразу на всём безопасном коде.

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

145. "Уязвимось в Glibc, позволяющая вызвать крах чужого процесса" +/–

Сообщение от freecoder (ok), 18-Авг-21, 22:13

В Rust принят другой подход: используя unsafe-блок программист должен сам позаботиться о безопасности кода и о том, что никаких небезопасных операций не просочилось в safe часть языка. В открытых проектах обычно обязательно рядом с unsafe-блокам пишут комментарий с меткой SAFETY, в котором разъясняется, почему именно такое использование небезопасных операций в данном случае безопасно.

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

147. "Уязвимось в Glibc, позволяющая вызвать крах чужого процесса" +/–

Сообщение от Брат Анон (ok), 18-Авг-21, 23:39

> В Rust принят другой подход: используя unsafe-блок программист должен сам позаботиться
> о безопасности кода и о том, что никаких небезопасных операций не
> просочилось в safe часть языка. В открытых проектах обычно обязательно рядом
> с unsafe-блокам пишут комментарий с меткой SAFETY, в котором разъясняется, почему
> именно такое использование небезопасных операций в данном случае безопасно.
Это вредная практика. Безопасность кода должна быть доказана. Программист -- это тупое ленивое животное априрори допускающее ошибки. Не может безопасности на 95%. Либо она 100%, либо 0.
Сегодня хак работает, а завтра поменялся компилятор или платформа и хак внезапно становится брешью в пол забора.

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

152. "Уязвимось в Glibc, позволяющая вызвать крах чужого процесса" –2 +/–

Сообщение от freecoder (ok), 19-Авг-21, 11:54

К сожалению со сторонниками "черное-белое и никаких оттенков" спорить бесполезно. Вас послушаешь, так все равно, 1 уязвимость в программе или 100.
100% безопасность вообще ничто обеспечить не может, как и 100% здоровье. А значит можно "курить, бухать, жрать таблетки - и пох.", я понял вашу идеологию.

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

155. "Уязвимось в Glibc, позволяющая вызвать крах чужого процесса" +1 +/–

Сообщение от Брат Анон (ok), 19-Авг-21, 13:42

> К сожалению со сторонниками "черное-белое и никаких оттенков" спорить бесполезно. Вас послушаешь,
> так все равно, 1 уязвимость в программе или 100.
> 100% безопасность вообще ничто обеспечить не может, как и 100% здоровье. А
> значит можно "курить, бухать, жрать таблетки - и пох.", я понял
> вашу идеологию.
Я топлю не за "чёрно-белое". А за то, что инструмент должен давать какие-то базовые гарантии. А если в какой-то части не может дать -- он должен предупреждать пользователя. И предупреждать так, чтобы отмахнуться от этого предупреждения было невозможно. Либо должна быть нажата кнопка, либо явно проставлен сигнальный маркер, либо что-то ещё. Чтобы в случае погромиста -- если в манифесте объявлен явный запрет на финты ушами -- обойти его не было никакой возможности.
Вы ни черта не поняли из того, что я написал. Если самолёт не прошёл сертификацию -- его нельзя пускать в производство. Если лекарства не прошли клинические испытания -- их нельзя давать людям. Но это не гарантирует, что конкретный сертифицированный самолёт не упадёт, а конкретное лицензированное лекарство у конкретного человека не вызовет анафилактический шок. Именно это я вам  и пытаюсь объяснить: 100% решение может быть, но его априрори надо ДОКАЗЫВАТЬ. Пока не доказано -- оно никак не может быть безопасным/надёжным/гарантированным. В отношении Раста это означает: никакой код код не может на Расте считаться достаточно надёжным, пока это не доказано. Тем более, когда присутствуют блоки unsafe.

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

161. "Уязвимось в Glibc, позволяющая вызвать крах чужого процесса" +/–

Сообщение от Аноним (-), 21-Авг-21, 12:21

>Если лекарства не прошли клинические испытания -- их нельзя давать людям.
Ты это можешь сказать тем, кто продвигает российскую вакцину? Или рабское сознание не позволяет?

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

163. "Уязвимось в Glibc, позволяющая вызвать крах чужого процесса" +/–

Сообщение от Брат Анон (ok), 24-Авг-21, 09:12

>>Если лекарства не прошли клинические испытания -- их нельзя давать людям.
> Ты это можешь сказать тем, кто продвигает российскую вакцину? Или рабское сознание
> не позволяет?
Вы меня с кем-то путаете, уважаемый аноним.

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

162. "Уязвимось в Glibc, позволяющая вызвать крах чужого процесса" +/–

Сообщение от freecoder (ok), 23-Авг-21, 16:37

Вот вам более понятный пример: вы доказываете теорему. При этом ссылаетесь на другие теоремы, уже доказанные, и в процессе доказательства еще выделяете леммы, которые доказываете отдельно. Так вот, есть разница, доказано ли 95% утверждений вашей теоремы или только 5%. Вы этой разницы не видите, но она существенна: зная, что леммы и теоремы, на которые ссылается данная, уже доказаны, вам остается проверить (доказать корректность) только оставшиеся 5% рассуждений, а не доказывать вообще все, что входит в теорему, чего вы в общем случае сделать просто физически не сможете.

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

164. "Уязвимось в Glibc, позволяющая вызвать крах чужого процесса" +/–

Сообщение от Брат Анон (ok), 24-Авг-21, 09:15

> а не доказывать вообще все, что входит в теорему, чего вы
> в общем случае сделать просто физически не сможете.
Вы привели пример, известный в логике, как "подмена понятий". Всё что вы написали - -чушь чуть более, чем полностью.
Вот вам пример, на пальцах показывающий, что всё, что вы написали -- чушь. Есть в математике число "пи". Человечество научилось выражать эту вполне конкретную математическую величину в виде символа "пи". Попробуйте на практике с такой же математической точностью выразить символ "пи" в двоичном представлении. Вперде!

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

53. "Уязвимось в Glibc, позволяющая вызвать крах чужого процесса" +1 +/–

Сообщение от Аноним (53), 17-Авг-21, 11:28

Лучшее - враг хорошего

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

59. Скрыто модератором –1 +/–

Сообщение от Zenitur (ok), 17-Авг-21, 11:55

Это американские шпионы добавили, чтобы очернить наш любимый Glibc, когда тот решил стать более независимым.

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

77. Скрыто модератором +/–

Сообщение от Аноним (70), 17-Авг-21, 13:27

Вот, как раз, наоборот, он решил стать более зависимым от копрорастов.

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

65. "Уязвимось в Glibc, позволяющая вызвать крах чужого процесса" –6 +/–

Сообщение от Gogi (??), 17-Авг-21, 12:24

Вот и выросло "поколение ЕГЭ", пишущее программы!

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

74. "Уязвимось в Glibc, позволяющая вызвать крах чужого процесса" +2 +/–

Сообщение от Аноним (70), 17-Авг-21, 13:23

Среди разработчиков Glibc есть хоть один россиянин?

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

91. "Уязвимось в Glibc, позволяющая вызвать крах чужого процесса" +2 +/–

Сообщение от Michael Shigorin (ok), 17-Авг-21, 14:17

Выпустивший https://www.opennet.dev/opennews/art.shtml?num=48009 с час как зашёл в офис, пообщались с ещё одним участником разработки glibc, ну а третий попозже обычно приходит.
git clone https://sourceware.org/git/glibc.git
cd glibc
git checkout release/2.34/master
git log --author=@altlinux.org | grep ^Author | sort | uniq -c
     55 Author: Dmitry V. Levin <ldv@altlinux.org>
      3 Author: Gleb Fotengauer-Malinovskiy <glebfm@altlinux.org>
      1 Author: Vitaly Chikunov <vt@altlinux.org>

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

98. "Уязвимось в Glibc, позволяющая вызвать крах чужого процесса" –2 +/–

Сообщение от Microsoft GNU Assembly (?), 17-Авг-21, 14:50

они, конечно же, придумали как кардинально изменить си-туацию? даю хинт: Dlang

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

116. "Уязвимось в Glibc, позволяющая вызвать крах чужого процесса" –2 +/–

Сообщение от Аноним (118), 17-Авг-21, 18:39

> они, конечно же, придумали как кардинально изменить си-туацию? даю хинт: Dlang
Даю правильный хинт: выкидываем весь этот треш в виде go, rust, dlang и прочее и начинаем читать книжки.

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

154. "Уязвимось в Glibc, позволяющая вызвать крах чужого процесса" +/–

Сообщение от Аноним (154), 19-Авг-21, 12:01

И кто заплатит за чтение книжек? Заказчику надо здесь и сейчас, потом следующую фичу и побольше и потратить поменьше. Пока ты там читаешь книжки, на Го уже написали три стартапа, два из которых уже закрылись, а ты все еще читаешь.

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

102. "Уязвимось в Glibc, позволяющая вызвать крах чужого процесса" +/–

Сообщение от joda (?), 17-Авг-21, 15:01

Надо полагать, что следующее исправление приведёт к ещё большему упрощению краха чужих процессов. ;-))

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

108. "Уязвимось в Glibc, позволяющая вызвать крах чужого процесса" +1 +/–

Сообщение от Аноним (108), 17-Авг-21, 15:59

Вангую, что абсолютное большинство программистов вообще почти ничерта не знает. И это нормально, потому что у большинства людей есть семья, друзья, хобби - в общем, жизнь. Потому и возникают эксперименты, вроде Rust - чтобы спасать время и личную жизнь программистов, ну или хотя бы попытаться это сделать. Это здорово, что есть люди, готовые всю свою жизнь и время посвятить узкой специализации, но их мало, все такими быть не обязаны и все экономические потребости общества эти люди грудью не закроют.

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

111. "Уязвимось в Glibc, позволяющая вызвать крах чужого процесса" –1 +/–

Сообщение от Хан (?), 17-Авг-21, 16:31

Если не хочешь копаться в особенностях процессора и оси то не стоит связываться с низкоуровневыми языками типа C/C++

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

126. "Уязвимось в Glibc, позволяющая вызвать крах чужого процесса" +/–

Сообщение от Аноним (126), 17-Авг-21, 23:50

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

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

130. "Уязвимось в Glibc, позволяющая вызвать крах чужого процесса" +/–

Сообщение от Аноним (108), 18-Авг-21, 05:28

Это необходимое условие, но недостаточное.

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

132. "Уязвимось в Glibc, позволяющая вызвать крах чужого процесса" +1 +/–

Сообщение от Аноним (132), 18-Авг-21, 08:33

Программист это что-то врожденное.

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

109. "Уязвимось в Glibc, позволяющая вызвать крах чужого процесса" +/–

Сообщение от Аноним (33), 17-Авг-21, 16:08

Зато крестовики уже присобачили борроу чеккер к сиплюсплюшечке https://www.youtube.com/watch?v=Lj1GppqNr8c включили c++ core check из visual studio поигрались и забыли как страшный сон.

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

112. "Уязвимось в Glibc, позволяющая вызвать крах чужого процесса" –2 +/–

Сообщение от Хан (?), 17-Авг-21, 16:32

Когда в появится в стандарте C++ тогда и говори

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

131. "Уязвимось в Glibc, позволяющая вызвать крах чужого процесса" +/–

Сообщение от Аноним (132), 18-Авг-21, 08:33

О чем с тобой говорить с хрустиком? Ты сначала напиши что-нибудь продакшн реди.

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

135. "Уязвимось в Glibc, позволяющая вызвать крах чужого процесса" +/–

Сообщение от Аноним (135), 18-Авг-21, 12:22

Что плохого в borrow checker'e?

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

153. "Уязвимось в Glibc, позволяющая вызвать крах чужого процесса" +/–

Сообщение от Аноним (154), 19-Авг-21, 11:59

Делает мозги почем зря.

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

133. "Уязвимось в Glibc, позволяющая вызвать крах чужого процесса" +/–

Сообщение от Аноним (-), 18-Авг-21, 08:59

Хм. А в Fedora пока 2.33. Не спешат в таких вопросах.

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

143. "Уязвимось в Glibc, позволяющая вызвать крах чужого процесса" +/–

Сообщение от Брат Анон (ok), 18-Авг-21, 12:41

> Хм. А в Fedora пока 2.33. Не спешат в таких вопросах.
Читайте внимательно новость. Релиз уже отозван, ни в дин дистр это не попадёт по определению.

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

158. "Уязвимось в Glibc, позволяющая вызвать крах чужого процесса" +/–

Сообщение от village_coder (ok), 20-Авг-21, 16:51

Чужих процессов не бывает...

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

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

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

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру

1. "Уязвимось в Glibc, позволяющая вызвать крах чужого процесса"	+8 +/–
Сообщение от Аноним (1), 17-Авг-21, 08:52
Призываю в тред всех тех кто отписывался по поводу недавней уязвимости в стандартной библиотеке Go. Расскажите почему "это другое!"
Ответить \| Правка \| Наверх \| Cообщить модератору


	3. Скрыто модератором	–14 +/–
	Сообщение от Аноним (3), 17-Авг-21, 08:53
	ты как с двача вышел то? а ну бырсь обратно в /s faggot
	Ответить \| Правка \| Наверх \| Cообщить модератору


	30. Скрыто модератором	–5 +/–
	Сообщение от Аноним (30), 17-Авг-21, 09:58
	Не раньше, чем вы расскажете стишок про безопасную сишку *пододвигает табуретку
	Ответить \| Правка \| Наверх \| Cообщить модератору


	63. Скрыто модератором	+5 +/–
	Сообщение от Аноним (63), 17-Авг-21, 12:07
	А кто и когда топил за безопасность сишки?
	Ответить \| Правка \| Наверх \| Cообщить модератору


	70. Скрыто модератором	+6 +/–
	Сообщение от Аноним (70), 17-Авг-21, 13:09
	Толко после поэмы про безопастный Rust.
	Ответить \| Правка \| К родителю #30 \| Наверх \| Cообщить модератору


	71. Скрыто модератором	+/–
	Сообщение от Аноним (71), 17-Авг-21, 13:15
	Только после Элиады о победе языка Си, над Rust.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	75. Скрыто модератором	+3 +/–
	Сообщение от Аноним (75), 17-Авг-21, 13:26
	Историческая литература в соседнем отделе.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	7. "Уязвимось в Glibc, позволяющая вызвать крах чужого процесса"	+3 +/–
	Сообщение от Аноним (7), 17-Авг-21, 08:58
	Никто не будет говорить, что "это другое". Во всех языках могут быть уязвимости, во всех процессорах могут быть уязвимости, во всех математических операциях могут быть уязвимости. Просто адепты "безопасных" языков с этим никак смириться не могут и рейдят новости о других "небезопасных" языках. Включите голову немного и исключите из цепочки человек-машина человека - тогда точно никаких узвимостей не будет, я гарантирую это! (ц)
	Ответить \| Правка \| К родителю #1 \| Наверх \| Cообщить модератору


	17. "Уязвимось в Glibc, позволяющая вызвать крах чужого процесса"	+1 +/–
	Сообщение от Аноним (17), 17-Авг-21, 09:24
	Ты что если перекрыть один из тысячи векторов ошибок язык мгновенно становится безопасными и весь его софт становится безопасным по определению. Кроме сторонних библиотек и стандартных библиотек на этом языке. Но это не язык виноват он же безопасный.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	29. "Уязвимось в Glibc, позволяющая вызвать крах чужого процесса"	+/–
	Сообщение от Аноним (30), 17-Авг-21, 09:54
	Ну, допустим, три четверти уязвимостей приходятся на этот один из тысячи векторов.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	33. "Уязвимось в Glibc, позволяющая вызвать крах чужого процесса"	–2 +/–
	Сообщение от Аноним (33), 17-Авг-21, 10:04
	Допустим одна из тысячи уязвимостей приходится на это вектор.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	39. "Уязвимось в Glibc, позволяющая вызвать крах чужого процесса"	+/–
	Сообщение от Аноним (30), 17-Авг-21, 10:42
	Допустим, еще и 749 тоже. В сумме как раз 750 получается.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	8. "Уязвимось в Glibc, позволяющая вызвать крах чужого процесса"	–2 +/–
	Сообщение от another_one (ok), 17-Авг-21, 09:03
	Ага, а вы помнити seg fault?!
	Ответить \| Правка \| К родителю #1 \| Наверх \| Cообщить модератору


	10. "Уязвимось в Glibc, позволяющая вызвать крах чужого процесса"	+6 +/–
	Сообщение от Аноним (1), 17-Авг-21, 09:08
	Хаха, да ладно не будут) Что же скажет Хан, Урри, Онаним, пох, нах?, стоп, последнего вроде не было... ... приводящей к разыменования указателя NULL ... > Эпичное смузихлёбство в ретро-академической степени > оне художнеги, оне так видют.
	Ответить \| Правка \| К родителю #1 \| Наверх \| Cообщить модератору


	26. "Уязвимось в Glibc, позволяющая вызвать крах чужого процесса"	+6 +/–
	Сообщение от Аноним (30), 17-Авг-21, 09:49
	Им пофиг на glibc, у них systemd32.dll, в которой дыр нет.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	48. "Уязвимось в Glibc, позволяющая вызвать крах чужого процесса"	–2 +/–
	Сообщение от Урри (ok), 17-Авг-21, 11:16
	Урри скажет, что рукожопы. У Урри его сишный код уже много лет не падал, хотя крутится миллионами копий в продакшене на серверах гугла. А что?
	Ответить \| Правка \| К родителю #10 \| Наверх \| Cообщить модератору


	12. "Уязвимось в Glibc, позволяющая вызвать крах чужого процесса"	–6 +/–
	Сообщение от Онаним (?), 17-Авг-21, 09:10
	Потому что сишечки не позиционируют себя как "безопасный езычог".
	Ответить \| Правка \| К родителю #1 \| Наверх \| Cообщить модератору


	27. "Уязвимось в Glibc, позволяющая вызвать крах чужого процесса"	–3 +/–
	Сообщение от Аноним (30), 17-Авг-21, 09:51
	Ну, всяко побезопаснее хруста, на котором даже за границы буфера фиг выйдешь.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	43. "Уязвимось в Glibc, позволяющая вызвать крах чужого процесса"	+/–
	Сообщение от Аноним (30), 17-Авг-21, 10:54
	> Потому что сишечки не позиционируют себя как "безопасный езычог". Так и хруст не позиционируется как супербезопасный. Он позиционируется как нормальный. Как Go, Java, Erlang и множество других, менее распространённых языков. Содержание уязвимостей не более 5% объёма. А вот C и C++ позиционируются как ультрасупердырявые языки, состоящие из дыр на 95%, и любой нетривиальный код на них будет содержать как минимум одну дыру.
	Ответить \| Правка \| К родителю #12 \| Наверх \| Cообщить модератору


	72. "Уязвимось в Glibc, позволяющая вызвать крах чужого процесса"	+/–
	Сообщение от Аноним (70), 17-Авг-21, 13:17
	А, ну раз он позиционируется как нормальный, как и множество других, то нах он тогда нужен с его синтаксисом. Есть множество других с более вменяемым синтаксисом.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	157. "Уязвимось в Glibc, позволяющая вызвать крах чужого процесса"	+/–
	Сообщение от Онаним (?), 20-Авг-21, 00:02
	Нормальный? С таким синтаксисом? Хера себе у вас нормальность. C позиционируется как язык, на котором можно с машиной делать практически всё. Поэтому "обизянпасность" там конечно требует сурового подхода, а фактор человеческий значит очень многое. С другой стороны, то, что можно на сях (ядрышко например) - на хрусте разве что через жопу, и то не факт, что вообще работать будет.
	Ответить \| Правка \| К родителю #43 \| Наверх \| Cообщить модератору


	15. "Уязвимось в Glibc, позволяющая вызвать крах чужого процесса"	–2 +/–
	Сообщение от Аноним (17), 17-Авг-21, 09:22
	В про то что была уязвимость и твоём святом растике, ты не написал. Какой же ты смешной)
	Ответить \| Правка \| К родителю #1 \| Наверх \| Cообщить модератору


	19. "Уязвимось в Glibc, позволяющая вызвать крах чужого процесса"	+3 +/–
	Сообщение от Аноним (1), 17-Авг-21, 09:30
	А на раст мне пофиг - я на нем не пишу. У Го нет такого пункта в продвижении как "супербезопасный язык". Но раз ты уже вспомнил раст, то да, на нем разыменовать NULL тоже бы не получилось.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	44. "Уязвимось в Glibc, позволяющая вызвать крах чужого процесса"	–1 +/–
	Сообщение от Аноним (30), 17-Авг-21, 10:55
	> У Го нет такого пункта в продвижении как "супербезопасный язык". Ну, все более-менее в курсе, что там нельзя просто взять и переполнить буфер. А это уже повод для ненависти.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	49. "Уязвимось в Glibc, позволяющая вызвать крах чужого процесса"	–1 +/–
	Сообщение от Dzen Python (ok), 17-Авг-21, 11:18
	Легко и просто. Сишники, пишущие либси: а) не орут на каждом углу, что борроу чекер и анальные ограничения вне блоков unsafe есть какая-то панацея "от всего". б) понимают, что поломать можно даже полную ява-виртуалку без инвоков внешнего бинарного кода, была бы критическая кривизна рук. в) просто правят баги, живущие в коде у КРУПНОГО ЫНТЫРПРАЙСА (привет, шиндошвс), на который молятся молодые хрустикофанатики, десятилетиями. В отличие от них, молодое хрустопоколение смуззихрустиков: а) Возводит в фичи языка умственные костыли. б) Набегает на новости про ошибки, правленные сишниками. в) Травит создателей своих же библиотек за "неоправданное" (по мнению ребёнка с подкатанными штанишками, естессно) использование ансейфа в критичных по времени операциях и при этом г) Устраивает лютую, дикую истерику пятилетнего малыша, когда у них в стандартном неткоде нашли факап, достойный первокура провинциальной россеянской ит-шараги.
	Ответить \| Правка \| К родителю #1 \| Наверх \| Cообщить модератору


	58. "Уязвимось в Glibc, позволяющая вызвать крах чужого процесса"	+4 +/–
	Сообщение от Аноним (1), 17-Авг-21, 11:49
	> г) ...в стандартном неткоде нашли факап, достойный первокура провинциальной россеянской ит-шараги ну допустим... а не проверять на NULL перед разыменованием это чей уровень? чуваков которые пишут либу для миллиардов устройств? или студня которого отчислили после первой сессий? или чувака из пту который прочитал книгу "C for dummies", правда бухой и не до конца? Это ошибка уровня перепутать педали в авто. PS а) это орут только упоротые сишники не знающие матчасть, поэтому в каждой теме приходится давать ссылки от чего конкретно защищает borrow checker б) пфф, это все знаю. просто где-то это можно делать незаметно для себя и окружающих, а где-то придется постараться и написать что-то вроде mem::forget в) вы хотя бы в теме разобрались - его не за ансейф "травили" (хаха, травили, неженка какой нашелся, может пойти поплакаться своему психиатру), а за то что он по сути насpал в коде, а сверху прикрыл ковриком чтобы видно не было.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	97. "Уязвимось в Glibc, позволяющая вызвать крах чужого процесса"	+1 +/–
	Сообщение от Аноним (-), 17-Авг-21, 14:48
	>> уязвимости в стандартной библиотеке Go. >> Go > а) не орут на каждом углу, что борроу чекер и анальные ограничения вне блоков unsafe > молодые хрустикофанатики, десятилетиями. > В отличие от них, молодое хрустопоколение смуззихрустиков: В принципе, достаточно, чтобы составить мнение о "квалификации" очередного "оналитега" (о том, что очередной Эксперд ни на сишке, ни растишке ничего не пишет, можно догадаться из контекста). ЗЫ: Еще пару раз напиши, кто именно истерику устраивает и в какие новости набегает, чтобы точно-точно никто не перепутал :)
	Ответить \| Правка \| К родителю #49 \| Наверх \| Cообщить модератору


	118. "Уязвимось в Glibc, позволяющая вызвать крах чужого процесса"	+1 +/–
	Сообщение от Аноним (118), 17-Авг-21, 18:49
	> Легко и просто. > Сишники, пишущие либси: ... Это шикарно!!! Снимаю шляпу. Молодец, красиво и верно. Я даже себе запишу.
	Ответить \| Правка \| К родителю #49 \| Наверх \| Cообщить модератору


	125. "Уязвимось в Glibc, позволяющая вызвать крах чужого процесса"	+3 +/–
	Сообщение от freecoder (ok), 17-Авг-21, 22:55
	> в) Травит создателей своих же библиотек за "неоправданное" (по мнению ребёнка с подкатанными штанишками, естессно) использование ансейфа в критичных по времени операциях Ну вы же ничего не знаете о той ситуации и делаете прямо противоположные реальности выводы. А я вам расскажу, что случилось: Николай написал unsafe-код в недрах библиотеки actix-web так, что появилась возможность триггерить UB из пользовательского safe-кода! И что должно было сообщество сделать, когда в самом популярном веб-фреймворке есть такое? Стали обсуждать и предлагать патчи. А Николай взял, и удалил обсуждения. Дескать, это его сервер для рекордов, он должен быть супер-быстрым и ему плевать, что пользовательский safe-код будет время от времени приводить к UB. Ну, кто-то ему в комментариях написал, что с таким отношением к unsafe и UB Rust не для него. Николай тут же взял и удалил репозиторий с проектом, а потом написал, что уходит из Open Source. Вообще, вся эта ситуация крайне странная. Николай вел себя очень истерично, хотя дискуссия в целом была довольно мирная (есть отзеркаленные треды обсуждений, которые Николай потер). Кроме того, не надо забывать, что Николай работает в security-подразделении MS. Может быть он так и планировал - оставить бэкдор в библиотеке, которая станет стандартом де-факто в экосистеме Раста. А тут спалился. Поднял истерику, чтобы отвлечь внимание от настоящей проблемы - и это сработало. Вот вы, например, повелись на этот шум. Сообщество же сработало очень четко и максимально корректно. Никакой травли не было, Николая уговаривали остаться. Даже движение в поддержку его пошатнувшейся психики организовали, и открытое письмо - мол, мы тебя любим, вернись. Но UB все равно требовалось убрать. В итоге actix-web был восстановлен и передан другому мейнтейнеру, а Николай начал свой новый личный рекордный проект, который делает уже от своего имени и не позиционирует его как проект сообщества. Все встало на свои места.
	Ответить \| Правка \| К родителю #49 \| Наверх \| Cообщить модератору


	134. "Уязвимось в Glibc, позволяющая вызвать крах чужого процесса"	+/–
	Сообщение от Брат Анон (ok), 18-Авг-21, 12:21
	Мне как пользователи софта вообще накласть, что дам думают сишники и иже с ними. Я вижу сегфолты, уязвимости и падения прикладнух. Если это сишники победить не могут, а я теряю данные -- я не хочу, чтобы мой софт писали на си, я не хочу, чтобы каждый божий день постили новости об очередном CVE. От того, что кто-то передо мной кто-то непрерывно годами повторяет "халва" -- от этого у меня халва не появится.
	Ответить \| Правка \| К родителю #49 \| Наверх \| Cообщить модератору